Re: [Phpgroupware-developers] the new templating system

[Ralf Becker]

I had quite a long talk with ceb about the benefits and drawbacks of 
eTemplates and xslt. As it was in german, i will try to give here a 
translation of the important points:

address@hidden wrote:
> after getting practically experiences in using etemplates and xslt to
> create the html interface here my thoughts on how it could work out.
>
> i would suggest to use a wrapper template file to switch between the
> xslttemplates class to create the resulting html/pdf/... output format and
> a templates layer to build the interface for i.e. gtk or a resulting xul
> output. we could do so by detecting the requesting client and/or add a
> configuration part to setup.

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.

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.
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!!!

> 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.

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

- 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.

> 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.


> i think it is important to describe the layout in a xsl file to keep the
> flexibility for each app. to only have a basic layout description (i.e.
> xul-like format) to create any output format for any app seems to end up
> in a very limited layout and a big overhead of classes. it would mean we
> would have to create classes which handle the translation from a xul-tag
> in a html-tag a or pdf-formatting-object. this doesnt make sense since
> xslt can do this for us.
>
> for the gtk interface its sure needed to support a set of layout
> descriptions in xld ( :) ) format. also, not everyone should have
> to learn any layout description format to be able to support an interface
> for his app in the special format. i think, for some clients using (or
> will use) phpgw its good to have a class which creates the interface. but
> to create the html output and some special outputs, which are used by some
> apps only, should be done by xslt using xsl tpls.
>
> 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.

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

> so, the way i prefer (at least to build the html interface) does not
> support an automatically interface for every app in any output format. but
> it guarants attractive resulting output, less overhead and keeps
> flexibility for the apps.
>
> to have a more consistent layout for all of the applications we already
> agreed in using css files. i ported the phpgw themes to {theme}.css for
> the default layout. each layout can have own theme.css files which are
> stored in phpgwapi/templates/{layout}/css.

eTemplates already uses css and can load separet css-files as well as 
embeded css.

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.

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.

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
- all internationlisation in handled within the etemplates class, no 
more lang-calls are necessary, the lang-files get update by pressing a 
single button
- the dialogs can be designed with the interactive editor of the 
etemplates app or with an xul-like xml-dialect
- 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)
- 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

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.

Ralf

> ceb
>
> On Sun, 22 Sep 2002, Dan Kuykendall wrote:
>
>
> > Im not yet sure how its all going to work out best. I just want to find
> > the best solution for phpgw.
> >
> > My goals, and I think this match up with ceb, are:
> >
> > 1) To abstract more of the UI from each app
> > 2) More consistancy between apps
> > 3) an easier method for apps to get data from other apps and be able to
> > display that data. So appB could request data from appA as well as the
> > UI definition for displaying that data.
> >
> > 4) to have very nice looking html so that the interface can be very
> > attractive
> >
> > 5) needs to perform abot as well or better than the current solution. At
> > worst the tradeoff will be a very sligh performance loss (we can pick up
> > that loss by fixing other areas of phpGW.
> > 6) needs to be at least partially xml based and in a way that would more
> > easily allow for generating other interfaces such as XUL, GTK or
> > WinForms, etc...
> >
> > After spending what seems like way too much time on all this, we have
> > learned a great deal. Heres a run down.
> >
> > ceb ported the notes app to etemplates. ralf helped and had to add new
> > stuff to etemplates to support this, such as adding in some new
> > nextmatches support. notes works in etemplates, but ceb is not entirely
> > happy with the performance or with the resulting html. ralf has a few
> > new fixes for the performance, but the html result is still need to be
> > worked on.
> >
> > ceb is now trying out my xmltool and xsltemplate class on notes. She has
> > just started but is very happy with the resulting html and performance.
> >
> >
> > The problem with xsl is that each app would end up needing to support
> > other interfaces on their own. For example, if we wanted a gtk or xul
> > interface, each app would need to have a template set for generating
> > those interfaces. With etemplates we just need to do this in the api by
> > having a conversion of the widgets and all apps will automaticly be
> > presented in those interfaces. I think this would be a great great feature.
> >
> > So right now XSL has the clear advantage in producing attractive html,
> > and etemplates has the advantage of interface independance. Both help
> > solve 1, 2 and 3 in my above list. XSL does 4 and 5 but not much for 6.
> > etemplates does 6 great, is weak in 4 and so far with 5 but ralf says
> > his fixes will help on 5.
> >
> > So seeing that etemplates is weak were xsl is strong and xsl is weak
> > where etemplates is strong, we are going to look at a marrage of the
> > two. This would mean that apps would just define their basic interface
> > in xml (XML Layout Doc, XLD for short), this XLD is very XUL like.
> > etemplates would load this up, do the calls to the bo class that is
> > specified in the xml layout doc. It will generate the xml result, load
> > up the xslt templates which are needed and let the XSLT template class
> > take over. In XSL we will have a version of every needed widget which
> > will be used to generate the html.
> > So we will have various template sets, which will actually be XSL files.
>
>
> to generate the html interface we wouldnt need the xml files but could use
> the xslttemplates class directly.
>
>
>
> > We will also want to figure out how to have a special way for app
> > developers to customize their html. So that they will still define the
> > interface in the XLD, but will also be able to have direct control of
> > the overall layout of the app when its presented in HTML. I am still
> > trying to figure out how best to solve this and still make sure they are
> > using etemplates, so that their app can run via gtk, xul and so on.
>
>
> the best way to have the needed flexibility is to have the layout
> description in xsl files.
>
>
>
> > We always look forward to feedback, but also keep in mind that we have
> > been looking at this for a long time and may get grouchy if the comments
> > are overly critical :-)
> >
> > But seriously, fresh input is very helpful when you have been looking at
> > something for too long and could be missing some easy and obvious (to
> > anyone but you) solution.
> >
> > Seek3r
> >
> > p.s. ceb and ralf deserve tremendous thanks for their work on this. In
> > the end everyone will greatly benefit from their efforts.
> >
> > address@hidden wrote:
> >
> > > the index function of notes is now ported to work with class
> > > xslttemplates. the class uses xslt to create the html output. it is the
> > > other method, next to etemplates, we are testing right now.
> > > did someone look the etemplates version? any comments?
> > >
> > > grtx. Bettina [ceb]
> > >
> > > [have a lot of funk]
> > >
> > >
> > >
> > > _______________________________________________
> > > Phpgroupware-developers mailing list
> > > address@hidden
> > > http://mail.gnu.org/mailman/listinfo/phpgroupware-developers
> >
> >
> >
> > _______________________________________________
> > Phpgroupware-developers mailing list
> > address@hidden
> > http://mail.gnu.org/mailman/listinfo/phpgroupware-developers
>
>
>
>
> _______________________________________________
> Phpgroupware-developers mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/phpgroupware-developers


--
Ralf Becker
digital ROCK                                 Telefon: +49 (631) 31657-51
Leibnizstr. 17                               Telefax: +49 (631) 31657-52
D-67663 Kaiserslautern                       Internet:www.digitalROCK.de