cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: [cforms] Should I commit the class, new, struct, union changes yet?
Date Fri, 26 Dec 2003 11:58:00 GMT

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.

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.

let's get it in cvs, it will make progress and colaboration a lot easier

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                          

View raw message