A Complete List of PHP Template Engines?

[alfred3x]

Thanks Harry for the very complete list of templating engines, and for fostering such an interesting discussion of the pros and cons of various templating approaches (i.e. XSLT vs the world

I'm very keen to see a comprehensive benchmark of these templating engines, or at least the top 10 or 20. I understand it's a *lot* of work, but I'm sure if we all muck in, it'll get done fairly quickly. (Of course, we then have the problem of disparate hardware/software platforms... But you know, some kind of metric is better than none at all.)

[jasonlotito]

You have not convinced me that XSLT template design is not template driven design. what about WYSIWYG editors like XSLT Designer from Altova?

Unfortunately, until XSLT adoption is more wide spread, suggesting that designers should abandon tools the currently use to design in another piece of software is not the answer.

Rather, you should promote XSLT adoption in Dreamweaver and GoLive. Luckily, Macromedia seems to be more than willing to work to support standards.

However, even still, there doesn't exist a good XSLT-PHP Templating engine out there right now (at least, none that I have seen). From everything I have seen, I still have to work to output XML, and then I have to go the extra mile of connecting the XML and the XSLT together.

Also, the XSLT approach fails to meet my 7th criteria, that of Flexibility. XSLT is for converting XML documents to other XML documents. This limits the use of the template engine to XML documents, something that is not suitable.

[tezza]

For me the issue is simple.

It is not a case of "standards for the sake of standards".

At the end of the day, I want to be able to use various pre-written applications or componenets that are written in PHP. A good example is phpBB or some sort of portal system like PHP Nuke. When I adopt these, I want them to take on the common look & feel of my site or application. Thankfully these apps do indeed use a templating system which allows me to do this.

The problem is that they all use different [proprietary] systems forcing me not only to learn multiple templating languages, but to take a peice-meal approach to integration issues.

Standards are designed to provide relief for those developers (of such applications) who want it. For the end-user/developer like myself, it is easier if they all (or at least most) used the same system.

I don't think there is much point arguing over which system is better (although, PERSONALLY, I haven't seen a "better" system than XSLT). I just think it is easier to only have to worry about the one system that the industry supports.

I think people *should* use whatever they want. As someone mentioned before, people are entitled to re-invent the wheel - I do it myself sometimes. But on the issue of what's easier for the developer out there?

I think the following quote typifies user/developer sentiment...

Makes you wonder what would happen if they were all integrated into one. Maybe someday life will be that simple!

KISS

[jasonlotito]

...snip...
Standards are designed to provide relief for those developers (of such applications) who want it. For the end-user/developer like myself, it is easier if they all (or at least most) used the same system.
...snip...

I agree. I am an advocate of sorts for standards when it comes to CSS, XHTML, etc. I like standards in coding, and documentation. When standards are good, they are great.

However, in a case like XSLT, what it was designed for (XML to XML conversions), and what it's used for (XML to XHTML web designs), things can go wrong. Trying to design a design using XSLT is wrong. It's just wrong.

100% wrong. Wrong, wrong, wrong. =) I don't know, just felt like saying it a few times.

That's what CSS is for. XSLT, for what it was designed for is great. However, out of it's element, it's a mess. Of course, that's just like anything, really.

[tezza]

However, even still, there doesn't exist a good XSLT-PHP Templating engine out there right now (at least, none that I have seen). From everything I have seen, I still have to work to output XML, and then I have to go the extra mile of connecting the XML and the XSLT together.

I'm totally with you on this issue brother, I think many other developers who do want to use XML/XSLT feel the same way (even if there are a couple of systems like Krysalis and Ambivilance already out there). This is what I faced when I first started coding XML/XSLT apps in PHP.

I think developers want simplicity, good cohestion and good decoupling. I intend to personally contribute to making this a reality for XML/XSLT application on the PHP platform.

following is a post which is the contents of my application to sourceforge for the beginning of such a project.

take note of today's date. This project is going to get wings quickly (provided (and when), I recieve appoval from SF.net).

[tezza]

