You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Marc Portier <mp...@outerthought.org> on 2004/03/30 11:07:19 UTC
[cforms] discussing the scratchpad (was Re: [WIKI-UPDATE] SandBox
WoodyScratchpad Mon Mar 29 21:00:04 2004)
Since this starts looking like a consensus-reaching discussion I'm
pulling it to the dev list
others that want to join in, be sure to read up:
> Page: http://wiki.cocoondev.org/Wiki.jsp?page=WoodyScratchpad , version: 12 on Sun Mar 29 19:17:58 2004 by 65.116.199.19
>
> + (tim: +1 to this alternative; nice syntax, and conveys the right ideas more clearly.)
> +
Tim, thx for this feedback,
ok if I swap it over the previous section then?
> -
> - This would also stress nicely that prefixes only have local scope, that the sources are the real important things, and that the form-manger could cache these repositories based on the source.
> + This would also stress nicely that prefixes only have local scope, that the sources are the real important things, and that the form-manger could cache these repositories based on the source. (tim: +1 the pre-built definition caching is one of the reasons for importing instead of just using (x|c)include)
> ? ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> - **Anywhere a widget definition is allowed. (+1 mpo)
> + **Anywhere a widget definition is allowed. (+1 mpo, +1 tim)
> ? ++++++++
>
> - *Where should imported types be registered (affects namespace)? (mpo: I don't get this question)
> + *Where should imported types be registered (affects namespace)? (mpo: I don't get this question) (tim: let's ignore it, I don't think it makes sense anymore.)
> ? ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
ok
> - **Widget definitions that will have instances created.
> + **Widget definitions that will have instances created. (tim: Does this have any usecases?)
> ? ++++++++++++++++++++++++++++++++++++
not that I know of, in fact I couldn't really place that one either :-(
>
> + (''tim: I was thinking of offering both forms, not just one-or-the-other, because I have usecases for both.'')
ah, wasn't clear, I like the idea, just have to make the syntax clear then
> - *What should we do if the expression evaluates to the default anyway? (mpo: seems more logic in the when@test/otherwise filosophy?)
> + *What should we do if the expression evaluates to the default anyway? (mpo: seems more logic in the when@test/otherwise filosophy?) (tim: I do not understand; could you clarify you comment?)
> ? +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
in the when/@test and otherwise there is no real expression to be
evaulated, just a last section that is always true if none of the above
was...
> - *What namespace should the widget id's be in? (''mpo: supposing you refer to namespacing with respect to generated request-parameter names, right?'')
> + *What namespace should the widget id's be in? (''mpo: supposing you refer to namespacing with respect to generated request-parameter names, right?'') (''tim: yes'')
> ? +++++++++++++++
>
I'll rephrase our dialog as an extra clarification then
> - ''mpo comments: I would prefer the case/@expr and default to become when/@test and otherwise''
> + ''mpo comments: I would prefer the case/@expr and default to become when/@test and otherwise''//
> ? ++
>
> + ''tim comments: when/@test would be fine with me; should we also copy the word 'choose' from xslt, instead of using 'choice'? 'choice' seems more declarative, but I would be ok with either word.''
>
choose points at processing and doing the action
choice makes it an entity
the latter seems to hint that there is actually a widget with its own
value to be used for driving the choice?
(that was the case now, no? or is this just a vague memory of an
unfinished discussion?)
regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: [cforms] discussing the scratchpad (was Re: [WIKI-UPDATE] SandBox
WoodyScratchpad Mon Mar 29 21:00:04 2004)
Posted by Marc Portier <mp...@outerthought.org>.
Tim Larson wrote:
<snip/>
>>ok if I swap it over the previous section then?
>
>
> Yes, please do. I am not interested in saving the comments (wiki
> history will do that for us), just in hammering out the best design.
>
ok, still have to though
<snip />
>>
>>>+ (''tim: I was thinking of offering both forms, not just
>>>one-or-the-other, because I have usecases for both.'')
>>
>>ah, wasn't clear, I like the idea, just have to make the syntax clear then
>
>
> Yes, any suggestions for the "c switch"-like syntax? Or do you just mean
> that the explaination needs to be more understandable?
>
nope you got me allright
we just have to find a good syntax for them both, right?
proposing here and now:
switch-like:
<fb:choice expression="">
<fb:when result="">
<fb:otherwise>
ifelseif-like
<fb:choice>
<fb:when test="">
<fb:otherwise>
wdyt?
<snip />
>
>>>+ *What namespace should the widget id's be in? (''mpo: supposing you
>>>refer to namespacing with respect to generated request-parameter names,
>>>right?'') (''tim: yes'')
>>
>>I'll rephrase our dialog as an extra clarification then
>
>
> Thanks.
>
another still todo
>
>>>+ ''mpo comments: I would prefer the case/@expr and default to become
>>>when/@test and otherwise''//
>>>
>>>+ ''tim comments: when/@test would be fine with me; should we also copy
>>>the word 'choose' from xslt, instead of using 'choice'? 'choice' seems
>>>more declarative, but I would be ok with either word.''
>>
>>choose points at processing and doing the action
>>choice makes it an entity
>>
>>the latter seems to hint that there is actually a widget with its own
>>value to be used for driving the choice?
>
>
> There will be an actual widget, because we have to store the previous
> choice to be able to tell if the new choice is different and thus
> requires action, such as creating the associated widgets. This will
> also solve the early validation problem the union widget introduced to
> the field widget. By this reasoning, the name should be "choice", right?
>
thx for clarifying again, this is how I (thought I) remembered the
discussion (been some time)
I'm ok either way, only slightly favouring the noun.
regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: [cforms] discussing the scratchpad (was Re: [WIKI-UPDATE] SandBox WoodyScratchpad Mon Mar 29 21:00:04 2004)
Posted by Tim Larson <ti...@keow.org>.
On Tue, Mar 30, 2004 at 11:07:19AM +0200, Marc Portier wrote:
> Since this starts looking like a consensus-reaching discussion I'm
> pulling it to the dev list
>
> others that want to join in, be sure to read up:
>
> >Page: http://wiki.cocoondev.org/Wiki.jsp?page=WoodyScratchpad , version:
> >12 on Sun Mar 29 19:17:58 2004 by 65.116.199.19
>
> >+ (tim: +1 to this alternative; nice syntax, and conveys the right ideas
> >more clearly.)
>
> Tim, thx for this feedback,
> ok if I swap it over the previous section then?
Yes, please do. I am not interested in saving the comments (wiki
history will do that for us), just in hammering out the best design.
> >+ This would also stress nicely that prefixes only have local scope, that
> >the sources are the real important things, and that the form-manger could
> >cache these repositories based on the source. (tim: +1 the pre-built
> >definition caching is one of the reasons for importing instead of just
> >using (x|c)include)
>
> >+ (''tim: I was thinking of offering both forms, not just
> >one-or-the-other, because I have usecases for both.'')
>
> ah, wasn't clear, I like the idea, just have to make the syntax clear then
Yes, any suggestions for the "c switch"-like syntax? Or do you just mean
that the explaination needs to be more understandable?
> >+ *What should we do if the expression evaluates to the default anyway?
> >(mpo: seems more logic in the when@test/otherwise filosophy?) (tim: I do
> >not understand; could you clarify your comment?)
>
> in the when/@test and otherwise there is no real expression to be
> evaulated, just a last section that is always true if none of the above
> was...
Thinking clearer now, the original question did not make sense. Skipping.
> >+ *What namespace should the widget id's be in? (''mpo: supposing you
> >refer to namespacing with respect to generated request-parameter names,
> >right?'') (''tim: yes'')
>
> I'll rephrase our dialog as an extra clarification then
Thanks.
> >+ ''mpo comments: I would prefer the case/@expr and default to become
> >when/@test and otherwise''//
> >
> >+ ''tim comments: when/@test would be fine with me; should we also copy
> >the word 'choose' from xslt, instead of using 'choice'? 'choice' seems
> >more declarative, but I would be ok with either word.''
>
> choose points at processing and doing the action
> choice makes it an entity
>
> the latter seems to hint that there is actually a widget with its own
> value to be used for driving the choice?
There will be an actual widget, because we have to store the previous
choice to be able to tell if the new choice is different and thus
requires action, such as creating the associated widgets. This will
also solve the early validation problem the union widget introduced to
the field widget. By this reasoning, the name should be "choice", right?
--Tim Larson
Re: [cforms] discussing the scratchpad (was Re: [WIKI-UPDATE] SandBox
WoodyScratchpad Mon Mar 29 21:00:04 2004)
Posted by Marc Portier <mp...@outerthought.org>.
Tim Larson wrote:
> Marc wrote my comments very well in my place, so I will move on to
> some new comments. By the way, thank you both for jumping in to
> this discussion. I have been holding back on implementing any of
> the ideas in the WoodyScratchpad until there would be a discussion
> like this and the forming of a consensus.
>
I felt that, and I'm sorry for not coimming back to this topic earlier,
I really think these added widgets will greatly enhance the cforms
feature-set
> We must be able to detect when a choice widgets changes cases, so
> we need to remember the previous case so we can compare against it.
> We also must know what the current selected case is to be able to
> drive the template and the save side of the binding.
>
> We do not need to be able to directly set a case, except via setting
> the values that are references by the expression(s) in the "expr"
> attribute of the choice or in the "test" attributes of the case's.
>
> On the other hand, since the choice has to store a value indicating
> which case is selected, we could just go ahead and treat this as the
> "value" of the choice widget. Getting the value will tell you the
> current case, and attempting to set the value will trigger the
> evaluation of the expression in the "expr" attribute, eventually
> causing a case to be selected and the underlying value to be set.
>
ok, I rest my case, reading up your argumentation it does sound like the
'value' is enough... but in the ifelseif style we'll need some
indication of value-setting then?
> As you can see, externally setting the value is only useful for the
> "c switch" style of the choice widget, unless you used the attempt
> to set a value on the if-elseif-elseif-else style choice widget as
> a manual trigger to cause re-evaluation and just discarded the
> specific value that was passed.
>
> I think it would be handy to be able to specify for all/most types
> of widgets a direction attribute like we have in the binding: load,
> save, or both. We may choose different names like input, output,
> both, none, etc.
>
> This would control whether the request parameter for a widget would
> be processed (e.g. so the widget will not be reset to null when the
> parameter is missing, and to prevent the user setting the value by
> manipulating the posted parameter values), and whether the current
> value of a widget would be made available to the template layer
> (e.g. we do not want to send passwords back to the user).
>
up to now this has been under the (implied) control of the widget type
(code in the class) itself, (e.g. fd:output versus fd:field)
and I like this more then the explicit attribute which might not make
any sense?
for the choice I think it could easily detect c-switch or ifelsif style
and thus decide what to with values that were set, no?
> I bring this up in part because these options should give us the
> needed protection against the user hacking the case selection of
> most choice widgets, while still allowing selected choice widgets
> to easily allow the user to select the case.
>
> WDYT?
>
see above,
regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: [cforms] discussing the scratchpad (was Re: [WIKI-UPDATE] SandBox WoodyScratchpad Mon Mar 29 21:00:04 2004)
Posted by Tim Larson <ti...@keow.org>.
Marc wrote my comments very well in my place, so I will move on to
some new comments. By the way, thank you both for jumping in to
this discussion. I have been holding back on implementing any of
the ideas in the WoodyScratchpad until there would be a discussion
like this and the forming of a consensus.
We must be able to detect when a choice widgets changes cases, so
we need to remember the previous case so we can compare against it.
We also must know what the current selected case is to be able to
drive the template and the save side of the binding.
We do not need to be able to directly set a case, except via setting
the values that are references by the expression(s) in the "expr"
attribute of the choice or in the "test" attributes of the case's.
On the other hand, since the choice has to store a value indicating
which case is selected, we could just go ahead and treat this as the
"value" of the choice widget. Getting the value will tell you the
current case, and attempting to set the value will trigger the
evaluation of the expression in the "expr" attribute, eventually
causing a case to be selected and the underlying value to be set.
As you can see, externally setting the value is only useful for the
"c switch" style of the choice widget, unless you used the attempt
to set a value on the if-elseif-elseif-else style choice widget as
a manual trigger to cause re-evaluation and just discarded the
specific value that was passed.
I think it would be handy to be able to specify for all/most types
of widgets a direction attribute like we have in the binding: load,
save, or both. We may choose different names like input, output,
both, none, etc.
This would control whether the request parameter for a widget would
be processed (e.g. so the widget will not be reset to null when the
parameter is missing, and to prevent the user setting the value by
manipulating the posted parameter values), and whether the current
value of a widget would be made available to the template layer
(e.g. we do not want to send passwords back to the user).
I bring this up in part because these options should give us the
needed protection against the user hacking the case selection of
most choice widgets, while still allowing selected choice widgets
to easily allow the user to select the case.
WDYT?
--Tim Larson
Re: [cforms] discussing the scratchpad (was Re: [WIKI-UPDATE] SandBox
WoodyScratchpad Mon Mar 29 21:00:04 2004)
Posted by Marc Portier <mp...@outerthought.org>.
Tim Larson wrote:
> On Wed, Mar 31, 2004 at 12:38:44PM +0200, Marc Portier wrote:
>
>>Sylvain Wallez wrote:
>>
>>>Marc Portier wrote:
>>>
>>>>>Example:
>>>>>
>>>>><wd:choice id="some-id">
>>>>><wd:field id="field-A".../>
>>>>><wd:case id="case-0" expr="case-1-expression">
>>>>> <wd:ref id="field-A"/>
>>>>></wd:case>
>>>>></wd:choice>
>
>
> We could think of defining widgets inside a case as being merely
> a syntactic shorthand for defining these widgets directly in the
> choice and then referencing them into that case. This shortcut
> may only be used on widgets which are only used by one case.
>
> In other words, do not think of cases as widgets or containers,
> but only as parts of the control structure syntax. This removes
> the problem of having two reference paths to a widget.
>
+1
>
>>>>hm, I think Tim and I were still thinking about not having the choice
>>>>actually contain it's widgets... (I have to say I'm still doubthing,
>>>>but don't see it yet)
>
>
> The motivation behind this was to ease the process of evolving a
> simple widget or collection of widgets into a choice of widgets.
> If the widgets listed "in" the choice are referenced by widget-id
> rather than by choice-id.widget-id then the existing templates
> and bindings could continue to work unmodified to ease the
> incremental process of development.
>
ah, didn't get that, my original motivation was actually
negative-motivation: I couldn't see a reason to complicate things, but
when starting the talk with sylvain I realized the container-child
relation and find the effect on the request-parameter quite logic
as foir templating: I guess the existing ft:widget elements don't need
to be changed, but rather wrapped inside a ft:choice/ft:case structure?
in any case I find it logic that the change in the model would have an
impact on the styling...
> Besides making the implementation of choice more complicated,
> this plan may not work out anyway. I will be examining use cases
> tomorrow to see if there is actually any merit in this design,
> but wanted to at least let you know the motivations right now
> since we have a such a big timezone difference between when your
> day starts and when mine does.
>
ok, staying tuned over here for when the sun comes up again :-)
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: [cforms] discussing the scratchpad (was Re: [WIKI-UPDATE] SandBox WoodyScratchpad Mon Mar 29 21:00:04 2004)
Posted by Tim Larson <ti...@keow.org>.
On Wed, Mar 31, 2004 at 12:38:44PM +0200, Marc Portier wrote:
> Sylvain Wallez wrote:
> >Marc Portier wrote:
> >>>Example:
> >>>
> >>><wd:choice id="some-id">
> >>> <wd:field id="field-A".../>
> >>> <wd:case id="case-0" expr="case-1-expression">
> >>> <wd:ref id="field-A"/>
> >>> </wd:case>
> >>></wd:choice>
We could think of defining widgets inside a case as being merely
a syntactic shorthand for defining these widgets directly in the
choice and then referencing them into that case. This shortcut
may only be used on widgets which are only used by one case.
In other words, do not think of cases as widgets or containers,
but only as parts of the control structure syntax. This removes
the problem of having two reference paths to a widget.
> >>hm, I think Tim and I were still thinking about not having the choice
> >>actually contain it's widgets... (I have to say I'm still doubthing,
> >>but don't see it yet)
The motivation behind this was to ease the process of evolving a
simple widget or collection of widgets into a choice of widgets.
If the widgets listed "in" the choice are referenced by widget-id
rather than by choice-id.widget-id then the existing templates
and bindings could continue to work unmodified to ease the
incremental process of development.
Besides making the implementation of choice more complicated,
this plan may not work out anyway. I will be examining use cases
tomorrow to see if there is actually any merit in this design,
but wanted to at least let you know the motivations right now
since we have a such a big timezone difference between when your
day starts and when mine does.
--Tim Larson
Re: [cforms] discussing the scratchpad (was Re: [WIKI-UPDATE] SandBox
WoodyScratchpad Mon Mar 29 21:00:04 2004)
Posted by Marc Portier <mp...@outerthought.org>.
Sylvain Wallez wrote:
> Marc Portier wrote:
>
<snip />
>
> Tim and I once discussed the @define and @extend on IRC (which resulted
> in the wiki scratchpad page), but there was no repository at that time.
>
that part of history I didn't know...
>> so here goes the idea:
>> each cforms defintion file can @define reusable definition-templates
>> and to reuse them in a different file you would need to refer to it in
>> some way, hence the prefix idea
>>
>> from there I saw the resemblance to how xmlns binds a prefix to a uri,
>> and tzadaam
>>
>> I think this confirms your fresh understanding, right?
>
>
>
> Yep, and I totally agree with this. Having a hierarchy of types would
> lead to a complicated mess from a user point of view. Also, my remark on
> nested repositories is finally non-sense. A repository only publishes
> the types it defines, even if these types extend types defined by
> another repository. Repository import is not a transitive relation.
>
> So +1 for @prefix and namespaced notation, as types and widget ids leave
> in different spaces.
>
yep, that was the feeling
> Now for type repositories to be real repositories, there's something
> missing in the samples: we should be able to define a type without
> defining a widget. In other words, it should be legal to have no @id if
> there is a @defines, e.g:
>
> <wd:field defines-type="date-field">
> <wd:datatype base="date"/>
> </wd:field>
>
> This has the effect of declaring the type, but not producing any actual
> widget in the parent container (be it a form or a repository).
>
it's already there Sylvain: sample2 on the scratchpad page
>> <snip />
>>
>>> "choice" is better, as it *is* a widget. It's a container widget with
>>> an id (therefore defining a scope) and no value.
>>>
>>> This container can have two kinds of children:
>>> - regular widgets that are referenced by the "case" and are therefore
>>> common to several cases,
>>> - "case" widgets that are in turn container for regular widgets and
>>> references for the above common widgets.
>>>
>>> This leads to the interesting fact that common widgets can actually
>>> be referenced by two names: one considering only their definition,
>>> and one considering their reference in a case.
>>>
>>> Example:
>>>
>>> <wd:choice id="some-id">
>>> <wd:field id="field-A".../>
>>> <wd:case id="case-0" expr="case-1-expression">
>>> <wd:ref id="field-A"/>
>>> </wd:case>
>>> </wd:choice>
>>>
>>> field-A can be referenced using "some-id.field-A" (don't care about
>>> the actual case) and "some-id.case-o.field-A". It's canonical name
>>> (used in request parameters) will be of course "some-id.field-A".
>>>
>>
>> hm, I think Tim and I were still thinking about not having the choice
>> actually contain it's widgets... (I have to say I'm still doubthing,
>> but don't see it yet)
>
>
>
> Mmmh... are you stating that wd:choice doesn't contain its widgets? Or
> do you mean wd:case?
>
I _was_ making a statement on wd:choice, but you convinced me: choice is
a container, requestparams should be nested choiceID.childID
> The problem we have to solve with wd:choice is that there can be some
> widgets that are common to different cases. But IMO a wd:choice should
> not reference widgets that are its siblings, but *contain* them.
> wd:choice is a container.
>
> Now the question is whether a wd:case can define its own widgets (i.e.
> it is a container, child of the wd:choice) or if if can only reference
> widgets defined in wd:choice (and therefore represent the "value" of the
> wd:choice).
>
> References are needed in a wd:case since we need widgets common to
> different cases.
>
> Widgets in a wd:case implicitely turns them into container, leading to
> the dual path I outlined above. Thinking further, this overcomplexifies
> the widget containment. Also, a wd:case can be considered as the "value"
> of the wd:choice, driving, as you point out below, the list of available
> children in the wd:choice.
>
yes, but I think there is two things, though
as I see it the 'choice' has a value that can be set
(either by a request carrying its value, or by eventhandling code)
setting of that value will lead to the cases to be re-evaluated
the chosen case (internall processing to the choice class) does two things:
- 1/ describe which child-widgets need to be instantiated
- 2/ set some 'choice-label' where the template-transformer can react upon?
as I see it that last one != the actual 'value'
in any case, the wd:case are not to be seen as containers nor widgets
(they should thus not have an @id)
> So, here's a sum up of my (current) opinion: wd:choice is a container
> whose children are the widgets for all cases, and wd:case only define
> test expressions that decide the available children of the wd:choice and
> its "value", that can be used later on in the template.
>
> How does this sound?
>
matches my understanding indeed
>> i.e. the request-param in my head would just be 'field-A', there is
>> however also a 'some-id' request param to communicate the value that
>> will drive the choice...
>
>
>
> Mmmh..., IMO this will be "some-id.field-A", and there should *not* be a
> parameter driving the choice. It's the result of the server-side
> evaluation of the test expressions. Otherwise, we're open to consistency
> problems and hacked requests.
>
hm, didn't think about that, but in the cases where you have a very
clear link between a widget and the choice to make this means that
people will need to add an explicit widget to their definition
in my head that would be a styling aspect: the template would choose if
its on the form or not
have to think about the hacking though, what could go wrong?
>> also, I don't know if there are to be two paths into the beast: point
>> being that the 'case' part is IMHO not to be a separate
>> widget-definition class, but rather a part of the
>> configuration/processing context of the widget
>
>
>
> Yep. The wd:case defines the "value" of the wd:choice.
>
see above, I don't think it needs to be matching the 'value', I think
it's something else (that's probably how I avoid the hacking issue?)
>> in other words: when asking a choice-widget which children it has, it
>> would just list the currently 'chosen' widgets, and not the nested cases.
>
>
>
> Agree.
>
>> (hm, the last paragraph does sound like there is some
>> parent-child/containment that justifies the nested request-param...)
>
>
>
> Yes :-)
>
thx for shedding the light :-)
>>> Case id's are also important because they will be used in views to
>>> select which part of the template is to be displayed.
>>
>>
>>
>> not sure here, couldn't the template just react on those widgets that
>> seem to have been 'chosen' at the time?
>
>
>
> This isn't sufficient, as the view may want to produce different layouts
> or informative text depending on the chosen case.
>
yeah, you're right the selected case should set some 'choice-label' oinm
which the template can react
>> from a styling POV you'll probably have a custom style surounding each
>> of the possible children, and maybe other arrangements depending on
>> the mix of available widgets... so reacting on the mix seems more
>> sensible then duplicating the decision logic in the template, no?
>>
>> in any case, looking at the use-case behind these, I tend to believe
>> that a generator approach is more natural, no?
>
>
>
> Yes, definitely yes. I started using the generator approach a while ago
> (with JXTemplate macros) because I needed:
> - different renderings for empty/non-empty repeaters (don't want a table
> with just headers if it's empty)
> - a very special rendering for a wd:output containing the ID of a node
> in a tree structure (the rendering shows the full path of the node, a la
> dmoz.org, with i18nized node labels)
> - conditional blocks depending on a widget's value (actually a poor
> man's wd:choice)
>
> These features are impossible to achieve with a transformer, but are
> really easy with a generator.
>
yep, revisiting the generator is also somewhere on my todo list
regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: [cforms] discussing the scratchpad (was Re: [WIKI-UPDATE] SandBox
WoodyScratchpad Mon Mar 29 21:00:04 2004)
Posted by Sylvain Wallez <sy...@apache.org>.
Marc Portier wrote:
>
>
> Sylvain Wallez wrote:
>
> <snip />
>
>> I made some comments in the wiki (but continuing here seems better to
>
>
> yep, I just saw that, and was already typing :-)
>
>> me). I don't like much this namespace-like syntax, especially if a
>> <wd:import> can appear everywhere in a definition file.
>>
>> Also, the "extends" attribute will require a notation to crawl up the
>> ancestors, as e.g. a widget inside a repeater can extend a type
>> defined outside the repeater.
>>
>> Or did I miss the point and the type scope is different from the
>> widget scope, meaning we have a flat type space (globally unique
>> names throughout a definition file) whereas the widget space is
>> hierarchical (unique among siblings)? In that case (and I prefer this
>> solution), then yes, a namespace-like syntax makes sense.
>>
>
> actually, your last paragraph shows you did get the point
> (in the end :-))
>
> here is the history I was typing up for you:
>
> Sylvain,
> I think we have evolved a radically different view of what wd:import
> was doing
>
> In the current setup it would not be a widget, hence no id, no
> container of other widgets.
>
> actually all this started when during a discussion (we had a number of
> those, quite long-winding ones in nov-dec-jan? on the list here)
>
> Tim and I started seeing that the current 'class' and 'new' widgets
> ARE NO REAL WIDGETS (as in 'instances' mapping to request params, what
> disguised them was the way how they abused the @id in a totally
> different way then the other widgets)
>
> In any case we decided that this define-reuse feature-set is in fact a
> different aspect then the form-build-up aspect...
> We concluded that attributes @define and @extend would be better
> suited to that purpose
> Reserving @id for those cases were we actually want to instantiate and
> thus reserve a request-parameter id.
>
> Once we were there we had actually created a local space in which the
> locally @define were reusable with a @extend. We had created a local
> repository of widgets... so naturally came the solution for external
> repositories
Tim and I once discussed the @define and @extend on IRC (which resulted
in the wiki scratchpad page), but there was no repository at that time.
> so here goes the idea:
> each cforms defintion file can @define reusable definition-templates
> and to reuse them in a different file you would need to refer to it in
> some way, hence the prefix idea
>
> from there I saw the resemblance to how xmlns binds a prefix to a uri,
> and tzadaam
>
> I think this confirms your fresh understanding, right?
Yep, and I totally agree with this. Having a hierarchy of types would
lead to a complicated mess from a user point of view. Also, my remark on
nested repositories is finally non-sense. A repository only publishes
the types it defines, even if these types extend types defined by
another repository. Repository import is not a transitive relation.
So +1 for @prefix and namespaced notation, as types and widget ids leave
in different spaces.
Now for type repositories to be real repositories, there's something
missing in the samples: we should be able to define a type without
defining a widget. In other words, it should be legal to have no @id if
there is a @defines, e.g:
<wd:field defines-type="date-field">
<wd:datatype base="date"/>
</wd:field>
This has the effect of declaring the type, but not producing any actual
widget in the parent container (be it a form or a repository).
> <snip />
>
>> "choice" is better, as it *is* a widget. It's a container widget with
>> an id (therefore defining a scope) and no value.
>>
>> This container can have two kinds of children:
>> - regular widgets that are referenced by the "case" and are therefore
>> common to several cases,
>> - "case" widgets that are in turn container for regular widgets and
>> references for the above common widgets.
>>
>> This leads to the interesting fact that common widgets can actually
>> be referenced by two names: one considering only their definition,
>> and one considering their reference in a case.
>>
>> Example:
>>
>> <wd:choice id="some-id">
>> <wd:field id="field-A".../>
>> <wd:case id="case-0" expr="case-1-expression">
>> <wd:ref id="field-A"/>
>> </wd:case>
>> </wd:choice>
>>
>> field-A can be referenced using "some-id.field-A" (don't care about
>> the actual case) and "some-id.case-o.field-A". It's canonical name
>> (used in request parameters) will be of course "some-id.field-A".
>>
>
> hm, I think Tim and I were still thinking about not having the choice
> actually contain it's widgets... (I have to say I'm still doubthing,
> but don't see it yet)
Mmmh... are you stating that wd:choice doesn't contain its widgets? Or
do you mean wd:case?
The problem we have to solve with wd:choice is that there can be some
widgets that are common to different cases. But IMO a wd:choice should
not reference widgets that are its siblings, but *contain* them.
wd:choice is a container.
Now the question is whether a wd:case can define its own widgets (i.e.
it is a container, child of the wd:choice) or if if can only reference
widgets defined in wd:choice (and therefore represent the "value" of the
wd:choice).
References are needed in a wd:case since we need widgets common to
different cases.
Widgets in a wd:case implicitely turns them into container, leading to
the dual path I outlined above. Thinking further, this overcomplexifies
the widget containment. Also, a wd:case can be considered as the "value"
of the wd:choice, driving, as you point out below, the list of available
children in the wd:choice.
So, here's a sum up of my (current) opinion: wd:choice is a container
whose children are the widgets for all cases, and wd:case only define
test expressions that decide the available children of the wd:choice and
its "value", that can be used later on in the template.
How does this sound?
> i.e. the request-param in my head would just be 'field-A', there is
> however also a 'some-id' request param to communicate the value that
> will drive the choice...
Mmmh..., IMO this will be "some-id.field-A", and there should *not* be a
parameter driving the choice. It's the result of the server-side
evaluation of the test expressions. Otherwise, we're open to consistency
problems and hacked requests.
> also, I don't know if there are to be two paths into the beast: point
> being that the 'case' part is IMHO not to be a separate
> widget-definition class, but rather a part of the
> configuration/processing context of the widget
Yep. The wd:case defines the "value" of the wd:choice.
> in other words: when asking a choice-widget which children it has, it
> would just list the currently 'chosen' widgets, and not the nested cases.
Agree.
> (hm, the last paragraph does sound like there is some
> parent-child/containment that justifies the nested request-param...)
Yes :-)
>> Case id's are also important because they will be used in views to
>> select which part of the template is to be displayed.
>
>
> not sure here, couldn't the template just react on those widgets that
> seem to have been 'chosen' at the time?
This isn't sufficient, as the view may want to produce different layouts
or informative text depending on the chosen case.
> from a styling POV you'll probably have a custom style surounding each
> of the possible children, and maybe other arrangements depending on
> the mix of available widgets... so reacting on the mix seems more
> sensible then duplicating the decision logic in the template, no?
>
> in any case, looking at the use-case behind these, I tend to believe
> that a generator approach is more natural, no?
Yes, definitely yes. I started using the generator approach a while ago
(with JXTemplate macros) because I needed:
- different renderings for empty/non-empty repeaters (don't want a table
with just headers if it's empty)
- a very special rendering for a wd:output containing the ID of a node
in a tree structure (the rendering shows the full path of the node, a la
dmoz.org, with i18nized node labels)
- conditional blocks depending on a widget's value (actually a poor
man's wd:choice)
These features are impossible to achieve with a transformer, but are
really easy with a generator.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [cforms] discussing the scratchpad (was Re: [WIKI-UPDATE] SandBox
WoodyScratchpad Mon Mar 29 21:00:04 2004)
Posted by Marc Portier <mp...@outerthought.org>.
Sylvain Wallez wrote:
<snip />
> I made some comments in the wiki (but continuing here seems better to
yep, I just saw that, and was already typing :-)
> me). I don't like much this namespace-like syntax, especially if a
> <wd:import> can appear everywhere in a definition file.
>
> Also, the "extends" attribute will require a notation to crawl up the
> ancestors, as e.g. a widget inside a repeater can extend a type defined
> outside the repeater.
>
> Or did I miss the point and the type scope is different from the widget
> scope, meaning we have a flat type space (globally unique names
> throughout a definition file) whereas the widget space is hierarchical
> (unique among siblings)? In that case (and I prefer this solution), then
> yes, a namespace-like syntax makes sense.
>
actually, your last paragraph shows you did get the point
(in the end :-))
here is the history I was typing up for you:
Sylvain,
I think we have evolved a radically different view of what wd:import was
doing
In the current setup it would not be a widget, hence no id, no container
of other widgets.
actually all this started when during a discussion (we had a number of
those, quite long-winding ones in nov-dec-jan? on the list here)
Tim and I started seeing that the current 'class' and 'new' widgets ARE
NO REAL WIDGETS (as in 'instances' mapping to request params, what
disguised them was the way how they abused the @id in a totally
different way then the other widgets)
In any case we decided that this define-reuse feature-set is in fact a
different aspect then the form-build-up aspect...
We concluded that attributes @define and @extend would be better suited
to that purpose
Reserving @id for those cases were we actually want to instantiate and
thus reserve a request-parameter id.
Once we were there we had actually created a local space in which the
locally @define were reusable with a @extend. We had created a local
repository of widgets... so naturally came the solution for external
repositories
so here goes the idea:
each cforms defintion file can @define reusable definition-templates
and to reuse them in a different file you would need to refer to it in
some way, hence the prefix idea
from there I saw the resemblance to how xmlns binds a prefix to a uri,
and tzadaam
I think this confirms your fresh understanding, right?
<snip />
>
> "choice" is better, as it *is* a widget. It's a container widget with an
> id (therefore defining a scope) and no value.
>
> This container can have two kinds of children:
> - regular widgets that are referenced by the "case" and are therefore
> common to several cases,
> - "case" widgets that are in turn container for regular widgets and
> references for the above common widgets.
>
> This leads to the interesting fact that common widgets can actually be
> referenced by two names: one considering only their definition, and one
> considering their reference in a case.
>
> Example:
>
> <wd:choice id="some-id">
> <wd:field id="field-A".../>
> <wd:case id="case-0" expr="case-1-expression">
> <wd:ref id="field-A"/>
> </wd:case>
> </wd:choice>
>
> field-A can be referenced using "some-id.field-A" (don't care about the
> actual case) and "some-id.case-o.field-A". It's canonical name (used in
> request parameters) will be of course "some-id.field-A".
>
hm, I think Tim and I were still thinking about not having the choice
actually contain it's widgets... (I have to say I'm still doubthing, but
don't see it yet)
i.e. the request-param in my head would just be 'field-A', there is
however also a 'some-id' request param to communicate the value that
will drive the choice...
also, I don't know if there are to be two paths into the beast: point
being that the 'case' part is IMHO not to be a separate
widget-definition class, but rather a part of the
configuration/processing context of the widget
in other words: when asking a choice-widget which children it has, it
would just list the currently 'chosen' widgets, and not the nested cases.
(hm, the last paragraph does sound like there is some
parent-child/containment that justifies the nested request-param...)
> Case id's are also important because they will be used in views to
> select which part of the template is to be displayed.
>
not sure here, couldn't the template just react on those widgets that
seem to have been 'chosen' at the time?
from a styling POV you'll probably have a custom style surounding each
of the possible children, and maybe other arrangements depending on the
mix of available widgets... so reacting on the mix seems more sensible
then duplicating the decision logic in the template, no?
in any case, looking at the use-case behind these, I tend to believe
that a generator approach is more natural, no?
regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: [cforms] discussing the scratchpad (was Re: [WIKI-UPDATE] SandBox WoodyScratchpad Mon Mar 29 21:00:04 2004)
Posted by Tim Larson <ti...@keow.org>.
On Tue, Mar 30, 2004 at 11:24:50PM +0200, Sylvain Wallez wrote:
<snip/>
I saw the wiki changes before I saw your email so I put comments there
first. I have a bunch more comments for your email, but I might not be
able to get them to the mailing list tonight, we'll see how my times
goes.
--Tim Larson
Re: [cforms] discussing the scratchpad (was Re: [WIKI-UPDATE] SandBox
WoodyScratchpad Mon Mar 29 21:00:04 2004)
Posted by Sylvain Wallez <sy...@apache.org>.
Marc Portier wrote:
> Since this starts looking like a consensus-reaching discussion I'm
> pulling it to the dev list
>
> others that want to join in, be sure to read up:
>
>> Page: http://wiki.cocoondev.org/Wiki.jsp?page=WoodyScratchpad ,
>> version: 12 on Sun Mar 29 19:17:58 2004 by 65.116.199.19
>>
>
>
>> + (tim: +1 to this alternative; nice syntax, and conveys the right
>> ideas more clearly.)
>> +
>
>
> Tim, thx for this feedback,
> ok if I swap it over the previous section then?
I made some comments in the wiki (but continuing here seems better to
me). I don't like much this namespace-like syntax, especially if a
<wd:import> can appear everywhere in a definition file.
Also, the "extends" attribute will require a notation to crawl up the
ancestors, as e.g. a widget inside a repeater can extend a type defined
outside the repeater.
Or did I miss the point and the type scope is different from the widget
scope, meaning we have a flat type space (globally unique names
throughout a definition file) whereas the widget space is hierarchical
(unique among siblings)? In that case (and I prefer this solution), then
yes, a namespace-like syntax makes sense.
>> - - This would also stress nicely that prefixes only have local
>> scope, that the sources are the real important things, and that the
>> form-manger could cache these repositories based on the source.
>> + This would also stress nicely that prefixes only have local scope,
>> that the sources are the real important things, and that the
>> form-manger could cache these repositories based on the source. (tim:
>> +1 the pre-built definition caching is one of the reasons for
>> importing instead of just using (x|c)include)
>> ?
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
>>
>> - **Anywhere a widget definition is allowed. (+1 mpo)
>> + **Anywhere a widget definition is allowed. (+1 mpo, +1 tim)
>> ? ++++++++
>>
>> - *Where should imported types be registered (affects namespace)?
>> (mpo: I don't get this question)
>> + *Where should imported types be registered (affects namespace)?
>> (mpo: I don't get this question) (tim: let's ignore it, I don't think
>> it makes sense anymore.)
>> ?
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
>
> ok
>
>> - **Widget definitions that will have instances created.
>> + **Widget definitions that will have instances created. (tim: Does
>> this have any usecases?)
>> ?
>> ++++++++++++++++++++++++++++++++++++
>
>
> not that I know of, in fact I couldn't really place that one either :-(
>
>>
>> + (''tim: I was thinking of offering both forms, not just
>> one-or-the-other, because I have usecases for both.'')
>
>
> ah, wasn't clear, I like the idea, just have to make the syntax clear
> then
>
>> - *What should we do if the expression evaluates to the default
>> anyway? (mpo: seems more logic in the when@test/otherwise filosophy?)
>> + *What should we do if the expression evaluates to the default
>> anyway? (mpo: seems more logic in the when@test/otherwise filosophy?)
>> (tim: I do not understand; could you clarify you comment?)
>> ?
>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
>
> in the when/@test and otherwise there is no real expression to be
> evaulated, just a last section that is always true if none of the
> above was...
>
>> - *What namespace should the widget id's be in? (''mpo: supposing you
>> refer to namespacing with respect to generated request-parameter
>> names, right?'')
>> + *What namespace should the widget id's be in? (''mpo: supposing you
>> refer to namespacing with respect to generated request-parameter
>> names, right?'') (''tim: yes'')
>> ?
>> +++++++++++++++
>>
>
> I'll rephrase our dialog as an extra clarification then
>
>> - ''mpo comments: I would prefer the case/@expr and default to become
>> when/@test and otherwise''
>> + ''mpo comments: I would prefer the case/@expr and default to become
>> when/@test and otherwise''//
>> ?
>> ++
>>
>> + ''tim comments: when/@test would be fine with me; should we also
>> copy the word 'choose' from xslt, instead of using 'choice'? 'choice'
>> seems more declarative, but I would be ok with either word.''
>>
>
> choose points at processing and doing the action
> choice makes it an entity
>
> the latter seems to hint that there is actually a widget with its own
> value to be used for driving the choice?
"choice" is better, as it *is* a widget. It's a container widget with an
id (therefore defining a scope) and no value.
This container can have two kinds of children:
- regular widgets that are referenced by the "case" and are therefore
common to several cases,
- "case" widgets that are in turn container for regular widgets and
references for the above common widgets.
This leads to the interesting fact that common widgets can actually be
referenced by two names: one considering only their definition, and one
considering their reference in a case.
Example:
<wd:choice id="some-id">
<wd:field id="field-A".../>
<wd:case id="case-0" expr="case-1-expression">
<wd:ref id="field-A"/>
</wd:case>
</wd:choice>
field-A can be referenced using "some-id.field-A" (don't care about the
actual case) and "some-id.case-o.field-A". It's canonical name (used in
request parameters) will be of course "some-id.field-A".
Case id's are also important because they will be used in views to
select which part of the template is to be displayed.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }