cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Reinhard Poetz" <>
Subject RE: [cforms] Should I commit the class, new, struct, union changes yet?
Date Thu, 25 Dec 2003 15:29:32 GMT

From: Upayavira [] 

> 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


View raw message