To put my money (effort) where my mouth is, I am personally gonna take some action to prove what I have been talking about. Below is the application for a new project at sourceforge which I am calling "XML Application Objects: for PHP".

check it out
++++++++++++++++++++++++++++++++++++++++++++++++++

The XAO class library will be written in PHP. It will require the DOM XML and XSLT extensions. Optionally, it may require the PEAR library and XML-RPC extension. As the libray develops and new functionality is added, other PHP extensions such as CURL may be required.

XAO may be utilised whereever the PHP/webserver platform is available.

Developing robust XML applications in PHP using XSLT requires signifigant effort when writing applications from scratch. XAO takes out much of the mundane work required to perform the tasks associated with XML content aggregation and payload transformation (XSLT). It also provides a point of collaboration for developers to solidify and stabalise these basic functions. The design of the library itself is intended to foster free-form object oriented design and therefore takes a lightwieght approach to the API. The library itself may be used as a framework (framework mode) or simply as functional entities. While designed to be inherited, the classes may also by simply bound by association instead. Flexibility, choice, and low-impact are the drivers behind the design.

Challenges:
* obstacle include PHPs limited error management.
* path resolution issues for XSLT processors (ie. XSL import directives)
* routing trapped exceptions
* thread safety for flat file XML datasources
* the changing nature of the DOM XML extension for PHP

Specifically, the library will provide the following core functionality:
* CONTENT AGGREGATION framework (the basis of XAO in framework mode)
* Safer, simpler, more ubiquitous DOM XML document instatiation (and in some cases, thread safety for XML flat files)
* DOM XML document API accelerators (simplified DOM API helpers for content creation and searching)
* XML content debugging
* XSLT transformation debugging
* Graceful XML based exception handling (where possible)
* User Agenet evaluation API (used for client-side transformations)
* Tabular data (RDBMS query results) to XML conversion and structural mutation via user-defined call-back methods [available only in interpreted languages] (aggregation module)
* Pure XML database access for Xindice (aggregation module)
* Simplified SOAP/XML-RPC (remote aggregation module).
* Asyncronous messaging client - ie. Jabbber (aggregation module).

As a matter of fact, it is possible to slap together an application for displaying XML content without writing any of your own classes.

The primary protocols and formats will all be XML based - except where converting an external content source to XML for use in XAO. As such the list of data encapsulation schemas is open ended. ie. SOAP/XML-RPC, RSS, DocBook, Jabber. At the core is XSL and the DOM API.

The startup source code for this project is based on work I've used in production applications for the past 9 months. While it is only the beginning, I have enough experience to know exactly what direction needs to be taken. As yet, there is no dedicated web page hosting the source (hence my SF application). I will use my personal web site to host tutorials and examples of implementation if SF does not have PHP(4.2.x+)/DOM/XSLT facilities.

[jasonlotito]

tezza: Good show!

In designing this, I think you should also look to other template engines, and see what makes them popular. There are reasons they are popular, and it's not just because XSLT has a higher learning curve.

In developing a library, I spend time working on the interface to the library (note: I am sure you are well aware of this, I am just including it here to sound important =)). I write up code, actual PHP code (or whatever) that is a sample of how I would use the library of code I am writing. That way, when I go in to design the library, I have a clear understanding of what the end result needs to be.

Sometimes this can be difficult. I have an interface that is just difficult to develop. Usually this means one of two things: either (1) that the interface was poorly designed from the beginning, or (2) I just need to work harder.

[HarryF]

XSLT is not alone remember - there's also CSS which (apparently) is a form of XSLT. The two together may provide a clue - the active word being "styling". Perhaps we should talk about "styling" vs. "templating"

The test may be (just fishing) is to ask "is it a reversable operation"?

In other words, given the end product (e.g. output html) and the "rules" (e.g. a XSL document or a template parser) that were used to get there, can you get back to the starting document? With XSLT I'm pretty sure you can but I'm also fairly sure that parsing a template is a one way operation.

[tezza]

I agree. I am an advocate of sorts for standards when it comes to CSS, XHTML, etc. I like standards in coding, and documentation. When standards are good, they are great.

