PHP 5 And In Core DOM, XML and XSLT
Apparently, all these "Smarty adorers" did not consider that PHP 5 introduced a lot of core classes to work over DOM, XML, and transform them via XSL files. Nothing to do, they prefer to move an entire template application rather than use the best native, fast, in core, solution. Here a couple of reasons to generally prefer XML and XSL Transformations rather than whatever engine, specially those written in PHP itself, a not that fast interpreted programming language.Think Portable
Apparently developers like to be stuck forever in a single programming language, something I cannot even try to consider, since Information Technology means Flexibility and Updates. An extremely valid point to choose XML as output, and XSL as Transformer, is the universality of the XML markup language first, and complete separation between data and business logic from its presentation after.Something PHP developers often look for, discarding without a valid reason what is already there since ages. Even if the entire website or application programming language will change (performances anybody?), rather than simply take care about how to reproduce the same XML via the new language, they prefer to recreate for each sub-part of the website the code to make that completely new and different template engine work. This becomes even more ridiculous when arguments are like:
if I need php in the middle of the presentation layer, I simply put it there ...... "good thinking", isn't it?
Think Scalable
First of all, XML can be easily cached without even moving a single database connection. Moreover, having zero dependencies from external engines probably based on the same XML + XSLT concept, could simply make our application faster. XML has thousands of implementations, libraries, and fast parsers, for every kind of programming language and latest dabases could even interact directly with stored XML (or retrieve data directly in XML, did you know that?)
An application that as main intermediate layer has XML will have so many long therms advantages hard to imagine, are you still thinking a foreach inside the layout is a good solution?
Think About Your Career
Ok, I use PHP and I want a template engine that will bring me nothing new to learn, except its own PHP exposed API. And tomorrow, when I'll move into another better structured company, everything about XML, XSL(T), and XPath, will be a non-sense, "'cause I know peeaichpee", isn't it?
If you think you know enough about XML and XSLT and you are not using these layers I bet you do not truly know them or real potentials.
I bet you do not know XPath, you do not know how to generate a valid XHTML/HTML layout, and you do not know XSLT strategies to retrieve only info you want to show and nothing else.
Well, think about this, more enterprise ready stuff, rather than just whoevercanuseit programming language (easy to start, hard to use properly, that's PHP) ... is it an extra plus to at least give them a try?
Extreme Performances? A concrete Example
The New York Times website is using these technologies since ages and it implemented its own XSL Cache Extension in order to obtain best performances with xsl documents. At the same time, XSLT is present in every browser, included Internet Explorer 5 so it is even possible to simply delegate transformation to the client, speeding up even more the server. Here a simple example, based on my "old" JXON proposal.
Do you still think there are so many better options?
16 comments:
can't we say the same thing about DOM Selectors? why use CSS selectors if you have XPath? ;)
XPath is ideal for XML structures, where class does not mean anything different from other attributes while CSS is the natural way to write style sheet, then CSS selectors are natural way to retrieve DOM nodes over (x)HTML structures. If the document is XML, of course XPath become the best option (I still wonder who the hell is using jQuery CSS selectors over XML nodes, jQuery team put effort to make that library compatible with XML as well ... )
As you already know I usually work with XML/XSLT.
I have to say that sometimes is unavoidable, for example if you have to render the same xml data over different platform like I do.
For example I've to render the same xml on a pocket pc with a resolution of 240x320 pixels and normal pc, xslt here are a manna from the heaven!
Sometimes, instead, using XSLT become a form of overengineering, if you have only few data that changes, for example.
I recently wrote a little MVC framework in Perl that basically is a simply replace
(that is the same replace I used here: http://forum.html.it/forum/showthread.php?s=&threadid=536334 in PHP)
so I can reuse the same template across different language.
Sometimes simple solution are the better!
That's the point, XSLT is simple. More you use it, more things are simple and fast as is for every other language. Moreover, you do not re-invent the wheel every time, you bring the XSLT and that's it. In your case, you could have used just the XSL rather than implement the engine in another programming language with different syntax, more debug, etc etc ...
P.S. in your PHP example you are using /e to evaluate variables ... that is truly bad in my opinion. Sorry.
Andrew, that example is 6 years old, but, just for the sake, is still works and is just a function, you can port that function in perl in 5 minutes;
...but this is not the point, the point is xsl is not so simple to work with for complex things, I'm using xsl since 2004 and I know xpath very well, so I know what i'm talking about.
The point is that xsl is a valuable tool but like all the tools its abuse can drive to the wrong path.
Christian, xslt transform xml into xhtml. If this is the purpose, I cannot spot any problem using the best and fastest option we have. In any case, when I said IT is about Flexibility I meant that obviously, if there is a particular case where things could be more simple and fast without XSLT, well, we can consider that case. Avoid XSL only because "we do not know it" or because "there is no time" is, in my opinion, not-professional at all. Time is the same while benefits, generally speaking, enormous compared with whatever language specific solution.
The problem is that XPath is a lot less flexible than CSS selectors and there are cases where you have selectors that can't be translated into XPath.
>> there are cases where you have selectors that can't be translated into XPath
... on the rerver side, right? like what, "element:hover" ? Give me some example please ... that XPath for XML is less flexible than CSS Selectors (and please tell me who uses CSS selectors for XML) is totally new to me ...
Sorry oorza, but I think you are confusing XML and XSLT via XPath with jQuery or soemthing else ... any idea how does XSLT work?
P.S. CSS to XPath, for every XSL related query I cannot see any better flexibility from CSS ... but still, I think you are talking about something else.
As a Javascript lover, I'd like that everything I work with would be JavaScript-like or JSON-like. I mean, I'd like that the language to specify the interface were JSON-based before than XHTML. Or that the styles would be specified with a JSON format. Or the templates, I miss a system based on JSON but with the flexibility of the Javascript functions.
I want Javascript to jump over all the elements of the web experience. One way of thinking, multiple profits.
you can use XSL to transform XML into JSON without problems :-)
@Alsanan:
I come from years of client side XSLT/XML.
For our new project, we switched to JSON.
But then I missed the speedy XSLT.
So came the library PURE Unobtrusive Rendering Engine.
The HTML is kept clean and not sliced anymore.
And only JS+HTML is needed to render JSON data.
Andrea, if you have some times, have a look. Your feedback would be very appreciated.
Mic Clivic, I will for sure! Thanks
Well said: "and latest dabases could even interact directly with stored XML (or retrieve data directly in XML, did you know that?)"
There are now several native xml DBs (I'm associated with EMC's xDB). XQuery can build your pages from your DB with no data wrenching. Javascript is relegated to client-side response to XForms. It's a very simple approach.
Take a look at http://en.wikibooks.org/wiki/XRX too:
Post a Comment