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