It’s been an intense couple weeks. In addition to finally getting our Eval pilot out the door I got pretty sick and was barely able to code for like a week. It’s easy to forget how much effort is actually involved with sitting on your butt in front of a screen. Before I got sick I had a chance to spend an evening coding with The Josh Ryan who was in town for a little while, and got pretty excited again about parse specs.
URL Engineering
Every sane web programming framework has some sort of way of re-engineering your URL structures without destroying the rest of your application.
For example in Django, you set up all your URL’s in a central place like this (example from the Django Book):
from django.conf.urls.defaults import *
from mysite.views import current_datetime, hours_ahead
urlpatterns = patterns('',
(r'^time/$', current_datetime),
(r'^time/plus/(d{1,2})/$', hours_ahead),
)
Every time a request comes in, it runs through all the regular expression tuples you define, and if one matches it stops and sends it to the function you specify in the 2nd tuple index. Extra parameters are handled with pretty standard regular expression syntax. So in the second tuple there, the hours_ahead function also gets the stored result from the parenthesis in the regex. Of course there’s more too it, like if you want to get parameters or POST stuff, but that’s a pretty good example of creating dead sexy URL’s using old fasioned regex’s.
Another interesting example is the RESTlet framework, which uses something that adheres pretty closely to the drafted URI Template. So in this case, you set up this thing called a router, and then you attach URI Template Handlers to it: (from the RESTlet Tutorial
Router router = new Router(context);
...
// Attach the handlers to the root router
router.attach("/users/{user}", account);
router.attach("/users/{user}/orders", orders);
router.attach("/users/{user}/orders/{order}", order);
In the case of Django, the second basic argument was a function reference, in this case it’s an instance of RESTlet specific handler class. So if your URL was “/users/sgithens” the account handler would get the request with a ‘user’ parameter containing value ’sgithens’.
In the case of RSF we have the ViewParameter system, which incorporates parse specs you can modify. A good example is actually EVALSYS-452 that I had to fix last week. Basically I had the default view params with not modifications.
public class DownloadReportViewParams extends SimpleViewParameters {
public Long templateId;
public Long evalId;
public String[] groupIds;
public DownloadReportViewParams() {}
public DownloadReportViewParams(String viewID, Long templateId, Long evalId, String[] groupIds) {
this.viewID = viewID;
this.templateId = templateId;
this.evalId = evalId;
this.groupIds = groupIds;
}
}
This was producing just really crap URL’s like: http://server.org/site/tool/downloadedExcelFile. Of course you end up saving a file called “downloadedExcelFile” to your hardrive and then Excel can’t figure out what it is.
The solution is pretty easy by adding a filename parameter and customizing the parse spec to place it in the URL structure.
public class DownloadReportViewParams extends SimpleViewParameters {
public Long templateId;
public Long evalId;
public String filename;
public String[] groupIds;
public DownloadReportViewParams() {}
public DownloadReportViewParams(String viewID, Long templateId, Long evalId, String[] groupIds, String filename) {
this.viewID = viewID;
this.templateId = templateId;
this.evalId = evalId;
this.groupIds = groupIds;
this.filename = filename;
}
public String getParseSpec() {
return super.getParseSpec() + ",templateId,evalId,groupIds, @1:filename";
}
}
This now results in URLs like: http://server.org/site/tool/downloadedExcelFile/filenameValue.xls and Excel is super happy. The other parameters in the list still show up as URL parameters. And the @ preceded things show up in your URL path. By defuault your view id (downloadedExcelFile in this case) is @0.
CoC’s vs Under Cover Dealings
One thing we’ve been sort of pondering is whether RSF needs a Chain of Crap Pattern implementation of this. (Chains of Crap are like the way you string stuff together in JQuery, or generally just declare huge lists of things (Chains of Crap are *not* always bad, but it’s important to be careful)). For instance, in the Django CoC it basically runs through all the regex’s in order. In the case of RESTlet, I’m pretty sure it’s more of an under cover thing. You initially attach the routers, but I don’t think the order matters as it uses some sort of scoring system to pick the best template for the incoming URL.
RSF is sort of a hybrid. While you define all your ViewParameters and Views in a very decentralized way, under the covers it’s a CoC that takes the first View ID that matches. I think we need one of two things:
- A CoC somewhere that uses either Regex’s, URI Templates, or a type of ParseSpec to match incoming URL’s
- An addition to the parse spec that allows URL’s to be matched that don’t contain the view id. Really the only handicap right now is that URL’s have to have the ViewID in them. Once we get rid of that requirement it’s pretty much home free for hot URL’s
Paris Papers
In the same vein as the above issues, Ryan Lowe and I are submitting a paper for the next conference in Paris about some of the stuff we’ve been working on with new style Sakai Helpers and URL’s in the Assignment, Gradebook, and other places. Well, I mean we call them Helpers still because there is a legacy in Sakai to call them that, but really we’re talking well documented HTTP interfaces.
When you think about, from a standardization standpoint, presentation wise we’re kind of screwed. This year alone I’m sure we’ll have tools written in JSP, Velocity, JSF, Struts, RSF, RESTlet, Wicket, sdata, Ambrosia, Pylons/Django on Jython, Rails on JRuby, and whatever framework someone decides to write on top of the servlet spec on a random Tuesday afternoon. The interesting thing about this problem is that it makes Sakai a microcosm of the rest of the internet. Lots of people are already solving these very real problems on the wider internet and interconnecting systems built on everything from PHP apps to Google Spreadsheets.
On the server side we have the JVM class specification to exchange things, whether via the Sakai Component Manager, RMI, or whatever, but when it comes to tools working together, we believe this is the essential way to fix a lot of our problems, regardless of whether you’re sending entire pages or asyncronous fragments, and whether your payload is XML, JSON, SOAP, or some random DSL. Well documented HTTP interfaces, because we are never going to port everything to a single view technology.
That’s a small slice of what we hope to talk about.
PYCON!!!
Guido going over Python 3000 issues
PyCon 2008 is underway here in Chicago! We had an amazing 1100 some people register, up from last years 600. Unfortunately because I’m just getting done being sick I’m going home and sleeping at night, but am still getting a chance to sprint a bit on some Jython stuff, an explicity some Jython stuff that Sash depends on. I got to meet and talk to most of the lead Jython developers which was pretty exciting. Cool stuff is happening. I’m pretty confident that it’ll be up to Python 2.5 functionality in the next month or 2. The talks have been pretty fun, and it’s amazing how many awesome Python libraries there are that I haven’t seen before.
Jim and Tobias talking about the new Jython compiler that was developed during the last Google Summer of Code. They are working on upcoming research options like developing an AST for it with multiple front and back end targets.
Features of the new Jython Compiler. Combined with the new ANTLR based parser that Frank as finished recently supporting 2.5 syntax most of the pieces are available for bringing Jython up to speed again with CPython.
The new compiler running Python coroutines (not supported in the current Jython release).