However, in a case like XSLT, what it was designed for (XML to XML conversions), and what it's used for (XML to XHTML web designs), things can go wrong. Trying to design a design using XSLT is wrong. It's just wrong.

100% wrong. Wrong, wrong, wrong. =) I don't know, just felt like saying it a few times.

That's what CSS is for. XSLT, for what it was designed for is great. However, out of it's element, it's a mess. Of course, that's just like anything, really.

Based on my own experience, I can sympathise with you. Believe me!

XSLT is not a mdium for DESIGN.

My advice is to do your generic design in whatever design tool you're used to (ie. dreamweaver), then decompose it into templates. Then you can cut/paste these into an XSL stylsheet. This concept is not new, for many years people have done just this with PHP, ASP, ColdFusion. They do all their creative work in DW, then make a PHP page out of it, putting code where the dynamic bits go. You can do this and a great deal more with XSLT.

Also, check out XSLT designer from altova.
(no, I do not work for altova).

[tezza]

XSLT is not alone remember - there's also CSS which (apparently) is a form of XSLT. The two together may provide a clue - the active word being "styling". Perhaps we should talk about "styling" vs. "templating"

It's unfortunate that XSLT has the word "style" in it when it clearly has nothing to do with styling. This might explain some of people's misconceptions about it's usage.

The test may be (just fishing) is to ask "is it a reversable operation"?

In other words, given the end product (e.g. output html) and the "rules" (e.g. a XSL document or a template parser) that were used to get there, can you get back to the starting document? With XSLT I'm pretty sure you can but I'm also fairly sure that parsing a template is a one way operation.

A can answer this.

If you KEEP all the content of the original source XML when creating output XML, then yes, the processes is reversable - providing you also have enough information to create the original relationships.

If you use the <output/> directive to create output that is NOT well formed (XML based) - such as HTML, then it is not reversable. It is worth noting that XHTML was designed to be well-formed so there is no reason not to output a well-formed result tree unless you are creating a CSV file or something.

[Selkirk]

A template engine for the web should meet certain criteria. For me, this criteria is the following:

1. Pass the Dreamweaver test.
2. Simplicity.
3. Validating.
4. Cacheable.
5. Self-Inspecting.
6. Secure.
7. Flexibility.

Outstanding post.

Does anyone have any criteria to add to this?

[tezza]

In developing a library, I spend time working on the interface to the library (note: I am sure you are well aware of this, I am just including it here to sound important =)). I write up code, actual PHP code (or whatever) that is a sample of how I would use the library of code I am writing. That way, when I go in to design the library, I have a clear understanding of what the end result needs to be.

A couple of good points there. For the most part, I have already developed the core interfaces. This has been a very evolutionary process based on "how I wanted to use a simple API" as you say.

As mentioned in the SF.net application form, XAO can be used in framework mode, or simply as a library of convenience.

In framework mode, you could have this.

include_once "classes/XAO_DomDoc.php";
$objAppDoc = new DomDoc("xhtml.xsl"); // optional param
$objAppDoc->ConsumeFile("article.docbook.xml");
$objAppDoc->TransformSend(); 

This is it's simplest form. In reality, you would inherit the DomDoc class and set up all your application initialisation in the constructor - including an application-wide xslt file if applicable.

