Summary of the developer IRC session on March 21st.

There were in the chat:
 k-fish (Karsten)
 Loge   (Marc)
 rabol  (Steen)
 newb   (Frank)
 canani (Ricardo)
 brr    (Bjørn)
 mdelamere (Michael)

I'll try to summarize what was discussed, most of the issues are still
current.

config.inc.php
--------------

We want to move away from the current php include file, and take the
XML approach.

This came up after a hard discussion about write permission on the XML
file, drawbacks of XML parsing, advantages of XML (validation) and a
discussion about what constant values are in the configuration.


Passing variables
-----------------

We settled on a base set of variables to use when calling
modules. Parameters are to be passed via GET if simple links are used,
when forms are used, everything is to be passed via POST. No mixing of
GET and POST in one call as it can be seen at some places around the
code now.

We will use strictly $HTTP_GET_VARS and $HTTP_POST_VARS, for 0.7 and
later releases this will be replaced by $_GET and $_POST. Every
variable has to be checked and/or typecasted to be safe.

Standard variables are:
 mod, obj, view, op

mod to indicate the module, obj to indicate the object (contact
entreprise, user,group...).

On a list: view=details or view=newform (to update) or
view=deleteconfirmation and on the delete/confirmation form, we post
the op=delete.

op is update, delete, and create only. op is POST!


OO structure
------------

A heavy discussion went on for almost an hour. Finally we agreed on
newb and me to continue working on the "example OO notes module" and
then discuss OO'ing again after a while. This has not been happening
yet, sadly...

Anyway, some of the points discussed were...

1. OO'ing is A Good Thing.

2. Having one central index file acting as a hub for everything is A
   Good Thing, meaning we will have a central app object providing a
   Smarty instance, XML parser, what is currently in the userfunc.inc,
   container.inc, ...

3. We discussed the pro's and con's of instanciating all modules at
   app startup (and store them in the session) or on demand. We didn't
   come to a solution here.

We agreed on postponing this a little, until newb and I had worked
further on the notes module OO'ing process.


Output
------

We discussed the way of returning output to the client.

newb and I favour the method of having the module return just a
template and the associated data. The module would only be responsible
for the modules part of the output. Header, footer, menu, ... would be
rendered by the main app object.

The data passed back by the module could just be an array, since
Smarty can handle the assignment of arrays to a template. If something
like an image or a PDF file would be returned, the module would output
it, and just exit().

mdelamere suggested to let the module return a half-rendered template,
to have complete control in the module.

We then agreed, that everybody would try to work out a working example
and that we would afterwards discuss this again. This is still open.


Overview feature
----------------

When OO'ing is further done, every module should provide a
get_overview() or sth. similar if it makes sense. The overview module
would then just call the available methods and we'd be set.


Tasks / Release Management
--------------------------

1. Find a XML parser written in PHP only
   This has been solved, phpDOM is already in use.

2. Update roadmap, make people back off from the webmail, answer some
   FAQ about filemanager module, ...

3. Complete database abstraction.

4. Fix bugs, fix bugs, fix bugs.

5. Create sample implementations of output solutions (newb/k-fish,
   mdelamere/Loge).

6. Continue work on the OO'ing proof-of-concept (newb, k-fish).


Probably a lot of interesting details are missing here, so have a look
at the full log if you want the gory stuff. It is available at
 http://www.k-fish.de/krabutzig/mgw/devtalk-020321.html


Karsten