It is not a case of "standards for the sake of standards"
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...
Originally Posted by suzkaw
application to sourceforge for new project.
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.
* 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.
it's about "content aggregation"
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.
you could hide the controller stuff inside the MyApp constructor'
$objAppDoc = new MyApp();
$objAppDoc->Throw("This page requires a valid request for an article.");
$objAppDoc = new MyApp($_GET);