note that docbook is a readily available schema you could use for writing articles or whatever other content management (see http://www.docbook.org/ for free online oreilly book)

or how about...

include_once "classes/MyApp.php";
include_once "classes/StarWriter.php";

$objAppDoc = new MyApp();
$objStarDoc = new StarWriter("OpenOfficeRocks.xxx");
$objAppDoc->ConsumeDoc($objStarDoc->objGetDomDoc);
$objAppDoc->TransformSend(); 

how you like them bickies?

BTW. Open Office docs (star office) are just zipped XML files. Gee, those "standards" keep popping up everywhere...

[tezza]

You can see why I call it XML Application Objects.

I should call this the "gravity" pattern - if it doesn't already exist.

Your XML application object ($objAppDoc) sucks up the content from all the other XML objects.

The other XML objects can optionally all be children of the DomDoc class (which the application object is also a child of). In this case, DomDoc class is the single fundamental building block of the app. This is what I meant earlier about centralisation through inheritance. Using an MVC is an purely optional. YOU DON'T HAVE TO USE IT THIS WAY, IT IS ALL OPTIONAL.

here is a very simplistic controller for those who don't mind being resticted to an MVC request protocol.

include_once "classes/MyApp.php";
$objAppDoc = new MyApp();
if(file_exists("articles/".$_GET["article"].".xml")){
    $objAppDoc->ConsumeFile("articles/".$_GET["article"].".xml");
}
else {
    $objAppDoc->Throw("This page requires a valid request for an article.");
}
$objAppDoc->TransformSend(); 

you could hide the controller stuff inside the MyApp constructor'

include_once "classes/MyApp.php";
$objAppDoc = new MyApp($_GET);
$objAppDoc->TransformSend(); 

[HarryF]

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.

No it doesn't hurt but I think when a particular wheel gets re-invented as many times as the template engine, it's interesting to ask why. More to the point, while building the list, I took a quick look at the examples and off the top of my head, at least 70% are "Smarty style" in that they have some kind of imperative syntax. Another 20%ish use HTML comments. In other words people are coming up with the same solution to the problem. Also the word "simple" appears with great frequency...

My guess as to why most of these template engines came into being is the authors took a look at what was already available and found it too complex / difficult to use then though "How hard can it be to replace a variable marker?" and wrote their own. But any template system that stays the course then needs to find some way to introduce "loops" and possibly conditional elements to the template syntax. Then perhaps they start introducing some kind of macro to allow for "re-usable HTML" and possibly re-invent the include statement and pretty soon it's as complex as the template system they were originally trying to avoid using.

So the question is can a template engine be designed that will suit everyone (or at least the majority) - one which offers such "value" that people no longer feel the need to re-invent it?

One area where I do see as a problem is, aside from PHP itself and Interakts Dreamweaver add ons, none of these template engines is supported by a deskop design tool. Being more specific, the "macro" features delivered by some like Smarty (e.g. the table function) are not supported. When you compare that something like ASP.NET's webmatrix, you've got a drag and drop editor which allows you to drag something like a Calendar onto your page (the Calendar perhaps being made up of a particular table structure).

Personally I think that's important because the "weight" of any PHP application is not the PHP code itself but the markup used for the user interface. If you look at the various petstore debates the equation was the same - most of the "lines of code" were in the templates; i.e. the HTML.

Not quite sure how to phrase it but perhaps a point add to the list of what a good template engine should do is something like;

8. Reduces the effort required build the templates.

The might also be re-phrased as "allows for re-usable user interface components".

In other words rather than;

<table>
<caption>{month} {year}</caption>
<tr>
<th>{1stDayOfWeek}</th>
<th>{2ndDayOfWeek}</th>
<th>{3rdDayOfWeek}</th>

etc. etc.

Instead you just have;

<calendar />

[jasonlotito]

No it doesn't hurt but I think when a particular wheel gets re-invented as many times as the template engine, it's interesting to ask why. More to the point, while building the list, I took a quick look at the examples and off the top of my head, at least 70% are "Smarty style" in that they have some kind of imperative syntax. Another 20%ish use HTML comments. In other words people are coming up with the same solution to the problem. Also the word "simple" appears with great frequency...

...snip...

8. Reduces the effort required build the templates.

First, #8 is covered under Simplicity. If the template engine makes something simple, it's also reducing the effort. If it's difficult to do something, even if the syntax is simple, the template is not simple. At least, that's my take, and how I interpret what I wrote, heh.

In response to your first paragraph, you make an interesting statement regarding how template languages look. Some using an imperative syntax, and some using HTML comments.

However, I believe both approaches are wrong.

A better way would be something like this:

<!-- IF isFormError -->
        <dl>
        <!-- LOOP ON FormErrors FOR EACH Error -->
                <dt>{Error.Name}</dt>
                <dd>{Error.Description}</dd>
        <!-- END LOOP -->
        </dl>
<!-- END IF -->

It mixes the two together. It passes the Dreamweaver test, it's simple. I haven't tested it, but it should validate. Assuming the template engine would compile this down to PHP (that sounds funny, compiling 'down' to PHP), it's cacheable. As far as being self-inspecting, secure, and flexible, well that's more an engine implementation.

However, some potential problems arrise:

<!-- IF isFormError -->
        <dl>
        <!-- LOOP ON FormErrors FOR EACH Error -->
                <!-- ALTERNATE color BETWEEN 'red' AND 'blue' -->
                <dt style="color: {color}">{Error.Name}</dt>
                <dd>{Error.Description}</dd>
        
        <!-- END LOOP -->
        </dl>
<!-- END IF -->

Okay, pretty straight forward, and something that is easily parsed and compiled. Howver, you run into a problem with the use of color: {color}.

Simply put, it fails the Dreamweaver test.

Hrm.. got me thinking though.

[Dr Livingston]

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.

That is very true.

This is getting to be a hot topic although I think a lot of people taking part forget the point to XSL ?

Okay, XSL-T isn't an applied Templating mechanism though with XML you can implement it as one, regardless of the definition of what an actual Template is...

But my point is that XSL was not originally meant for templating - it was meant to transform one form of data to another and it does it well, in an easy and structured manner.

Okay, some folks have great difficulty in learning XSL-T but so what ? This isn't to say there is a problem with the technology just because Job Blogs on Floor 14 can't understand the process of using XML and XSL for example is it ?

Folks... We need XML and XSL-T. Simple as that really, regardless of what you use it for or how, we need this technology.

As stated earlier as well I can agree that there are badly design XSL stylesheets out there, though you need to remember that there is usually more than one solution to the same problem in the sense of how you design a stylesheet ?

[Dr Livingston]

HarryF

In other words rather than;
Code
<table> <caption>{month} {year}</caption> <tr> <th>{1stDayOfWeek}</th> <th>{2ndDayOfWeek}</th> <th>{3rdDayOfWeek}</th>
etc. etc.

Instead you just have;
Code
<calendar />

_________________

Exactly Instead then of referring to a variable or data, you refer to the actual script which displays the calendar ?

I had done the same thing myself. I would put a well formed XML tag in the XML template and once my script found this tag, it'd create the compontent dynamically, not based on data from the template but from script.

About both the same idea I think ?

[prefab]

How about ColdFusion's take on this issue? OK, it's not MVC pure, but it does seem designer friendly. That said, I'm currently developing a conceptually similar approach with PHP. At the moment I use SAX to parse the XML template file and take the appropriate actions. Eventually I'll use HTMLSax (thanks HarryF)...

Some might argue that this approach will mix logic with presentation, they're right... but imo it all depends on how you allow this and how 'designer friendly' it is. If you look at Smarty for example, it clearly lets you mix logic in there, furthermore imo not at all in a nice way...

I guess my approach is a mixture syntacticly somewhere between ColdFusion CFML and XSLT...

- prefab

<!-- example of assoc array iteration -->
<ff_loop sid="arrayloop" src="myArray" scope="special"/>

<!-- applies to all -->
<ff_outputfilter sid="arrayloop" filter="substr" offset="0" length="4"/>

<ff_filterset sid="arrayloop" prop="name">
    <ff_outputfilter _assign="testing" filter="substr" offset="2" length="10"/>
    <ff_outputfilter filter="format" format="value %s"/>
    <ff_outputfilter filter="upper"/>
</ff_filterset>

<ul>
<ff_output sid="arrayloop" alternate="red|orange|green" offset="#get.offset#" limit="5">
     <li style="color: #_alternate_#">#_counter_# #_key_# #_value_# #_alternate_#</li>
</ff_output>

<ff_outputelse sid="arrayloop">
     <li>no results</li>
</ff_outputelse>
</ul> 

[HarryF]

Jason - have to refer you to the WACT Wiki on the TemplateView which is turning out to be the most insightful study of templates I've seen. Also, hope you don't mind but added you template criteria as Good Template Smells.

Although templates and the word "simple" often appear in the same sentence, think this discussion is already proving (as has been done before) that there's no simple answers and many different points of view. Hopefully the TemplateView is starting to identify the "problem" precisely, which is important step towards a better solution.

Some might argue that this approach will mix logic with presentation, they're right...

Have to pick that one up - this is one of the "fine details" of discussing template which is too easy to describe carelessly.

Put simply all templates have logic - i.e. there is always logic in the presentation logic. Whether it's imperative (PHP control structures / Smarty logic etc.) or declarative with the logic being "disguised" by an XML tree structure (like ASP.NET), it's still logic. There's no getting away from it.

Put practically the moment you want to generate the rows of a table, you need some form of "loop" which gets "repeated" whether it's;

<table>
{loop:results}
<tr>
<td>{data}</td>
</tr>
{/loop:results}
</table>

<table>
<!-- Loop:results -->
<tr>
<td><!--data--></td>
</tr>
<!-- EndLoop:Results -->
</table>

Or

<table>
<tr id="results" runat="server">
<td><%=data%></td>
</tr>
</table>

[jasonlotito]

Jason - have to refer you to the WACT Wiki on the TemplateView which is turning out to be the most insightful study of templates I've seen. Also, hope you don't mind but added you template criteria as Good Template Smells.

Although templates and the word "simple" often appear in the same sentence, think this discussion is already proving (as has been done before) that there's no simple answers and many different points of view. Hopefully the TemplateView is starting to identify the "problem" precisely, which is important step towards a better solution.

Not a problem. Actually, I have been looking at that wiki for a few days, just didn't read the section that described the method I discussed (I just read over it...go figure).

Also, no problem in adding it to the Good Template Smells section. I am glad to see other people find it useful. =)

