We jointly got the cforms internals code into a mess: too much features have been hack-added (even worse: without updating javadocs) rather then refactor-added.
I do propose:
- some refactoring of the kind
- introduce more granular methods
(e.g. to call parseValue() in stead of getValue() in all occasions
where the return is ignored anyway?)
- method/member renamings
- javadoc cleanups
- clean out the binding interface
(this will surely break class/new/union/ binding)
- solidify classes and interfaces by making immutables where possible and appropriate (IMHO the form-definitions could benefit)
- finally fix the binding of the repeaters
- add a row-identity aspect to the repeater-rows
- ATM I even think it should combine multivalue-binding since that looks strongly like another (unneccesary?) fork of the repeater-binding code
- get into adding the stuff from http://wiki.cocoondev.org/Wiki.jsp?page=WoodyScratchpad
+1 I also got the feeling of mingled functionality in some methods (e.g. getValue() causing always also the validation) when diving into the code for finding out the reason for the to-early validation on wd:action.
While getting into above I'ld like us all to have the freedom to (temporary) break things: the class, new, union, struct (possibly even aggregate) comes to mind.
This is not because I find those additions (nor the people that did it) to be the target suspects for the current state of things.
Plus, the more stuff we break, the more reason there will be for more hands to help in! (now from who did I learn that :-))
Huh? ;-)
But seriouly: The above would be my main '-1' argumentation to anyone proposing to do this in a separate CVS branch (just so you know) (putting down some CFORMS_0.0.1 tag before on the cfroms block might be meaningfull though)
+1 for the tag. Maybe after 2.1.5 release, otherwise the release should include the tagged version then.
In any case looking for suspects is not the goal, nor is it to break stuff. It rather is about creating a clean basis to re-add the needed features of the class/new/union/struct/repeater-binding allong the lines of how we've been discussing them lately.
AFAICS it's this or keeping eternally waiting at the side of the swimmingpool. (= mpo-logism for keeping cforms 'unstable')
Same feelings here.
Joerg
