Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Date: Tue, 8 Mar 2005 16:40:04 +0000
From: Tim Larson <tim@keow.org>
To: dev@cocoon.apache.org
Subject: Re: Whiteboard Forms - Reusable form definitions (imports)
Message-ID: <20050308164004.GD30663@localhost>
References: <422D5BF7.5030602@apache.org> <20050308150719.GA30663@localhost>
 <422DC9B2.3090502@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <422DC9B2.3090502@apache.org>
User-Agent: Mutt/1.5.6+20040907i

On Tue, Mar 08, 2005 at 04:50:10PM +0100, Reinhard Poetz wrote:
> Tim Larson wrote:
> >On Tue, Mar 08, 2005 at 09:01:59AM +0100, Reinhard Poetz wrote:
> >>In many of my forms date widgets are used: birthdate, start date, end 
> >>date, ... Definining those widgets is nearly always the same, except the 
> >>label. IMO it would make sense not only to have reusable macro libraries 
> >>but also reusable widget libraries (renamed fd:macros to fd:library):
> >
> >I was already considering renaming fd:macros to fd:library; do you
> >want to change it or should I?
> 
> can do it. What do you thing about reusable widgets as mentioned in my 
> initial mail of this thread? Shall I add them?

Practicality may change this (feel free to comment), but in my initial
design I wanted to create these abilities:

 (1) Define a base macro.
 (2) Define a macro extending from a base macro.
 (3) Create an unmodified expansion of a macro.
 (4) Create an inline-extended expansion of a macro.
 (5) Create an inline-extended expansion of a macro, while
     also creating a new reusable macro based on the extension.
 (6) Import collections of macros for expansion and/or extension.
 (7) Define collections (libraries) of macros, possibly themselves
     based on other collections of macros via imports and extensions.

Extension facility should eventually include such things as:
  Adding/modifying/removing widget definitions, templates, bindings.
  Changing names, labels, hints, and help on widget definitions.
  Adding/removing/modifying validation elements/logic.
  Adding in a previously unspecified or different datatype.
  Supplying/changing default values/selection lists/selections.
  Adding/removing/modifying styling (for template macros)
  Changing paths and ids (for binding macros)
  Etc.

I may also want to separately support parameterized macros, the
difference being that parameters would be expected and coded for
in the macro definitions, while extensions could be seen more as
sculpting a statue out of an unsuspecting (copy of a) block of wood.

With this context (which we can refine or restrict as necessary) how
do you picture merging the "reusable widgets" syntax and and semantics?

I mainly see some potential to make extensions more concise (less
wear on the fingers and eyes,) due to removing the fd:macro wrapper
around those macros/reusable-widgets which happen to only contain a
single widget.

--Tim Larson