[Selkirk]

<!-- IF isFormError -->
        <dl>
        <!-- LOOP ON FormErrors FOR EACH Error -->
                <dt>{Error.Name}</dt>
                <dd>{Error.Description}</dd>
        <!-- END LOOP -->
        </dl>
<!-- END IF -->

This is a good way to illustrate the difference between an imperative and declarative custom tag approach to embedding presentation logic in a template.

Here is the declarative equivalent from WACT:

<ErrorSummary>
    <ul>
        <list:ListItem>
            <li>{$ErrorMessage}
        </list:ListItem>
    </ul>
</ErrorSummary>

Advantages

• The custom ErrorSummary tag helps to capture more of the semantics of the template fragment. ErrorSummary captures the purpose or intent of what is being done. Programming code elsewhere determines the how.
• Reduces duplication of effort in templates. (as procedures or classes do in programming code.)
• The ErrorSummaryComponent that this tag is attached to provides a centralized place to attach logic for that purpose. This means that for some changes, you can make a change in one place instead of everywhere the template fragment is used.
• Descriptive declarative tags are easier to global search and replace on.
• This approach limits what it is possible for the html designer to do.
• Syntax is simpler for complex examples.

Disadvantages

• It is more difficult to create a new tag or new component than it is to put another IF or LOOP into the template.
  (although with WACT, you can create a new tag and use it in an application's templates without changing either the framework or the application in any way. Unfortunately this currently takes more programming skill than few simple IF or LOOP statements.)
• Immaturity of PHP component based libraries means few existing tags and components to choose from.
• This approach limits what it is possible for the html designer to do.
• Feels constraining to programmers.

Hope I'm not getting too far off topic.

[tezza]

<ff_outputelse sid="arrayloop">
     <li>no results</li>
</ff_outputelse>
</ul> 

As long as you are already intent on re-inventing the wheel again ;-)

