Timothy Larson wrote:
I have a huge commit pending that adds the class, new, struct, and union concepts to the CForms binding, model, and template implementation. At this point there are still a few issues to work out, but I do not see any regressions in it that would affect forms that do not use the new features. The new features all work, and the included sample (still primitive) form development GUI is also working except for the save side of its binding because of some JXPath issues.
Please read the following list of issues and then express your opinion of whether I should commit the code now or post the updated patch on the wiki or in the bug database. In this case, I lean toward committing first to allow for easier discussion afterwords.
+1
early commits are beneficial for everyone, using the cvs for it is pretty much the _only_ way to actually do it
(and you should get benefits too: needing to do less merges to cope with the changes from the rest of us)
even more: I'm in the progress of adding some step-by-step binding samples (close to a tutorial, as opposed to the current more demo-like samples) would be nice to include the new stuff right away...
Interface changes: There are a few assorted new interfaces and a few additions to existing interfaces. These will need to be discussed and possibly changed or reverted, but I think this will be easier to do if we just go ahead and commit the code so everyone can get a feel for how it all works.
would be nice if you can sum these up together with the commit?
Class/New resolution: This currently works, but I am still experimenting to find the best code layout, lookup, and caching strategies to apply.
Premature validation: Union case value lookup causes early validation of the widget containing the case value.
Inefficient code: Still (at least) one instance where we climb the widget or widget definition tree because if a deficient caching strategy. Also, the template transformer still has some of the inefficiencies that Bruno pointed out. I believe these can all be worked out, but in the mean time I made it so the old and the new transformers can live together in the source code. It just takes one "extends" change to switch between them. By the way, there are aspects of the new transformer that should be faster than the current on, such as hash lookups of template names in place of linear searches with string comparisons.
CForms-specific binding issues: Added an experimental new repeater binding to give more flexibility in binding to XML documents. When its issues are worked out we can decide where to put it or where to merge the code or ideas.
great, I haven't started yet on the @strategy idea expressed some time ago... as I see things now it would make sense to try to see how binding-declaration of the different repeater-binding-strategies could be expressed with loads of common stuf...
The <wb:insert-node/> binding currently only registers a factory. Either it should actually insert a node or we should create another binding element to do so. The lack of a true node insertion binding hurts a use case within the sample form development GUI.
yeah, there is something clunky about that... basically the insert is followed by an update to do the actual binding... but that is only obvious if you know the code....
if there is a notation/strategy that yields a 'lesser surprise' then I'm all for
JXPath bugs affecting binding: These bugs currently break the sample form development GUI. Cannot create <prefix:localname><prefix:localname></...></...> if the prefixes match.
don't understand,
actually never tried anything namespacy yet on jxpath, but very interested to get it correct
The already-reported-bug about elements not being created automatically for paths to attributes.
WDYT?
let's get it in cvs, it will make progress and colaboration a lot easier
-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]
