On 16-Apr-2002 Cameron McBride wrote: >> 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' )
Sounds like you read http://www.anybrowser.org/campaign/. > Plus, it won't work in my favorite browser! (w3m -- a text browser) > =-) Well, you *could* give it JavaScript support, using either libjs or JavaScript.pm ;-P > 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. With JavaScript form validation, it's pretty easy to allow browsers with no JS support, or JS turned off, to still be able to submit the form without writing extra code. The JS code just gets ignored. However, with the XML-RPC idea, without JavaScript, the application is dead. Implementing and maintaining a non-RPC and a RPC version would be a lot of extra work. In that case, I'd rather just stick to the non-JS way. > 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. Do you scream misuse, when sites like windowsupdate.microsoft.com use VBScript or ActiveX or whatever's its called to do RPC, without reloading the entire page? > Again, I may be misguided and unfairly biased -- Aren't we all? :-) Do you scream misuse, when sites like windowsupdate.microsoft.com use Visual Basic or ActiveX or whatever's its called to do RPC, without reloading the entire page? > 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... Modules still seem the way to go... I find it easier to keep modules sanely indented and organized, even if they are big. [$ sub foo $] [- $sth=$dbh->prepare() ... ] <table> [$ endsub $] Doesn't scale well... which is where Embperl::Object comes in of course. I found Embperl pretty easy to learn... the problem is not having lots of sophisticated source code to learn from. > 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). I agree, in a controlled or known environment it could be feasable. http://ashleyit.com/rs/jsrs/select/php/select.php This example works fine in IE6 and Mozilla. I was suprised to see Konqueror 3.0.5 not populate it, as KDE3's JavaScript support is getting pretty good. Netscape 4.x didn't like it either, but it is archaic. I haven't found a project to use my ideas on yet though, and probably won't for a while since I'm looking for work. Regards, Wim Kerkhoff -|- www.nyetwork.org -|- [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
