Re: [Phpgroupware-developers] the new templating system

[Dan Kuykendall]

Ralf Becker wrote:
> > i would suggest to use a wrapper template file to switch between the
> > xslttemplates class to create the resulting html/pdf/... output format 
> > and
>
> I would like the idea, unfortunally the concepts of the eTemplates and 
> the xslt are not identical:
>
> a) xslt renders the content of a page (for shure in a lot more flexible 
> way than the old templates) and allows to have different output for html 
> or eg. pdf. This is similar to the eTemplates: the app puts the variable 
> content in a variable and passes that with the name of the template to 
> class which renders the page.

Correct, XSL allows us to control the resulting HTML in a very flexible way.

> b) xslt does NOT allow any program logic like the eTemplate and the 
> extension-interface of the eTemplates. Let me give an example: an 
> eTemplate-extension like eg. the tab-widget has its own program logic:
> if the user clicks on a tab, the widget loads that tab. In a regular 
> web-application this is done by passing the control back to the 
> application and the app checks what to do. That way each app needs to 
> know from the tabs and tabs are only possible where the app-developers 
> implemented them. The widgets in eTemplate are different, they can load 
> eg. a new tab without passing control back to the app and without the 
> app-developer needs to care in his code if a tab-widget is used or not.

You are wrong about this. XSL *does* have program logic. You can 
actually do quite a number of useful functions inside of XSL.

Also, this is not a great example. I can do all of this with XSL and 
<DIV>'s. I can just hide and unhide the <DIV>'s as needed for each tab. 
In fact I have already done this for an application I just wrote in the 
last month.


> Let me explan what happens after a app calls the exec-function of the 
> eTemplate-class for html:
> 1. the class shows the phpgw-framework (eg. navbar, ...)
> 2. the class puts a single (!) form around the rendered template and
> 3. puts its own calls-methode process_exec as action in the form
> So far it is similar to xslt, the difference starts when the user 
> submits the form:
> 4. the process_exec method of the etemplate class gets called and 
> retrievs the changed content from $_POST[] (or $HTTP_POST_VARS as it was 
> called before) then it parses the content to allow widgets to request a 
> reload, like the tab-widget does if the user clicks on a tab or to 
> change the content: eg. the date-widget in eTemplates take a timestamp 
> as input and renders that as 3 textual inputs or select-boxes, but it 
> returns a timestamt to the app. This logic is necessary to allow komplex 
> modular widget.
> 5. process_exec calls the callback of the app with the (changed) content 
> as parameter.
>
> SO THIS WILL NOT WORK EASILY!!!

Your right. This is very complicated stuff. But I think we can do all 
this using XSL. I will explain how in a bit.

> > to use xsl files to describe the layout seems to be the most flexible way
> > to get an attractive layout, have the data seperated from the layout
> > description and keep a good performance.
>
> - Without any doubt the xslt is more flexible in rendering any layout, 
> as this was never a design goal of eTemplates. The goal (from the layout 
> point of view) for etemplates is a consistent user-interface archived by 
> a set of common widget. This make the app-development easier and each 
> app provits automaticaly by the further development of the widgets. Eg. 
> if the date-widget gets a nice calendar-popup to select the date with, 
> it is used in all apps, without any change. This is the concept of all 
> modern userinterfaces.

With the XSL widgets templates Im putting together, we will be able to 
have the consistancy.

> - the total separation of data and layout is archived in etemplates too

Ditto with XSL

> - i made some benchmarks with the notes app: the settled 
> etemplate-interface - it already include a nextmatch-widget - is a few 
> percent slower than the basic xslt interface without any style-sheets.

ceb has now gotten the XSL templating to run *faster* than the existing 
templating system.

> > also, this way app developers can change the output format individually.
> > an example for changing the output format would be to create pdf output
> > to show invoices in an overall html interface.
>  >
>  > we can use the xslt parser to create alot of output formats next to 
> html.
>  > i looked at examples to create pdf-, java source-, vrml-output using 
> xslt
>  > as well but didn't test it practically.
>  > not every app would need all of the formats, and some of them we dont 
> need
>  > at all :).
>
> That is possible with eTemplates too, as with xslt it just need someone 
> to specify the transformation / code it. eTemplates already has proved 
> that it is able to run an app from the same (!) code under gtk and html. 
> But that needs not only the ability to render the layout, it need 
> program logic or differnt ui-layers in each app.

