My intention is not bashing the edit wizards. My intention is to think about where to put our effort. In creating new wizards, or in improving the wizards we already have. This is the reason why i started this discussion.I am aware that it would be better to write new code than rewrite the old one, but I take offence at the way people like to bash the wizards without ever properly learnign how to use them. That is not a productive way of going about it.
I really think that the wizards, from a users point of view, are pretty good. An annoying problem with the wizards is the lack of a locking mechanism. Editorial people at the vpro frequently saw the message that something was changed in the cloud while trying to save all the information entered in the wizards.
A big problem with the existing wizards is it's architecture. They have been designed in such a way that a client browser could manage clouds, and that at the end (after all mutations) the client could sent information to mmbase to compute these actions. In the end this design was never used. Dove was created (to make it possible to communicate from browsers with MMBase), and for every user that is working with the wizards parts of the clouds are copied and maintained out of the MMBase cloud (a copy of the partial cloud that is used, and another copy of how the partialy cloud has been mutated). This would have made sense if the clouds were maintained by the clients itself, but now these clouds are maintained on the server itself which results in a waist of resources, especially if you are having a lot of persons using the wizards... This design also disables us to use locking of objects, it would be better to use the MMCI directly, and maintain the transactions within MMBase (this means not using partial clouds on top of MMBase). I don't have to go into more details now, but these wrong design issues could be reconsidered. And I think it would be possible to make new wizards that are easier to understand and more powerful. I rather put some effort in improving the transaction handler within MMBase than creating vague constructions on top of MMBase that will implement some sort of locking mechanism within the edit wizards.
Rob
