First, Welcome Bill. I didn't know you were lurking, so I am really glad to see you announce yourself (note to list: I haven't had the pleasure of meeting Bill, but I will never cease to be grateful to him for speaking up for me, a Perl-novice, as the world of Perl was heaving around me.).
Now, allow me to disagree with you by reiterating and agreeing with Mark. On Fri, Mar 5, 2010 at 9:23 PM, Mark Stosberg <[email protected]> wrote: > > Thanks for commenting Bill. > >> > 5. clean URIs (routes) without screwing around with bazillion settings >> >> To me, this seems to be more of a current programming fad than a real >> user issue. I've never had a single user complain that long or ugly >> URIs bothered them. > > Let's look at one: > > /cgi-bin/user.cgi/edit?user_id=23 > > That URL has a lot of junk in it tht is about implementation details > that essentially says "blah blah blah" to the user. This clean version > communicates the essential: > > /user/23/edit > > Users may not complain because they aren't aware there there's any other > way to do it. But presented with the old and new side by side, I think > easy to agree which style is more pleasant to use. > > With some support from your framework, clean URIs are easy to create and > process. Indeed. URIs don't matter if the application is completely database-driven, where the URI itself becomes a proxy for querying the database, or for performing some other complicated task with lots of parameters. For example, if I am querying the Delta Airlines database for flights between 4 points, with variables of flight departure and arrival times, days of week, price points, companion seat availability, etc., then it is expected that the URI will be complicated, and the application interface will be an entry point. However, URIs, and clean URIs, matter greatly when the model is for document retrieval. For example, my website, punkish.org, or any blog for that matter, is primarily a collection of documents representing my thoughts as writings. It is much more logical for me to direct someone to punkish.org/e-Infrastructure-for-Scientific-Data thank to some complicated set of parameters that mean nothing. In fact, I will contend that even in the case of the former, once the results have been got, it is desirable to have a mechanism that allows one user to share that results URI with someone else, just like Google Maps does once you have created your desired map... it has a little widget in the top right that lets you embed or email a link to that map view. It would be nice though if I can email something like http://www.google.com/maps?q=my-work-place instead of http://www.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=1630+linden+drive,+madison,+wi&sll=43.06685,-89.408949&sspn=0.009139,0.016973&ie=UTF8&hq=&hnear=1630+Linden+Dr,+Madison,+Dane,+Wisconsin+53706&ll=43.075244,-89.412714&spn=0.004569,0.008487&z=17 which is easily accomplished by just storing the latter in a db table and giving it a name, so you can have named queries. > >> If hiding URLs from users is a design goal it also seems like it is >> easily solved by using AJAX to update content. > There is no official reason for using or not using AJAX, but the generally assumed reason is that AJAX allows you to replace *parts* of a page without reloading the page. AJAX makes sense in many cases, but is nonsensical in many other cases. Besides, Mark very well emphasized a major caveat with AJAX below, something I experience when I accidentally hit the browser back button in Gmail. > With that method you would also have be careful to not break the back > button, which means making sure the URL gets updated, which is just > trading one kind of clean URL design for another. > >> Personally, I think the CGI Application Framework project goals might >> do well to include how the framework can integrate tighter with the >> client side features available now and those coming in HTML5. This >> would obviously require making the inclusion of javascript in output >> something that is easier to do. >> >> HTML::Prototype is a good example of what I mean. Helper tags for >> JavaScript are needed to really take advantage of all the upcoming >> potential for web app developers. The client side data storage features >> in HTML5 go a long way past cookies. Among other things, this will add >> some offline feature capabilities to our repertoire. > > I think using Perl to generate JavaScript was a bad idea. It creates > more complexity, but you still need to know and use JavaScript. Perhaps > if it eliminated the need to worry about JavaScript completely I would > see it as valuable, but it does not. > > It's not clear to me what else a framework like our should be doing to > integrate with the client side. I see that as primarily being a concern > for templates. Someone could perhaps ships some sample templates for > website developers with a web framework, I suppose. > I completely agree with Mark. Each tool should do what it is good at... Perl should do stuff in the backend, JavaScript in the frontend. The way for one to communicate with the other is your mechanism of choice ... mine is JSON. This is one of the reasons I never used CGI.pm or CGI::Simple.pm for its html generating abilities. I always found the following to be silly print table({-border=>undef}, caption('When Should You Eat Your Vegetables?'), Tr({-align=>CENTER,-valign=>TOP}, [ th(['Vegetable', 'Breakfast','Lunch','Dinner']), td(['Tomatoes' , 'no', 'yes', 'yes']), td(['Broccoli' , 'no', 'no', 'yes']), td(['Onions' , 'yes','yes', 'yes']) ] ) ); when I already knew how to do its HTML equivalent. Hence, use templates. That way I also have the ability to learn and update my jQuery framework and plugins (jQuery is my tool of choice on the front-end) separately, without depending on yet another externality, a Perl module that embeds jQuery for me. It also allows me to have a direct URI for my JavaScript files so they can be cached by the browsers, and can even be served from a separate server than the application hosting server. >> It won't be long before we can't ignore these mobile devices. Google >> boldly stated this week that "In three years desktops will be >> irrelevant". That's because everyone will be using web apps. Apple is >> certainly moving that direction with the MacBook Air, iPhone/iTouch, >> and now the iPad, and of course there are "Netbooks". > I think we already are at a point where we can't ignore mobile devices, but like the desktop landscape, they too have a fractured browser scenario... I can just choose to develop for one platform (WebKit) or take pains to develop for all. It will depend on who my audience is.. those developing income-generating applications will likely target a dominant platform. Me, I still don't carry a cellphone, perhaps one of the 17 people in the world. I develop, at least for now, for desktop browsers. There too, I have kept my life simple by choosing to ignore IE6/7, and hoping things work in IE8 (I don't own or have access to a Windows machine). For normal, document-oriented applications, my stuff should work in a WebKit based browser. The carbonmodel app that I am developing will be considerably more complex than anything I have done so far, but for starters, I will focus only on desktop. My assumption, perhaps wrong, is that anyone doing serious scientific (or even serious non-scientific) work will be using a desktop, not a mobile phone. > It's not at all clear me that a future of tethered devices like the > "iDevices" is one we should be looking forward to and enabling: > > http://www.slate.com/id/2223214/pagenum/all/ > >> That's more than I've said here than in the past five years. I do hope >> some of you find it useful. > > I appreciate you speaking up. > > Mark > > -- > http://mark.stosberg.com/ > > > -- Puneet Kishor http://www.punkish.org Carbon Model http://carbonmodel.org Charter Member, Open Source Geospatial Foundation http://www.osgeo.org Science Commons Fellow, http://sciencecommons.org/about/whoweare/kishor Nelson Institute, UW-Madison http://www.nelson.wisc.edu ----------------------------------------------------------------------- Assertions are politics; backing up assertions with evidence is science ======================================================================= ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################
