Dear Devs, Thank you all very much for your help! Thanks to Tim for the last minute comments! I've submitted my application last night ( way before time in California ;) ). Lets see what comes out of it. I've updated the proposal a little yesterday, see http://wiki.apache.org/cocoon/CocoonFormsLibraryProject. I hope I got things right, I got a little confused about the exact terms and structure of CForms...
Bye! max On 6/14/05, Tim Larson <[EMAIL PROTECTED]> wrote: > On Tue, Jun 14, 2005 at 07:41:55PM +0100, Tim Larson wrote: > > On Tue, Jun 14, 2005 at 10:41:57AM +0200, Max Pfingsthorn wrote: > > > Thank you very much, Reinhard! > > > > > > I'll fix that and submit it later today. After the email by Tim > > > yesterday, I am a bit afraid that most work is already done and this > > > project gets too small... I guess there is some bits of designing to > > > be done, and the "marketing" anyway (i.e. docs and further examples). > > > Does macro inheritance work yet? Or declaring single fields in the > > > library? > > Declaring a macro containing a single field works, but the > syntax is more verbose than it should be for handling just > a single widget, and iirc, it could use some work on being > able to specify a new id/name for the field at the point > of the macro expansion. > > ...And yes, there needs to be more/better documentation, > and we sorely need to create some simple step-by-step > examples of using the macro/library features. > > Another possible work area: > Use the macro/library support to make full forms > nestable, with either the same or different templates. > The current implementation does not do this, instead > requiring such dual use (stand-alone and nested) forms > to be implemented as two files, the body of the form > in a macro library and then another file containing > a Form widget and importing the first file to act as > a wrapper around it for stand-alone use. > There are similar complications when it comes to using > the binding and templating frameworks on nested/ dual-use > forms, which could affect the structure of the base > flowscripts. > > Drifting a little bit away from the macro/lib discussion, > into my motivation for having such a facility... > > I would like to have a declarative way of associating > bindings, form models, and templates with each other, > so when a parent form tells the form framework that it > wants to display some sub-form, it does not have to > tie the pieces together using code/programming. > My use-case is a web-based IDE for editing sitemaps, > forms, flowscripts, database mappings, portal configs, > etc. where any one of those may be a top-level form, > and the various related files/data/configs that they > reference could be opened in context as nested/sub forms. > > Some may think this is silly, but working toward this > goal has already proven useful...causing several bugs > to be discovered and the code fixed, and producing a > number of new widgets now used in other contexts: > struct/group, union/choose, class/new (the first > implementation of macro-like reusable groups of widget > definitions), and a first draft of a macro library > system that works for bindings, form models, and form > templates. > > Have fun, > --Tim Larson >