May I make a suggestion...

instead of using ff_ as a prefix, why not use a valid namespace such as

<ff:outputelse> 

namespaces in XML were designed to provide the sort of scope management you are trying to achieve. If you do it the standards way, there will likely be more opportunities to enhance the technology.

[tezza]

One area where I do see as a problem is, aside from PHP itself and Interakts Dreamweaver add ons, none of these template engines is supported by a deskop design tool. Being more specific, the "macro" features delivered by some like Smarty (e.g. the table function) are not supported. When you compare that something like ASP.NET's webmatrix, you've got a drag and drop editor which allows you to drag something like a Calendar onto your page (the Calendar perhaps being made up of a particular table structure).

You're right Harry, this really is a problem - FOR PROPRIETARY TEMPLATE SYSTEMS. As I've mentioned before, there are already many WYSIWYG tools for working with content in XML/XSLT.

So far, all this talk about DreamWeaver support has centrered around the ability for a *content* editor to use DreamWeaver to edit the content without the proprietary template system being affected - "the dreamweaver test". How come everyone is ignoring the fact that there are already many content editors (such as XMetal) that allow you to edit your content as WYSIWYG with your standards based XSLT template applied.

authentic 5 is a standards-based, browser enabled document editor that allows business users to seamlessly capture ideas and information directly into an XML format, which are saved to any content management system, database, or XML repository, for later retrieval or transformation - unlocking corporate knowledge.

