[cgiapp] Dancer, URIs, and Web Apps

Sat Mar 6 10:22:08 EST 2010

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 <mark at summersault.com> 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
=======================================================================