cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Larson <>
Subject Re: [cforms] Forwarding: Explanation of "dynamic stuff in form model"
Date Thu, 08 Jan 2004 15:27:53 GMT
--- Marc Portier <> wrote:
> Tim Larson wrote:
> > --- Marc Portier <> wrote:
> >>1/ to me this sounds like the use of @id on new and class was fraudulous:
> >>what I mean is: it is abusing that field in the implementation classes, 
> >>but with utterly different semantics:  not to be mapped onto actual 
> >>request-parameter-names, but rather a type-def/type-ref mechanism
> > 
> > This is all true, except for the small detail that the class id is
> > currently occupying space in the same namespace as the regular widget
> which seems to be more of a consequence of current approach then a goal, no?

I think so; see "red flag" comment below.

> > We also need to be able to distinguish between just-create-prototype
> > versus create-widgets-and-create-prototype-at-the-same-time.
> see my other posting... distinguishing is done by looking at the 
> combination of present attributes
> <wd:whatever id=".." >       --> classic use, create widget
> <wd:whatever type-def=".." > --> prototype-only (ie equivalent of wrapping with
wd:class )
> <wd:whatever id=".." type-def=".." > --> create and prototype
> so one of @type-def or @id always would need to be present
> @id would say: give this a place in the active tree of nodes
> @type-def would say: add this to the active registry of reusable prototypes

This separation of widget and prototype namespaces seems good.
Instead of letting any widget act as a prototype, only the ones
marked with a type-def attribute are available as prototypes.
This provides a red flag to anyone modifying the widget, alerting
them that their changes may affect other parts of the form.

> > In addition, how would you handle a class containing two or more widgets?
> > For this case I think we still need a wrapping element without namespacing.
> > Example with current (possibly soon to be old) syntax:
> >   <wd:class id="asdf">
> >     <wd:widget id="qwerty"/>
> >     <wd:widget id="zxcv"/>
> >   </wd:class>
> >   <wd:new id="asdf">
> > which should be functionally equivalent to:
> >   <wd:widget id="qwerty"/>
> >   <wd:widget id="zxcv"/>
> > 
> touche, but let's cheat by changing the rules of the game:
> I don't like this feature, and I don't think you need it :-)

I will describe below how to support the feature cheaply, and
further down, the reasons why it is needed.

> Here is why I don't like it
> suppose this:
>     <wd:class id="asdf">
>       <wd:widget id="qwerty"/>
>       <wd:widget id="zxcv"/>
>     </wd:class>
> then using this:
>     <wd:new id="asdf">
>     <wd:widget id="qwerty">
> would lead to a conflict, right?
> if we like to extend the re-use paradigm to central catalogs, then 
> having this feature would expect me to know the internals of the 'asdf' 
> class to make sure this doesn't happen, right?

Quoting myself:
> > Not good.  When reusing, currently with "new", you should not need to
> > know or restate what type(s) of widget(s) the class contains.  I.e. we

I am going to relax this statement from "should not need to know or
restate" to just "should not need to restate", because if you write a
custom template or binding for an instance of a prototype (currently
called a "class"), then you already need to know the types and ids of
the widgets the prototype contains.  Just like "type-def" acts as a red
flag, informing the form designer to be careful when a widget is acting
as a prototype, a special element (currently "new", but could be "inline",
etc.) could be required to create an instance of one of these multi-widget
prototypes which add their widget ids to the current namespace.

This way there is never a question about when id clashes are possible,
following the pattern of only having those who need the feature pay the
costs of using the feature.

> And I think you don't need it, it's not adding features, is it?

I will start with some admittedly less significant arguments:
By not introducing another layer of namespacing, we saves memory,
processing, and network bandwidth by allowing for shorter fully
qualified widget ids, and more importantly, save the form designer
from having to navigate the namespace in the binding and template.
These issues seem unimportant until we get catalogs and start to
build up forms via composition of prototypes which are in turn
built via composition of other prototypes...then sprinkle in a few
repeaters to taste, and we could have some very long fully qualified
ids to deal with.  With non-namespacing prototypes there could be
several layers of composition in use without burdening the ids.

Here is a more significant argument:
It allows the set of cases (choices) in a union to be built up by
adding a set of choices for each multi-widget prototype that is
referenced.  Pseudocode to illustrate:
    <new type-ref="prototype1"/>
    <new type-ref="prototype2"/>
could expand into this combined set of union cases:
  <widget id="widgetA-from-prototype1"/>
  <widget id="widgetB-from-prototype1"/>
  <widget id="widgetC-from-prototype2"/>
  <widget id="widgetD-from-prototype2"/>
  <widget id="widgetE-from-prototype2"/>
We could not pull in *sets* of choices like this if each prototype
provided a wrapping namespace like struct does.  Instead we could
only pull in one union case per class, ugh!

> I do understand that this is quite an impact-heavy change proposal, I 
> just think it fits better
> other example of proposed writing:
> <wd:group type-def="Address">
>    <wd:widget id="Name">
>    <wd:widget id="Street">
>    <wd:widget id="Zip">
>    <wd:widget id="City">
> </wd:group>
> <wd:widget id="to" type-base="Address" >
> <wd:widget id="to" [assuming you meant "from"] type-base="Address" >
> while the current-style syntax requires:
> <wd:class id="address">
>    <wd:widget id="Name">
>    <wd:widget id="Street">
>    <wd:widget id="Zip">
>    <wd:widget id="City">
> </wd:class>
> <wd:struct id="to">
>    <wd:new id="address" />
> </wd:struct>
> <wd:struct id="from">
>    <wd:new id="address" />
> </wd:struct>

With our combined proposals, you could choose either way.
Remember that the wrapping <wd:struct/> is *only* needed
when there is a possiblity of generating duplicate ids,
so for use cases where "address" is only used once within
a particular namespace, even the current-style syntax would
not require a <wd:struct/>.

> so yes, in terms of re-use without extension (ie deriving)
> the <wd:widget> should function as a generic wrapper for the prototype 
> it's based upon

Ok, seems good then.

> I've always found the <common type="actual"> pattern a bad substitute to 
> <actual>... of course if you get into <common type="actualType" 
> id="actualId"> then you can start a discussion if it really is that much 
> better to choose some <actualType id="actualId"> over <actualId 
> type="actualType">... in thise case I think history made the choice, we 
> should just add the new stuff in an elegant way


To summarize, I like the type-def and type-ref design, and I think we should
retain a way to also create and use mulit-widget prototypes that do not
provide wrapping namespaces.

--Tim Larson

Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes

View raw message