phpgroupware-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Phpgroupware-developers] Templating system for phpGW


From: Dave Hall
Subject: Re: [Phpgroupware-developers] Templating system for phpGW
Date: Fri, 13 Sep 2002 10:45:12 +1000

Ralf and Seek3r,

This sounds great.  

Have you looked at http://www.xopus.org , they have a browser plugin
based wysiwyg xml editor.  It might be worth looking at optional support
for it in phpGW.  

Just my 2c

Cheers

skwashd
Dave Hall
--- Begin Message --- Subject: Re: [Phpgroupware-developers] Templating system for phpGW Date: Fri, 13 Sep 2002 00:17:55 +0200 User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 For everyone who want to stay tuned, whats going on with the new template-system in HEAD (its not taged for 0.9.14, but will work too):

1) Import and export of the eTemplates from xml is now implemented. The xml is similar to XUL, but not identical. With this new function eTemplates can now be created in 2 ways:
a) via the interactive eTemplate editor
b) with a normal text-editor as an xml-file (at the moment the xml-file need to be imported in the db via the eTemplate editor, to be used)

2) I finished a first version of a referenz-docu about the widget-types and the parameters (for xml: tags and attributes): http://www.phpgroupware.org/cvsdemo/etemplate/doc/referenz.html

3) still availible is the eTemplates Tutorial (how to write an phpGW app with eTemplates, with an example app and lots of screenshots): http://www.phpgroupware.org/cvsdemo/etemplate/doc/etemplate.html

Stay tuned ...

Ralf

Dan Kuykendall wrote:
As you know I have been working on an xslt solution for our templates system. I am not all that concerned with what we use, so long as we stop having apps do so much of the UI layer and move to a more robust templating solution.

A little history on this:

I orignally looked at using XUL since that could have provided a way to create a UI that can be converted to various platforms. But so far XUL is only useful to mozilla and java developers, and there is no XUL to HTML code out there... So XUL was out as a base template structure.

I then started learning XSLT for a project at work, and found that it could do what we needed very well. I then wrote a templates class that uses XSL for the templating. It works very well, but I then needed some easy to use xml handling code. So I had to side track and write really simple, yet powerful ones. That is where the xmltools.php I have sent out came from. I also have some challenges with XSL and phpGW in that it still doesnt provide a common wiget set that should be used. I was starting to work on this by creating a set of html wigets in a wiget.xsl that was basicly a collection of named templates that took params. This could work well, but ralfbecker came back into the picture because ceb talks to him and she asked me about using his etemplates.

I had looked at ralf's etemplates awhile ago but I wasnt sure how well it could work. I was concerned with the performance and the issue with having to use his UI for creating all the forms. I have attached the irc log from our conversation today and I am very interested in using etemplates. Its a bummer for me because I have potentially wasted alot of time writing my xsl template class, but my interest is in getting phpGW to be as fantastic as possible.

Using etemplates over my xsltemplates has many advantages.
* It doesnt require XSLT support to be included in the PHP installs for our users
* It will give all apps a consistant user interface.
* It will give us a single point at which we can control translations since app developers wont have to manually use lang() themselves. * It also makes use of CSS more controlled, since the etemplates will handle adding the class="whatever" into the various html elements. * It gives developers an interface for creating their app interfaces using the etemplates editor.

etemplates also accomplish my original goal of seperation the UI generation for the apps. Apps will just generate an array (or xml) of their data and let the templates system handle the rest.

Im interested in everyones feedback about this issue. Whatever we decide to use, will show up in the HEAD code pretty quickly and ceb, ralfbecker (if etemplates is the soltuion) and I will start converting the API and core apps to use it. Hopefully we will get other help, but those are the ones I know of that are commited to jumping into this particular problem and solving it. We will still leave the old templates class in place for other apps to cling to for awhile.

Seek3r


------------------------------------------------------------------------

