I of course think you should continue investigating, since then I won't have to. ;p

I'm amused, in a sadistic sort of way, by your constant struggles to make PHP do things the "right" way. There is a reason why PHP is not more widely used, and you seem to be bumping up against it regularly.

Even if you don't want to run Windows, have you considered that Mono's ASP.NET implementation is complete? You could use Apache with the Mono ASP.Net extension (mod_mono) and write applications where the presentation and logic are fully separated. And you could take advantage of having a true session state. Further, there are thousands of ASP.Net controls freely available to do the most common tasks.

If you don't want to pony up cash for the Visual Studio .NET, take a look at Web Matrix (http://www.asp.net/webmatrix/) an excellent, and free, IDE for ASP.Net applications created by the same guys at Microsoft who wrote Visual Studio .NET.

Alternativly, you could use #develop, a GPL'd IDE that supports C# and VB.Net for the creation of both Web applications (web services, web applications, etc) and GUI apps.

It's really worth looking into; once you develop object-oriented web pages, then you never want to go back to anything else.

From my experience with it at least, I think most people are simply afraid of XSLT because it basically requires learning a new language in order to handle the transformations, and it is significantly more powerful than any other template system they've ever encountered. XSLT certainly can be a steep learning curve, but I don't think it's that difficult, and I certainly can't see any problem with using it to separate form from function in your sites. I've done the same thing using Perl and Ruby for quite some time, and in those languages it works quite well.

for web apps that require significant MVC separation, PHP *really* does not seem to be the right choice. I'd go Java- it's free, and doing three-tier applications in it is a joy. Apache's Jakarta project has produced some wicked cool tools to do this stuff, including what looks like an awfully nice templating system called Velocity. It might be worth checking out... just sayin'... ;-)

XSLT is poorly named. It's not a stylesheet language. It has nothing to do with styles. It's a general-purpose functional programming language whose input is assumed to be XML. This makes it incredibly useful for transforming XML into different XML, or into other things.

This, I think, is one of the reasons for slow XSLT adoption. People expect it to be simple, but it's a real programming language, and requires quite a bit of thought to use.

Struts. When you absolutely, positively have to have real MVC now: Struts.

Struts is a Java framework for Model-2 webapp development. It runs in any JSP container, noteably tomcat. It's free. You can bolt any presentation front end onto it that you might want: regular JSP, Velocity, Tiles, you name it.

It handles about 80% of the controller for you. You just write the business logic.

The model is simplified as well by declarative form beans. And, if you don't like SQL, you can use a object-relational broker like Turbine. Just describe the schema, and it creates beans and database all at once.

Plus, you can easily scale it to multiple webservers.

The down side is that you need to do quite a bit of up-front configuration work before anything will happen. PHP gives you instant feedback, while Struts requires probably a day of work before you get a basic shell up and running. But after that, it's pretty easy to work with. And, it may have higher latency than PHP, though it will scale better.

I am currently learning the Tomcat thing right now. I am taking my third class in Java at PCC. So far I am loving tomcat. I have experimented with Java servlets mixed with jsp and I have to say it is nothing but smooth. Also, the best item for me is Eclipse completely and perfectly interfaces with tomcat (via a plugin).

Since a few months, I have only used XSLT as a template engine (inside my PHP framework). Read more about my experiences here.

I've made a Template Abstract Layer for XSLT in java take a look at it at http://tallxslt.sourceforge.net

Hi, I love xslt too, i became so mad about it that it ended up with webxadmin (webxadmin.free.fr)

my only problem with that at te moment is that to use xslt in PHP you need sablotron which is a pain to install.

apart from that, yes xslt+css is the best language you can imagine to build HTML as long as you have your data ready. That means you need another data standard to transfer from SQL (in my case) to XML. I use PHP for data processing and that's good enough.

ASP.NET is no better than PHP...in fact PHP has more advantages over ASP, than visa-versa...

With PHP comes flexibility...and a much larger codebase to use...

You could Prado (I thik www.xisc.com) which I believe emulates ASP.NET functionality...

The only thing ASP.NET has over PHP...beyond a reasonable dought is it's IDE...

Done rant!!!

