What about your simple one Harry?
| SitePoint Sponsor |
What about your simple one Harry?
I found an interesting one the other day.. I can't remember the damn name of it or URL of the site though. >_<
I use smarty, it's basic like what phpBB uses.
Here's another higher-end template forum:
63. Invisionboard
The latest incarnation is listed up there - http://simplet.sf.netWhat about your simple one Harry?
64. ATemplate
65. ctlTpl
66. hierarchy template
67. InTemplate
68. lorenphplib_patternizer
69. MyTemplate
70. Path Wrapper
71. phpoot
72. Smart Template
73. Templato
There's a bunch I've skipped which are all called just Template or similar which are too much effort to distinguish.
Think I need to specify that it has to be available online either as a demo or available for other people to download.I have my own web template phpObjects.WebTemplate though haven't created a dedicated page though ...
Well this list is touching 75 almost .... wowhuu ...
Well, you can see, it in action at various sites like digitalAmit, Sbpagra, etc ...Originally Posted by HarryF
but there is no download page as such ... might be in a week ot two
for PHP version 4.3.x, The short answer is an emphatic NO!
I can't remember the exact problems I had but there were some really basic things that it could not do. At worst, this just lead to some strange behaviours which would really mess with your mind if you were an XSLT newbie. XSLT is hard enough for programmers used to imperative programming (ie. PHP) even when you do have a solid XSLT processor such as Sablotron.
Don't use DOM XML's XSLT on a production site.
You can stop waiting around already. "Life is already that simple". A single industry standard has already been established for some time now. It's called XSL-Transformations here is the W3C site.Makes you wonder what would happen if they were all integrated into one.
http://www.w3.org/TR/xslt
version 2.0 of the standard has already reached "Working Draft" status.
If you commit to learning this one single templating system, not only will you find more support for it in PHP, but you can use it in ANY other modern middleware platform - be it Java, .NET, or ASP(v3).
Furthermore, you can could use it on the client-side in situations such as intranet apps where the user-agent is monatomic. Both IE and Mozilla-based browsers (Nav7) support it.
What are you waiting for?
It ain't an web industry standard until you can edit it in Dreamweaver.
I don't consider XSLT to be a template language.
I interpret this definition to mean that a template for an html document has to itself be an html document (mostly). XSLT fails this test.
XSLT can be used to implement the Transform View pattern this is not the same thing as a Template View.
Oh, BTW. The unabridged American Heritage Dictionary rocks! Get one.
It just so happens that the HTML template you are talking of is not held in the outermost container (as your definition seems to require). XSLT is more sophisticated than that. Typical XSLT templates for HTML templates define the general HTML packet in the "root" template. And since all XSLT templates exist inside a <stylsheet/> container, the HTML is not outermost.
This for me does not detract from it's status as a templating system. In other words (to use an American term) - "ain't no thang". [ed. not taking the micky. I like Amarican slang]
Also, I do no subscribe exclusively to the MVC pattern for contemporary client/server applications development. So the concise definition of the "template view" (in the context of MVC) is somewhat less important to me.
I think definitions of "what a template is" are subjective. However, I have much stronger opinions on using templates for applications in today's environement. Issues like re-use(in the context of code normalisation) and interoperability are at the fore for me personally as a developer.
On the DW issue, I'm not interested in one particular product's support (ie. dreamweaver - even though I think dreamweaver is itself an excellent product for what it does). If someone brings out a new XML technology that is useful, I'm not going to wait for Altova (of XML Spy fame - including XSLT [WYSIWYG] designer) to implement it before I use it.
btw. I thought your article at http://wact.sourceforge.net/index.php/TemplateView on the topic was most educational despite not agreeing with it 100%
Last edited by tezza; Aug 18, 2003 at 02:05. Reason: disclaimer
big rant
There seems to be a great deal of misinformation and mostly lack of appreciation for XSLT. The was some guy on comp.lang.php who was crying about it because "you need to prepend everything with xsl: and that's just a pain" (I didn't even justify it with a response). There were other people making equally inaccurate assertions about using XSLT. This demonstrates a fundamental lack of understanding amoungst web developers in general. It seems that too many web developers are too tired to keep up with standards. Yet they spend precious energy learning a new templating system which may only be transient at best.
I chose XSLT as my templating solution because I am fundamentally lazy. I only want to learn one type of templatig system where I can build up a library of templates and use them accross a broad range of projects - including ones that aren't done in PHP.
I remember developing websites in the mid to late 90s and experiencing first hand the problems that modern standards have worked to overcome. WHY GO BACK?
At the time, myself and many other web designers/developers struggled with different user-agents causing us more work (having to maintain different versions of highly functional sites for different browsers). It was a standards implementation problem. Since then, standards have evolved and adapted to become immune non-standards based clients (in our client/server environment)(1). "All template developers are doing now is moving the problem onto the backend."
I USED to use PHP for it's templating capabiity (ie. I could mix literal HTML markup with <?php ... ?> functional bits. Other technologies sprang up using the same principle to gain success - most noteably Cold Fuison, ASP, and more recently, JSP. However, as my PHP skills have improved, my appreciation for PHP as a purly useful scripting language has deepend. It's ability to parse templates is much less important to me. Now I use it for it's "out-of-the-box" high degree of functionality. I can even organise my code in an object oriented manner without the overhead of dealing with a [so called] fully-blown object oriented technology such as Java or C++. I'm going to conclude this paragraph by stating catagorically that templating methodologies that formed the basis of PHP, JSP, ASP are obsolete - they are now the "wrong" way to go.(2)
I must stress though that his is a recent phenomina that is due entirely to the *maturity* of XML and surrounding standards. No matter how good your proprietary template system is, it's not much use to me as a developer. As a developer, I only want to learn one templating system and I want to learn is well! I also want this templating system to have enough depth so that given enough knowledge, I can achieve almost anything with it. And since the XSLT specification is driven by a signifigant standards body, it will constantly be improved for the forseeable future.
Getting down to the individual aspects. First let me say that the article at http://wact.sourceforge.net/index.php/TemplateView very well worth the read. The author has obviously done a bit of research and it shows. Eventually he goes on to explain why his particularly templating solution is so good (using markers). This markers approach as briefly touched on by Harry in http://www.phppatterns.com/index.php...cleview/8/1/2/ . But by Harry's own acknowledgement, this method is tightly coupled(3) between the domain of display and the domain of content aggregation due to the fact that it's the backend programmer who has to provide all the new widgets. I don't care how good the rest of it is, this alone as a fatal flaw. By contrast, XSLT fully (and I *do* mean 100%) separates the job of producing the content from the job of arranging the output (in our case, usually HTML markup). XSLT Designers can easily create their own widgets using templates (named or otherwise). Furthermore, they can continue to use those widgets on their .NET or their JSF (Java Server Faces) applications. I'm not even gonna get into the benefits of hiving off the transform work onto the client (I avoid this due to the old "standard implementation" problem).
Then there is the issue of pumping mental energy into learning XSLT. Make no mistake, XSLT can be difficult. Sure, it's easy to do your basic hello world stuff but once you start dealing with real-world problems, you have to stoke the fires for your brain to keep up sometimes. But as I have experienced, with practice, life becomes very easy for XSLT design. I think one of the reasons it was difficult for me personally was because as a PHP programmer, I'm too used to imerative programming. Learning to write templates declaratively was half the battle. It's just different. I had to get over this different way of thinking which was tough for me. Part of the problem with attacking XSLT design with an imperative approach is that you try to use XSLT's imperative "bits", like the built in functions, too much. After some practice, you will get better at separating the display logic out from the content logic and you rely less on things like XSLT's inbuilt functions. It's the same story with the other imperative bits of the XSLT language such as <if/>, and <choose/>. At first these are awkward but you learn to use them less - not because they are a pain, but because functionally, your problem is solved better taking advantage of the declarative nature of the language. Another problem I had trouble getting my head around was variable (or parameter) scope, again, I was approaching the output declaration wrongly. Getting this right takes time and is hard for me to explain. Obviously for me, the investment of my energy into learning XSLT has been well worth the effort.
What about graphic designers? If it's hard for seasoned programmers, what hope do they have?
Firstly, graphic designers don't have the problem of having to force themselves to stop thinking imeratively. So the declarative nature of XSLT is actually more natural for them to pick up. You'd be surprised how quickly some graphic designers can learn XSLT.
Secondly, because XSLT is a standard, there will be more and more software like Altova's XSLT designer wich will allow WYSIWYG template development.
My real life experience with PHP, XML and XSLT?
It's been less than ideal(4). I had to create my own PHP library to make the experience less painful (5). Right now I have a perminenet job which involves mostly PHP application development. For the last nine months I've had a production application running on PHP which is a pure XML/XSLT application(6). Not only is it running on the windows version of apache 1.3.x, it's also relying on PHPs DOM XML extension. The site has been quite busy and we've never had a crash. I haven't even had a chance to implement any form of caching yet! Anyway, the point is that the technology is here and it is useable today.
I can speculate on a number of reasons why good PHP developers are still ignoring the XML/XSLT combination dispite it's maturity.
1) It's different. XSLT is different, it uses declarative thinking, not imparative thinking.
2) FUD - there is a lot of misinformation being peddled by people who have only meddled.
3) There are more non-standards template solutions for PHP then there are standards (XML/XSLT) based solutions. I think this is more for reasons of legacy since PHP has been around since before XML. I haven't used it yet, but I think Krysalis offers a standards based solution ( http://www.interakt.ro/products/Krysalis/ ).
My recomendation for developing modern websites:
1) Come up with a vocabulary that encapsulates what you are trying to say - an XML schema. This can be can be informal, you don't have to learn schema definitions, just decide what tags/attributes (and their general relationships) you will use as a minimum. This can be an on-going thing, don't worry if you've left something out for later. I'm no XML schema expert [yet] and I can successfully build functional applications in XML.
2) Work out which objects (roles and responsibilities) you will need (DON'T use functional decomposition). Then build XML accessor methods on the appropriate classes so they can provide their content using your XML vocabulary.
3) build some XSLT templates which will provide suitable output for your needs. Better still, get your interface designer to build them, notifying them of your XML vocabulary/structure.
4) find a framework (like Krysalis) or work out some other convenient way to perform the transformation on demand. (this is the hard part at the moment but I hope my XAO library will ease that process).
This is only the begining, but it's enough for most basic applications. Solutions can really scale from here.
I hope to release my "XML Application Objects" library soon and then I hope to get more PHP programmers to use OO and XML/XSLT. XAO is not a framework - you can use it as one if you like (You can implement a controller). It was designed not to "intrude" on your OO design. It's just a library to help make the mundane work of managing transformations (and hopefully graceful exceptions) easier.
While this is turning out to be a very large post, I may as well recommended books:
1) "XSLT 2nd Edition: programmers reference" (Michal Kay). Don't try to read this, just use it as a reference - trust me.
2) "XSLT and XPath: On the edge" (Jeni Tennison). This is more like a cookbook, but more than a cookbook.
If you join the XSL mailing list at http://www.mulberrytech.com/xsl/xsl-list you will find that both of these authors are fairly active on there. The sort of support provided there would be worth heaps commercially - couldn't ask for better!
If you're a newbie and want to learn XSLT, I recomend using the web. Sites like http://www.zvon.org/ and http://www.w3schools.com/ are good places to start.
FOOTNOTES:
(1) I am NOT talking about HTML or even XHTML!
(2) Clearly, I am refering to their usage as TEMPLATES, not to their usage in general. I plan on porting a library from PHP to Java using JSP as entry points to the application the same way .php pages provide entry points to most PHP apps.
(3) Tight coupling is bad(tm). Tight cohesion is good. Loose coupling is good. So from a design pattern point of view, proprietary marker based templating solutions (while better than most) are *still* bad. See the Addison and Wesley "Design Patterns Explained: A New Perspective on Object Oriented Design" book by Alan Shalloway and James R. Trott on page 8 (yup, right at the beginning of the book).
(4) Mostly PHP's terrible error handling was to blame here. This aspect alone makes it difficult to handle exceptions in an XML context.
(5) The library that I am developing is not yet fit for release (aside from the fact that PHP might/will change the behavious of the DOM XML extension). I need to re-factor the design and do some more testing. I've developed the library in my own spare time on a test project (pure XML photo album software with no need for an RDBMS). It is not a framework because it does not call the developer's scripts. Using a controller(MVC) is up to the developer - centralisation is achieved through inheritance. I think I'll ask around here for opinions on whether or not I should submit it for inclusion in PEAR. I actually came up with a light-weight MVC controller which I used in the application successfully but it was entirely procedural so the design was limited. It was always my intention to move to a 100% OO solution.
(6) No, it's not using the XSLT functionality from the DOM XML extension. As I mentioned in a previous post, this would be a really bad idea.
Last edited by tezza; Aug 18, 2003 at 00:56. Reason: improved clarity.
I'm going to slightly contradict what I said in the last post about avoiding client-side transformations. Parity between Mozillas and IEs XSL processor is very good. As yet, I have never come accross any stylesheet which does not transform identically by the two. This is due to the fact that the underlying XSLT processor's support for the standard is pretty much spot on in both cases. Learning lessons from the past, the XSLT standard allows propper extension points for vendors to supply proprietary (value added) functionality. That means people like you and me can develop stylsheets which use only standard features to produce whatever the hell markup we like (such as XUL, IE-specific DHTML, WAP decks, or PDA optimised XHTML).
Last edited by tezza; Aug 18, 2003 at 01:18.
So am I right in saying you like XSLT?
There's things I like about XSLT but in the name of debate, will concentrate on what I don't like.
- Not sure I'd call XSLT entirely declarative. XPath has a very imperative feel to it but seems to stop short of actually giving a programmer what they need. Of course that could be me as you say - I haven't developed my skills to fluency.
- XSLT adds extra complexity - that's a big one. With PHP and XSLT in Krysalis (or Apache Cocoon which Krysalis is based on) you might have;
DB > PHP [Data Access] > XML > PHP [Business Logic] > XSLT > PHP [Presentation Logic] > XSLT > XHTML
Ignoring potential performance issues, dealing with XML and XSLT gives me more work to do. A well constructed framework, like Krysalis, can protect me from it but I'd rather have;
DB > PHP [Data Access] > PHP [Business Logic] > PHP [Presentation Logic] > XHTML
The XML / XSLT aspect seems to introduce more areas that can go wrong. My *guess* is it also reduces flexibility; certain tasks become extremely difficult but perhaps that's the hacker speaking.
Bottom line, by way of analogy; ideally I'd like to avoid even having to deal with SQL in PHP - rather have a library I trust that gives me an API for generating SQL.
- In theory it should be possible to rendering XHTML, WML, SOAP or any other XML-like format by simply adding new stylesheets on top of your business logic.
In practice none of these formats are "symmetric".
A WML based UI will be so different from from an XHTML based UI that you're probably end up needing to define different "controllers" to deal with it plus probably needing to "shape" the underlying business logic to what you need.
SOAP will definately require new business logic; SOAP API's need to be coarsely grained and and make as much data as possible available per request because each SOAP call comes at the cost of the underlying network.
- Does it improve the speed at which applications are developed? My own experiences say no but then perhaps a decent framework (Krysalis) or API such as you've developed change than picture.
One more for the list of templates;
74. [http://extemplates.narod.ru/]ExTemplates[/url]
Well there are some things that I like about using the technology, but given enough time, I could do a rant just as long about things I find irritating using XSLT. What I *like* is the fact that it is only ONE templating system that has to give me irritation. Once I learn to deal with that, I can use it everywhere standards are used! I have to say, I really didn't like XSLT for a long time (due to my lack of understanding of it).So am I right in saying you like XSLT?
Let me be quick to point out that if XSLT 1.0 was perfect, there would be no need for XSLT 2.0. As it happens, XSLT is a standard so there is a good chance that it will *continue* to be improved on it's shortcommings.
Glad to here it. Gives me the opportunity to explain some common grieviences raised with XSLT.
Too right. Like most useful technologies (ie. PHP), it's a little bit of a mongrel breed. While it is fundamentally declarative, it incorporates XPath which as you point out, it more "functional" than declarative. The <if/>, <choose/> and <for-each/> directives are most definately imperative. XSLT is certainly not a "pure" declarative language. These are almost supplementary features which can be best described as "weak".
XSLT does indeed add another layer of complexity as indeed does any other templating option. Basically if you have chosen to use a templating system, you have already chosen to add another layer of complexity - so now you need to learn all about your chosen templating system. It really is only a matter of choosing between making that effort count in the long run, or frittering it away on some proprietarily restricted system.
I *really* should get around to evaluating Krysalis so I can make intelligent discussion about it. If indeed it implements the pipeline you've outlined above, then I have to agree that this is a level of complexity your application doesn't need.
Here's how I do XSLT _in an RDBMS driven scenario_.
DB > PHP [Data-Access / Business-Logic] > XML[DOM] > XSLT [presenation logic] > XHTML
Now considder that XML provides the opportunity (in limited circamstances) to provide mass storage for your data which is *superior* to an RDBMS (depending on the structure of your data). For instance, a pure XML database like Xindice ( http://xml.apache.org/xindice/ ) or a flat file (under even more limited circumstances).
XMLDB > PHP [Data-Access / Business-Logic] > XSLT [presenation logic] > XHTML
You'll notice that each of the layers here are not repeated and each provides abstraction. So youre abstraction to layer ration is at it's highest.
Applications really should not be more complicated than this.
Given my last two pipeline examples, there is no more work to do than what you are proposing here. In your example, you still have to go to the effort of learning the workings and syntax of the proprietary system (denoted here as "PHP [presentation logic]")
There's no difference in the amount of layers in your application and the amount of technologies. The fact that "PHP [presentation logic]" is using PHP as it's underlying technology doesn't reduce the workload, the syntax introduced by the proprietary template schema is a technology in it's own right - which may or may not be simpler.
Again, no more points of failure exist than with any other proprietary templating system. If I decide to use smarty, I'm still introducing another place where something can go wrong. I don't understand this pervasive perception that other proprietary systems are somehow immune from being regarded as extra work and extra complexity yet somehow XSLT is. It's one of the reasons I feel I need to adopt a soap-box mentality with discussing these issues in order to "fight the FUD".
As for flexibility, XSLT offers just as much added flexibility as you're average proprietary system. Maybe sometimes more, maybe sometimes less, the fundamental issue is really no different. In my understsanding, extra layers of abstraction always add flexibility (otherwise, why would you introduce them?) and on the flip side, they *always* add another point of failure (the down side).
Getting back to the basic reason for adding abstraction; "Requirements always change". In other words "Requirements always change". Or let me put it another way, "Requirements always change". So better to have layers of separation so that implementating change doesn't have a domino effect of your modules. Introducing change into your code is the most common source of bugs, and they are the bugs of the worst kind - the hard-to-detect ones. Abstraction layers provide bondaries that stop these domino effects from propagating if implemented properly (using a black-box approach). ie. bugs in the business logic don't propagate to the display logic and vice versa. "loose coupling" and all that...
That's doable but you'd end up replacing one layer with yet another. Just because it happens to be coded in PHP doesn't mean it's not a new technology that brings with it a new set of responsibilities (effort).
Boooh!
You're mixing buisness logic with formatting
I'm not sure what you mean. Do you mean in the context of "bi-directional"?
Glad you brought this up
This is a question of design. Your XML packet (or any outgoing payload for that matter) should only take into account the data that a request should recive. If you're taking into account things like the interface, then your display logic is not 100% abstracted as it should be. IT SHOULD MAKE ABSOLUTELY NO DIFFERENCE WHETHER OR NOT MY REQUESTED PAYLOAD IS DESTINED FOR A DECK OF CARDS (WML) OR A SINGLE WEB BROWSER PAGE (XHTML). If the display logic needs to do things *such as* slicing up content into ergonomicly appropriate chunks (cards), then the XSLT display logic can handle that. As for proprietary templating systems? well, that probably depends on which one you use as to whether this *sort of* capability is even supported.
Another example of this is a user having to page through result-sets, say, from a web search engine. While the result list is constant, you could use XSLT to display multiple pages limited to $n results at a time. This could be highly effecient, *especially* if your user-agent is detected to be XSLT capable. In terms of efficiency, you can abstract the task of improving that to the server side. So if you have a billion results, you could use a cursor to retrieve 1000 at a time and get the UA to make a new request every finishes paginating through it's last requested block of results. The number of pages per repsonse packet block may vary according to anything from UA capaciy (ie. a 5 line phone display) to user preferences. In this case you are making decisions about the optimal granularity totally independantly of the user interface.
Even when the transformation is totally (or partially (conditional upon the UA)) server-side, there are performance enhancing opportunities just like with any other templating system. You can cache at two levels, you can cache XML payloads, and you can cache transformations. There is easily just as much flexibility for performance increases as there are for proprietary systems such as smarty.
Don't even start me on the advantages of using C based processors for your XSLT transformations as opposed to interpreted PHP code (without the availabilty and disadvantages of pre-compilers).
Ah yes, SOAP is high-latency due to trully massive protocol overhead - not helped by the rather inefficient encapsulation inherent in XML encoding.
See, not even an evangelist like me thinks that XML is perfect.
I live in hope.
I know that you are not alone in finding XML/XSLT applications development in PHP to be combersome. Until I developed my skinny controller (now deemed by me to be obsolete), debugging XML/XSLT from PHP was a complete and utter nightmare. However, including a debugging subsystem in "skinny" actually made it EASIER to debug than in non-XML/XSLT apps because I could debug my business content and my display logic separately.
From now on, I'll make a commitment to spend less time talking about it on a forum, and more time developing a decent XML/XSLT library for PHP so that I can *prove* that "the standard way is the better way".
I'll be calling on the expertise in this forum for help on the OO design.
<sighs>
Oh crap. midnight again
I'll come back and edit this post for typos tomm.
I'll also post an example of how I'm doing things for the moment.
Last edited by tezza; Aug 18, 2003 at 07:24.
I have to disagree with this testament, whole heartedly.
XML, XSL(T), HTML, XHTML...
Each markup language mentioned are as a whole a template or have a defined schema, whether the output of the templates state changes after being processed is of no relevance. As mentioned a 'A document or file having a preset format, used as a starting point', is exactly what occurs, when you use XSL(T); 1. you have a preset format 2. you have a starting point.. So essentially with that statement, your contesting against all these so called templating systems(TS).
Secondly, anyone in their righteous mind would employ, some form of lucrative caching mechanism, in order to save resources. Dutifully there are an abundance of problems, that do occur with this, however this is entirely dependant on your methods of caching and whether it is best adopted to your audience.
I have to agree with Tezza on numerous matters brought to light, which have plagued the web (and numerous corporations). With XML you at least have a conform~ative way of abstracting data, instead of spending rediculous amounts of money on getting people to input data, from legacy systems.
Edit:
more to say, rebooting.
Just on tip off - there's a good Krysalis tutorial here [PDF] which explains the architecture then goes into detail on using it as a SOAP server. Was a chapter Wrox's (RIP) PHP Web Services book.
Crudely worded "on top" - I meant apply a new stylesheet at the presentation logic layer "on top of" existing business logic.Boooh!- In theory it should be possible to rendering XHTML, WML, SOAP or any other XML-like format by simply adding new stylesheets on top of your business logic.
You're mixing buisness logic with formatting
The notion or "symmetry" is the idea that all content types rendered by the presentation logic are essentially equal. In practice though, I don't think that's true. Sure they'll all have elements in common but my opinion is the only two content types that are really symmetric are HTML and XHTML.
To deal with WML, for example, the "controller" MVC will likely need to perform quite different operations. First you've got session which will need to be passed via the URL rather than as cookies. Then in designing your UI, there's a good chance you'll need a very different user navigation system than with the (X)HTML equivalent. That's just for starters.
The point is I don't think all this can be handled simply by using a different stylesheet applied to the same XML document.
For < PHP5 I'm not even going to comtemplate this idea myself now that I've had more time to look into it and think about itfor PHP version 4.3.x, The short answer is an emphatic NO!
Like you say Tezza, it's just a multiple version nightmare just waiting to happen
Thus I've downloaded PHP5, latest build and as soon as I can get this up and running I'll be using PHP5 solely for this idea I put on this post - a lot more stable and robust.
That and a point I made in a PM to another member I think PHP4.x.x will quickly drop off once a stable realease of PHP5 is available and I can seriously see that the web hosts will grab every chance they have to move over to PHP5 very quickly - there is going to be an incredable demand for it I believe ?
Umm... I've really started the ball rolling huh ?
I would mostly have to agree with Tezza on the points of XSL-T. I've used it a lot in the past with PHP and the Sablotron extension.
I used XML templates and then transformed these after I replaced given XML well formed tags with dynamic data to xHTML and WML with the minimum amount of fuss or trouble.
Very convienent and it is easy to edit the templates as well, though more importantly I think as HarryF stated there is a drawback and that is more load on the server to transform the XML templates.
There is a very notable increase in page load times for example so I'm not so keen to continue using this method, although in saying this I'd definitely use XSL-T again in the future (ie PHP5 ?) if there wasn't such a time lag brought on by the XSL transformation.
PHP5 and it's integrated DOM may well be the solution I'm waiting for I think folks ? What do you think Harry ? You know a bit more about PHP5 and we do
XML = Extensible markup language
HTML = HyperText markup language
XHTML = Extensible Hypertext markup language?
[B]XSL(T) = Extensible Stylesheet language (Transformations)[B]
XML, HTML and XHTML are document markup languages. XSLT is not a markup language. XSLT is a turing complete functional programming language.
Going back to the definition of a template:
The operating word here is document. XSLT is a program. (Yes, a program file can be a document in another context, but that misses the point. Read Tim Berners Lee's Principle of Least Power on why html is not a programming language for clarification of this issue.)2. Computer Science a. A document or file having a preset format, used as a starting point for a particular application so that the format does not have to be recreated each time it is used.
My interpretation of this in a web application context is that a template is an HTML document used as a starting point for creating a final HTML document.
To put it into html terms, which example more closely matches the idea of a template?
orPHP Code:<h3><?php echo $title; ?></h3>I would say that the first example could be considered a template (although not necessarily a prototypical example of a template), while the second is a program and not a template.PHP Code:<?php echo "<h3>$title</h3>"; ?>
XSLT was designed to separate presentation from content. Templates can be used to separate presentation from content. This does not make XSLT a template language.
Why is it a good idea to separate presentation from content? Because the two typically have different causes for change and different rates of change. Separating the two makes many changes easier to make.
I prefer to think of Templates as a way to separate HTML from code, the ModelViewController pattern as a way to separate presentation from data, and Templates as a one possible way to implement a View.
Why separate HTML from code? One reason is to take advantage of specialized editors for HTML. Another is that HTML design represents a different skill set than programming.
XSLT can also separate HTML from code, but it does this by embedding it inside of a different kind of code. The editor support is not there. The pool people who know XSLT is tiny compared to the pool of people who know HTML. The learning curve to go from HTML to XSLT is steep. The learning curve to go from HTML to Templates is generally shallow.
Separating presentation involves complexity. If you have divided responsibilities on a web application, you have to ask where should I dump this complexity? On the designer or on the programmer? XSLT dumps it on the designer. Templates (can) dump it on the programmer.
Template engines that resemble programming languages (imperative design) dump that complexity back on the designer.
Would I be wrong in assuming that most of the people arguing in favor of XSLT and imperative features in templates either do not divide responsibilities between different people for programming and design, or are on the programming side and want to push the complexity to the design side?
That said, there IS a place for XSLT and imperative template languages. IT has to do with the degree of separation between the programmer of a product and the designer.
For a one person project, it hardly matters what you do.
For an internal project, where the designer and programmer are part of the same organization, I think the template approach is better. (complexity is dumped on the programmer).
For a commercial product (such as x-cart), where the programmer of the product and the template designer (or customizer) are very different people, something with programming language power like XSLT or an imperative template language makes sense.
If the commercial product has a consumer audience, XSLT looses its appeal. Jane blogger is not going to learn XSLT just so she can make her blog pretty.
Good Points there Selkirk, me personally I think the workload is for the most part dumped right at the programmer's door, though I would prefer the workload in regards to design and using templates be dumped right at the door of the designer since they have the easy life...
Us programmer's it's actually us who have to use our brains, whereas designer's only need some imagination and a bit of flare so to speak ?
Why should the designer's get the easy life huh ?
I still can't clarify your distinction of XSLT as something other than, a markup language, maybe i'm looking blindly into what your implying, but as far as I see it XSLT, is a derivative of XML. Set aside any injunctions with processing/parsing them, at the heart of it, its a template('please correct me'). When you actually come to parse, that template via the many parsers, it provides some limited logic and conditional, capabilities.
Yes, that is essentially the fundamentals for a programming language(PL), but then you could argue that scripting languages are full blown PL's.
I can understand that, html is not a programming language as it does not embed any conditional arguments, such as XSLT. However, I still think thats rather out of conext as you mentioned. ("When I get a chance I will read Principle of Least Power." ). Also i'm not refering to XSLT altogether as an templating language. Although it does provide solutions to resolve templating strategies, ("Look at smarty is that a program because it involves logic in the template, which is handled by PHP?"). In a way this could get a bit rhetorical on actually classifying a definition. But in my opinion (IMO), I see a single xslt document as a template. Without added functionality of a parser, there would be no logic, to aid XSLT as well as 'smarty'.XSLT is a program. (Yes, a program file can be a document in another context, but that misses the point. Read Tim Berners Lee's Principle of Least Power on why html is not a programming language for clarification of this issue.)
Anyway i'm running short on time, so I look forward to your response.
By creating an interface for the designer, simply pushes towards a inflexible system. But thats my next challenge [img]images/smilies/biggrin.gif[/img]
[NOTE]INSTANT SAXON
Details
Engine Type: XSLT Engine
Vendor: Michael H. Key
Platform: Windows 95, 98, NT, 2000 **
Language: Java
URL: http://users.iclway.co.uk/mhkay/saxo...1/instant.html
ORACLE XSL
Details
Engine Type: XSLT Engine
Vendor: Oracle
Platform: Java, C, C++ and PL/SQL
URL: http://otn.oracle.com/tech/xml/content.html
SAXON
Details
Engine Type: XSLT Engine
Vendor: Michael H. Key
Platform: Windows 95, 98, NT, 2000 **
Language: Java
URL: http://users.iclway.co.uk/mhkay/saxo...6.4/index.html
SABLOTRON
Details
Engine Type: XSLT Engine
Vendor: Ginger Alliance
Platform: C++, g++, Perl, PHP, Object Pascal, Ruby, Erlang, Tcl, Ada, Python, Linux, Windows NT/2000/XP, Solaris, HP-UX, Irix, FreeBSD, OpenBSD, OpenServer, Open Unix, MacOS X, etc.
URL: http://www.gingerall.com/charlie/ga/xml/p_sab.xml
XALAN
Details
Engine Type: XSLT Engine
Vendor: Apache Software Foundation (ASF)
Platform: ?
Language: Java
URL: http://xml.apache.org/xalan-j/index.html
XERCES
Details
Engine Type: XSLT Engine
Vendor: Apache Software Foundation (ASF)
Platform: Java, C++, COM, Perl
URL: http://xml.apache.org/xerces-j/index.html
XT
Details
Engine Type: XSLT Engine
Vendor: James Clark
Platform: Java, UNIX, Windows
URL: http://www.blnz.com/xt/index.html
XP
Details
Engine Type: XSLT Engine
Vendor: James Clark
Platform: Java
URL: http://www.jclark.com/xml/xp/index.html
UNICORN
Details
Engine Type: XSLT Engine
Vendor: Unicorn Enterprises SA
Platform: C++
URL: http://www.unicorn-enterprises.com/
4XSLT (4Suite)
Details
Engine Type: XSLT Engine
Vendor: FourThought
Platform: C, Python, Windows, UNIX
URL: http://4suite.org/index.xhtml
XML PULL PARSER (XPP)
Details
Engine Type: XSLT Engine
Vendor: Aleksander Slominksi
Platform: Java
URL: http://www.extreme.indiana.edu/xgws/xsoap/xpp/
I drew this up a while ago...
[/NOTE]
XSLT is not a derivative of XML. XSLT is an XML application.
They are.Yes, that is essentially the fundamentals for a programming language(PL), but then you could argue that scripting languages are full blown PL's.
Thats the whole point of The Principle of Least Power. Sometimes inflexible is good. As Spiderman might say: With great flexibility comes great complexity.By creating an interface for the designer, simply pushes towards a inflexible system.
XSLT is used to implement the Transform View pattern.
Here is a data flow diagram for a Transform View via XSLT:
With an XSLT Transform View you start with an XML data document and the style sheet "injects" html into it to result in the final HTML document.Code:[ Application Data ] ---> [ XML ] --- (XSLT processor) ---> [ HTML ] ^ / / [ XSLT ]
With Template View you start with an HTML document and the template API "injects" data into it to result in the final HTML document.
Does that make sense?Code:[ Application Data ] \ \ \ v [ Template ] --- (Template Engine) ---> [ HTML ]
Hi All. First post on SitePoint, so I may as well get my feet wet with a dilly.
This is a neat thread (thanks HarryF)--I do find the XSLT discussion is just getting in the way. I wrote about XSLT at the smarty-forum (HERE) and I can sum up by saying that despite the fact that it is a so called W3C standard (the W3C being an industry co-opted comittee that is no longer much relevant) it really doesn't fit the bill as a programmer's or designer's best friend.
I've been an adherent of XML since the first release draft in 98 and after many years of plugging, I'm not sure it really does EVERYTHING that it is claimed it can do. For serialization (and soon RPC) I now prefer YAML. For templating I prefer Smarty. For data representation I prefer SQL. There are niches that XML (and thus XSLT) can live, but the syntax burden alone rules it out as human PRODUCABLE content. XSLT in particular, is probably the worst of all possible "standards" that is coming from the W3C (but I like XPath).
Don't believe the hype: you'll be learning another W3C template language before your XSLT 2.0 code is fully debugged.
Okay, I just wanted to put my 2 cents in.
A template engine for the web should meet certain criteria. For me, this criteria is the following:
1. Pass the Dreamweaver test. You should be able to design the website AND the template in Dreamweaver. At any time, you should be able to open the template up in Dreamweaver, make changes visually, modify the template if you mad any major changes, and close it with relative ease.
2. Simplicity. The learning curve for the Templating engine should be small. Their are many designers out there, and while some of them can grasp difficult programming methodologies, a lot of them can't. Just as we programmers might have difficulty grasping the finer points in font selection, we have to assume the same for the designers with regards to logic.
3. Validating. The Template should allow, without any modification, the Template itself to be validated against the W3 validation services.
4. Cacheable. Whether you are talking about PHP as your templating language, XSLT, or simply a Smarty-style templating engine, every time the engine reads the template and parses it, it wastes time. The template engine should cache the template to prevent having to reparse the template every iteration. PHP based template engines are usually already cached by their very nature of being PHP, but Smarty or XSLT templating engines need this.
5. Self-Inspecting. Template engines should be self-aware. If a designer uploads, or otherwise modifies a template so that the template is no longer usable, the template engine should NOT allow this to break the existing, working template.
6. Secure. Template engines, and templates themselves, should be considered insecure, and limited functionality should be in place. Designers and users of the template language are not always trusted members of the staff. Even so-called trusted members of the staff have mean streaks in them. It's the same everyone at a company logs in with their own password to their computer (or at least should).
7. Flexibility. The template engine should be built with flexibility in mind. Not all templates created will be HTML based. Therefore, the templating language should evolve to suit those needs. Whether this involves changing the syntax of the template language itself, or merely adding additional functionality to suit the need, so be it. The template engine, of course in the realm of this topic, is suited for use on the web, WML, XHTML, and even SVG are all valid, and important things a template language should work with.
Heh, well, it turns out to be seven things I look for in a template engine. I am not promoting any type of template language. I am merely saying, these are the things required (at least, in my mind) of a template language. If it doesn't suit ALL these requirements, it's just not up to par.
However, with all these requirements, pretty much everything mentioned previously (all the Marker based template engines, XSLT, etc.) fail one or more of these conditions, I believe.
This isn't meant to say these template engines are bad. Rather, these are suggested as goals. Things to shoot for.
As far as reinventing the wheel is concerned, I don't see anything wrong in having 50, 60, or even 100 templating engines/languages out there. So what? How does that hurt us? I guarantee if all those developers got together, it wouldn't make a difference. Each one developed their template engine for a reason. Whether that reason was to learn how to make one, just for fun, because they couldn't find features in another one and it was too difficult to modify, or maybe they even thought they could do it better.
People always talk about reinventing the wheel, and I always chuckle when I hear that. Programmers reinvent the wheel all the time. That's why we have all that we have. What if Linux decided to NOT create Linux because Minix did mostly what he needed. Rather, he decided to put a little effort into fixing Minix so as not to reinvent the wheel. Yeah, I know, it may not entirely be the same thing, but that's also the point.
These people went looking for a template engine that fit their needs. They didn't find one, so they made one themself. More power to them. If suddenly they come to find that one that did what they needed it to do existed, so be it. It wasn't there when they needed it the most.
This was the reasons I ran my boards on phpBB. Invision Board wasn't launched yet, so I went with what was already there. I have people who as me why I didn't go with this board or that package. I tell them: phpBB had what I wanted at the time. Nothing else did. It was as simple as that.
Anyways, now I am way off topic, and making no sense.
I see what you mean now. Having said that, I can assure you that you can indeed create enirely different interce systems at the XSL level. I'm not kidding. Even if the entity types for these different interfaces are fundamentally different. I believe that the WML decks vs HTML single pages is an ideal example (see my previous post) of asymetric types. The decks require customised navigation infrastructire that the single HTML doesn't want. This whole interface *subsystem* can be encapsulated (completely decoupled) in XSLT - regardless of if transformation is client-side or server-side.
I sincerely hope you are right about the speedy adoption of PHP 5. But since there is no ETA on it, I can't afford to hold my breath.
Yes, this is indeed an issue as you point out. I do believe it would be an issue for any other system though. Other systems like smarty alleviate this problem by doing some form of caching (including compiled PHP script caching) which is very admirable (really, smarty is quite impressive). But what's to say that an XSLT user can't cache transformations or the XML source depending on demand. There are no less than two opportunities here for caching.
Having gained some experience from being on the XSL mailing list, I should point out that XSLT processor performance is also greatly affected by the XSL code itself. For instance, you can create ineficient XPath queries very easily if you are an XSL newbie. Of course this usually only comes into play if your XML datasources become large.
To avoid the complexity of inventing my own XML/XSLT caching subsystem, my production application (which has been quite busy) doesn't use any caching at all. I think the stylesheets are reasonably efficient, but that are also quite complex in this case. In XSL circles, it is widely accepted that XSLT processors written in C - especially sablotron, are "blazingly fast" (depending on the templates).
Proprietary template system written *on top* of PHP are interpreted. So they would have to be simpler (less sophistication) to keep up with processors like sablotron.
I'll conclude by saying that the performance overhead issue is not as simple as all that. There are many factors involved so it is unfair to assert that XSLT usage neccesarily means higher performance overhead than other proprietary templating systems.
You have not convinced me that XSLT template design is not template driven design.
what about WYSIWYG editors like XSLT Designer from Altova?
Are there any editors that will "translate" (interpret) any proprietary PHP template languages allowing the user to design templates in this language with real-time WYSIWYG tracking?
For content management, they provide an active-x control that uses an XSLT template to provide the wysiwyg for the underlying content (which is dandily contrained to your schema).
Posting Permissions
Bookmarks