cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Max Pfingsthorn" <m.pfingsth...@hippo.nl>
Subject Re: CForms Summer of Code project
Date Wed, 15 Jun 2005 10:16:11 GMT
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 <tim@keow.org> 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
> 

Mime
View raw message