RE: [EDITWIZARD] remaining issues

[Ernst Bunders]

Title: [EDITWIZARD] remaining issues

Reading these things i wonder about a fiew things:

 

1 is it not a good idea to store all this data in de database for the length of their use? i can imagine the memory use weighs more than the database overhead

 

2 am i right those form xml's don't change till the wizard is being altered (like jsp's) , can't they be cached?

 

2 is it not a good idea to add checkout function to nodes? this will allso make things easyer?

 

Ernst

-----Oorspronkelijk bericht-----
Van: Pierre van Rooden [mailto:[EMAIL PROTECTED]
Verzonden: maandag 2 juni 2003 16:21
Aan: '[EMAIL PROTECTED]'
Onderwerp: [EDITWIZARD] remaining issues

In the past weeks I have been working on improving parts of the editwizards (and, consequently, dove). I added search facilities in the list, better security, customizable error pages, a few additional options on lists, and I fixed a few bugs.

I am working on the documentation (but due to the sheer number of options available, this will take some time).

There still remain a number issue with the wizards which take some more time to solve.
These are the following:

[1] All data regarding wizards is stored in the session. This includes four xml trees: the 'original data' retrieved from MMBase, the 'user data' including changed and new objects, the wizard schema, and the 'form xml', which is passed to xsl and used to create a (html) form.

All these objects stay active and in memory.

[1a] The wizard schema is read and maintained in memory for every user that logs on - even if they use the same wizard. It woud make more sense if there would be a 'xml reader' class associated with the wizards. Thsi class can read teh xmls (and probably cache them), and pass them to wizards that need it. Everey user session will then have a refernce to a wizard retrieved by the reader, but since the wizard is not 'created' by the user session, more users can use the same instance of the wizard tree. In addition, by caching wizards, loading the xml can be sped up.

[1b] The form xml is only used to create a html form - but the wizard somehow keeps it in memory. It may save memory if wizards discard the xml once it is used. The code that creates the form (in Wizard.java) could simply drop it (haven't checked yet if this would have consequences).

[1c] Since MMBase has no locking mechanism, the wizard maintains a 'original data' xml tree. The Dove uses this tree to validate changes (so if someone changes the object, the wizard issues an error). Perhaps a less memory-consuming way can be found to check on changes in an object (so the original data tree is not needed), but I gather this would either require versioning (or 'last modified dates'), or another method to make comparison easy (hashcodes?).

[2] Wizards cannot be configured, at least not 'globally'. It is possible to pass configuration parameters (such as maxuploadsize), but no way to add a config file with global settings.

If there is a static 'reader' class for wizards (see 1a), this could possibly also contain configuration settings, read from an xml file. A wizard ProcessorModule class could be a way to implement this (as it can be read from the bridge, and allows customization through the admin pages).

[3] Wizards issue a LOT of errors in the log, because they attempt to validate every xml file.
This is not very practical. While useful when debugging, in a typical production environment you would like to turn validation off (quicker, and no senseless warnings if you forget a doctype). This could be done if you can configure the wizards (see 3)

[4] Documentation sucks. Am on it. Takes a lot of time to write though. Bare with me.

[5] Some security issues still remain:
- the wizards do not check if a relation between two objects is allowed. This should probably be checked in list.jsp when creating a searchlist

- popupwizards ('startwizard' fields and commands) now check if you can edit an object, but not if you can create it. This is because you cannot read rights directly from the name for a wizard. A xml reader may be used to facilitate info about a wizard (by pre-fetching it and checking the create action in the xml).

[6] No interactive error handling: If something goes wrong, you are OUT. There is no way to trace back when you made a mistake (i.e. made a relation you were not allowed to, or entered data that mmbase or the database refused). An interactive way to step back and re-enter data would be valuable.

I would value if people add their own points/suggestions to this list. I will also add these items as bugs or wishes to the bugtracker, to track their progress.

I know that people (i.e. Finalist) are ready to take this up. As such, as the maintainer of the editwizard project, I plan to re-open the project for the purpose of fixing these bugs/wishes. This will allow people who wish to contribute to join the project.

Pierre