Timothy Larson wrote:
> Explanation of Aggregate/Struct differences
> --- Marc Portier <[EMAIL PROTECTED]> 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 1-to-1.
> 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 values.
> 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 mapping
> 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 dependencies,
> and is not constrained to only containing field widgets. That being said,
> 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 related
> 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 UnionDefinition.java 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 id="lastname"/>
> <!-- 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" /> </class>
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?
wdyt?
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 qualified
> 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 struct
> and an aggregate make more sense now?
>
> --Tim Larson
>
>
> __________________________________
> Do you Yahoo!?
> Find out what made the Top Yahoo! Searches of 2003
> http://search.yahoo.com/top2003
-marc= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
