> 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,
You have a very good point here, but is it a realistic one? (stateful thing) Almost every time I have played with things in Javascript -- I run into some hangup with it being implemented differently in different browsers. Course that is always well documented, and easy to find... (being cynical here). But really, its a neat idea -- but the requiring a JS enabled browser seems to open up a *HUGE* can of worms in terms of support and bugs. And I do not consider an exclusive use statement as acceptable, its opposite of what the web is for. (by this I am referring to the ever popular: 'This site requires that you use version XXX of XXX's lastest browser, available for free download at www.xxx.com' ) Plus, it won't work in my favorite browser! (w3m -- a text browser) =-) > 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. I say the line to draw is between 'helpful' and 'required'. If you want to implement some JS that makes navigation / life easier with such a browser -- great, just make it work in case someone has that off as well. (Like the Embperl autogenerated JS for form validation, a nice feature -- but not required). With the plethora of new browsers coming out -- and actually being usable, I just see this problem growing. Your 4th option is slick, but again -- if I found a page using javascript to make hidden additional calls to a site, I would be wary of that site. It seems to scream misuse to me. Again, I may be misguided and unfairly biased -- its just my opinion. > 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. I agree, there has to be better ways. And some of your suggestions seem very interesting (I kind of like the syntax parsing thing you mentioned). I think that is what Embperl was trying to achieve with the new JS form validation stuff. What I try and do is separate out components and put them in their own spaces and use (emb)perl to tie them together. Whether you use modules, or funcions -- its up to you what makes more sense. I know I would confuse the heck outta myself if I had that combo in one object I was trying to debug... After that entire spiel, I think your suggestion for the JS XML-RPC *could* find a useful home in a specific application (say on an intranet that has to do *** easily for so-and-so's secretary to update it, etc). Just my lengthy 1/50th of a dollar. Cameron Cameron --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
