Comments on: Filtering versus conditional logic http://rc3.org/2008/10/14/filtering-versus-conditional-logic/ Rafe Colburn on software development (and other topics) Mon, 21 May 2012 23:52:43 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: http://rcrowley.org/ http://rc3.org/2008/10/14/filtering-versus-conditional-logic/comment-page-1/#comment-3149 http://rcrowley.org/ Thu, 16 Oct 2008 01:18:26 +0000 http://rc3.org/?p=8597#comment-3149 <p>http://github.com/rcrowley/sometimes/tree/master</p> http://github.com/rcrowley/sometimes/tree/master

]]> By: http://rcrowley.org/ http://rc3.org/2008/10/14/filtering-versus-conditional-logic/comment-page-1/#comment-3148 http://rcrowley.org/ Thu, 16 Oct 2008 00:19:24 +0000 http://rc3.org/?p=8597#comment-3148 <p>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.</p> <p>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.</p> 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.

]]> By: Jacob Davies http://rc3.org/2008/10/14/filtering-versus-conditional-logic/comment-page-1/#comment-3147 Jacob Davies Wed, 15 Oct 2008 22:00:49 +0000 http://rc3.org/?p=8597#comment-3147 <p>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.</p> <p>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.</p> <p>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 <em>required</em> to get the correct form of the document.</p> <p>This is all bad.</p> <p>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.</p> <p>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.</p> <p>I'm not holding my breath.</p> 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.

]]> By: l.m.orchard http://rc3.org/2008/10/14/filtering-versus-conditional-logic/comment-page-1/#comment-3146 l.m.orchard Wed, 15 Oct 2008 12:48:56 +0000 http://rc3.org/?p=8597#comment-3146 <p>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.</p> <p>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.</p> <p>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.</p> 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.

]]> By: http://rcrowley.org/ http://rc3.org/2008/10/14/filtering-versus-conditional-logic/comment-page-1/#comment-3145 http://rcrowley.org/ Wed, 15 Oct 2008 06:29:02 +0000 http://rc3.org/?p=8597#comment-3145 <p>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 <code>needs_authentication = true</code> then filtering as you describe can be applied during the hash-of-hashes to XHTML translation.</p> 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 = true then filtering as you describe can be applied during the hash-of-hashes to XHTML translation.

]]> By: Aristotle Pagaltzis http://rc3.org/2008/10/14/filtering-versus-conditional-logic/comment-page-1/#comment-3144 Aristotle Pagaltzis Wed, 15 Oct 2008 05:27:07 +0000 http://rc3.org/?p=8597#comment-3144 <p>In Genshi this is much nicer for single elements:</p> <pre><code><a href="" py:strip="not logged_in">My stuff</a> </code></pre> <p>And also when you want to do it for many elements:</p> <pre><code><span py:match="a" py:content="node()" py:strip="True"/> </code></pre> In Genshi this is much nicer for single elements:

<a href="" py:strip="not logged_in">My stuff</a>

And also when you want to do it for many elements:

<span py:match="a" py:content="node()" py:strip="True"/>
]]> By: Jacob Davies http://rc3.org/2008/10/14/filtering-versus-conditional-logic/comment-page-1/#comment-3143 Jacob Davies Wed, 15 Oct 2008 04:02:48 +0000 http://rc3.org/?p=8597#comment-3143 <p>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.</p> 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.

]]>