Why not use a little JavaScript client side to populate the list using an "Add" button then send the list to the server when they click "Submit"?
True laziness is hard work
| [reply] |
You'll need to store the array-in-progress somewhere (session, database, hidden DOM elements in your AJAX replies...) because each AJAX transaction is an independent HTTP request, meaning that your environment does not automatically carry over from one to the next.
The basic structure of your AJAX handler, then, will be something along the lines of:
retrieve previous set of values
add new user-submitted value to the set
store new set of values
send an HTML snippet back for CGI::Ajax to insert into the page
If you show some of your current code, we can provide more detailed advice, but perhaps that brief outline will be enough to get you going. | [reply]
[d/l] |
You want to keep state for the session, a logical choice would be CGI::State. There are many ways to keep state (cookies, hidden fields etc.) all have their (dis)advantages. You can also Ajax for keeping state though I'm not sure that is the way to go for you. Where do you want to keep state on the client or on the server?
Cheers
Harry
| [reply] |
My field-experience with helper modules like these has been mixed. They sound helpful, and I am quite sure that they are, in appropriate circumstances, but I consistently find that, if I start out with one of them, I do not finish with any of them. (Let me stress that this is meant as no slight whatsoever either against these packages, nor against their authors!)
Usually, I find that I must knuckle-down and write JavaScript code, using some existing framework or another (Prototype, ExtJS, pick-one...) to do the necessary browser-specific heavy lifting on the client side ... which is now the side where everything that the end-user sees now takes place. The user is no longer talking to “your Perl program,” running on a server someplace. Instead, the user is talking to a JavaScript program running on his or her browser, and it is talking to your Perl program. (Naturally, a CPAN module designed for use with the client-side framework that I have selected is used to decode the request and to encode the response.) The unfortunate consequence of this, is that I am now writing and maintaining two programs, but c’est la guerre.
Again to my way of thinking, the client is not “telling the server to call this-or-that Perl module.” The client is “making a request,” and really doesn’t know or care how the server carries out that request. This is the approach, and the mind-set, that works best for me.
Session-cookies are, of course, fundamental to all HTTP protocols, so every incoming AJAX request will be accompanied by such a cookie (or, equivalently, by an authentication string which your client is obliged to keep and to send with every request). Your server-side code has to validate this string with every request, and then use it to retrieve session-state data from the server-side store that you have made for that purpose.
| [reply] |
