Re: Http query variables
Hi Alex, > I would definitely not use +String, to avoid the trouble and cost of > conversions. > > If it is just a list of cons pairs where the CDR parts are atomic, there > is no currently other way than +Any. But if it is of a homogeneous list > structure like > >((key1 "string1" 123) (key2 "string2" 456) ...) > > then thinking about > >(rel xxx (+List +Bag) > ((+Symbol)) # key > ((+String)) > ((+Number) 2) ) thanks for suggestions, Tomas -- UNSUBSCRIBE: mailto:[EMAIL PROTECTED]
Re: Http query variables
Hi Tomas, > One more question;-) If I have an assoc list, what is the best way to > store it in the picolisp database? Using +Any or +String (and > converting it manually)? I would definitely not use +String, to avoid the trouble and cost of conversions. If it is just a list of cons pairs where the CDR parts are atomic, there is no currently other way than +Any. But if it is of a homogeneous list structure like ((key1 "string1" 123) (key2 "string2" 456) ...) then thinking about (rel xxx (+List +Bag) ((+Symbol)) # key ((+String)) ((+Number) 2) ) might be useful. Cheers, - Alex -- UNSUBSCRIBE: mailto:[EMAIL PROTECTED]
Re: Http query variables
Hi Alex, > For this there is another mechanism in '_htSet': If the name does not > start with '*', the corresponding value is stored in the 'http' property > of that symbol. This will avoid conflicts with existing symbols. I'll have a look at that, thanks. > Storing these symbols in '*Allow' is still required, though. Perhaps a > bit paranoid? But your application must know these names in advance > anyway, as it has to process them, so it would not hurt to put them into > '*Allow'. You can also add such symbols with 'allow' dynamically at > runtime. My application does not need to know all of them, just some subset is needed. However, having the list of all received key/value pairs is still useful for logging, for example. One more question;-) If I have an assoc list, what is the best way to store it in the picolisp database? Using +Any or +String (and converting it manually)? Thank you, Tomas -- UNSUBSCRIBE: mailto:[EMAIL PROTECTED]
Re: Http query variables
Hi Tomas, > > Another possibility is to use a separate set of reserved variables, > > and build the association list from their values. > > what do you mean? Well, no special idea ... It could be anything, just to build up an association list. But this is obsolete, as I now understand what the reason of your question is (see below). > I do not want these variables assigned as I do not have under control > what I get on the request (their names, number etc.). It is a 3rd > party protocol and having them on a list would be more suitable than OK, now I see your point. Then using the normal globals won't work anyway, because they are required to have their names start with an asterisk. A 3rd party protocol would probably never use variables line '*Name' or '*Street', but 'name' and 'street'. For this there is another mechanism in '_htSet': If the name does not start with '*', the corresponding value is stored in the 'http' property of that symbol. This will avoid conflicts with existing symbols. > digging through 3rd party API and 'allow'ing long list of variables > that could even clash with picolisp names. Storing these symbols in '*Allow' is still required, though. Perhaps a bit paranoid? But your application must know these names in advance anyway, as it has to process them, so it would not hurt to put them into '*Allow'. You can also add such symbols with 'allow' dynamically at runtime. > > If you have a routine for modifying '_htSet', > > Not sure how that would look like. Maybe modifying @lib/http.l > directly is simpler. Yes, indeed :-) Cheers, - Alex -- UNSUBSCRIBE: mailto:[EMAIL PROTECTED]
Re: Http query variables
Hi Alex, > Another possibility is to use a separate set of reserved variables, > and build the association list from their values. what do you mean? > Why do you not want these variables be assigned? Using such global > variables is the simplest and most efficient solution in most cases. I > do not see a problem with it, as you can control which variables are > used, and thus avoid possible conflicts. I do not want these variables assigned as I do not have under control what I get on the request (their names, number etc.). It is a 3rd party protocol and having them on a list would be more suitable than digging through 3rd party API and 'allow'ing long list of variables that could even clash with picolisp names. > If you have a routine for modifying '_htSet', Not sure how that would look like. Maybe modifying @lib/http.l directly is simpler. Thank you for explanation, Tomas -- UNSUBSCRIBE: mailto:[EMAIL PROTECTED]
Re: Http query variables
Hi Tomas, > if I use 'allowed' in my web application, PicoLisp will assign > variables from QUERY_STRING (if called via GET HTTP method) or the > message body (if POST used). To be precise: This is independent of 'allowed' and '*Allow' (these just inhibit illegal access to the server). > What if I do not want the variables to > be assigned and just want to get an assoc list of these keys/values > instead? This is hard-coded into the server. You could redefine the internal function '_htSet', which receives the variables and values and does the above assignment (as you probably know as you refer to "*HtSet" below). Redefining '_htSet' from the outside (by simply calling (undef '_htSet), followed by (de _htSet (..) ..)) might not work, because then the transient symbol "http" (which is used in the 'throw') cannot be accessed. So it might be necessary to path '_htSet' on the fly. Another possibility is to use a separate set of reserved variables, and build the association list from their values. Why do you not want these variables be assigned? Using such global variables is the simplest and most efficient solution in most cases. I do not see a problem with it, as you can control which variables are used, and thus avoid possible conflicts. > Also, is it possible to combine these cases in one > application, e.g. having different behaviour for different url > handlers? If you have a routine for modifying '_htSet', you could call it in the beginning of some applications, and not call it in others. > What does "*HtSet" do, what is it for and how is it supposed > to be used? The http server handles variables of the form '*Foo(X)' such that it puts the value into an association list in the variable '*Foo', using the key 'X'. This is, for example, used heavily in "lib/form.l" for the '*Gui(N)' components. "*HtSet" contains a list of all such variables, and is used to clear the assoc list when that variable appears for the first time, to avoid adding new values to possibly old ones (remained from a previous request). Cheers, - Alex -- UNSUBSCRIBE: mailto:[EMAIL PROTECTED]
Http query variables
Hi Alex, if I use 'allowed' in my web application, PicoLisp will assign variables from QUERY_STRING (if called via GET HTTP method) or the message body (if POST used). What if I do not want the variables to be assigned and just want to get an assoc list of these keys/values instead? Also, is it possible to combine these cases in one application, e.g. having different behaviour for different url handlers? What does "*HtSet" do, what is it for and how is it supposed to be used? Thank you, Tomas -- UNSUBSCRIBE: mailto:[EMAIL PROTECTED]
