Content with Style - Comments on XML as intermediate application layer

Content with Style - Comment #1 on XML as intermediate application layer

Mon, 23 May 2005 18:35:04 +0000

Interesting concept.

Perhaps I’m being obtuse, but what would be the advantage of this approach over a template system like Smarty for example?

Content with Style - Comment #2 on XML as intermediate application layer

Mon, 23 May 2005 19:49:05 +0000

Nice article. I use a similar approach for my developments and I love how everything is neatly compartmented.
When appropriate, I even move XML and XSLT to the client. It trims down on server access and allows for more responsive and faster apps. Of course it’s not supported by all browsers.

Adam: I don’t know Smarty, but XSLT is a W3C standard.. That count for something.

NB: Your comment form is stressing me out… I thought my caps-lock was broken or something.

Content with Style - Comment #3 on XML as intermediate application layer

Mon, 23 May 2005 22:28:30 +0000

@Adam:
I’m not sure about Smarty, since I never bothered to use it, but XML leaves definetly more and as Cedric pointed out, standard compliant opportunies.
For example could the XML directly be used as feed for web services.
Also, with developing the frontend using a dummy XML and writing the XSL by testing it on the client, the swap is incredibly easy afterwards. No need to take HTML-templates apart and put in smarty placeholders … Point?

@Cedric:
Thanks, yeah, I see your point and I wish I could go for that, but since especially accessible applications demand markup that screenreaders and lynx can digest I’ll do it on the server … ... If I know it’ll be IE 6 with MSXML I do stuff like my XML Editor in pure JS …

forms:
think that’s better now

Content with Style - Comment #4 on XML as intermediate application layer

Wed, 25 May 2005 00:27:53 +0000

From what little I’ve seen of Smarty, there’s an awful lot in there that you’re never going to use. I was looking to use it quite recently but decided that the added overhead (mental, as much as processor) was just too great and sacked it off in favour of a custom, lightweight approach. That said, I know people who swear by it so I guess it’s whatever suits you and your project best…

Content with Style - Comment #5 on XML as intermediate application layer

Thu, 26 May 2005 23:11:08 +0000

Smarty is the worst. Not only do I have to learn a templating format, I am forced to use a propriety standard and that is something I am not ok with.

In addition, XML and XSLT can be used to provide accessibility for other devices with little to no code changes, so it extremely flexible, unlike Smarty.

Plus, as someone mentioned above Smarty is terribily bloated and you probably won’t even use half of its “features”.

Content with Style - Comment #6 on XML as intermediate application layer

Fri, 03 Jun 2005 03:49:03 +0000

All this sounds fine and dandy but unless you can run the xslt transformations on the client then arent you adding processing overheads?

Surely PHP based templates are the most effective methods. I’ve followed the arguements on templating engines and come to the conclusion that they are mostly pointless (since php makes a fine template language).

The one advantage of systems like smarty over php is they enforce discipline so nasty php code that shouldn’t be in the template can’t be in the template.

Also adding smarty/xslt/xml to the mix adds further complexly and the requirement to know additional markup/code.

My final issue is 5 layers adds to the number of files to think about when trying to nail down an problem. I already find this an anoyance with the MVC system I have in place and 5 layers sound like they will increase the problem.

Phew thats a large post but I am interested to see what you think of my view and to learn of any possible improvements I can make to my MVC code

Content with Style - Comment #7 on XML as intermediate application layer

Fri, 03 Jun 2005 17:42:36 +0000

Hey Ben. I don’t really know if and how much XSLT with e.g. Sablotron
increases the processing load on the server. But even if it increases it, I’d trade that against a flexible layer that afterwards can be processed into anything.
If it became a serious issue for the server to handle it i’d say just cache the XML or even better, the whole page :)
Also let me point out that with XML as application layer you can use one XML output and transform it for each targeted platform.

It would be interesting to get a Benchmark on how much the processign load and execution time are increased by stuff like that. Anyone got some links?

Content with Style - Comment #8 on XML as intermediate application layer

Sun, 05 Jun 2005 01:04:53 +0000

Hi, I totaly agree with you, and if my host supported XSLT conversions(server-side) I would be far on my way. Though, this also have it’s problem, as you would have to come up with a standardized way of making your XML, as making new XSLT for every project you do might be a little tedious and I’ve never had a project where I had time to do this.

Content with Style - Comment #9 on XML as intermediate application layer

Thu, 16 Jun 2005 13:32:41 +0000

With MSXML and .NET’s XSLT implementations (don’t know about other ones unfortunately) you can cache a compiled version of the XSLT.

In ASP you use the XSLTProcessor and you can put the compiled version into an Application variable, for example. With .NET’s version you have much more power e.g. putting it into the Cache object and setting a dependency on itself so if you update the XSL you don’t have to reset the web server or invalidate the cache manually through admin scripts like you would with ASP.

This helps with performance. (The idea is similar to using Stored Procedures or parameterized SQL queries, so the compiled statements can be cached internally, etc.)

Content with Style - Comment #10 on XML as intermediate application layer

Thu, 16 Jun 2005 16:40:17 +0000

Thanks Anup for flagging that up.

Also I had a chat with Matthias who spotted that there is a little discussion going on on a couple of sites that goes like “XSLT vs Smarty”.
I already made my point on that earlier, but one thing I forgot to mention: Smarty or any PHP templating language is PHP only, XSLT is multi-platform and nearly every up-to-date language offers an XSLT processor.

Means that, if you’re forced to port your project, you can still keep the XSLs …
Also your skills (I guess it’s more than a five minute job to “learn” Smarty) are presistant troughout all platforms and languages. That’s where I see a major benefit in using w3c techniques.

Content with Style - Comment #11 on XML as intermediate application layer

Fri, 28 Jul 2006 07:51:27 +0000

Pascal,

I forgot I posted to this some time ago, and never saw your reply, but your point about keeping the XSL skills when you port is very important, I think.

In fact, my personal site for 8 years has been ASP (glueing a 99% XML/XSL driven content). I have finally decided to port to PHP, and you are right (and that is what I hoped too!) that it is not as much work as needed.

Not finished porting yet, but my XSLs hardly changed at all (the main problem being with ASP (and ASP.NET) you can pass XML Nodes as XSLT parameters, but with PHP 5 it seems you cannot. But that was not a major issue for me anyway, as I simply inserted the nodes into the XML anyway.

Content with Style - Comment #12 on XML as intermediate application layer

Mon, 10 Mar 2008 19:58:16 +0000

As far as I know, a problem with XSLT approach is the designing part—I haven’t seen a WYSIWYG editor that would let you see a rendered HTML/CSS result before you run the transformation. However, using a template such as PHPTAL does.

If there’s an editor that would do that, I’d like to know what it is.

P.S. It would be good to see in which year posts were made.

Content with Style - Comment #13 on XML as intermediate application layer

Sat, 13 Dec 2008 17:44:50 +0000

I just read this again, after a long long time. It's coming to my 6th year in London soon, and even for me "Why bothering" is a funny funny headline. I can understand why my partner accuses me of overusing the progressive.