Yes this is a problem I have with just using pure xsl. Each app has to 
specificly support each interface type. In some cases this makes the 
best sense. For example, if we support WAP (or whatever slimmed down 
html cell phones and such are starting to use), then its best for each 
app to create a specific template set for this which displays only the 
nessesary information in a nice format. This is not something that could 
be automated in etemplates style.

> > for the gtk interface its sure needed to support a set of layout
> > descriptions in xld ( :) ) format.

XLD is an XML doc format I am creating. Its similar to the xul-like doc 
that etemplates is now using, except that its designed to nest properly.

> > using xslt avoids a number of extra classes and layers, but every app
> > developer would have to create the tpl sets for the special format by
> > himself.

Yes, this is what much of this boils down to.
We have to choose between XSL which allows for a nice web interface, but 
isnt automaticly portable to other interfaces, or etemplates which has a 
good deal of overhead, and not so great HTML.

I have an idea for meeting both needs with a new etemplates 
implementation... more on that in a bit.

> For my understanding both concepts needs new / additional classes. Some 
> like Seek3r's xmltools are used by both, as the both are xml-based.

Yes, but the stuff for XSL is much smaller and quicker. Also with some 
tweaks Im doing to the XSLT Template class, its possible to have offload 
most of the rendering to the browser (if it supports it XSLT). SO far 
only IE6 has a stable XSLT engine, but mozilla's is getting close to 
being stable enough.

> To summerice the above: it is NOT possible to use a simple wrapper (like 
> eg. the different db-classes) to abstract from the underlying 
> template-system OR all the progam logic stuff needs to be implemented 
> for xslt to and it has to be limited to a set of common widget where the 
> xslt-template-class can do the same stuff like process_exec for the 
> etemplate. This leads only to two differnet syntaxes for the same 
> concept. Which negates all arguments about the flexibility of xslt.

Right, a simple wrapper is not going to work. But a redesigning of the 
html rendering etemplates class to use XSL at its core, along with some 
better integration into the API I think we can make it work for both worlds.

> Ceb suggested now a temporal split / branch (for the notes app and 
> others) to enable more developer to compare the two concepts. I support 
> that idear, but dont think it is possible to support to branches on a 
> long run.

Yes, this is a good temporary solution to allow both systems to be 
tested out an improved. It will help us find the real winner.

> My recomandation is clear ;-) useing the eTemplates and (if necessary 
> from the layout) use or allow xslt for rendering the widget.
>
> There are a lot more arguemts for eTemplate, just to mention a few more:
> - context sensite help is already implemented, help messages can be 
> added to any widget

Very handy feature, that I think is a sign of why something like 
etemplates is so useful.

> - all internationlisation in handled within the etemplates class, no 
> more lang-calls are necessary, the lang-files get update by pressing a 
> single button

Yes, and this needs to taken into account. I have already started work 
on putting this kind of support into the xslttemplate class as well. It 
doesnt work as well for it tho.

> - the dialogs can be designed with the interactive editor of the 
> etemplates app or with an xul-like xml-dialect

Useful, but this may break on and off during development and 
adjustments. It also needs to be written and used more as a starting 
point. Once the app gets a little complex, I think it becomes too 
cumbersome.

> - eTemplate have a highly modular design: each app can extend the 
> eTemplate by developing own widgets (using an defined interface, that is 
> used to implement all more complex widget in the eTemplates-class itself)

Ditto for xsl, since apps can load up their own additional xsl files.

> - there is already documentation about the eTemplates: a tutorial 
> http://www.phpgroupware.org/cvsdemo/etemplate/doc/etemplate.html and the 
> reference docu 
> http://www.phpgroupware.org/cvsdemo/etemplate/doc/referenz.html

OK, I cannot compete with actual documentation :-p

> I would like to invite everyone to compare the code of the etemplates 
> port of notes and the xslt-port. Have a look how elegant and simple the 
> new nextmatch-widget make scrollable lists. At the moment u need to tag 
> notes at a date of 2002-09-20 to get the etemplate version.

I put in a nextmatches widget for the XSL camp, and ceb us already using 
it in notes. So both apps should be fully functional from either xsl or 
etemplates, so its a good time to compare the two fairly.

Dan

p.s. I am sending this and will start writing an explaintion of how I 
think etemplates can be re-written to properly use XSLT and therefore 
give us the ability to produce attractive and flexible HTML.