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 Wed, 07 Jan 2004 14:02:10 GMT
--- Marc Portier <> wrote:
> 1/ this would make the  builders stateful, so we probably will need some 
> different type of classes like 'prototype' or something (could be inner 
> class of the builder).

I will have to think about this stateful builder issue some more, but
time is a little tight right now.

> Overall this pretty  much resembles the copy-constructor idea, but by 
> creating the prototype and it's derived into different classes you _can_ 
> get everything final...
> 2/ but there is a more essential issue I think, 'order' of definition is 
> only one thing (for that we could just do a DOM-search to look ahead in 
> the definition file, remember?)
> However, you spent quite some time explaining me that binding and 
> definition graphs could get cyclic (ie no longer straight top-down 
> trees) by using the 'union' (to be called: 'choice')
> class (x) --> union --> new (x)
>                     \--> other stuff...

Yes, essential for the form-based-GUI use case, and for some interactive
data exploration use cases...

> in which case there really is a chicken and egg problem:
> chicken class-x will wait to be constructed untill all it's children are 
> known, as will sub-chicken 'union', so to relieve the 'we are all 
> waiting each other' we need to be able to create the egg new-x in some 
> 'dummy way' with a non-final ref to be filled-in later once class-x is 
> actually done

I will try to work out the details when I have time again, but I think
the coordinating builder-and-object-constructor idea can be made to
solve this while retaining 'final'.

> > "class" nor "new" currently wrap any namespacing around the widget
> > definitions that are retrieved from the class via "new".  That is:
> >   <wd:class id="asdf">
> >     <wd:widget id="qwerty"/>
> >   </wd:class>
> >   <wd:new id="asdf">
> > is functionally equivalent to:
> >   <wd:widget id="qwerty"/>
> > and *not* to:
> >   <wd:some-wrapper-widget-or-element id="asdf">
> >     <wd:widget id="qwerty"/>
> >   </wd:some-wrapper-widget-or-element>
> > 
> > (How) does this affect your proposals?
> actually it kinda offers extra arguments to my reasoning:
> 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
ids.  The introduction of "type-def" would give us a way to put the
class name in a separate "types" namespace.  I.e. "type-ref" could
only see classes (types) and wt:widget, etc. could only see widgets.

> 2/ the elements new and class are just decorating around whatever is 
> inside them: so why not use attributes in stead, those are more suited 
> for the decorating job... the actual elements in the wd:file then all 
> map onto actual types, while two introduced attributes (I would propose 
> @type-def and @type-ref would take over the define/reuse goal of 'class' 
> and 'new')
> so in your above example, the new equivalent syntax for
>  >   <wd:class id="asdf">
>  >     <wd:widget id="qwerty"/>
>  >   </wd:class>
> would become
> <wd:widget id="qwerty" type-def="asdf" />

We also need to be able to distinguish between just-create-prototype
versus create-widgets-and-create-prototype-at-the-same-time.

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:new id="asdf">
which should be functionally equivalent to:
  <wd:widget id="qwerty"/>
  <wd:widget id="zxcv"/>

> if you need namespacing you would need the 'struct' (for which group 
> would be a more sensible name indeed) concept...
> if it needs to be reused or not is in a different dimension, and to be 
> done by adding an optional type-def attribute:
> <wd:struct id="group-name" type-def="asdf">
>    ... his members here
> </wd:struct>

Ok, struct (or "group") working as normal.

> on the reuse-side there is some extra argumentation for this approach by 
> the introduction of the 'deriving'
> if we don't do deriving then
> - reuse can be with a generic wd:widget wrapper:
>    <wd:widget type-ref="adsf"> (in stead of wd:new, so no big win)

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
should not have to reuse like this: <wd:aggregatefield type-ref="asdf"/>
On the other hand, this could be a (possibly weak) argument to change
widget definitions to look like this:
  <wd:widget id="hjkl" type="aggregatefield"...>
It is a little more wordy, and using <wd:widget type-ref="asdf"/> to
reuse a class containing more than one widget still looks funny because
"wd:widget" is singular but would be refering to multiple widgets.

> if we do provide it, then
> - the (see copy-constructor idea) define-reuse widgets will need to 
> match so depending on the wd:TYPE that was used for the type-def, you 
> would need a matching wd:TYPE for reuse, supposing you had a struct, and 
> you want to derive to reuse and add a field:
>    <wd:struct type-ref="asdf>
>      .. more children here
>    </wd:struct>

Again we would need a wrapping element (currently provided by wd:class)
to be able to also implement a non-namespaced version of this example of
derived reuse.

> hm, that last sample makes me think we should maybe change @type-ref to 
> @type-base... but before getting in those details , we should allign on 
> the concepts first...

Yes, using "base" in the name would parallel datatype syntax.

--Tim Larson

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

View raw message