Pure xml pages will be the future, why not be a head of the game and start programming with XSLT! I have started! There are a few plus points that XSLT has over template engines:
- Faster
- Requires Less Server Resources, the php function eval() is a heavy load function, and should be avoided on a big website - all template engines use this
- Easier to Switch (I can switch begin XSL stylesheets to provide my content too different media's -- mobile, web, pda, tv etc..)


If you use firefox, look at the crazy error screen source when you go to a wrong address! You need the webdeveloper tool bar to view the source though!

Interesting... I saw this myself as well when learning XSLT and saw endless possibilities. Cached XSLT meaning the only output from the application is the content, browser side XSLT when available and hence the ability to manipulate content on the client side (eg: sorting tables). With XSLT able to be done on the server side as well, there is a fallback for browsers that do not support XSLT so there is no reason to not use it. Outputting XML from a script is also so much easier and as you mentioned, comes with the benefit of providing XML feeds at the same time. Though it took awhile to learn how to do this properly with not enough resources available - one problem was multi-lingual capabilities which took over an hour of experimenting to get it right. I'd love to know if you have any nice ideas using this as I am mid way through a full site creation and management script (CMS, forums, ...) and am utilising XML/XSLT in my framework as much as possible.

Sorry for the double post. I included my email if you wanted to dicuss anything with me as I probably won't be checking back here without a reminder but found out that it is readily available for the email harvesters, can you get rid of the email or add a special character in the email or something please? Thanks

XSLT is a very interesting thing, but how can i use it in a content managment system, that generates the forms automatically.
Should i generate the xls-file with php? Is there an easier solution?

We've been using XSLT as templates for quite some years, and views in our framework are based on it: http://www.xml.lt/Resources/Framework

Instead of ridiculing Wonko’s efforts to find a solid template system for his PHP/MySQL application framework, consider that people may choose PHP for their own reasons, I can think of several practical ones. This thread is for people that have chosen for PHP/MySQL and want a template system, not switch platform.

There are several things wrong with using XSLT as your template language. First of all, it assumes that your data is in XML, and if it isn’t, you have to convert it, which is a big waste of time and performance. Second, XSLT is too verbose for anything that isn’t a full-blown, serious web application, and even then it’s only good for things like plugins and themes. And third, you’re essentially adding another layer of abstraction that your application has to work through, thus lowering performance and increasing memory usage and such.

Now, if your application already uses XML for its data, XSLT might be a good choice, but it’s definitely not worth the effort to convert to XML. You’d be converting to XML and then to HTML, adding an unneeded step to the process.

Just came across this post -

XSLT is by far one of the best solutions if you are developing web based applications that need the ability to separate presentation from the data – (the argument for doing this has been well gone over – if you don’t, changing your code later as a pain)

Some of the comments discuss “converting” data to XML – this is extremely simple, especially if your application is using well built classes. Converting data to XML is very fast, plus, MOST data sources produce direct XML output as an option already.

As a simple example, we use an class that stores our working XML, as the page loads, we add to the XML from various sources -

When it’s time to render the page, we pick the stylesheet, run the transform, then output the result – We cache the transformation as well so we can reduce that overhead for high traffic -

If you are working with mysql, simple write a wrapper class that takes a mysql recordset and converts it to XML – this is super-fast

you then get the added benefit of easily adding data from other sources – Think of all of the external WEB 2.0 APIs – how many of them don’t have an XML output?? – most do – consume it, add it to your XML source

The best part is, once you want to do something else with your data, it’s simple. Create a mobile XSLT stylesheet, or, create one that spits out RSS, or, create a public API that sends XML, list goes on…. You never have to change any of you base code – just change the XSLT and your set!

I could go on, but using XSLT has simplified our programming and maintenence. The comments about smarty are right on – its limitations are large as well.

(also – if you aren’t using some version of M-V-C – you should be, this has also been one of our biggest helps in reducing code maintenence and upgrades) – We wrote our own, but you can research some of the other solutions out there as well -

Hi,
have just searched the net to get some opinions about XSLT as a template engine and here’s my one:
I’ve used the XSLT/PHP/MySQL combination for a year now (though not constantly since I did not develop all the time)
I was amazed by the fact that separating the Model,View,Controller an be done so clearly. I am still amazed and I have a good implemenation of generating XML from my data source and putting it into the XSLT template. I have to mention that I did not really use any other template engine before because they seemed to me as “unofficial” and XSLT is more versatile.
Moreover with XSLT you can easily define fragments: not only fragment-sites but also buttons fields etc.
I use that feature, for example, for generating paging.

Nevertheless there two points which are not so good about XSLT that I’d like to point out :
- it is very verbose => so you can lose your way in quite large documents
- I use Spry as an AJAX engine and it sometimes becomes a little bit tricky if I want to use the spry attributes with spry variables ({var}) (I always have to declare them with xslt, which is very circuitous)

These are the major drawbacks about XSL as a template engine in my opinion. Apart from that with XSLT creating web apps is real fun.

XSLT is definitely a good solution..
But has anybody checked the speed of rendering such a solution compared to Smarty etc.
I am not sure whether its a good choice for very high traffic sites..

More than verbosity, the major concern could be the total time taken to render a page, vis-a-vis traditional solutions.

And what about google indexing? Can google read for example the links contained in the xml documents?

@Gianni Leggio :
The result’s sources of the processing between xml and xsl (throw php or not) is, in this case, a standard HTML page, so google, and any other search engine, just see a HTML page :)

