Re: How do I remove unused GET parameters from the URL?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Michael, while i respect your choices, i think you should know that
jquery.com is pretty good at minimizing browser-incompatibility
headaches (and keeping js apps small), and the quircks that are left
are easy enough to learn about.

for things whereby
- the server needs to generate tons of HTML for a small(ish) dataset, or
- the client generates data (also to be translated to html) that the
server doesnt really need to know about (yet)

js can really take some stress off the server.


On Wed, Jan 20, 2010 at 9:31 AM, Michael A. Peters <mpeters@xxxxxxx> wrote:
> Rene Veerman wrote:
>>>
>>> That's how I would do it personally (opposed to js).
>>
>> wtf??!  js = less server stress :)
>>
>
> Many (myself included) surf with script blockers due to XSS and js is more
> difficult to thoroughly test because the implementation is done by browsers
> without a good standards body for validating the the code.
>
> I've run into a couple situations where scripts worked perfectly for me in
> Firefox, Opera, and Konq only to find out they failed in IE either because
> IE did things differently (like attaching events) or something as stupid as
> IE not liking a space that the other browsers worked fine with.
>
> window.open(url,'Download
> Media','width=620,height=200,toolbar=0,location=0,directories=0,menubar=0,resizable=0');
>
> failed in IE because of the space between Download and Media, yet worked in
> all other browsers I tried, and didn't even give a warning in Firefox with
> the firebug plugin.
>
> Thus for me to implement a solution in JavaScript, the testing time goes way
> up because I have to test it in several versions of several different
> browsers.
>
> If I can do it server side, the only issues are CSS and appropriate
> fallbacks for bleeding edge tags (like the html5 tags), but I have to test
> for those anyway so doing it server side doesn't cost me any extra testing
> time and doesn't end up with failures because I didn't test a particular
> version of a particular browser.
>
> Also, by minimizing the JavaScript, I minimize the amount of fallback
> testing I need to still keep viewers who have scripting disabled.
>
> Until there is some kind of a proper standard that the major browser vendors
> adhere to with a validator I can check my JS against that will pretty much
> guarantee any validating JS works in the various browsers, I will continue
> to do stuff server side as much as possible.
>
> I do use JavaScript for things like form validation (validated server side
> as well), upload progress, dynamic select menus where the content of one
> depends upon what was selected in another, etc. - but if I can do it server
> side I do, that's my philosophy. I understand it is a minority philosophy,
> but I get less headaches that way.
>

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux