Marc Portier wrote:
Hi there,
just found a small glitch in the aggregate-binding which is somewhat related to a broader discussion IMHO
(yeah, I know its related to the bug we closed only yesterday, just that I found out a nicer test after that)
now that the sample is in cvs, I opened a new bug for this specific issue: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=28307
[just an apetizer]
<snip cause="now you can check for yourself with the new aggregate sample"/>
But the actual rant still holds:
I'm a bit reluctant to check this in since as far as I understand this will also fire the validation on the object, which (again AFAICS) should be without danger in this case, but kinda blows high over what is really needed here...
[the main course]
widgets are complex babes but our current code structure
(naming, atomicity and resposibility of its methods) isn't really helping me... well, actually it might be useful for more people then just me to clear the confusion out...
in stead of trying to guess from current code, I'ld like to get a hold of what (and why) should happen from a higher level, and from there use that knowledge to try clean up, refactor and make self explaining what we have since now IMHO we've ended up in some historical soup which is soon going to prevent us from effectively add features or fix bugs
if this is only my limited view of things just say so, in the other case: who wants to take a first stab?
What is the state-machine behind the widgets/fields?
Hurray! The more I dive into the code the merrier I get!
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.
<irony of-type="needless, but hey: I'm human.">
Adding to it the extra challenge to follow up on history and argumentation thanx to a very important woody->cforms rename on a version management system that doesn't support directory renames and guess what: it really looks like we should get 2.1.5 out asap.
</irony>
Wake up, people! This will not go away by ignoring it.
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
more?
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 :-))
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)
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')
Comments, suggestions and help welcome. (Guess, what I also don't have time for this)
-marc= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