Your PHP generate Xml data, use a xsl to transform them to a html page witch is return to the client (ie: google bot, firefox, etc…)

@Borse :
You can mix xsl with a home-made cache system to improve rendering speed, even use pre-compiled or part-cached system for static content of your site (like menu, header, footer, etc…)

A html page can be generated from multiple xml and multiple xsl, all merge in one html output :)

Yes, I fell in love with XSL too :D

I’ve tried XSLT and developed two large-ish websites with it. It’s not bad, but:

• I had to pass all needed data upfront, so my code had to know how template is going to work. That violates separation a little.
• All data had to be in DOM nodes. It usually requires pointless conversion step from objects/arrays.
• It’s easy to shoot yourself in the foot if you’re not careful with XSLT template paths and modes. One one site after a while I had no idea which templates are being applied.

I’ve switched to PHPTAL, which is also XML templating engine and guarantees XML wellformed output, but is more imperative and can read PHP objects directly and lazily.

While researching template engines, I came across this blog and other sources, and I decided try using XSL. So far it has been an excellent choice. I don’t think I’ll ever be able to go back to string-based templates. All I have to do is generate XML containing the elements to insert, and I can then have the XSL applied on the server or the client. All the controls and loops are handled via XSL. It works perfectly, and it’s a lot faster.

“I’m worried that I’m missing some glaring problem that will eventually bite me and result in a lot of wasted time and effort.”

So now, after almost 6 years, did anything nasty bite you?
I am wondering because I have to choose between Native PHP Templates and XML+XSLT. So far I am leaning toward XSLT, but my overall/global experience with it is very low.

Yep, two things bit me:

1. Performance
2. Template complexity and verbosity

Even with a simple web app like a blog, the complexity of the XSLT templates gets out of hand pretty quickly, and it starts to be a real chore to keep things organized and maintainable. The verbosity of XSLT (and XML in general) also really starts to suck. That’s a lot of typing.

But even worse than that: XSLT is slow. I spent months optimizing and caching to speed things up, but there’s just no getting around it. XSLT will never be even remotely as fast as native PHP templates.

In the end, I went back to native PHP templates and was much happier. They’re fast as blazes, and if you’re careful and disciplined, it’s easy to keep them simple and maintainable. There are certain use cases where XSLT is really lovely and makes a lot of sense, but I don’t think it makes a good general-purpose template engine.

I didn’t do any of speed tests myself, but I am amazed that PHP5 didn’t improve speed with that new libxslt library :( How’s that possible? :(

I am in the middle of XML course now, so it’s best to finish what I have started. And then make my own timings. But now I am hugely discouraged.

Do you have some sample of too complex xslt template you worked on? If not here, send it to my email.

Can speed problem be solved by sending whole xml + xslt to clients browser and let it do parsing to html? Are there some huge drawbacks?

fyi – nytimes.com uses XSLT transformations for their site. 106 Million visits per month. There is also an article on an in-memory XSLT Template Cache they developed for PHP and released into open source.

Also – For those that are talking about the complexity of XSLT – I have found the following things helped greatly:

1. Use includes, on the fly for the specific templates you need – use a global template to include page-level template files
2. Use <xsl:call-template to call named templates
3. Use apply templates only when looping through rows

We are rendering everything with xslt right now and our performance problem is never the transformation – 90% of the time, its still the database – which, XSLT make caching so easy because we can cache our xml retrieved from the DB…

We have been using Radicore to develop PHP applications and it uses the XSLT for its presentation layer. It has served us well and makes it ‘easy’ for the developers to focus on their code and the graphic artists on the presentation layer.

www.radicore.org

…and xml + xslt is still the future of web development?
uhm, there is something that must be escaping me!

. xslt is hard to learn

. xslt is easily unmanageable for anything but the simplest of cases

. whatever your native programming language is, converting from native to html will be faster and use less memory than going through xml and xslt. I pity the developers whose native programming language / frameworks are based on xml

. xml does not map exactly to programming languages native data structures, as it is too rich (cue element vs. attribute wars in the dark ages of xml)

The only thing that was not easily foreseen 6 years ago is the sheer numbre of xslt enthusiast who would have responded to the op. When the only tool you have is a hammer … ;-)

for the nostalgic: xml is slowly going the way of the dodo, with json becoming the standard for common-case data encoding

PHP is going to another direction, it evolved the coding features but not the presentation features, so now if you work in a team with designers it become necessary to use a template engine, also performance are very close:
http://www.phpcomparison.net/