--- Marc Portier <[EMAIL PROTECTED]> wrote:
Tim Larson wrote:
--- Marc Portier <[EMAIL PROTECTED]> 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.
indeed, didn't even think about that extra bonus
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.
I can live with that.
(hm, added later:
below I find myself still struggling with the case you present... I really can live with the concept "the one using should pay the cost" and thus conclude to "let's support both" however the proposed use is just not something I would galdly recommend, sorry)
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.
hm, you are right, but is indeed questionable:
- if BW becomes an issue you could still use short id's, but probably will be faced with the fact that it only has minor effect IMHO
- navigating the widget-tree could be resolved by adding some WidgetLookupHelper that parses a hierachical String to navigate the tree for you (much like xpath versus DOM traversal, haven't looked yet at how we could maybe reuse jxpath in this area)
- and catalogs? well, they should be organized well to avoid the issue :-)
note in this respect that using the 'extend' idea one _can_ add widgets to the base-group (meaning: inside it's namespace) so smart extension trees can be
(note that people doing extensions will need to know about the base class internals to avoid name-clashes: in any case we will need to speak about these extensions in more depth later on IMHO)
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:
<union>
<new type-ref="prototype1"/>
<new type-ref="prototype2"/>
</union>
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"/>
and the possible clash if both prototypes would have both a widget/@id='F', right?
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!
hm, don't like it,
Kinda looks too much like using xml &entities; in the sense that it is more targetted to economising typing then it is to help define the widget structure: you are _not_ re-using the structure here! This is a different kind of reuse, and doing it the same way makes it confusing to me.
Looking at the wd:widgets inside the union we have to realize that they are not equivalent to the children of the <wd:group>. Meaning case-sets to be reused inside union are functionally different to grouping-prototypes that actually create a class-like struct.
Example: if I have a <wd:group type-def="Address"> then it would be odd to reuse that inside a 'union' that would allow you to edit only one part of it... union-cases are OR, group-children are AND?
In fact it also brings to light a different double-use of @id, no?
IIUC (please help clearing the mist) the union-instance has it's own id that is used to namespace the selected-child?
However, this id is not present in the request-params, right? in stead the selecting-value is picked from the id in the @case?
That value then is used to select the active child?
So the union/@id role is NOT a request-param, and
union/wd:widgets/*/@id is both a request-param (in the union/@id namespace) and a matching-value to get selected? (this last thing is the main problem you want to address with non-namespacing groups, again it looks like a consequence of an earlier decission, not a goal)
hm, I'm afraid I'm getting into new change proposals here, so shoot at will:
1/ why not have the selecting-widget defined INSIDE the union (that is his role, no?) --> so no more @case required, and thus no other widget to build and refer to
<wd:choice>
<wd:datatype base="string">
<wd:selection-list>
<wd:item value=""/>
<wd:item value="OPT1"/>
<wd:item value="OPT2"/>
<wd:selection-list>2/ and then have nested wd:cases (I would use the grouping wd:widgets in fact that provide themselves the test to be selected)
The @expression hints that similar logic as in the validation expressions might be used possibly?
<wd:cases>
<wd:case expression="OPT1">
<... whatever the sub-widget might be ...>
</wd:case>
<wd:default>
</wd:default>
</wd:cases>
</wd:choice>re-using these case-sets in different 'choices' sounds more like a special case of extending (deriving) the union itself...
(it would also more logically map the wt:class, no?)
I'm quite sure there are more details I'm overlooking yet, but as a general approach this is less confusing IMHO
wdyt?
<snip/>
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.
again, I'm not in principle against some combination of the best of both worlds, I'm just are cautious of patching something that is really the consequence of some other choices that could be reconsidered...
hope I gave some arguments above
--Tim Larson
__________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus
regards, -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]
