Re: [Phpgroupware-developers] the new templating system

[ceb]

i started now to change the framework to use css files instead to store
the settings in the phpgw_info array. the different layouts can have
its own themes, which are stored in phpgwapi/{layout}/css.
the function which selects the user themes to show them in the select
box of the preferences section reads the names of the css files from the
choosen layout's css dir.
for the default layout i ported all theme files to css. for idsociety
i created an idsociety and a submarine css file and all other layouts
only have a submarine css file right now. i like the submarine theme... :)

since it isnt needed anymore to load all the settings in the phpgw_info
array phpgroupware runs quiet a bit faster than before.

the notes app already uses the css file. to make the other apps working
with them, ralfbecker was helping me to change some of the apps tpl files.
but since all apps need new xsl tpl files, we will not spend much time to
update the old html tpls.

also i created xsl widgets for the categories_select_box, the
filter_select_box and the search_field which are used in the apps list
(main) pages. i made them as seperate widgets to have the ability to
include them seperatly. also i made a xsl widget, which includes all of
these sort/filter options in one widget.

also i created a delete_widget and an app_header widget which can be used
by all apps. the files are in phpgwapi/templates/default
and can be used for each layout. to make this work i modified the
get_tpl_dir function to pass the attribute $layout as the second
attribute.
so get_tpl_dir('phpgwapi','default') returns the path to the default
layout dir independend of the choosen layout.

ceb

On Thu, 26 Sep 2002, Dan Kuykendall wrote:

> 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.
>
>
>
> _______________________________________________
> Phpgroupware-developers mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/phpgroupware-developers
>