cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira>
Subject Re: [cforms] Should I commit the class, new, struct, union changes yet?
Date Wed, 24 Dec 2003 22:00:00 GMT

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.
>--Tim Larson
>Do you Yahoo!?
>New Yahoo! Photos - easier uploading and sharing.

View raw message