On Mar 6, 2010, at 9:22 AM, P Kishor wrote: > 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.0 > 6685, > -89.408949&sspn=0.009139,0.016973&ie=UTF8&hq=&hnear=1630+Linden+Dr,+Mad > ison,+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. >
Puneet, you're very kind, and as you know, I've sort of created my own approach to building web apps, so it's not surprising when anyone disagrees with me ;) Your example illustrates the point of why coders work to clean up URLs very well. I agree, that's an ugly URL and I've seen a bunch like it and for way too long now. But I believe this really exposes a lack on the part of the software used to view these links. If the client rendered it as a button it would be much cleaner for everyone. Adding something like &button="View Map" to a URI is all it should take on our part, if anything. The "WebKit" project works to extend support for things like that and I'm excited to see the added support for web apps. When I started my little web app over ten years ago I felt like a third world citizen. I wasn't allowed to put anything on the clients desk or pick anything up without asking, every single time they or I wanted to do either. In fact, I originally built my little app to run on a single iMac for a small business owner. It ran in the web browser using the built-in web server and perl and this allowed me to overcome some of those limits (the "Go Back" button was still there though). When I discovered I could "Script the DOM" I quit doing multi-page forms according the examples in the CGI docs and instead loaded them all into one screen that hid and showed layers. This alone saved at least four calls to the server each time a user made a document, and it made it much easier and faster for the user to get their work done. With the new features in HTML 5 I will be able to let the user store data on the client side too and sync it up later. All I have to do is add a couple buttons and some JS to do that. CGI::App might provide shortcuts to do that. It seems logical to me. Web apps will still have huge limits placed on them as compared to native apps. But this is changing. As web app developers, we are getting a little room on the clients desktop with HTML 5 and Apple provides access to some of the other tools that reside there too, this is not a small change. And it brings up the question, "How do I want to access them?" Having individual toolboxes for the all the different parts is one way to approach it. In my view, one tool to work with HTML and CSS makes sense. One tool that integrates the server and client side coding does too. They are all pillars for the same overarching framework and that needs consideration when moving forward with how any of them are constructed and when integration of tools improves productivity it makes sense. Kindest Regards, -- Bill Stephenson ##### 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/ ## ## ## ################################################################
