2009/3/31 Philip Olson <phi...@roshambo.org>: > >> Even though I don't actively contribute I still hope I can put my 2 cents >> into here: > > Of course, and by posting you are being active :) > >> As far as using a "fancy" looking comment system, I would vote for it. >> Everything is going "web 2.0" with the "ooohhh" and "ahhh"s (gmail is a >> prime example, there are tons of libraries and sample code for Javascript >> effects). Almost every site I visit uses some sort of Javascript or AJAX in >> background (even vBulletin has gone AJAX to some extent). > > Yeah, people almost expect such features these days. > >> I believe that the "fancy" effects will not hinder a system, but actually >> make it easier and more useful for the general person (if its done right!). >> To defend the use of Javascript (and other Javascript-related effects); >> you can always have 2 versions of your site - one for people who have a >> Javascript compatiable browser and the rest who don't. I am 99% sure you can >> detect in some way if the browser does support Javascript or not and serve a >> page appropriately. If anything else I am sure you could analyze the >> user-agent string and determine if its a Javascript capable browser or not. >> But then again this who idea would requre you to keep 2 versions of the >> same site. >
You don't need 2 versions. Even with the most complex of sites, it should be developed without JS initially. You then use unobtrusive JavaScript inclusion to modify the page as appropriate. This technique allows the widest range of clients with the least amount of effort. It is pretty much a given that the user-agent string is useless for anything other than truly rudimentary browser analysis. The browscap.ini file from Gary Keith (http://browsers.garykeith.com/stream.asp?PHP_BrowsCapINI) is fine and dandy but is updated pretty much every week. New user-agent strings are constantly being created. And, having said that, the agent string doesn't actually tell you if JS is supported or enabled. That can only be done on the client. So, "they" say don't bother. Assume it isn't. That way you site works with no special effects, AJAX, etc. Add JS to the mix and its a few form actions overridden, some observers and voila, Web 2.0 in all its glory. > If something is useful, then it's worth doing. Although more effort would be > put into the new system, a fallback to a more basic version is required for > people who simply do not like the new or can't handle it. The logistics of > presenting data between the two systems (as users add data through each) is > one problem, however minor it may seem. > > Oh, and then there is the small [large] task of actually creating and > implementing it... Volunteers? :) But first we need to determine what we > want and need, whereas this discussion has essentially focused on (A) If we > like JS, (B) Not everything handles JS, and (C) The Django book example has > problems. > > Assuming we will implement JavaScript, what do people think about the > original ideas? > I use Prototype/Scriptaculous (both served by Google API, so the more sites that use the Google API cache the better for all). When using AJAX I supply a JS callback (using the JSONP concept) to let server side know the style of call being made. Essentially this means 1 set of HTML/CSS (with or without JS) and 1 set of server side scripts which are told to generate HTML or JSONP output. All the server side logic should be identical and it is just the output that is tuned. > Regards, > Philip > > -- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!"