The editor loads the XSLT template in the background to determin the WYSIWYG at runtime.

Featuring tight integration with content management systems, Corel XMetaL 4 offers four integrated components, each built to meet the precise needs of authors, developers and IT managers. This robust platform enables anyone to create valid XML content, and streamlines the process of distributing information to the Web, print and other media.

* Corel XMetaL Author
* Corel XMetaL for ActiveX
* Corel XMetaL Developer
* Corel XMetaL Central

XMLdocs is a web-based content authoring, management and publishing system that is radically different from existing XML content solutions. Designed for groups of non-technical businesspeople, XMLdocs allows authors to create XML documents using familiar word-processing functionality from within Microsoft Internet Explorer.

There are waaayyyyy to many to list all of them...

So far I've just been talking about *content* authoring. Well how about developing new templates? How many of you can claim that even one software package out there helps users develop templates in your syntax - ie. generate your proprietary format?
Well since XSLT is a standard, some XSLT creation tools already exist. The best one I know of is by altova. There's bound to be more as time goes by. That is because XSLT has a future unlike the 70 odd non-standard attempts out there.

Presenting stylevision 5 – an innovative new visual approach to rapid prototyping and development of XSLT stylesheets for generating dynamic content. stylevision 5 can be used to develop input forms for Document Frameworks, which are standards based, web-enabled XML content management systems for working with XML content in real-world production environments, such as web-publishing, knowledge management or e-commerce.
----
Writing even the simplest XSLT stylesheets by hand is a truly daunting task [tezza: for end users], requiring an understanding of XSL elements, XPath query language, and complicated rules-based document processing models. By abstracting away the underlying error-prone semantics, anyone can write stylesheets using considerably less time, and resulting in substantial cost savings.

Talk about tools!

Ain't no problem for people who use XSLT as their templating system.

[tezza]

Instead you just have;

<calendar />

Ahem... and who designs the calendar widget???

<s:call-template name="calendar"/> 

The designer designs the calendar widget.

nuff said.

[tezza]

Okay, some folks have great difficulty in learning XSL-T but so what ? This isn't to say there is a problem with the technology just because Job Blogs on Floor 14 can't understand the process of using XML and XSL for example is it ?

An excellent, excellent point my friend. I'm glad you pointed this out.

There is no way I'm going to pretend that XSLT does not have the potential to be complex/sophisticated. But I will say this.

The difficulty level for the average sight-designer is "scalable". That is to say, they can bite off as much as they feel that they can chew. This is how I started. It's the same with everything. You begin with "Hello World" and then you learn only the bits that you need. This is not a new concept and XSLT is no different.

I think the problem for XSLT, in PHP specifically, is more one of infrastructure. "How do I integrate it easily into the flow of my program and deal with potential exceptions." It's only a matter of time before that problem is overcome (if it isn't already).

I've registered a project on sf.net to address this and should have an intro page up by the end of the day.