[cgiapp] Dancer, URIs, and Web Apps

[Bill Stephenson]

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