cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: [cforms] Forwarding: Explanation of Aggregate/Struct differences
Date Mon, 05 Jan 2004 23:35:25 GMT

Timothy Larson wrote:

 > Explanation of Aggregate/Struct differences
 > --- Marc Portier <> wrote:
 >>>>>> - still doubthing if struct is so much more different then aggregate
 > We have values and we have widgets, but they are not always matched 
 > Looking at the *values* in an aggregate we find a solitary value and
 > (because it acts as a container for field widgets) an ordered list of 
 > The fact that these are all contained in one widget can be viewed as 
a nice
 > syntactic sugar, making it easier to express the specialized 
dependency logic
 > (merged-value/split-children-values) between the solitary value and the
 > ordered list of values.  When cforms get full support for (easilly)
 > expressing dependencies between widgets, we could (at least in 
theory) split
 > up the aggregate widget by allowing the solitary value and the list 
of values
 > to be placed whereever we wish, such as in separate, otherwise unrelated,
 > widgets.  This flexibility may in some cases allow for a more direct 
 > between the form and the back end data.

yeah like have a getValue on the parent level produce a Map of the 
nested child-values?

 > A "struct" widget looks somewhat like an aggregate, because it 
contains an
 > ordered list of widgets, but is actually quite different.  It does not
 > contain a separate solitary value, does not implicitely express 
 > and is not constrained to only containing field widgets.  That being 
 > if we chose to break up the aggregate widget as described above I 
think it
 > would be common to use a "struct" widget to contain the list of 
values, via
 > containing a list of field widgets.  If we adopt such a design, then 
we would
 > no longer require (but might still want for the nice syntax it 
supports?) a
 > separate AggregateField widget type.
 > Note that the "struct" widget type has other uses; in fact its use 
 > to aggregate functionality was an afterthought.  Struct widgets allow 
a list
 > of widgets to be place where usually only one widget is supported, 
such as
 > in a union case (look at in the formmodel). 
They also,
 > probably more importantly, allow to namespace a collections of 
widgets which
 > would otherwise have conflicting fully qualified id's.
 > For example (pseudocode):

hm I would of have prefered a distinct @id, @type and @name...

wd:new/@id seems to do two things: reference the class and set the widget-id

I would of have expected something like wd:class/@type (and NO @id here)
while the wd:new/@id would set that independantly of a wd:new/@name 
refering to the @type of the wd:class it depends upon

I suppose this current setup has to do with how widgets consume 
themselves the request-parameters given to them? Have to think some more 
about this one...

 >   <struct id="manager">   <new id="person-class"/> </struct>
 >   <struct id="underling"> <new id="person-class"/> </struct>
 >   <class id="person-class">
 >     <field id="employeeid"/>
 >     <field id="firstname"/> <field id="middlename"/> <field 
 >     <!-- And a bunch of widgets to support query-by-example employee 
lookup -->
 >   </class>

with the new attributes proposed that would allow:
   <new name="person-class" id="manager" />
   <new name="person-class" id="underling" />
   <class type="person-class">
     <field id="employeeid" />
     <field id="firstname" />

at which time we have reduced the need for struct seperate from class?

and to the builders this becomes:
<class-struct id="...">  a normal struct

<class-struct type="..."> a normal class (so the struct-builder would 
need to do an addClass towards the classResolver)

<class-struct type="..." id=".."> a class that is immediately 'used' (so 
a combination of class and new in one?

taking it one step further: why not allow a @type on all widgets we 
currently have, so they can automatically be cloned/'used' more then once?

looking at it from this angle the use/reuse realm seems to be a 
different dimension then the structuring/definition one, no?


maybe again some light shining from the XMLSchema and the likes corner?

 > Without the namespaces ("manager" and "underling") that the struct widget
 > provides, we could not reuse the "person-class" for both people 
because the
 > widgets "employeeid", "firstname", etc. would have the same fully 
 > id's for both people, causing the form definition to fail to be loaded on
 > account of duplicate widget id errors.
 > Do the use case for the struct widget and the differences between a 
 > and an aggregate make more sense now?
 > --Tim Larson
 > __________________________________
 > Do you Yahoo!?
 > Find out what made the Top Yahoo! Searches of 2003

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                          

View raw message