|
/ Hathaway Weblog / Noun-Verb Web Development |
The competition among open source web frameworks is heating up. I know of somewhere between 10 and 20, so the actual number of published frameworks is probably in the triple digits range. I just discovered another one today, RIFE.
The overview on the RIFE home page makes a distinction between web frameworks:
There are currently two major schools of web application development frameworks: request-based and component-based.
Request-based frameworks are very close to the original CGI specification. They use controllers and actions that directly handle incoming requests. Each request is fundamentally stateless. With the introduction of server-side sessions, a certain degree of statefulness has been achieved. The different frameworks basically differentiate themselves by the way they map logic to URLs and how data is structured and provided to the developer.
That's a useful distinction, but I've found a different distinction to be much more useful in evaluating frameworks: the noun-verb style versus the verb-noun style.
The verb-noun style places the verb before the noun in the URI. For example, "http://forums.gentoo.org/viewtopic.php?t=394999". The verb is "http://forums.gentoo.org/viewtopic.php" and the noun is "t=394999". It's rare to see CGI or PHP scripts deviate from this style.
The noun-verb style places the noun before the verb. For example, "http://www.ubuntu.com/donations/document_view". The verb is "document_view". You can change the verb to "sendto_form" to request a different verb on the same noun.
So why does it matter? Because, thanks to relative URIs, it's easy to integrate applications that use the noun-verb style. Integration means convincing multiple applications to operate on the same data, with a user interface that smoothly transitions between the applications. If you have one application for viewing wiki pages, another application for editing wiki pages, and a third application for editing wiki pages offline in your nice text editor, linking between those applications in the noun-verb style is trivial. You just put relative URIs like "view", "edit", and "edit_offline" in your pages. In the more common verb-noun style, if you want to do that kind of integration, you're on your own; I have not seen a standard way to do it.
This has a strong parallel with object-oriented development. When you call a method, you provide the noun (the object) then the verb (the method), with optional nouns as arguments. When you call a function, OTOH, you provide the verb and optional nouns. This distinction is the essence of object-oriented development, but to some people, the order is anything but trivial. The main benefit of objects is that they introduce small, manageable, extensible namespaces, reducing the number of things programmers have to think about at once. Shouldn't web developers enjoy similar benefits?
Zope has always used the noun-verb style. Does TurboGears? Does Django? Does Ruby on Rails? Does RIFE? This detail is important to me, but it's unclear which projects have this vision.
Comments
IMO "application integration" for heterogeneous codebases is like the old "component architecture" stuff from the 80s: overhyped, underimpressive. While noun-verb is a nice feature in principle, it wouldn't even be on my radar for the "gotta have" list, let alone at the top.
That said, of the recent mainstream python frameworks I think Django is pretty much alone in explicitly designing for integration of _homogenous_ code, i.e., if it's all django-based. I have no idea about RIFE; I gave up on java for web apps somewhere around 2001.
I think relative links are... problematic at best. So I don't know that it's a very meaningful feature, all told. And relative links in Zope... bah.
I think the noun/verb vs. verb/noun distinction often reflects on the model-first or ui-first design process. With verb/noun you often think in terms of UI and screens, and then what you interact with. With noun/verb it's a more OO technique of putting the object first, but I think as a result the UI can be pushed to the side.
Interesting comments.
Application integration may be an old term, but the concept is as fresh as ever: I don't want to have to write all the code myself--I want to mix my code with others' code, saving me work. The integration takes many forms, but we all do it. Check out https://launchpad.net/, and watch the URI as you switch tabs.
Is Zope 2 homogeneous in the same way as Django? Code for Zope 2 is written in Python, but it's also required to target Zope 2.
Overuse of absolute links is a violation of DRY. What if I want to change the host name or host my application somewhere other than the site root? Relative links are great. :-) I admit, however, that all of my relative links in Zope 2 are converted to absolute links before delivery to the client. For example:
<a tal:attributes="href context/foo_action/absolute_url">Foo</a>
Choosing a model first actually improve UIs, IMHO. The model provides a focus for the page. However, as you suggest, it's easy to abuse this principle and write 1000 lines of model before starting on the UI. It's much better to write a tiny model and start work on the UI immediately.
Followup: Django appears to get this right. It also lets you be more creative.
http://www.djangoproject.com/documentation/url_dispatch/
Django makes it easy to follow the W3C URI style guide. Note that the style guide suggests URIs with no verb at all; the implicit "GET" is enough.
http://www.w3.org/Provider/Style/URI.html
Hmm... Django's regex approach is appealing. Zope applications like CMF and Plone have to create a big hierarchy of folders and objects in the object database before they can function. No step like that is needed if you use regexes instead of traversal. (You can also create your own traversal adapters, but if it's possible to do the same thing with either regexes or traversal adapters, everyone is going to choose regexes, since they already know that technology.)
Yes, I meant to add a "like Zope" in there somewhere, but I couldn't make the grammar come out right on my first try and forgot to try again. :)
The other rather convenient feature that Django has is URL generation so that the app's that plug-in pick-up the right location. Of course, if you want to run a Django 'app' outside of a bigger Django project... you'll need someway to tell that app of its new URL space.
I wouldn't bet that everyone is going to choose regexes, I've been using them for awhile now with a Myghty and they get cumbersome after you have a big stack of them. I greatly prefer the Rails style of Routes, which I ported to Python. In my usage, its almost as flexible (as sub-sections can have regexp's done on them), and less work for me when adding things since I don't need to go and update a list of regexes.
"Hmm... Django's regex approach is appealing. Zope applications like CMF and Plone have to create a big hierarchy of folders and objects in the object database before they can function. No step like that is needed if you use regexes instead of traversal."
i am not sure what is appealing about the regex approach. URL space/is/hierarchical/by/design. a lot of web frameworks try to stray away from unnecessary coupling between URL hierarchy and filesystem hierarchy, which i think is good, because in lots of applications there will be no such mapping, or perhaps no filesystem at all. but thats not to say that eliminating the hierarchy entirely is not a totally insane idea (which is what using regular expressions for request->resource mapping does, it makes the address space totally flat) - are you sure that all of the resources in your application are totally indepenent of one another? or do you use the regular expression mapping to emulate a hierarchy anyway?
Routes is similar to Django's approach: http://routes.groovie.org/trac/
The difference is that Routes is reversable. And perhaps a little more abstract. The idea of using Routes to totally replace any object publishing system at all (even a very simple one like Webware's) is appealing to me, though I haven't had a chance to actually try it.
Moe, the appeal is full control over naming. I wrote about the importance of careful naming before:
http://hathawaymix.org/Weblog/2005-09-07
In fact, look at that URI of that weblog entry. I created a folder called "Weblog" just so I could someday move my weblog off the hathawaymix.org home page without changing all of the URIs. But this is just a simple site. Check out the URIs you'll find at del.icio.us:
http://del.icio.us/tag/design http://del.icio.us/kapowee/png-transparency http://del.icio.us/doc/about http://del.icio.us/rss/izogi
These are admirably good URIs, but there are probably far too many tags and users to apply the same solution I used for my "Weblog" folder. A list of regexes would probably work perfectly in the case of del.icio.us.
Ian--to go one step further and make the URIs reversible is an impressive feat. I wonder what Routes does to resolve ambiguity. I need to check it out--thanks for the pointer.
BTW, I'm going to revise my original position: noun-verb order isn't as important as simply having full control over the mapping of URIs to resources. I observe that web designers who take control over their URIs often gravitate toward simple nouns and noun-verb order, but that's only a happy side effect.
One more thing. If there were a standard way to separate verbs from nouns in URIs, Web pre-fetching software like the Google Web Accelerator could be viable. Not that I'm advocating such a separation. I have better things to do. ;-)
Hi, just a little note that RIFE gives you total control over your URL space. You can do any kind of style you prefer. To achieve your noun-verb style can simply be achieved by setup up the pathinfo mappings you want: http://rifers.org/wiki/display/RIFE/Pathinfo+mapping+for+element+inputs
Best regards,
Geert
