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. 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. 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. 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. JXPath bugs affecting binding: These bugs currently break the sample form development GUI. Cannot create <prefix:localname><prefix:localname></...></...> if the prefixes match. The already-reported-bug about elements not being created automatically for paths to attributes. WDYT? --Tim Larson __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/
