From: Upayavira [mailto:[EMAIL PROTECTED] > Tim, > > Commit it. With CVS, we can always roll back if it breaks anything > seriously, and sticking it into CVS is the best way to get people to > look over your code. And if there are bugs, other people can > then get on > and fix them. > > Regards, Upayavira > > 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. > > > >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.
I can only underline what Upayavira said. Please commit it - I think many of us are "code-minded" people (hope this is understandable in English ;-) and so this is the best way to spread new things in our community. -- Reinhard
