Re: [Phpgroupware-developers] the new templating system

[ceb]

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.

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.

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

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

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
>