Re: Error when referencing http_parameters

Anne Ogborn <[email protected]>
Newsgroups gmane.comp.ai.prolog.swi
Message-ID <[email protected]>
I agree - you don't want to force storing POST data.

>An alternative I see to avoid the confusion is to deprecate using
http_parameters/2,3 for POST requests and add
http_read_post_parameters/2,3 to deal with POST request. The `read'
quite clearly indicates that you can do this only once.

How about doing whats convenient for the user in the case where the data's expected to be small?  Add an option to http_parameters/3 keep_post_data
that hangs onto the data until the end of the call. If you call http_parameters/2,3
more than once on a post and haven't put keep_post_data in the first such call,
it throws.
Alternatively, there could be a new http_keep_post_data/0 that must be called before http_parameters/2,3

Then fixing Phillip's problem resolves to a one line change.

My experience writing handlers is that it's far from a strange thing to do to have to have separate handlers depending on some parameters, and want to treat the data differently, when working on consumer facing web pages where one page often has many functions.  For example, a common division is
 not signed in - redirect to login, hanging on to original query to get user back to what they were doing afterwards

user error - entries are invalid, need to display form asking them to modify and resubmit

invalid - can't make sense of this - redirect to a 500 or 404 page

correct - mainline case, which might have multiple handlers depending on a CRUD action.

Whats wrong with good old prolog style is that you need to handle http_parameters failing. e.g. taking your example, if a parameter is expected to be int, and it's not, then we need to redisplay the page with a red box around the entry. In commercial practice, 500 error and a message page isn't acceptable. Syntax checking has to be an idempotent predicate so we can match against multiple cases. Mixing it with a read operation makes that impossible.

I'm generally more a fan of asking 'what is convenient for the user' rather than asking 'how can I make the user do what I want?'
-------------- next part --------------
HTML attachment scrubbed and removed
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.