Nope. Most browsers restrict javascript from accessing any site other than the one the javascript was loaded from for security reasons. Additionally, javascript doesn't have any way of unzipping the files itself, AFAIK, and again, it can't access programs on the user's computer for security reasons.
You could fetch it using a server side language, though.
-- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstuck...@attglobal.net ==================
>Nope. Most browsers restrict javascript from accessing any site other >than the one the javascript was loaded from for security reasons. >Additionally, javascript doesn't have any way of unzipping the files >itself, AFAIK, and again, it can't access programs on the user's >computer for security reasons.
>You could fetch it using a server side language, though.
Fetching it server-side would allow the server to retrieve a copy only when it's been updated and then save it in a local format to conserve unpacking and reformatting time, which I think makes it a better approach anyway.
Client-side scripting seems to be going through an "overused new toy" phase. Or maybe that's just my perception, but I get the idea that everyone feels like they have to keep up with the fanciest client-side scripting on the block.
On Thu, 12 Nov 2009 00:35:17 -0700, crankypuss <n...@email.thanks> wrote:
> >You could fetch it using a server side language, though.
> Fetching it server-side would allow the server to retrieve a copy only > when it's been updated and then save it in a local format to conserve > unpacking and reformatting time, which I think makes it a better > approach anyway.
Yes, you're almost certainly right, it's just that I have done lots of client-side scripting, but zilch server-side, so I would have to start from scratch. Probably next thing to look at though.
> Client-side scripting seems to be going through an "overused new toy" > phase. Or maybe that's just my perception, but I get the idea that > everyone feels like they have to keep up with the fanciest client-side > scripting on the block.
Yes, you're right. Never was there a better field for reasonably strict application of Keep It Simple Stupid than web-design.
Client side scripting is good for things like data entry cleanup & control to prevent corrupt data getting back to the server, and specific functionality where needed - I've created satellite dish and tv aerial alignment calculators, a regular expression tester, a slideshow script, data conversion pages, etc, and I have pages where JS is used to hide complexity like mathematics which if desired the user can display by clicking something - but I can't stand visiting hyper-active sites that are always flashing things, popping up windows, animations, etc. The programmers of such sites would usually do better to get the basics right - a colour scheme that is readable and easy on the eyes independently of the user's choice of desktop colours, decent font size, good English with sensible paragraphing, spell-checking, etc - than yet another crash-bang-wallop look-what-I-can-do trick.
Java Jive <j...@evij.com.invalid> wrote: >..., it's just that I have done lots of >client-side scripting, but zilch server-side, so I would have to start >from scratch.
If you're ever going to do something that's beyond what comes "out of the box" you'll need to get involved with some server-side scripting. At some point you started from scratch on client-side, server-side's not really any harder (though debugging can be a pain in the ass), it's only different.
>Client side scripting is good for things like data entry cleanup & >control to prevent corrupt data getting back to the server,
Cleanup yes, control no. If you don't always assume that every piece of data your server receives is absolute garbage sent by some hacker, you're likely to run into trouble whether you're asking for it or not. Any bad data you keep away from your server by depending on client-side scripting, I can put into it by sending the data directly to the server without ever running your client-side code. Don't think that sending the data encrypted makes any difference, if you're depending on client-side validation your server may end up getting securely encrypted garbage.
Client-side scripting is not the place to validate data beyond the aspect of issuing descriptive error messages to help the user. You can pop up cute message boxes, help make things easier for the user, have some kind of mini-app that figures out the data for him, maybe helps with navigation, but all data still needs to be checked when it reaches the server. Client-side scripting is front-end stuff, user-interface enhancements, the minute you start putting functionality into client-side that the server depends on, you're offering yourself up to every hacker on the planet.
> >..., it's just that I have done lots of > >client-side scripting, but zilch server-side, so I would have to start > >from scratch.
> If you're ever going to do something that's beyond what comes "out of > the box" you'll need to get involved with some server-side scripting. > At some point you started from scratch on client-side, server-side's > not really any harder (though debugging can be a pain in the ass), > it's only different.
> >Client side scripting is good for things like data entry cleanup & > >control to prevent corrupt data getting back to the server,
> Cleanup yes, control no. If you don't always assume that every piece > of data your server receives is absolute garbage sent by some hacker, > you're likely to run into trouble whether you're asking for it or not. > Any bad data you keep away from your server by depending on > client-side scripting, I can put into it by sending the data directly > to the server without ever running your client-side code. Don't think > that sending the data encrypted makes any difference, if you're > depending on client-side validation your server may end up getting > securely encrypted garbage.
> Client-side scripting is not the place to validate data beyond the > aspect of issuing descriptive error messages to help the user. You > can pop up cute message boxes, help make things easier for the user, > have some kind of mini-app that figures out the data for him, maybe > helps with navigation, but all data still needs to be checked when it > reaches the server. Client-side scripting is front-end stuff, > user-interface enhancements, the minute you start putting > functionality into client-side that the server depends on, you're > offering yourself up to every hacker on the planet.
|
