On 16-Apr-2002 Cameron McBride wrote: >> In a nutshell, create a hidden layer. In that hidden layer, do a >> GET/POST to a embperl/mod_perl page. The request will get sent to the >> hidden in-memory document, which can then be parsed back into javascript >> variables. > > ooo, perhaps there might be valid uses -- but this just feels 'dirty', > no? Crafty stuff to say the least...
I prefer 'crafty' to 'dirty' :-) If a Javascript enabled browser is already a requirement, it's a great way of turning a browser from a stateless machine into a stateful one. For example, think of the common problem, where you have multiple <select>'s on a page. If you want SelectB to change when a different option in SelectA is chosen, you have a couple of options: 1. No Javascript: user must click a "go" or "next" button to re-populate SelectB 2. With simple Javascript: use onChange="document.form.submit()". One lessclick for the user, but still forces a refresh of the entire page. 3. Using lots of perl code, write out several dozen lines of Javascript to create arrays. When SelectA is changed, have it call a function to delete all the options in SelectB, and recreate them using the appropriate array. Coding this is painful! 4. Using something like that JS XML-RPC library, do another request to the server. This request would not be for the entire page, but just new data for SelectB. At first glance, it appears that there would be more load on the server and network. But not really. When reloading the entire page, all the images, stylesheets, are being redownloaded. A lot more code is being run as well. Ie, the database is being accessed to grab the data for SelectA, even though it hasn't changed since the previous request. With caching done at the server, proxy server, and client level it would be nearly invisible to the user yet too. I dunno if this is a new idea, but I've been thinking of setting up a Recipe/Syntax for allowing something like this: Foo: <select name="SelectA" sql="select foo_id as value, desc as name from foo"> Bar: <select name="SelectB" sql="select bar_id as value, price as name from bar" sql_parent="SelectA"> And have the syntax take care of doing the correct database calls, insert the javascript, and so forth. But it needs a lot more thought. Some of the Perl/Embperl code I've written is pretty hairy, just because of intermixing SQL, Embperl, HTML, and Javascript all in the same object. There have got to be better ways that use less code. Regards, Wim Kerkhoff [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