Sep 10 08:18:50 <ralfbecker>      ceb: Hi, how is the work on the templates 
proceding?
Sep 10 08:28:09 <Seek3r_> hey
Sep 10 08:28:33 <ceb>     oh heya Seek3r_
Sep 10 08:28:36 ---     You are now known as Seek3r
Sep 10 08:30:51 <neotexan>        hello Seek3r
Sep 10 08:31:51 <Seek3r>  hey neotexan
Sep 10 08:32:12 <neotexan>        I've changed jobs...no more defense:)
Sep 10 08:32:47 <ralfbecker>      Seek3r: hi
Sep 10 08:32:54 <ceb>     Seek3r: i told ralfbecker about the current state of 
the xml tpl class tests
Sep 10 08:33:45 <ceb>     right now he described how his class works... 
ralfbecker: could you repeat this please?
Sep 10 08:33:57 <ralfbecker>      Seek3r: i would like to explain abit the 
benefits of a widget-bases approach in comparison to plain XSL-transformation
Sep 10 08:34:01 <ceb>     i mean the function calls
Sep 10 08:34:06 <ceb>     :)
Sep 10 08:34:45 <ralfbecker>      u mean how it works from an apps-programmers 
side?
Sep 10 08:35:21 <ralfbecker>      u create the classe and optional pass a 
template name
Sep 10 08:36:10 <ralfbecker>      the u call a function call exec and pass a 
content-array (the data) plus a methode name, to be called with the returned data of 
the form
Sep 10 08:36:57 <ralfbecker>      with that approach the template class itself 
can resend the form (eg. the change the tabs of a tab-widget) without interaction of 
the app
Sep 10 08:37:20 <ralfbecker>      from the app-side it gets called when the 
data is ready to prceed
Sep 10 08:38:27 <ralfbecker>      with that approach u can have widgets with 
own programm-logic (like a tab-widget) which can work transparently for an app
Sep 10 08:39:08 <ralfbecker>      eg. a template-designer could create a 
template with tabs and it does not need any change of the app-code
Sep 10 08:39:59 <ralfbecker>      a tab-widget is only one example what is 
possible (and one which i already realized with the eTeamplates)
Sep 10 08:40:25 <ralfbecker>      Seek3r: do u understand my point?
Sep 10 08:40:51 *       fixe would like to announce the new AxisGroupware.Org 
portal. Please take a moment to check it out. Thank You.
Sep 10 08:41:02 -->  ____iggy_ (address@hidden) has joined #phpgroupware
Sep 10 08:44:59 ra3vat ralfbecker Sep 10 08:45:08 -->        UltraSparc 
(address@hidden) has joined #phpgroupware
Sep 10 08:45:09 <Seek3r>  ralfbecker: sorry, had to walk away for a sec to do 
something
Sep 10 08:45:11 <Seek3r>  reading now
Sep 10 08:45:41 <--  UltraSparc has quit (Client Quit)
Sep 10 08:46:48 <Seek3r>  ralf, yes I think I understand
Sep 10 08:47:16 <ralfbecker>      i think for the transformation or both ideas 
are very close
Sep 10 08:47:45 <ralfbecker>      with transformation i mean getting html from 
xml
Sep 10 08:47:50 <Seek3r>  right
Sep 10 08:48:23 <ralfbecker>      the advantage of the etemplates is the 
widget-concept and most of all the control-flow
Sep 10 08:48:24 <Seek3r>  so with your stuff the app packages up its data as 
xml or an array and passes it to etemplate
Sep 10 08:48:35 <ralfbecker>      yep
Sep 10 08:48:49 <ralfbecker>      the etemplate load the template (from the db, 
for now)
Sep 10 08:48:59 <Seek3r>  why from db?
Sep 10 08:49:10 <ralfbecker>      and creates a first html-form out of the 
template and the data
Sep 10 08:50:00 <ralfbecker>      as it showed up templates contains other 
templates, its quite fast to load it from the db
Sep 10 08:50:24 <ralfbecker>      the distribution is done via files and works 
with CVS too
Sep 10 08:50:37 <ralfbecker>      but i think this is a minor detail
Sep 10 08:51:28 <ralfbecker>      from the control-flow an app passed its data 
and a call-back methode to the template-class (and of course a template-name)
Sep 10 08:52:15 <ralfbecker>      the template-class generates an html-form (if 
we are just talking html) and puts itself (the template-class) as the receipient of 
the form
Sep 10 08:52:40 <ralfbecker>      when the users send the form, control gets 
passed back to the template-class and NOT to the app
Sep 10 08:52:46 <Seek3r>  sure
Sep 10 08:53:00 <ralfbecker>      the template-class or its extensions can do 
some post processing
Sep 10 08:53:23 <ralfbecker>      eg. build a time-stamp from 3-date-fields
Sep 10 08:54:01 <Seek3r>  hmm. thats cool
Sep 10 08:54:11 <ralfbecker>      after that post-processing, if none of the 
widgets require further user-interaction the result-data (as array) gets passed to to 
method of the app
Sep 10 08:54:35 <--  MAS (address@hidden) has left #phpgroupware ("Client 
Exiting")
Sep 10 08:54:37 <ralfbecker>      my first try of the template class was 
missing that feature
Sep 10 08:54:51 <ralfbecker>      but it turned out it makes things so much 
easier
Sep 10 08:55:19 <Seek3r>  this actually works well in the n-tier structure 
because its actually possible to have etemplates hit the app objects the same way an 
xml-rpc/soap client would
Sep 10 08:55:28 <ralfbecker>      specialy the widgets which are independent 
classes and extend the eTemplates
Sep 10 08:55:54 <ralfbecker>      yes
Sep 10 08:56:24 <ralfbecker>      i can then replace the UI-layer with other 
implementations of the etemplate-class
Sep 10 08:56:32 <Seek3r>  is that an easy task?
Sep 10 08:56:43 <ralfbecker>      i already have a working phpgtk-layer
Sep 10 08:56:55 <Seek3r>  wait, before the gtk...
Sep 10 08:57:14 <ralfbecker>      to replace the UI-layer?
Sep 10 08:57:17 <Seek3r>  yes
Sep 10 08:57:37 <ralfbecker>      it was done in 1-2 days
Sep 10 08:57:45 <ralfbecker>      for gtk
Sep 10 08:58:14 <Seek3r>  why does it have to be done by writing a new class?
Sep 10 08:58:29 <Seek3r>  why cant they just take the widgets templates and 
edit them?
Sep 10 08:58:41 <ralfbecker>      who?
Sep 10 08:59:07 <ralfbecker>      u mean to extend the etemplate with an other 
widget?
Sep 10 08:59:33 <ralfbecker>      u can just edit an etemplate to create an 
other look, of course
Sep 10 09:00:00 <ralfbecker>      the widget sometimes contain own 
program-logic, let me give you an example
Sep 10 09:00:04 <Seek3r>  I mean to create a new set of what the wigets look 
like
Sep 10 09:00:12 <Seek3r>  the html behind the widget object
Sep 10 09:00:18 <ralfbecker>      that is just editiong of the templates
Sep 10 09:00:43 <ralfbecker>      no difference to your or the actual 
template-concept
Sep 10 09:01:15 <ralfbecker>      the difference start if you want a new widget
Sep 10 09:01:24 <Seek3r>  ok, I see that
Sep 10 09:01:32 <ralfbecker>      the etemplates-class know several widget-types
Sep 10 09:01:43 <ralfbecker>      basicly all of html and some more
Sep 10 09:02:06 <Seek3r>  hmm... kinda works well with the new 5 part interface 
I put into the HEAD code... each of those can be the initial wigets
Sep 10 09:02:15 <ralfbecker>      to enable an app-programer to extend the 
etemplates without touching the class
Sep 10 09:02:41 <ralfbecker>      i created an extension-interface
Sep 10 09:03:08 <Seek3r>  hows that work?
Sep 10 09:03:15 <ralfbecker>      that keeps the class itself small and everone 
can extend it via a documented interface
Sep 10 09:03:35 <Seek3r>  they have an eTemplates extends class in their app 
area?
Sep 10 09:04:05 <ralfbecker>      the can have own eTemplates-extensions / 
widgets in theire app-dir
Sep 10 09:04:20 <Seek3r>  ok
Sep 10 09:04:32 <Seek3r>  sounds all very nice
Sep 10 09:04:40 <Seek3r>  now about the gtk interface
Sep 10 09:04:49 <ralfbecker>      if you decide a widget is worth putting in 
the api (or for now the etemplates-dir) you can put it there for all apps too
Sep 10 09:04:50 <Seek3r>  I heard you used XUL for that
Sep 10 09:04:56 <ralfbecker>      no
Sep 10 09:05:13 <ralfbecker>      XUL is an other idea for a UI-layer
Sep 10 09:05:23 <ralfbecker>      gtk used php-gtk
Sep 10 09:05:30 <Seek3r>  oh ok. Then lets ignore XUL for now
Sep 10 09:06:01 <ralfbecker>      instead of creating html from the template it 
creates a dialog with the necessary widgets
Sep 10 09:06:29 <Seek3r>  ok, next question
Sep 10 09:06:35 <ralfbecker>      if the extensions are programmed as eTemplate 
plus code it can be used by each UI-layer
Sep 10 09:06:38 <Seek3r>  what format are your templates in?
Sep 10 09:06:39 <ralfbecker>      k
Sep 10 09:06:55 <ralfbecker>      at the moment the templates are arrays
Sep 10 09:07:22 <Seek3r>  you store it seralized into the db?
Sep 10 09:07:44 <ralfbecker>      for now yes, i was thinking about xml ...
Sep 10 09:07:54 <ralfbecker>      there was just no need
Sep 10 09:08:17 <Seek3r>  hmmm... but this means the actual html tags are in 
the eTemplates class?
Sep 10 09:08:21 <ralfbecker>      i can programm an xml-interface which would 
allow programmers to write the templates with an editor
Sep 10 09:08:30 <ralfbecker>      no
Sep 10 09:08:47 <ralfbecker>      the etemplate-class uses the html-class to 
generate html-tags
Sep 10 09:09:13 <Seek3r>  the html class?
Sep 10 09:09:30 <ralfbecker>      the extemplates can have css-class-name and 
use css to customice it
Sep 10 09:09:56 <ralfbecker>      the html-class helps u to get arround the 
pain of putting html in php
Sep 10 09:09:59 <Seek3r>  the html class is a class with functions for all the 
various html elements?
Sep 10 09:10:06 <ralfbecker>      yes
Sep 10 09:10:23 <ralfbecker>      i use it in all my apps an other programmers 
us it too
Sep 10 09:10:36 <Seek3r>  so the eTemplates class doesnt actually generate any 
html itself?
Sep 10 09:10:41 <ralfbecker>      there are 3-4 versions in phpgw at the moment 
as it is not in the api
Sep 10 09:10:46 <ralfbecker>      no
Sep 10 09:11:08 <Seek3r>  yeah, I was starting to work on an html class for the 
api
Sep 10 09:11:18 <ralfbecker>      the html-class generates a table to organice 
the widgets
Sep 10 09:11:20 <Seek3r>  one that used out templates system for the actual html
Sep 10 09:11:30 <Seek3r>  out = our
Sep 10 09:12:19 <ralfbecker>      eg. an text-input-field widget calls the 
html->input function to generate the actual html
Sep 10 09:12:51 <ralfbecker>      but again we are very much into detail, 
details which the template class hides from the apps
Sep 10 09:13:10 <Seek3r>  I understand hiding it from the app developers... but 
I want to know the details :-)
Sep 10 09:13:22 <ralfbecker>      of course
Sep 10 09:13:54 <ralfbecker>      i just mean, i dont care about changing 
implementation details in the template-class
Sep 10 09:13:56 <Seek3r>  so the html class allows the etemplate class to set 
all the various atributes of each html element?
Sep 10 09:14:17 <ralfbecker>      to a certain extend yes
Sep 10 09:15:01 <ralfbecker>      the etemplates control only basic aspects of 
the html-options, the rest is doen at the moment via css
Sep 10 09:15:20 <Seek3r>  ahh. ok, thats fine
Sep 10 09:15:22 <ralfbecker>      lets say you can set the width of a 
text-field in an etemplate
Sep 10 09:15:40 <ralfbecker>      but you cant sets its color, this has to be 
done via css
Sep 10 09:15:50 <Seek3r>  thats fine
Sep 10 09:16:16 <ralfbecker>      one reason for the etemplates was to help 
geting a similar look-and-feel for all apps using it
Sep 10 09:16:35 <ralfbecker>      that is best to archive via a shared css
Sep 10 09:17:30 <Seek3r>  yeah, the api would have a collection of choices in 
css files... and then apps can add their own ones as well
Sep 10 09:17:58 <ralfbecker>      i think the strengs of the eTemplates concept 
is the program logic, the extensebility and for a novice programmer or designer the 
eTemplate-editor
Sep 10 09:18:45 <ralfbecker>      there is more work needed in actualy creating 
a shared set of widget and rendering it
Sep 10 09:19:05 <Seek3r>  I think its pretty clever. I remember when I looked 
at it many moons ago, the problem I had with it was that it wasnt really possible to 
create an interface without using your eTemplate-Editor
Sep 10 09:19:14 <Seek3r>  have you changed that at all?
Sep 10 09:19:45 <ralfbecker>      not yet, i will do it very quick if someone 
else considers using it
Sep 10 09:19:58 <Seek3r>  how would you make it possible?
Sep 10 09:20:32 <Seek3r>  oh, and by someone else, would the phpgwAPI and core apps count 
as "someone else"?
Sep 10 09:20:32 <ralfbecker>      i would read the etemplate from an xml-file 
instead of an array
Sep 10 09:20:42 <ralfbecker>      for shure
Sep 10 09:20:44 <ralfbecker>      ;-)
Sep 10 09:21:02 <Seek3r>  ceb: what do you think about this... youve been 
pretty quiet
Sep 10 09:21:30 ra3vat ralfbecker Sep 10 09:21:40 <ceb>   yes because i was 
talking with ralfbecker already
Sep 10 09:22:31 <ceb>     i like it , but i also would like to use an own 
editor and not the current etemplate interface
Sep 10 09:22:54 <Seek3r>  ralfbecker: I would also think we should setup the 
ability to use files instead of the db for the etemplates widget definitions... I 
would want to use the files for what we store in cvs, and then like the translation 
system, we can have a way to import this into the db
Sep 10 09:23:37 <ralfbecker>      i can do the import from xml within days
Sep 10 09:23:42 ra3vat ralfbecker Sep 10 09:23:51 <ralfbecker>    did i talked 
about the translation?
Sep 10 09:23:56 <Seek3r>  ralfbecker: ok. I should also send you my 
xmltools.php file
Sep 10 09:24:05 <Seek3r>  ralfbecker: no you didnt
Sep 10 09:24:47 <ralfbecker>      the etemplates can contain text, this texts 
gets automatically run throug the lang-function
Sep 10 09:25:05 <Seek3r>  ceb: yes, thats the only limitation that bothers me. 
The other is performance. I think performnce should be ok if the code is written 
well... but it is another layer that has the potential to slow things down
Sep 10 09:25:14 ra3vat ralfbecker Sep 10 09:25:16 <ralfbecker>    if you use 
the editor to create the etemplate, it adds the new phrases to the lang-files
Sep 10 09:25:22 <Seek3r>  ralfbecker: ok, cool... a central control to that
Sep 10 09:26:02 ra3vat ralfbecker Sep 10 09:26:04 <ceb>   and btw a small issue 
about the css: i dont think the apps should have their own css files also
Sep 10 09:26:07 <ralfbecker>      u can set an option if you dont want to use a 
lang-call
Sep 10 09:26:29 <Seek3r>  ceb: why not?
Sep 10 09:26:37 <ceb>     and the performance gets worse if it works like the 
current way to have the apps creating all their own tpl objects...
Sep 10 09:27:02 <Seek3r>  ceb: the css files shouldnt be like that
Sep 10 09:27:10 <ceb>     the css files would help to have a uniform look and 
feel for all apps
Sep 10 09:27:22 <ralfbecker>      thats my opionion too
Sep 10 09:27:30 <ceb>     kind of the themes right now
Sep 10 09:28:11 <ceb> if we again would have the apps decide about how they look all would stay like it is Sep 10 09:28:30 <Seek3r> ceb/ralf: wouldnt the apps need css classes for their custom wigets (via the extends thing)
Sep 10 09:28:35 <ceb>     the look of the ui should be uniform
Sep 10 09:28:43 <ceb> nop Sep 10 09:29:18 <ceb> we should code it that way the choosen 'theme' decides about the look
Sep 10 09:29:20 <ralfbecker>      for the extensions / new widgets they would, 
i would suggest to create a bigger pool of phpgw-standard widgets
Sep 10 09:30:12 <ralfbecker>      i would say noone should create its own 
date-entry-widgets as this is against a common look and feel
Sep 10 09:30:13 <Seek3r>  ralfbecker: yes, they will for the extentions... but 
if the standard widget set is complete enough, then that will be used very little
Sep 10 09:30:26 <ralfbecker>      yes
Sep 10 09:30:36 <ceb>     ok i have to run, sorry
Sep 10 09:30:41 <ceb>     bb in two hours
Sep 10 09:30:41 <Seek3r>  ceb: ok.
Sep 10 09:30:46 <ceb>     shower time...
Sep 10 09:30:48 <Seek3r>  this is some serious re-designing of things
Sep 10 09:30:59 <ralfbecker>      i think so
Sep 10 09:31:08 <Seek3r>  not as simple as switching to xsl instead of tpl for 
the templates system
Sep 10 09:31:24 <ralfbecker>      thats why i asked ceb about rethinking it
Sep 10 09:31:43 <ralfbecker>      no its alot about the programm-logic too
Sep 10 09:31:55 <ralfbecker>      how can we proceed now
Sep 10 09:32:13 <ralfbecker>      i can look into writing the etemplates via 
xml-files
Sep 10 09:32:35 <Seek3r>  give my xmltools.php file a look at
Sep 10 09:32:37 <ralfbecker>      if your xml-tools can help to translate xml 
to an array it would be helpful
Sep 10 09:32:45 <ralfbecker>      is it in the api
Sep 10 09:33:09 <Seek3r>  its can be used to convert any var (including arrays 
and class objects) into xml and then back
Sep 10 09:33:34 <Seek3r>  I will email it to you. I havent put it into the api 
yet, since I need to find a good point to where it will be loaded up.
Sep 10 09:33:45 <ralfbecker>      ok
Sep 10 09:33:53 <Seek3r>  it breaks convention with the normal api format of 
having a single class in a file
Sep 10 09:34:25 <Seek3r>  I do that because it uses multiple classes to 
generate a single xml document
Sep 10 09:34:32 <ralfbecker>      if you want to see the extensions working, 
you can have a look at my tab-widget-demo
Sep 10 09:35:10 <Seek3r>  where is all your code? do you have any app using it 
yet?
Sep 10 09:35:32 <ralfbecker>      the code is in the etemplates app
Sep 10 09:35:51 <ralfbecker>      the etemplates app is using the 
etemplates-class
Sep 10 09:36:05 <ralfbecker>      with etemplates-app i mean the editor and the 
db-tools
Sep 10 09:36:38 <ralfbecker>      at the moment im porting infolog to 
etemplates and i have a other app running with the etemplates
Sep 10 09:36:50 <ralfbecker>      that other app is not in the cvs
Sep 10 09:37:31 <ralfbecker>      the etemplate-editor is a complex application 
using the etemplate-system itself
Sep 10 09:37:56 <ralfbecker>      if you want i can show u around, i only need 
to power-up my development-system
Sep 10 09:38:15 <ralfbecker>      at the moment i'm in the office at a windows 
box
Sep 10 09:39:47 <ralfbecker>      Seek3r: could you mail me the xmltools-class 
so i can have a look if i can use it to read the etemplates from xml
Sep 10 09:43:38 <Seek3r>  whats your email address?
Sep 10 09:44:25 <ralfbecker>      address@hidden
Sep 10 09:44:57 <ralfbecker>      Seek3r: want me to show u the extensions, 
like the tab-widget
Sep 10 09:49:36 <Seek3r>  sure
Sep 10 09:49:51 *       Seek3r is fixing up the example of how to use his 
xmltools
Sep 10 09:50:38 <ralfbecker>      lets say in half an hour, could you 
checkout/update the etemplates-app on your box
Sep 10 09:51:29 <Seek3r>  Im ready now... just cleaning up the example a bit
Sep 10 09:52:02 <ralfbecker>      i need to get to my development-system
Sep 10 09:52:26 <ralfbecker>      i'm not developing under windows
Sep 10 09:52:46 <ralfbecker>      i be back in a fiew minutes, ok?
Sep 10 09:53:11 -->  Zone (address@hidden) has joined #phpgroupware
Sep 10 09:56:45 <Seek3r>  o
Sep 10 09:56:46 <Seek3r>  ok
Sep 10 10:01:08 <--  ralfbecker has quit ("ChatZilla 0.8.7 [Mozilla 
rv:1.0.0/20020530]")
Sep 10 10:03:48 <--  ____iggy_ has quit ("BitchX-1.0c19 -- just do it.")
Sep 10 10:18:19 -->  ralfbecker (address@hidden) has joined #phpgroupware
Sep 10 10:20:35 <ralfbecker>      Seek3r: should we start?
Sep 10 10:34:11 <Seek3r>  was just playing with my xmltools. I merged xmldoc 
and xmlnode into a single xmldoc class
Sep 10 10:34:55 <ralfbecker>      k, i'm adding a button to the editor to 
export a loaded eTemplate as xml-file
Sep 10 10:35:31 <ralfbecker>      Seek3r: if you want i can show u the 
tab-widget-extension
Sep 10 10:37:44 <Seek3r>  ok
Sep 10 10:37:56 <Seek3r>  did you find my xmltools easy to use?
Sep 10 10:38:09 <ralfbecker>      looks like
Sep 10 10:38:20 <ralfbecker>      it is exactly what i need
Sep 10 10:38:41 <Seek3r>  cool
Sep 10 10:38:54 <ralfbecker>      i'm just thinking about where to store the 
etemplates (for performance reasons)
Sep 10 10:39:48 <ralfbecker>      as complex etemplates, like the editor, 
sometimes consist out of 10 nested templates, i'm not shure how good it works from a 
file
Sep 10 10:40:07 <ralfbecker>      but one step after the other
Sep 10 10:40:17 <ralfbecker>      load the etemplate-app
Sep 10 10:40:35 <ralfbecker>      and type '%test' in the Name-field and hit 
Read
Sep 10 10:40:46 <Seek3r>  wait... where should I load this?
Sep 10 10:40:58 <Seek3r>  do a cvs checkout?
Sep 10 10:41:05 <ralfbecker>      do you have the etemplates app installed?
Sep 10 10:41:19 <ralfbecker>      if not checkout etemplates from HEAD
Sep 10 10:41:19 <Seek3r>  nope
Sep 10 10:41:43 <Seek3r>  whats the module name?
Sep 10 10:41:49 <ralfbecker>      it should work in HEAD or 0.9.14
Sep 10 10:41:51 <ralfbecker>      etemplate
Sep 10 10:42:06 <Seek3r>  grabbing it now
Sep 10 10:42:10 <ralfbecker>      k
Sep 10 10:42:30 <Seek3r>  I also just sent my new xmltools to the dev list. The 
new version has the single xmldoc class
Sep 10 10:43:02 <ralfbecker>      so i can load it via CreateObject
Sep 10 10:43:11 <Seek3r>  not yet.... but that will be possible soon
Sep 10 10:43:29 <Seek3r>  right now that class is in the xmltools file with the 
other functions
Sep 10 10:43:44 <Seek3r>  I will switch that to its own file so it can be used 
with CreateObject()
Sep 10 10:43:53 <ralfbecker>      btw. i would like to add a function 
LoadObject that just loads a class (or does nothing if the class is already loaded)
Sep 10 10:44:27 <Seek3r>  CreateObject() already does that
Sep 10 10:44:32 <ralfbecker>      i use the code of the function to ensure a 
class is loaded to extend it
Sep 10 10:44:34 <Seek3r>  hmm... maybe not
Sep 10 10:44:52 <ralfbecker>      but that gives me an object i dont need
Sep 10 10:45:09 <Seek3r>  also, since we are dropping PHP3 support I will 
probably change it to use include_once() instead of our custom solution
Sep 10 10:45:14 <ralfbecker>      LoadObject is identicat to CreateObject 
without creating it
Sep 10 10:45:34 <ralfbecker>      without php3-support thats no longer a problem
Sep 10 10:45:47 <ralfbecker>      i just dont want to use include_once
Sep 10 10:46:31 <Seek3r>  right, app developers wont use include_once(), only 
the api will use it
Sep 10 10:46:35 <ralfbecker>      i like the CreateObject or ExecMethod
Sep 10 10:47:12 <ralfbecker>      with the etemplates i only use methode-name 
no links as the cant work in gtk
Sep 10 10:47:15 <Seek3r>  oh, I also found a way to seriously improve the 
performance of ExecMethod()
Sep 10 10:47:26 <ralfbecker>      how?
Sep 10 10:48:38 <Seek3r>  http://www.php.net/manual/en/ref.funchand.php
Sep 10 10:48:54 <Seek3r>  by using call_user_func() instead of using exec()
Sep 10 10:49:10 <Seek3r>  exec() is very slow, but this call_user_func() is 
fine with performance
Sep 10 10:50:20 <Seek3r>  so by using many of the stuff in this page, I am 
re-writing CreateObject() and Execmethod() so that they can perform better and be 
more flexible.
Sep 10 10:51:00 <ralfbecker>      i thought u just use something like 
list($app,$class,$method) = explode('.',$string); $$method()
Sep 10 10:51:37 <ralfbecker>      did you installed the etemplates app?
Sep 10 10:52:58 <Seek3r>  yep
Sep 10 10:53:33 <ralfbecker>      call it to show the editor
Sep 10 10:53:43 <Seek3r>  but, Im running out of time... so we gotta hurry :-)
Sep 10 10:53:48 <ralfbecker>      then type '%test' in the name field
Sep 10 10:53:48 <Seek3r>  I see the editor
Sep 10 10:53:58 <Seek3r>  ok
Sep 10 10:54:15 <ralfbecker>      click on edit behind etemplate.tab_widget.test
Sep 10 10:54:50 <ralfbecker>      you can see the tab-widget in the 2. row
Sep 10 10:54:55 <ralfbecker>      if u click on show
Sep 10 10:55:07 <ralfbecker>      u can see it in action
Sep 10 10:55:11 <Seek3r>  I dont see what your talking about
Sep 10 10:55:38 <ralfbecker>      if you type '%test' in Name and hit Read
Sep 10 10:55:54 <ralfbecker>      it shows a list of templates matching that 
wildcard
Sep 10 10:56:31 <Seek3r>  Warning: stat failed for 
/home/phpgroupware/http/devteam/%test/setup/etemplates.inc.php (errno=2 - No such 
file or directory) in 
/home/phpgroupware/http/devteam/etemplate/inc/class.soetemplate.inc.php on line 639
Sep 10 10:56:32 <ralfbecker>      click on edit in the line: 
etemplate.tab_widget.test
Sep 10 10:56:35 <Seek3r>  but it shows the list
Sep 10 10:57:04 <Seek3r>  ok I see the details of the widget
Sep 10 10:57:20 <ralfbecker>      i tries to load the distribution file for the 
app '%test' ;-)
Sep 10 10:57:43 <ralfbecker>      the widget itself has labels separates by |
Sep 10 10:58:03 <ralfbecker>      and several etemplate-names separated by | too
Sep 10 10:58:09 <Seek3r>  I see
Sep 10 10:58:15 <ralfbecker>      click on show to see the template loaded
Sep 10 10:58:18 <Seek3r>  and I see what happens when I click show
Sep 10 10:58:21 <Seek3r>  neat
Sep 10 10:58:24 <ralfbecker>      k
Sep 10 10:58:29 <Seek3r>  this will take some getting use to
Sep 10 10:58:36 <ralfbecker>      from an apps point of view
Sep 10 10:58:48 <ralfbecker>      the chaning between the tabs is invisible
Sep 10 10:58:59 <ralfbecker>      the reload is done within the etemplate-class
Sep 10 10:59:02 <Seek3r>  yeah
Sep 10 10:59:29 <Seek3r>  how do I see whats in each of the tabs?
Sep 10 10:59:31 <ralfbecker>      so if this is the addressbook, a different 
template-set could use different tabs with an unchanged app
Sep 10 10:59:50 <ralfbecker>      u need to load the etemplate of each tab
Sep 10 10:59:51 <Seek3r>  nevermind, I found it
Sep 10 10:59:58 <ralfbecker>      go back to the editor
Sep 10 11:00:31 <ralfbecker>      an to to etemplate.tab_widget.test.work for 
example
Sep 10 11:00:43 <Seek3r>  yeah
Sep 10 11:01:09 <ralfbecker>      the tab-widget is not part of the 
etemplate-class its a self-contained extension
Sep 10 11:01:28 <ralfbecker>      but the editor autoloads each extension and 
show it
Sep 10 11:01:55 <Seek3r>  might as well add it to the etemplate class
Sep 10 11:02:00 <Seek3r>  but I see your point
Sep 10 11:02:09 <ralfbecker>      i could
Sep 10 11:02:41 <ralfbecker>      if you want to see the implementation of a 
simple extension look at date_field
Sep 10 11:03:03 <ralfbecker>      this widget-example allows to enter a date in 
3-text-fields
Sep 10 11:03:39 <ralfbecker>      it takes the content in a variable format 
(specified eg as Y-m-d) and puts it in 3 fields
Sep 10 11:04:02 <ralfbecker>      its in the class.datefield_widget.inc.php
Sep 10 11:04:13 <ralfbecker>      its a short and basic example
Sep 10 11:05:23 <Seek3r>  this is gonna take more than a couple mins
Sep 10 11:05:30 <Seek3r>  but now that I have it installed I can fiddle with it
Sep 10 11:05:42 <Seek3r>  do you think you could convert the notes app to use 
it?
Sep 10 11:05:47 <ralfbecker>      k, i'm going to add the xml-stuff
Sep 10 11:05:49 <Seek3r>  that would be a great example
Sep 10 11:06:07 <ralfbecker>      i think so
Sep 10 11:06:22 <ralfbecker>      i personal would use infolog ;-)
Sep 10 11:06:38 <Seek3r>  notes is super simple and easier to grasp
Sep 10 11:06:56 <Seek3r>  it would be a good example for everyone to start with 
in looking at it
Sep 10 11:07:09 <ralfbecker>      the first step to convert notes or infolog, 
is to create a nextmatch widget, i'm working on that
Sep 10 11:07:11 <Seek3r>  I then need to make the API use it for the overall 
interface
Sep 10 11:07:27 <ralfbecker>      there is a tutorial with an example-app
Sep 10 11:07:43 <ralfbecker>      its in the doc-dir of etemplate
Sep 10 11:07:59 <ralfbecker>      its at the same level like notes
Sep 10 11:08:18 <ralfbecker>      
http://www.phpgroupware.org/devdemo/etemplate/doc/etemplate.html
Sep 10 11:08:24 <Seek3r>  ok
Sep 10 11:08:42 <Seek3r>  I  will go thru that tonight or tomorrow night
Sep 10 11:08:59 <ralfbecker>      k, i will be here on irc
Sep 10 11:09:30 -->  kheb (address@hidden) has joined #phpgroupware
Sep 10 11:09:45 <Seek3r>  this looks like something we could use... it would 
certainly give us a more common look and feel thru all the apps, as well as a more 
controllable translation environment
Sep 10 11:10:51 <Seek3r>  we will need to get feedback from skeeter before we 
start making any final moves tho
Sep 10 11:11:47 <ralfbecker>      k


--
Ralf Becker
Outdoor Unlimited Training GmbH              Telefon: +49 (631) 31657-0
Leibnizstr. 17                               Telefax: +49 (631) 31657-26
D-67663 Kaiserslautern                  Internet:www.outdoor-training.de



_______________________________________________
Phpgroupware-developers mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/phpgroupware-developers

--- End Message ---

Attachment: dave.hall.vcf
Description: Card for <dave.hall@mbox.com.au>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]