Return-Path: 
 <dev-return-53667-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 777 invoked from network); 5 Jan 2004 15:38:31 -0000
Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12)
  by minotaur-2.apache.org with SMTP; 5 Jan 2004 15:38:31 -0000
Received: (qmail 17620 invoked by uid 500); 5 Jan 2004 15:38:23 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 17561 invoked by uid 500); 5 Jan 2004 15:38:22 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
list-post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 17540 invoked from network); 5 Jan 2004 15:38:21 -0000
Received: from unknown (HELO web41904.mail.yahoo.com) (66.218.93.155)
  by daedalus.apache.org with SMTP; 5 Jan 2004 15:38:21 -0000
Message-ID: <20040105153824.88898.qmail@web41904.mail.yahoo.com>
Received: from [65.116.199.19] by web41904.mail.yahoo.com via HTTP;
 Mon, 05 Jan 2004 07:38:24 PST
Date: Mon, 5 Jan 2004 07:38:24 -0800 (PST)
From: Tim Larson <timlarsonwork@yahoo.com>
Subject: [cforms] Forwarding: Explanation of Aggregate/Struct differences
To: dev@cocoon.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

[Forwarding from discussion with Marc.]

Explanation of Aggregate/Struct differences
--- Marc Portier <mpo@outerthought.org> 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.

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):
  <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>
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