cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Larson <>
Subject Re: CForms Summer of Code project
Date Tue, 14 Jun 2005 19:37:55 GMT
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

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

Have fun,
--Tim Larson

View raw message