One aspect of jQuery that I’ve really come to appreciate is its ability to apply filters to elements on a Web page. Let’s say, for example, that you want to disable all of the links on a Web page if the user has not yet logged in.
In most server-side frameworks, this requires you to add conditional logic to every link on the page (or just use a different template entirely). In PHP, you’d have to do something like:
<?php if ($login_page) { ?>
My stuff
<?php } else { ?>
<a href="">My stuff</a>
<?php } ?>
You could perhaps shorten that a bit if you were clever, but that’s what you’re up against. And the problem is that you have to repeat it 100 times if you have 100 links on the page. You have to add a lot of code to your page to do something relatively simple.
On the other hand, with a tool like jQuery, you can accomplish something similar with one line of code.
$("a").bind("click", function(e) { return false; });
Needless to say, it’s a much cleaner and simpler approach. This approach won’t work in terms of security since users can just disable JavaScript, but it’s great in terms of clarity and simplicity.
What I’m wondering is why more server-side frameworks don’t have similar selector-based DOM manipulation tools built in. Wouldn’t it be cool if you could attach such filters to views on the server side and manipulate the output page before it’s presented? Why isn’t this more common?
October 15, 2008 at 12:02 am
You’d need to parse the output of your program and then re-emit it, which of course is possible, but probably slow. Unless of course your application happens to be emitting XML using the DOM framework and you can intercept that before it’s turned to a string and written to the client.
October 15, 2008 at 1:27 am
In Genshi this is much nicer for single elements:
And also when you want to do it for many elements:
October 15, 2008 at 2:29 am
I’ve thought about something like this before, inspired slightly by _why’s Markaby project. The half-baked version goes like this: what if the eventually-emitted markup started out as a hash-of-hashes or a SimpleXML tree (or the like)? Then your templating system is just appending nodes to the tree. If the nodes in this tree are decorated with things like
needs_authentication = truethen filtering as you describe can be applied during the hash-of-hashes to XHTML translation.October 15, 2008 at 8:48 am
You could also tack on an XSLT filter at the end, if you’ve been diligent enough to maintain absolutely valid XHTML all along the way.
But, I’d imagine it’s not more common because, as Jacob said, you’d need to buffer up all the output from previous stages and parse it before applying further transformative filters – which is something I’d bet most frameworks don’t have the forethought or facility to accomplish.
Then again, some do – output buffering is pretty much dead simple in PHP, and I’ve seen some scary things done with regexes at the tail-end of a request to wedge in anti-CSRF bits into forms and to tack on metrics JS includes.
October 15, 2008 at 6:00 pm
One of the big problems in web development is this question of whether programs should emit data or should emit HTML. The whole programming model is built around emitting HTML, and pretending (using CSS) that it is really data. When really of course most of the time it’s mostly layout.
This is really a wholly unsolved mess of a problem. Template systems only go so far to solving it, because templates are not standardized and so tend to limit interoperability. And templates are only a partial solution to the whole data-versus-presentation problem – they still essentially say “The output of this program is HTML” even if there was an intermediate stage where it was a template + data.
The only things that hold out any hope here are real data formats that are easy to use and efficient. XML is one, but has proven to be pitifully slow and overcomplex. XML Schema made things worse, and completely screwed the pooch by including default values for elements (among other similar flaws), which means that validation is required to get the correct form of the document.
This is all bad.
JSON is the only thing that is remotely workable, but doesn’t have enough takeup yet. And even there it has problems, like that important datatypes like dates are not specified.
To me this is a way-unsolved problem. REST, XML, SOAP, JSON aren’t enough. I think we need something on the level of the CGI or Servlet API that specifies a language-independent (and yet, unlike the DOM, native-tailored) web programming model that involves data flows and not layout.
I’m not holding my breath.
October 15, 2008 at 8:19 pm
Jacob: you raise many good points. HTML as an output format is limiting. I would generalize this to all serialization schemes. Thinking on the server-side in terms of DOM nodes is a reasonable thing to do but again gets us caught up thinking about layout for anything complicated.
I think a good templating system can make the bridge between data and layout fairly seamless. The idea that HTML is only a serialization scheme can help by allowing us to manipulate the tree structure before it’s written out. Enough hand-waving. Code soon.
October 15, 2008 at 9:18 pm
http://github.com/rcrowley/sometimes/tree/master