You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Tim Larson <ti...@keow.org> on 2004/11/04 19:47:09 UTC
cforms plans, templating engines, etc.
I have given further thought to some issues that were raised
and this has changed my opinion on branching cforms into the
whiteboard, and caused me to also want to clarify some other
issues. I ask that you please read the *whole* email before
starting to form responses :) Details below:
Choose/when and widget renaming:
I am planning several changes to cforms. These changes have
been discussed on the dev mailing list and the #cocoon irc
channel and summarized on the wiki. These changes include
new parallel choose/when elements and semantics in the
binding, model, and template layers, and renaming various
widgets in parallel in all three layers. If I understood
correctly, these changes had reached consensus and it was
just a matter of having the time to implement. Folling the
"do the least for the most benefit" rule, I started this
work with choose/when in the template, soon to be followed
by the parallel implementation of choose/when in the model
and binding. Based on this, I believe choose/when should
be reinstated in at least the dev branch (svn trunk.)
The development of all this does not break backwards
compatibility and has been discussed and (iiuc) agreed on,
so I see no reason to fork the development away from the
svn trunk, with the corresponding lack of feedback and
testing this would produce.
Macros, widget types, and type libraries:
This has also been discussed in the standard places, with
some recent discussion of macros (a renaming and extension
of class/new) getting more recent work on irc and the wiki.
Type libraries are collections of parameterized, reusable
form fragments, and macros and widget types are a essential
part of the implementation. These changes do not break
backwards compatibility either, and type libraries are a
recurring request, so I think this development effort
should also occur in the main development branch.
Compiled templates:
This is apparently a more controversial proposal, so I am
discussing it in this separate section. The goal is to
progress from speeding up the FormsTemplateTransformer
transformation process by eliminating the repetative
parsing and interpreting of the form templates by changing
to a compiled model, similar to the form model's design
of builder, definition, and widget classes. This may end
up with either two or three layers, depending on what I
encounter during the implementation. Because this is such
a big change, it would have to happen in parallel with
the existing forms transformer to prevent disturbing
current users. Given this provision, it seems this should
also be developed in the main dev branch for the sake of
feedback and testing.
Globally optimized template/transform pipelines:
This is an extension of the previous idea, "compiled
templates." Because it is of more general use than just
for cforms, it would probably have to migrate into its
own block at some point. However, since it would be based
on the cforms compiled template code and its initial
driving usecase would be supporting the cforms view layer,
imho it would not be too out of place to start the
development on it within the cforms block, so this could
be resolved when we get to the point of implementing it.
Basically, please delay worrying about this sub-project at
least until the steps before it are finished :) Because
I would like to delay any worry about this until we reach
a point where this could be implemented, and thus would be
useful to discuss, I will not go into detail here about
this sub-project.
Widget States (tm):
Separate control of output, input, styling, and validation:
It has been discussed that there are times when we need
separate control of these aspects for individual widgets
and groups of widgets, but also that the common cases would
be handy to select via named states that set all these
aspects at the same time. Various proposals have been
discussed and now we have an implementation in the stable
branch that has not undergone any testing in the dev branch
to see if the design is a good match for our usecases, and
we are a just few days from releasing the stable branch and
having to either maintain this new interface or have the
pain of migrating users to a new interface if problems are
found. This seems like a backwards way to develop, and I
admit to playing a part in landing in this situation, so
how should we procede? I don't know if I will have enough
time before the scheduled release to think through the
effects of the current interface and implementation, so I
am a bit concerned. I do know that it does not currently
support some of my usecases, but I have not had time to
investigate whether or not it could be extended to do so
in a backwards compatible way.
JXTemplates and forms transformer:
With all this discussion about template engines and
expression languages, what is the reasoning for starting
from the JXTemplateTransformer which people say is
composed of very tangled code (aside: I have not looked
at its code myself,) instead of on the fairly readable,
modular code of the FormsTemplateTransformer? Even if
we do follow the current JXTT rehabilitation plan, could
I not continue to improve the forms transformer?
The official Apache line is that we allow for competing
technology to coexist, as long as they all have potential
and actively being persued and used. Could I have a
chance to try to improve the forms transformer past the
abilities and usage patterns of the JXTT? This would
involve adding conditionals (choose/when,) macros,
imports, compilation, etc. I have been careful to not
make a habit of breaking backwards compatibility or the
build process for others, and I have been pursuing and
incorporating feedback from the community via the ml's,
irc, and wiki, and I have been supporting the components
that I have added. So could there please be room for
both approaches to have a chance to prove themselves?
Sorry this email is so long and covers so many topics,
but I wanted the community to know where I am trying
to head, and to eliminate any confusion caused by me
not explaining myself in a clear enough way. *Please*
do not take this as directed at any individual.
--Tim Larson
Re: [cforms] New when/choose widgets (was Re: cforms plans, templating
engines, etc.)
Posted by Sylvain Wallez <sy...@apache.org>.
Hey, Marc comes back :-)
Marc Portier wrote:
>
> Sylvain Wallez wrote:
>
>> Tim Larson wrote:
>>
<snip/>
> I agree: the issue of which expression language to take is another
> (practical) counter-argument
>
> (although making the observation that something like this starts
> limiting our design-freedom really suggests that we should do
> something towards hiding all those expr-script-languages floating
> around in cocoon behind some generic interface, no?)
I totally agree: we need some system-level expression evaluation
facility in Cocoon. But that's another hot subject lately, which has not
yet reached consensus. Once progress will be made regarding expression
languages, we may reconsider it for CForms _if we feel it is needed_ (up
to now, with rather complex use cases, I never had this need).
>>>> Also, there are some points I'd like us to to formalize.
>>>>
>>>> 1/ The wiki uses "choice" and "case" for the definition and
>>>> "choose" and "when" for the template. IMO, this is confusing and we
>>>> should have the same wording in the definition and in the template.
>>>
>>>
>>> I would use the same names in template, model, and binding.
>>> "choose/when" seemed to me to be the closest to consensus.
>>> Anyone have a different opinion?
>>
>>
>> "choose" is a verb whereas "widget", "repeater", "field" are nouns.
>> Using a noun therefore seems more consistent to me and that would be
>> therefore "choice". But I've been also thinking lately about "select"
>> or "variant". Naming is a difficult but important subject, as it
>> conveys the underlying semantics.
>
>
> I remember also the suggestion to let it be influenced by the
> 'normal-live-nomenclature' of the typical end-user....
>
> current naming seems to have a C-programming heritage,
>
> 'choice' was suggested for it's schema/dtd ring to it
>
> 'select' would probably yield the wrong association in HTML infected
> heads?
>
> 'variant' doesn't say a thing to me, but that might be a plus :-)
"choice" sounds good, actually, and "select" is also a verb.
<snip/>
>> IMO, the choice widget is "something", i.e. a structural unit like
>> other widgets, whereas the various alternatives are more variants of
>> what's in that thing. That means that choice would have an id and
>> therefore affect the path, but not the cases which define what
>> widgets are children of the choice depending on the case value.
>>
>> Consider the following example (datatypes ommited for brevety) where
>> we define the connection setting to a datasource (for example a CVS
>> server):
>>
>> <fd:choice id="datasource" case="datasource-type">
>> <fd:widgets>
>> <fd:field id="server"/>
>> <fd:field id="path"/>
>> <fd:field id="login"/>
>> <fd:field id="password"/>
>> <fd:widgets>
>> <fd:when case="local">
>> <fd:widget ref="path"/>
>> </fd:when>
>> <fd:when case="remote">
>> <fd:widget ref="server"/>
>> <fd:widget ref="path"/>
>> <fd:widget ref="login"/>
>> <fd:widget ref="password"/>
>> </fd:when>
>> <fd:choice>
>>
>> The "datasource" is an entity and threfore should appear in the path,
>> whereas "local" and "remote" are just test values. So we have
>> "datasource/path" (always) and "datasource/login",
>> "datasource/server" etc (when case is "remote").
>>
>
> I agree, surely it would feel awkward to have 'remote' (a value!) in
> the name-path
Sure, but that's what we have today with the union/case widget and
that's why we need to fix it :-)
<snip/>
>> IMO, inline widget definitions in the "when" can be considered as
>> shortcuts for defining a widget in the choice and then referencing it
>> when that widget only applies to one particular case, i.e. :
>>
>> <fd:choice id="foo">
>> <fd:when case="bar">
>> <fd:field id="baz"/>
>> </fd:when>
>> </fd:choice>
>>
>> Should be strictly equivalent to writing :
>>
>> <fd:choice id="foo">
>> <fd:widgets>
>> <fd:field id="baz"/>
>> </fd:widgets>
>> <fd:when case="bar">
>> <fd:widget ref="baz"/>
>> </fd:when>
>> </fd:choice>
>>
>> That also means that child ids must be unique throughout the various
>> cases.
>
>
> I like it
Great!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [cforms] New when/choose widgets (was Re: cforms plans, templating
engines, etc.)
Posted by Marc Portier <mp...@outerthought.org>.
Sylvain Wallez wrote:
> Tim Larson wrote:
>
>> On Sun, Nov 07, 2004 at 09:29:56PM +0100, Sylvain Wallez wrote:
>>
>>> Tim Larson wrote:
>>>
>>>> On Fri, Nov 05, 2004 at 09:58:43PM +0100, Sylvain Wallez wrote:
>>>>
<snip />
>>> So, why do we need *both* versions? Isn't it FS? Can you give some
>>> examples that justify this need? Up to now, I personally never had
>>> the need for evaluated conditions. I sometimes would like to use
>>> types other than String, and that can easily be done by associating
>>> adding a convertor that defines how values for the different cases
>>> are to be converted to typed values.
>>>
>>
>>
>> Your converter idea for handling other datatypes sounds good.
>> I personally only need the simple switch version that references
>> a widget (via a path passed to lookupWidget()) for the switch
>> value and selects the case which has the id matching the value.
>> Others requested the expression-on-every-case version, so they
>> would have to supply usecases for that version.
>>
>>
>
> Good. So people, if you need expression on every case, please speak up!
>
I remember suggesting that, but it's not driven from a concrete use
case, just a personal feeling of simplicity (let's not call it FS he :-))
just the general observation that a construct of the kind
switch (variable_to_check)
case value_1:
case value_2:
case value_3:
default:
really is a special (simpler) case of some
if (test1)
else if (test2)
else if (test3)
else
rather then the reverse, but that is a personal feeling: if you really
have more then one variable driving the decissions than the switch
construct forces you to invent a formula producing some 'virtual'
switch-variable, if not then the if-else-if is probably just a bit more
typing
also, observing that deep down the implementation will be mapped on an
if-else-if anyway it might be just doable
so far for the context, I understand you guys push for a decission so:
- I dont' think the usability would be limiting that much either way
(one can always find use cases that will argument in favour of one or
the other, so *shrug*)
- as agreed on the hackathon: going forward towards cforms-stable is far
more important then nth degree of slickness in feature-completeness
> Also, if that need is because the case values are computed and not only
that's indeed the only point
> a single widget's values, that can be modelled by a <fd:output> widget.
so we have a workaround that can be documented
> And the initialize() stuff Tim added will allow to finish the on-create
> event handler I started to implement, thus allowing computed widgets to
> register themselves as change-listeners on widgets their value depends on.
>
cool
>>> Furthermore, what expression language will be used? This leads us
>>> back to the discussion about expressions in JXTG, and the necessary
>>> unification of expression evaluation within Cocoon as a whole. I'm
>>> also not a fan of xReporter's expression language which is really
>>> specific to CForms.
>>>
>>
>>
>> I got stuck on this point also. Perhaps someone with a usecase
>> for the e-o-e-case version could comment?
>>
>>
>
> :-)
>
I agree: the issue of which expression language to take is another
(practical) counter-argument
(although making the observation that something like this starts
limiting our design-freedom really suggests that we should do something
towards hiding all those expr-script-languages floating around in cocoon
behind some generic interface, no?)
>>> Also, there are some points I'd like us to to formalize.
>>>
>>> 1/ The wiki uses "choice" and "case" for the definition and "choose"
>>> and "when" for the template. IMO, this is confusing and we should
>>> have the same wording in the definition and in the template.
>>>
>>
>>
>> I would use the same names in template, model, and binding.
>> "choose/when" seemed to me to be the closest to consensus.
>> Anyone have a different opinion?
>>
>>
>
> "choose" is a verb whereas "widget", "repeater", "field" are nouns.
> Using a noun therefore seems more consistent to me and that would be
> therefore "choice". But I've been also thinking lately about "select" or
> "variant". Naming is a difficult but important subject, as it conveys
> the underlying semantics.
>
I remember also the suggestion to let it be influenced by the
'normal-live-nomenclature' of the typical end-user....
current naming seems to have a C-programming heritage,
'choice' was suggested for it's schema/dtd ring to it
'select' would probably yield the wrong association in HTML infected heads?
'variant' doesn't say a thing to me, but that might be a plus :-)
>>> 1/ Is it a container? Looking at the wiki, the "valued expression
>>> selects case" version has no id. Also, are each fd:case also
>>> containers? My opinion is that fd:when should be a container, but not
>>> fd:case. This is enforced by the reuse of widgets between cases.
>>>
>>
>>
>> Choose and when would both be *implemented* as containers, but
>> they would not affect the paths/namespaces of the widgets they
>> "contain". Think of it as a control structure rather than as
>> a real container "widget". Also the id on the "choose" should
>> be optional.
>>
>>
>
> IMO, the choice widget is "something", i.e. a structural unit like other
> widgets, whereas the various alternatives are more variants of what's in
> that thing. That means that choice would have an id and therefore affect
> the path, but not the cases which define what widgets are children of
> the choice depending on the case value.
>
> Consider the following example (datatypes ommited for brevety) where we
> define the connection setting to a datasource (for example a CVS server):
>
> <fd:choice id="datasource" case="datasource-type">
> <fd:widgets>
> <fd:field id="server"/>
> <fd:field id="path"/>
> <fd:field id="login"/>
> <fd:field id="password"/>
> <fd:widgets>
> <fd:when case="local">
> <fd:widget ref="path"/>
> </fd:when>
> <fd:when case="remote">
> <fd:widget ref="server"/>
> <fd:widget ref="path"/>
> <fd:widget ref="login"/>
> <fd:widget ref="password"/>
> </fd:when>
> <fd:choice>
>
> The "datasource" is an entity and threfore should appear in the path,
> whereas "local" and "remote" are just test values. So we have
> "datasource/path" (always) and "datasource/login", "datasource/server"
> etc (when case is "remote").
>
I agree, surely it would feel awkward to have 'remote' (a value!) in the
name-path
>> For example, this would allow the model to choose between two
>> widgets with the same id but with different datatypes without
>> having to modify the corresponding template to recognize that
>> a choice is even being made. In this example there is no need
>> for "choose" to have an id, because the choice does not need
>> to be referenced.
>>
>
> Sorry, but I find having the same id for different widgets depending on
> the choice condition very confusing. IMO, an id should designate one
> thing only, without ambiguity.
>
+1 being infected by java and xml I favour (verbose) explicity over
terseness (and magic)
> The choice condition should define _which_ widgets (and therefore ids)
> are available, not _how_ these widgets are defined. Also, it's very
> likely that a choice in the definition also leads to a choice in the
> view and in the binding.
>
>> For a "choose" that picks between different
>> sets of widgets, or whenever you want the template or binding
>> to be able to react to the selected choice, then the "choose"
>> control structure will need an id.
>>
>>
>
> And if it's got an id, it's no more a control structure, but a widget,
> hence the naming with a noun rather than a verb as outlined above.
>
>>> 2/ Widgets for a case: do we allow inline widgets to be defined in a
>>> fd:case, or only have references with fd:ref? Allowing both may cause
>>> some naming problems (this is also related to the previous question
>>> about containment), as an inline widget's name may conflict with a
>>> widget defined in fd:when. Similarily, if fd:case is not a container,
>>> widgets having the same name in different fd:cases will conflict.
>>>
>>
>>
>> Allow widget definitions in the "choose" for cherry-picking
>> in the "when"'s (refered to as fd:case's above,) and also
>> allow widget definitions in the "when"'s. This allows for
>> the type of example I described above.
>>
>>
>
> ... which I found confusing :-)
>
same here,
feels a bit like we're mixin' in the concern to reduce typing?
IMHO that aspect should be handled by the registry and new/class stuff?
> IMO, inline widget definitions in the "when" can be considered as
> shortcuts for defining a widget in the choice and then referencing it
> when that widget only applies to one particular case, i.e. :
>
> <fd:choice id="foo">
> <fd:when case="bar">
> <fd:field id="baz"/>
> </fd:when>
> </fd:choice>
>
> Should be strictly equivalent to writing :
>
> <fd:choice id="foo">
> <fd:widgets>
> <fd:field id="baz"/>
> </fd:widgets>
> <fd:when case="bar">
> <fd:widget ref="baz"/>
> </fd:when>
> </fd:choice>
>
> That also means that child ids must be unique throughout the various cases.
>
> WDYT?
>
I like it
-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] New when/choose widgets (was Re: cforms plans, templating
engines, etc.)
Posted by Sylvain Wallez <sy...@apache.org>.
Tim Larson wrote:
>On Sun, Nov 07, 2004 at 09:29:56PM +0100, Sylvain Wallez wrote:
>
>
>>Tim Larson wrote:
>>
>>
>>>On Fri, Nov 05, 2004 at 09:58:43PM +0100, Sylvain Wallez wrote:
>>>
>>>
>>>
>>>>Ok. Does this mean choose/when will replace union/case? Also, the wiki
>>>>[1] shows several alternatives for choose/when, and unless I missed
>>>>something we have not decided which approach to use.
>>>>
>>>>
>>>Yes, choose/when is intended to replace union/case (following
>>>with any deprecation pattern that is needed). There are two
>>>alternatives, with the intention to have *both*, to service
>>>different usecases.
>>>
>>>
>>Preliminary notice: don't get me wrong with all these questions and
>>remarks. I'm shaking the concept so that it solidifies and we all agree
>>on how it should behave before starting to write down some code.
>>
>>
>
>Thanks for providing feedback :)
>
>
>
>>So, why do we need *both* versions? Isn't it FS? Can you give some
>>examples that justify this need? Up to now, I personally never had the
>>need for evaluated conditions. I sometimes would like to use types other
>>than String, and that can easily be done by associating adding a
>>convertor that defines how values for the different cases are to be
>>converted to typed values.
>>
>>
>
>Your converter idea for handling other datatypes sounds good.
>I personally only need the simple switch version that references
>a widget (via a path passed to lookupWidget()) for the switch
>value and selects the case which has the id matching the value.
>Others requested the expression-on-every-case version, so they
>would have to supply usecases for that version.
>
>
Good. So people, if you need expression on every case, please speak up!
Also, if that need is because the case values are computed and not only
a single widget's values, that can be modelled by a <fd:output> widget.
And the initialize() stuff Tim added will allow to finish the on-create
event handler I started to implement, thus allowing computed widgets to
register themselves as change-listeners on widgets their value depends on.
>>Furthermore, what expression language will be used? This leads us back
>>to the discussion about expressions in JXTG, and the necessary
>>unification of expression evaluation within Cocoon as a whole. I'm also
>>not a fan of xReporter's expression language which is really specific to
>>CForms.
>>
>>
>
>I got stuck on this point also. Perhaps someone with a usecase
>for the e-o-e-case version could comment?
>
>
:-)
>>Also, there are some points I'd like us to to formalize.
>>
>>1/ The wiki uses "choice" and "case" for the definition and "choose" and
>>"when" for the template. IMO, this is confusing and we should have the
>>same wording in the definition and in the template.
>>
>>
>
>I would use the same names in template, model, and binding.
>"choose/when" seemed to me to be the closest to consensus.
>Anyone have a different opinion?
>
>
"choose" is a verb whereas "widget", "repeater", "field" are nouns.
Using a noun therefore seems more consistent to me and that would be
therefore "choice". But I've been also thinking lately about "select" or
"variant". Naming is a difficult but important subject, as it conveys
the underlying semantics.
>>1/ Is it a container? Looking at the wiki, the "valued expression
>>selects case" version has no id. Also, are each fd:case also containers?
>>My opinion is that fd:when should be a container, but not fd:case. This
>>is enforced by the reuse of widgets between cases.
>>
>>
>
>Choose and when would both be *implemented* as containers, but
>they would not affect the paths/namespaces of the widgets they
>"contain". Think of it as a control structure rather than as
>a real container "widget". Also the id on the "choose" should
>be optional.
>
>
IMO, the choice widget is "something", i.e. a structural unit like other
widgets, whereas the various alternatives are more variants of what's in
that thing. That means that choice would have an id and therefore affect
the path, but not the cases which define what widgets are children of
the choice depending on the case value.
Consider the following example (datatypes ommited for brevety) where we
define the connection setting to a datasource (for example a CVS server):
<fd:choice id="datasource" case="datasource-type">
<fd:widgets>
<fd:field id="server"/>
<fd:field id="path"/>
<fd:field id="login"/>
<fd:field id="password"/>
<fd:widgets>
<fd:when case="local">
<fd:widget ref="path"/>
</fd:when>
<fd:when case="remote">
<fd:widget ref="server"/>
<fd:widget ref="path"/>
<fd:widget ref="login"/>
<fd:widget ref="password"/>
</fd:when>
<fd:choice>
The "datasource" is an entity and threfore should appear in the path,
whereas "local" and "remote" are just test values. So we have
"datasource/path" (always) and "datasource/login", "datasource/server"
etc (when case is "remote").
>For example, this would allow the model to choose between two
>widgets with the same id but with different datatypes without
>having to modify the corresponding template to recognize that
>a choice is even being made. In this example there is no need
>for "choose" to have an id, because the choice does not need
>to be referenced.
>
Sorry, but I find having the same id for different widgets depending on
the choice condition very confusing. IMO, an id should designate one
thing only, without ambiguity.
The choice condition should define _which_ widgets (and therefore ids)
are available, not _how_ these widgets are defined. Also, it's very
likely that a choice in the definition also leads to a choice in the
view and in the binding.
>For a "choose" that picks between different
>sets of widgets, or whenever you want the template or binding
>to be able to react to the selected choice, then the "choose"
>control structure will need an id.
>
>
And if it's got an id, it's no more a control structure, but a widget,
hence the naming with a noun rather than a verb as outlined above.
>>2/ Widgets for a case: do we allow inline widgets to be defined in a
>>fd:case, or only have references with fd:ref? Allowing both may cause
>>some naming problems (this is also related to the previous question
>>about containment), as an inline widget's name may conflict with a
>>widget defined in fd:when. Similarily, if fd:case is not a container,
>>widgets having the same name in different fd:cases will conflict.
>>
>>
>
>Allow widget definitions in the "choose" for cherry-picking
>in the "when"'s (refered to as fd:case's above,) and also
>allow widget definitions in the "when"'s. This allows for
>the type of example I described above.
>
>
... which I found confusing :-)
IMO, inline widget definitions in the "when" can be considered as
shortcuts for defining a widget in the choice and then referencing it
when that widget only applies to one particular case, i.e. :
<fd:choice id="foo">
<fd:when case="bar">
<fd:field id="baz"/>
</fd:when>
</fd:choice>
Should be strictly equivalent to writing :
<fd:choice id="foo">
<fd:widgets>
<fd:field id="baz"/>
</fd:widgets>
<fd:when case="bar">
<fd:widget ref="baz"/>
</fd:when>
</fd:choice>
That also means that child ids must be unique throughout the various cases.
WDYT?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [cforms] New when/choose widgets (was Re: cforms plans, templating engines, etc.)
Posted by Tim Larson <ti...@keow.org>.
On Sun, Nov 07, 2004 at 09:29:56PM +0100, Sylvain Wallez wrote:
> Tim Larson wrote:
> >On Fri, Nov 05, 2004 at 09:58:43PM +0100, Sylvain Wallez wrote:
> >
> >>Ok. Does this mean choose/when will replace union/case? Also, the wiki
> >>[1] shows several alternatives for choose/when, and unless I missed
> >>something we have not decided which approach to use.
> >
> >Yes, choose/when is intended to replace union/case (following
> >with any deprecation pattern that is needed). There are two
> >alternatives, with the intention to have *both*, to service
> >different usecases.
>
> Preliminary notice: don't get me wrong with all these questions and
> remarks. I'm shaking the concept so that it solidifies and we all agree
> on how it should behave before starting to write down some code.
Thanks for providing feedback :)
> So, why do we need *both* versions? Isn't it FS? Can you give some
> examples that justify this need? Up to now, I personally never had the
> need for evaluated conditions. I sometimes would like to use types other
> than String, and that can easily be done by associating adding a
> convertor that defines how values for the different cases are to be
> converted to typed values.
Your converter idea for handling other datatypes sounds good.
I personally only need the simple switch version that references
a widget (via a path passed to lookupWidget()) for the switch
value and selects the case which has the id matching the value.
Others requested the expression-on-every-case version, so they
would have to supply usecases for that version.
> Furthermore, what expression language will be used? This leads us back
> to the discussion about expressions in JXTG, and the necessary
> unification of expression evaluation within Cocoon as a whole. I'm also
> not a fan of xReporter's expression language which is really specific to
> CForms.
I got stuck on this point also. Perhaps someone with a usecase
for the e-o-e-case version could comment?
> Also, there are some points I'd like us to to formalize.
>
> 1/ The wiki uses "choice" and "case" for the definition and "choose" and
> "when" for the template. IMO, this is confusing and we should have the
> same wording in the definition and in the template.
I would use the same names in template, model, and binding.
"choose/when" seemed to me to be the closest to consensus.
Anyone have a different opinion?
> 1/ Is it a container? Looking at the wiki, the "valued expression
> selects case" version has no id. Also, are each fd:case also containers?
> My opinion is that fd:when should be a container, but not fd:case. This
> is enforced by the reuse of widgets between cases.
Choose and when would both be *implemented* as containers, but
they would not affect the paths/namespaces of the widgets they
"contain". Think of it as a control structure rather than as
a real container "widget". Also the id on the "choose" should
be optional.
For example, this would allow the model to choose between two
widgets with the same id but with different datatypes without
having to modify the corresponding template to recognize that
a choice is even being made. In this example there is no need
for "choose" to have an id, because the choice does not need
to be referenced. For a "choose" that picks between different
sets of widgets, or whenever you want the template or binding
to be able to react to the selected choice, then the "choose"
control structure will need an id.
> 2/ Widgets for a case: do we allow inline widgets to be defined in a
> fd:case, or only have references with fd:ref? Allowing both may cause
> some naming problems (this is also related to the previous question
> about containment), as an inline widget's name may conflict with a
> widget defined in fd:when. Similarily, if fd:case is not a container,
> widgets having the same name in different fd:cases will conflict.
Allow widget definitions in the "choose" for cherry-picking
in the "when"'s (refered to as fd:case's above,) and also
allow widget definitions in the "when"'s. This allows for
the type of example I described above.
WDYT?
--Tim Larson
[cforms] New when/choose widgets (was Re: cforms plans, templating
engines, etc.)
Posted by Sylvain Wallez <sy...@apache.org>.
Tim Larson wrote:
>On Fri, Nov 05, 2004 at 09:58:43PM +0100, Sylvain Wallez wrote:
>
>
>>Ok. Does this mean choose/when will replace union/case? Also, the wiki
>>[1] shows several alternatives for choose/when, and unless I missed
>>something we have not decided which approach to use.
>>
>>
>
>Yes, choose/when is intended to replace union/case (following
>with any deprecation pattern that is needed). There are two
>alternatives, with the intention to have *both*, to service
>different usecases.
>
>
Preliminary notice: don't get me wrong with all these questions and
remarks. I'm shaking the concept so that it solidifies and we all agree
on how it should behave before starting to write down some code.
So, why do we need *both* versions? Isn't it FS? Can you give some
examples that justify this need? Up to now, I personally never had the
need for evaluated conditions. I sometimes would like to use types other
than String, and that can easily be done by associating adding a
convertor that defines how values for the different cases are to be
converted to typed values.
Furthermore, what expression language will be used? This leads us back
to the discussion about expressions in JXTG, and the necessary
unification of expression evaluation within Cocoon as a whole. I'm also
not a fan of xReporter's expression language which is really specific to
CForms.
Also, there are some points I'd like us to to formalize.
1/ The wiki uses "choice" and "case" for the definition and "choose" and
"when" for the template. IMO, this is confusing and we should have the
same wording in the definition and in the template.
1/ Is it a container? Looking at the wiki, the "valued expression
selects case" version has no id. Also, are each fd:case also containers?
My opinion is that fd:when should be a container, but not fd:case. This
is enforced by the reuse of widgets between cases.
2/ Widgets for a case: do we allow inline widgets to be defined in a
fd:case, or only have references with fd:ref? Allowing both may cause
some naming problems (this is also related to the previous question
about containment), as an inline widget's name may conflict with a
widget defined in fd:when. Similarily, if fd:case is not a container,
widgets having the same name in different fd:cases will conflict.
Thoughts?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [Question] Re: cforms plans, templating engines, etc.
Posted by Sylvain Wallez <sy...@apache.org>.
Tim Larson wrote:
>On Wed, Nov 10, 2004 at 08:54:33PM +0100, Sylvain Wallez wrote:
>
>
>>Tim Larson wrote:
>>
>>
<snip/>
>>>I finaly got to look at the widget states implementation,
>>>and even port parts of Swan to use it (working on porting
>>>the rest now). I see some things we can improve, but it
>>>looks good overall because of the separation between how
>>>we set states and how we query them.
>>>
>>>
>>Do you mean the distinction between getState() and getCombinedState()? I
>>implemented it that way because I felt that we may need to now the
>>actual state of a widget and not always the combination with it's parent
>>state according to the state priority rules.
>>
>>
>
>Yes, I like the the getState()/getCombinedState() split,
>and also the split between how we set a state (currently
>all attributes at once: readable, writeable, styling hint)
>versus how we query the state with isXXX (quering the
>attributes individually.) This will permit us to later
>allow setting the different attributes independently
>(if the need develops.)
>
>
>
>>>This will allow
>>>us to add more fine-grained state setting logic without
>>>disturbing existing state querying logic (if we find we
>>>need these changes in the future.) I will comment on
>>>the possible improvements later when I have collected
>>>my thoughts more, since they should not affect back-
>>>compatibility anyways.
>>>
>>>
>>Ok, waiting :-)
>>
>>
>
>The most visible problem is that getCombinedState() is
>called several times per widget, and (iiuc) it climbs
>up to the root of the widget tree on each call. This
>would be rather inefficient for a deeply nested form,
>such as an xml editor. Perhaps we should reverse and
>cache the updates, having a parent notify its children
>when its state changes? This would cut the number of
>tree passes considerably, at the cost of some memory
>use for caching the combined states.
>
>
I thought about this problem when implementing states, and wanted to add
a "parentStateChanged()" method to the Widget interface, so that a
container could notify its children that some state change happened in
the upper levels, for them to recompute their combined states.
I decided however not to add it as it seemed to me like letting the
internal state computing machinery appear on the general widget
interface. The state combination is very lightweight (comparing two
integers) and my feeling was that it should only become visible in very
large and very deep structures.
This is something we can add now or later with no other impact than this
new parentStateChanged method.
BTW, for something really inefficient, have a look at getParameterName()
before updating SVN: the string concatenation occurs at each call when
we know that, contrarily to states, a widget path never changes! I just
changed it so that computation occurs only once.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [Question] Re: cforms plans, templating engines, etc.
Posted by Tim Larson <ti...@keow.org>.
On Wed, Nov 10, 2004 at 08:54:33PM +0100, Sylvain Wallez wrote:
> Tim Larson wrote:
> >On Sun, Nov 07, 2004 at 09:29:40PM +0100, Sylvain Wallez wrote:
> >>Tim Larson wrote:
> >>>On Fri, Nov 05, 2004 at 09:58:43PM +0100, Sylvain Wallez wrote:
> >>>>Tim Larson wrote:
> >>>>
> >>>concerns before. I will try to take some time this weekend
> >>>to see how to resolve this. I really do not want to revert
> >>>the code if we can just improve it instead. I just feel
> >>>pressured by the short time before we plan to release.
> >>>
> >>So let's discuss your concerns. I started looking at Swan, and it seems
> >>to me that what's needed is simply and additional "output" state.
> >>
> >>Do you want me also to explain more clearly how states are implemented
> >>and behave (lacked the time to write some docs)?
> >
> >I finaly got to look at the widget states implementation,
> >and even port parts of Swan to use it (working on porting
> >the rest now). I see some things we can improve, but it
> >looks good overall because of the separation between how
> >we set states and how we query them.
>
> Do you mean the distinction between getState() and getCombinedState()? I
> implemented it that way because I felt that we may need to now the
> actual state of a widget and not always the combination with it's parent
> state according to the state priority rules.
Yes, I like the the getState()/getCombinedState() split,
and also the split between how we set a state (currently
all attributes at once: readable, writeable, styling hint)
versus how we query the state with isXXX (quering the
attributes individually.) This will permit us to later
allow setting the different attributes independently
(if the need develops.)
> >This will allow
> >us to add more fine-grained state setting logic without
> >disturbing existing state querying logic (if we find we
> >need these changes in the future.) I will comment on
> >the possible improvements later when I have collected
> >my thoughts more, since they should not affect back-
> >compatibility anyways.
>
> Ok, waiting :-)
The most visible problem is that getCombinedState() is
called several times per widget, and (iiuc) it climbs
up to the root of the widget tree on each call. This
would be rather inefficient for a deeply nested form,
such as an xml editor. Perhaps we should reverse and
cache the updates, having a parent notify its children
when its state changes? This would cut the number of
tree passes considerably, at the cost of some memory
use for caching the combined states.
> >[Question:]
> >http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=109994348811745&w=2
> >Is this change acceptable for keeping in the trunk and
> >including in the stable branch? (The part about changing
> >from isAcceptingInputs() to isValidatingValues() in
> >the widgets' validate() methods?) Currently both methods
> >will return the same value, but this will allow us to
> >split the logic later if needed.
>
> Good idea. The various isXXX methods on WidgetState are meant to avoid
> direct reference to actual state constants within the code. That firstly
> avoids inconsistencies and also allow later extension if needed (once
> again, I think we'll need to add an "output" state).
>
> So go on merging in the stable branch!
Ok :)
> >>Well, you've got a point here: yes, you should probably explain more
> >>what you want to do. The group's feedback will strengthen the ideas and
> >>turn them into a collective creation rather than a one-man show.
> >
> >Agreed. I will update my wiki page to explain my current
> >plans, so they can be discussed, changed, and improved :)
>
> Good idea, but rather than your page or WoodyScratchpad, what about a
> new CFormsScratchpad or a [RT] so that we can all work collaboratively
> towards well-defined evolutions?
Yes, that sounds like a better way.
--Tim Larson
Re: [Question] Re: cforms plans, templating engines, etc.
Posted by Sylvain Wallez <sy...@apache.org>.
Tim Larson wrote:
>On Sun, Nov 07, 2004 at 09:29:40PM +0100, Sylvain Wallez wrote:
>
>
>>Tim Larson wrote:
>>
>>
>>>On Fri, Nov 05, 2004 at 09:58:43PM +0100, Sylvain Wallez wrote:
>>>
>>>
>>>>Tim Larson wrote:
>>>>
>>>>
>>>concerns before. I will try to take some time this weekend
>>>to see how to resolve this. I really do not want to revert
>>>the code if we can just improve it instead. I just feel
>>>pressured by the short time before we plan to release.
>>>
>>>
>>So let's discuss your concerns. I started looking at Swan, and it seems
>>to me that what's needed is simply and additional "output" state.
>>
>>Do you want me also to explain more clearly how states are implemented
>>and behave (lacked the time to write some docs)?
>>
>>
>
>I finaly got to look at the widget states implementation,
>and even port parts of Swan to use it (working on porting
>the rest now). I see some things we can improve, but it
>looks good overall because of the separation between how
>we set states and how we query them.
>
Do you mean the distinction between getState() and getCombinedState()? I
implemented it that way because I felt that we may need to now the
actual state of a widget and not always the combination with it's parent
state according to the state priority rules.
>This will allow
>us to add more fine-grained state setting logic without
>disturbing existing state querying logic (if we find we
>need these changes in the future.) I will comment on
>the possible improvements later when I have collected
>my thoughts more, since they should not affect back-
>compatibility anyways.
>
>
Ok, waiting :-)
>[Question:]
>http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=109994348811745&w=2
>Is this change acceptable for keeping in the trunk and
>including in the stable branch? (The part about changing
>from isAcceptingInputs() to isValidatingValues() in
>the widgets' validate() methods?) Currently both methods
>will return the same value, but this will allow us to
>split the logic later if needed.
>
>
Good idea. The various isXXX methods on WidgetState are meant to avoid
direct reference to actual state constants within the code. That firstly
avoids inconsistencies and also allow later extension if needed (once
again, I think we'll need to add an "output" state).
So go on merging in the stable branch!
>>Well, you've got a point here: yes, you should probably explain more
>>what you want to do. The group's feedback will strengthen the ideas and
>>turn them into a collective creation rather than a one-man show.
>>
>>
>
>Agreed. I will update my wiki page to explain my current
>plans, so they can be discussed, changed, and improved :)
>
>
Good idea, but rather than your page or WoodyScratchpad, what about a
new CFormsScratchpad or a [RT] so that we can all work collaboratively
towards well-defined evolutions?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
[Question] Re: cforms plans, templating engines, etc.
Posted by Tim Larson <ti...@keow.org>.
On Sun, Nov 07, 2004 at 09:29:40PM +0100, Sylvain Wallez wrote:
> Tim Larson wrote:
> >On Fri, Nov 05, 2004 at 09:58:43PM +0100, Sylvain Wallez wrote:
> >>Tim Larson wrote:
>
> >concerns before. I will try to take some time this weekend
> >to see how to resolve this. I really do not want to revert
> >the code if we can just improve it instead. I just feel
> >pressured by the short time before we plan to release.
>
> So let's discuss your concerns. I started looking at Swan, and it seems
> to me that what's needed is simply and additional "output" state.
>
> Do you want me also to explain more clearly how states are implemented
> and behave (lacked the time to write some docs)?
I finaly got to look at the widget states implementation,
and even port parts of Swan to use it (working on porting
the rest now). I see some things we can improve, but it
looks good overall because of the separation between how
we set states and how we query them. This will allow
us to add more fine-grained state setting logic without
disturbing existing state querying logic (if we find we
need these changes in the future.) I will comment on
the possible improvements later when I have collected
my thoughts more, since they should not affect back-
compatibility anyways.
[Question:]
http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=109994348811745&w=2
Is this change acceptable for keeping in the trunk and
including in the stable branch? (The part about changing
from isAcceptingInputs() to isValidatingValues() in
the widgets' validate() methods?) Currently both methods
will return the same value, but this will allow us to
split the logic later if needed.
> Well, you've got a point here: yes, you should probably explain more
> what you want to do. The group's feedback will strengthen the ideas and
> turn them into a collective creation rather than a one-man show.
Agreed. I will update my wiki page to explain my current
plans, so they can be discussed, changed, and improved :)
> Well, I only saw changes to the template transformer, and no
> corresponding change in the form model, hence my impression you were
> writing a new template language. I also do not consider the
> WoodyScratchpad page a formal specification: we discussed for a while
> there, wrote down some ideas, and let them apart for quite a long time
> with still a lot of open questions and things to formalize.
> Great, I'm glad we solved some misunderstandings :-)
Me too :)
--Tim Larson
Re: cforms plans, templating engines, etc.
Posted by Sylvain Wallez <sy...@apache.org>.
Tim Larson wrote:
>On Fri, Nov 05, 2004 at 09:58:43PM +0100, Sylvain Wallez wrote:
>
>
>>Tim Larson wrote:
>>
>>Sorry for this late answer, I was out of office today (woke up a 5am to
>>go to the airport :-/ )
>>
>>
>
>No problem, we all have different schedules to juggle.
>Thank you very much for taking the time to consider and
>answer my concerns. Comments inline.
>
>
>>>and binding. Based on this, I believe choose/when should
>>>be reinstated in at least the dev branch (svn trunk.)
>>>
>>>
>>During the merge, I have not touched at it choose/when in trunk.
>>
>>
>
>Ok, I must have misunderstood this:
> > ft:choose: we've talked about it already, and I removed
> > it until we know more about Tim's experiments.
>to mean removed from both dev and stable when you only meant
>that it was excluded from stable for now, like we decided.
>(Sorry, I felt pressured by the impending release and am just
>now starting to go through your actual commit.)
>
>
Well, I should have been more clear by writing "I removed it from the
2.1.x branch" :-)
>>>The development of all this does not break backwards
>>>compatibility and has been discussed and (iiuc) agreed on,
>>>so I see no reason to fork the development away from the
>>>svn trunk, with the corresponding lack of feedback and
>>>testing this would produce.
>>>
>>>
>>Ok. Does this mean choose/when will replace union/case? Also, the wiki
>>[1] shows several alternatives for choose/when, and unless I missed
>>something we have not decided which approach to use.
>>
>>
>
>Yes, choose/when is intended to replace union/case (following
>with any deprecation pattern that is needed). There are two
>alternatives, with the intention to have *both*, to service
>different usecases.
>
>
I'm replying to this in a new thread, as we need to formalize this
choose/when thing.
>>>Macros, widget types, and type libraries:
>>>
>>>
>>Right. This is a necessary evolution.
>>
>>
>
>Great!
>
>
>>>Compiled templates:
>>>
>>>
>>The problem is _where_ in the dev branch? What are the areas where this
>>compiled template stuff is applicable? Is it limited to CForms?
>>
>>
>
>Yes, at this stage this will only be useful to CForms.
>
>
>>As I understand it, this is a rewrite of the FormsTransformer. This can
>>happen in the CForms block, but _besides_ the current code. Just as your
>>EffectPipe lived besides the original FormsTransformer before replacing
>>it once we all considered it was better. What makes this subject
>>controversial is that you seem to want to replace the EffectPipe right now.
>>
>>
>
>Yes it is a rewrite of that code. And my plan from the start was
>to implement it beside the existing code, just like you describe.
>Sorry for any confusion on that.
>
>
Ok, great.
<snip/>
>>What worries me is the fact that you want to explore new directions
>>which, although they seem really interesting and worth exploring, will
>>disturb the way to stability of the CForms block *if* they are
>>developped within that block.
>>
>>
>
>To summarize:
>Choose/when, macros, widget types, and libraries are aimed
>at backwards-compatible development in-place. Compiled
>templates are aimed to be developed beside the current FTT,
>but still in the same block and java package, just like how
>the EffectPipe code got started. The optimized pipeline
>code is still a ways off, but it would also be developed
>beside existing code rather than in-place, and its location
>is not an issue to me (its own block is fine if necessary.)
>
>Any remaining issues with the above plan?
>
>
Sounds good! We now have to work on each item, starting with choose/when
(see other thread).
>>>Widget States (tm):
>>>Separate control of output, input, styling, and validation:
>>>It has been discussed that there are times when we need
>>>separate control of these aspects for individual widgets
>>>and groups of widgets, but also that the common cases would
>>>be handy to select via named states that set all these
>>>aspects at the same time. Various proposals have been
>>>discussed and now we have an implementation in the stable
>>>branch that has not undergone any testing in the dev branch
>>>to see if the design is a good match for our usecases, and
>>>we are a just few days from releasing the stable branch and
>>>having to either maintain this new interface or have the
>>>pain of migrating users to a new interface if problems are
>>>found.
>>>
>>>
>>Hey, that's near to FUD: widget states have been discussed many times at
>>length, and I implemented something we collectively agreed upon. They
>>are in the stable branch because this is a feature that was identified
>>as being needed to reach stable state on CForms.
>>
>>
>
>Sorry for sounding like FUD, but I never bought into the
>current design, just the goals, and I have expressed my
>concerns before. I will try to take some time this weekend
>to see how to resolve this. I really do not want to revert
>the code if we can just improve it instead. I just feel
>pressured by the short time before we plan to release.
>
>
So let's discuss your concerns. I started looking at Swan, and it seems
to me that what's needed is simply and additional "output" state.
Do you want me also to explain more clearly how states are implemented
and behave (lacked the time to write some docs)?
<snip/>
>>>The official Apache line is that we allow for competing
>>>technology to coexist, as long as they all have potential
>>>and actively being persued and used. Could I have a
>>>chance to try to improve the forms transformer past the
>>>abilities and usage patterns of the JXTT?This would
>>>involve adding conditionals (choose/when,) macros,
>>>imports, compilation, etc. I have been careful to not
>>>make a habit of breaking backwards compatibility or the
>>>build process for others, and I have been pursuing and
>>>incorporating feedback from the community via the ml's,
>>>irc, and wiki, and I have been supporting the components
>>>that I have added. So could there please be room for
>>>both approaches to have a chance to prove themselves?
>>>
>>>
>>Tim, I understand your point. You feel frustrated because you don't feel
>>to have a place for experimenting. Everybody can experiment and many
>>original features in Cocoon started as experiments. But experiments
>>start their life *besides* the mainstream code. That's how the
>>TreeProcessor, flowscript, CForms, and your EffectPipe started their
>>life. They were at first experiments, one-man shows, revolutions [2].
>>And they found their way into the community, became mainstream and even
>>replaced what was there before.
>>
>>The development branch is for evolutions, and revolutions that are
>>driven by the community at large, such as real blocks. Revolutions and
>>experiments led by individuals can happen, and there are some rules for
>>this [3]. You can do a revolution, and you are even encouraged to if you
>>really feel the itch to scratch. But this should not be imposed to
>>others by putting the revolution into the evolutionary code base.
>>
>>
>
>I agree, please see above. This issue may evaporate now that we understand each other.
>
>
>>>Sorry this email is so long and covers so many topics,
>>>but I wanted the community to know where I am trying
>>>to head, and to eliminate any confusion caused by me
>>>not explaining myself in a clear enough way. *Please*
>>>do not take this as directed at any individual.
>>>
>>>
>>I don't take it personally, but I know I'm for a good part responsible
>>for this and I feel sorry if I somehow hurted you.
>>
>>
>
>When the clouds clear, I forgive you if there is anything
>to do so about, but I think this is all a simple case of
>misunderstanding, not something that needs forgiven :)
>Probably on my part for not explaining well enough to be
>understood.
>
>
Well, you've got a point here: yes, you should probably explain more
what you want to do. The group's feedback will strengthen the ideas and
turn them into a collective creation rather than a one-man show.
>The thing that bumped my hat off was this comment:
> > - the new "choose/when" statement in EffectWidgetReplacingPipe: for
> > complex control structures, we have template languages like JTXG and
> > XSP. It doesn't seem good to me that every transformer reinvents it's
> > own control structure language.
>This change had been discussed and (I thought) agreed on quite
>a while ago and documented as planned in the WoodyScratchpad
>wiki page. It looked like my efforts and plans for cforms were
>being closed down by a little side comment.
>
Well, I only saw changes to the template transformer, and no
corresponding change in the form model, hence my impression you were
writing a new template language. I also do not consider the
WoodyScratchpad page a formal specification: we discussed for a while
there, wrote down some ideas, and let them apart for quite a long time
with still a lot of open questions and things to formalize.
>I see now that it was only part of a misunderstanding of those plans, and not a large problem emerging, so my hat is firmly planted on my head again :)
>
>
Great, I'm glad we solved some misunderstandings :-)
>Thanks again for your well-reasoned responses above, and please
>let me know if any concerns remain so we can resolve them :)
>
>
My main concern is that CForms should be about forms, and not about
general-purpose templating. That's why I consider that the CForms
template language much closely match the definition language, and not go
into features that are not form-related. As shown by the current
discussions about templates, there's obviously room for improvement for
Cocoon in this area, and your compiled template seems interesting. But
that should not happen within the XML namespace of the CForms template
language, or we will mix concerns and confuse users.
Sylvain
PS: I'll be out of office tomorrow (monday), giving a 1-day Cocoon
introduction to a lot of potential new users :-)
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: cforms plans, templating engines, etc.
Posted by Tim Larson <ti...@keow.org>.
On Fri, Nov 05, 2004 at 09:58:43PM +0100, Sylvain Wallez wrote:
> Tim Larson wrote:
>
> Sorry for this late answer, I was out of office today (woke up a 5am to
> go to the airport :-/ )
No problem, we all have different schedules to juggle.
Thank you very much for taking the time to consider and
answer my concerns. Comments inline.
> >and binding. Based on this, I believe choose/when should
> >be reinstated in at least the dev branch (svn trunk.)
>
> During the merge, I have not touched at it choose/when in trunk.
Ok, I must have misunderstood this:
> ft:choose: we've talked about it already, and I removed
> it until we know more about Tim's experiments.
to mean removed from both dev and stable when you only meant
that it was excluded from stable for now, like we decided.
(Sorry, I felt pressured by the impending release and am just
now starting to go through your actual commit.)
> >The development of all this does not break backwards
> >compatibility and has been discussed and (iiuc) agreed on,
> >so I see no reason to fork the development away from the
> >svn trunk, with the corresponding lack of feedback and
> >testing this would produce.
>
> Ok. Does this mean choose/when will replace union/case? Also, the wiki
> [1] shows several alternatives for choose/when, and unless I missed
> something we have not decided which approach to use.
Yes, choose/when is intended to replace union/case (following
with any deprecation pattern that is needed). There are two
alternatives, with the intention to have *both*, to service
different usecases.
> >Macros, widget types, and type libraries:
>
> Right. This is a necessary evolution.
Great!
> >Compiled templates:
>
> The problem is _where_ in the dev branch? What are the areas where this
> compiled template stuff is applicable? Is it limited to CForms?
Yes, at this stage this will only be useful to CForms.
> As I understand it, this is a rewrite of the FormsTransformer. This can
> happen in the CForms block, but _besides_ the current code. Just as your
> EffectPipe lived besides the original FormsTransformer before replacing
> it once we all considered it was better. What makes this subject
> controversial is that you seem to want to replace the EffectPipe right now.
Yes it is a rewrite of that code. And my plan from the start was
to implement it beside the existing code, just like you describe.
Sorry for any confusion on that.
> >Globally optimized template/transform pipelines:
> >This is an extension of the previous idea, "compiled
> >templates." Because it is of more general use than just
> >for cforms, it would probably have to migrate into its
> >own block at some point. However, since it would be based
> >on the cforms compiled template code and its initial
> >driving usecase would be supporting the cforms view layer,
> >imho it would not be too out of place to start the
> >development on it within the cforms block, so this could
> >be resolved when we get to the point of implementing it.
>
> Mmmh... I don't agree here. What you describe here is a general-purpose
> feature, which happens to be applicable to CForms, but to other areas as
> well. We can make a parallel here with XSP: there's a general-purpose
> core engine, and some blocks who provide their own logicsheet to extend
> XSP in particular areas.
The location of this code (forms block or its own block) is
not a big issue to me. At first it would only be useful to
cforms, but as it progresses it will become more general
purpose like you describe. And this code is still several
projects away timewise anyways...
> >Basically, please delay worrying about this sub-project at
> >least until the steps before it are finished :) Because
> >I would like to delay any worry about this until we reach
> >a point where this could be implemented, and thus would be
> >useful to discuss, I will not go into detail here about
> >this sub-project.
>
> What worries me is the fact that you want to explore new directions
> which, although they seem really interesting and worth exploring, will
> disturb the way to stability of the CForms block *if* they are
> developped within that block.
To summarize:
Choose/when, macros, widget types, and libraries are aimed
at backwards-compatible development in-place. Compiled
templates are aimed to be developed beside the current FTT,
but still in the same block and java package, just like how
the EffectPipe code got started. The optimized pipeline
code is still a ways off, but it would also be developed
beside existing code rather than in-place, and its location
is not an issue to me (its own block is fine if necessary.)
Any remaining issues with the above plan?
> >Widget States (tm):
> >Separate control of output, input, styling, and validation:
> >It has been discussed that there are times when we need
> >separate control of these aspects for individual widgets
> >and groups of widgets, but also that the common cases would
> >be handy to select via named states that set all these
> >aspects at the same time. Various proposals have been
> >discussed and now we have an implementation in the stable
> >branch that has not undergone any testing in the dev branch
> >to see if the design is a good match for our usecases, and
> >we are a just few days from releasing the stable branch and
> >having to either maintain this new interface or have the
> >pain of migrating users to a new interface if problems are
> >found.
>
> Hey, that's near to FUD: widget states have been discussed many times at
> length, and I implemented something we collectively agreed upon. They
> are in the stable branch because this is a feature that was identified
> as being needed to reach stable state on CForms.
Sorry for sounding like FUD, but I never bought into the
current design, just the goals, and I have expressed my
concerns before. I will try to take some time this weekend
to see how to resolve this. I really do not want to revert
the code if we can just improve it instead. I just feel
pressured by the short time before we plan to release.
> >This seems like a backwards way to develop, and I
> >admit to playing a part in landing in this situation, so
> >how should we procede? I don't know if I will have enough
> >time before the scheduled release to think through the
> >effects of the current interface and implementation, so I
> >am a bit concerned. I do know that it does not currently
> >support some of my usecases, but I have not had time to
> >investigate whether or not it could be extended to do so
> >in a backwards compatible way.
>
> If that is so much a concern for you, you can call for a majority vote
> so that we decide if it should be removed or commented out for 2.1.6.
I really do not want to do that, so I will dig in the code
more over the next few days. I much prefer consensus over
majority votes.
> >JXTemplates and forms transformer:
> >With all this discussion about template engines and
> >expression languages, what is the reasoning for starting
> >from the JXTemplateTransformer which people say is
> >composed of very tangled code (aside: I have not looked
> >at its code myself,) instead of on the fairly readable,
> >modular code of the FormsTemplateTransformer?
>
> Mmmh... we are talking about the JXT _generator_, and not the transformer.
>
> >Even if
> >we do follow the current JXTT rehabilitation plan, could
> >I not continue to improve the forms transformer?
>
> Honestly, I don't know if many people use JXTT (please speak up!). It
> seems to me that mostly JXTG is used, where compiled templates can be
> cached.
Thanks for clarifying for me.
> >The official Apache line is that we allow for competing
> >technology to coexist, as long as they all have potential
> >and actively being persued and used. Could I have a
> >chance to try to improve the forms transformer past the
> >abilities and usage patterns of the JXTT?This would
> >involve adding conditionals (choose/when,) macros,
> >imports, compilation, etc. I have been careful to not
> >make a habit of breaking backwards compatibility or the
> >build process for others, and I have been pursuing and
> >incorporating feedback from the community via the ml's,
> >irc, and wiki, and I have been supporting the components
> >that I have added. So could there please be room for
> >both approaches to have a chance to prove themselves?
>
> Tim, I understand your point. You feel frustrated because you don't feel
> to have a place for experimenting. Everybody can experiment and many
> original features in Cocoon started as experiments. But experiments
> start their life *besides* the mainstream code. That's how the
> TreeProcessor, flowscript, CForms, and your EffectPipe started their
> life. They were at first experiments, one-man shows, revolutions [2].
> And they found their way into the community, became mainstream and even
> replaced what was there before.
>
> The development branch is for evolutions, and revolutions that are
> driven by the community at large, such as real blocks. Revolutions and
> experiments led by individuals can happen, and there are some rules for
> this [3]. You can do a revolution, and you are even encouraged to if you
> really feel the itch to scratch. But this should not be imposed to
> others by putting the revolution into the evolutionary code base.
I agree, please see above. This issue may evaporate now that
we understand each other.
> >Sorry this email is so long and covers so many topics,
> >but I wanted the community to know where I am trying
> >to head, and to eliminate any confusion caused by me
> >not explaining myself in a clear enough way. *Please*
> >do not take this as directed at any individual.
>
> I don't take it personally, but I know I'm for a good part responsible
> for this and I feel sorry if I somehow hurted you.
When the clouds clear, I forgive you if there is anything
to do so about, but I think this is all a simple case of
misunderstanding, not something that needs forgiven :)
Probably on my part for not explaining well enough to be
understood.
The thing that bumped my hat off was this comment:
> - the new "choose/when" statement in EffectWidgetReplacingPipe: for
> complex control structures, we have template languages like JTXG and
> XSP. It doesn't seem good to me that every transformer reinvents it's
> own control structure language.
This change had been discussed and (I thought) agreed on quite
a while ago and documented as planned in the WoodyScratchpad
wiki page. It looked like my efforts and plans for cforms were
being closed down by a little side comment. I see now that it
was only part of a misunderstanding of those plans, and not a
large problem emerging, so my hat is firmly planted on my head
again :)
Thanks again for your well-reasoned responses above, and please
let me know if any concerns remain so we can resolve them :)
--Tim Larson
Re: cforms plans, templating engines, etc.
Posted by Sylvain Wallez <sy...@apache.org>.
Tim Larson wrote:
Sorry for this late answer, I was out of office today (woke up a 5am to
go to the airport :-/ )
>I have given further thought to some issues that were raised
>and this has changed my opinion on branching cforms into the
>whiteboard, and caused me to also want to clarify some other
>issues. I ask that you please read the *whole* email before
>starting to form responses :) Details below:
>
>Choose/when and widget renaming:
>I am planning several changes to cforms. These changes have
>been discussed on the dev mailing list and the #cocoon irc
>channel and summarized on the wiki. These changes include
>new parallel choose/when elements and semantics in the
>binding, model, and template layers, and renaming various
>widgets in parallel in all three layers. If I understood
>correctly, these changes had reached consensus and it was
>just a matter of having the time to implement. Folling the
>"do the least for the most benefit" rule, I started this
>work with choose/when in the template, soon to be followed
>by the parallel implementation of choose/when in the model
>and binding. Based on this, I believe choose/when should
>be reinstated in at least the dev branch (svn trunk.)
>
>
During the merge, I have not touched at it choose/when in trunk.
>The development of all this does not break backwards
>compatibility and has been discussed and (iiuc) agreed on,
>so I see no reason to fork the development away from the
>svn trunk, with the corresponding lack of feedback and
>testing this would produce.
>
>
Ok. Does this mean choose/when will replace union/case? Also, the wiki
[1] shows several alternatives for choose/when, and unless I missed
something we have not decided which approach to use.
>Macros, widget types, and type libraries:
>This has also been discussed in the standard places, with
>some recent discussion of macros (a renaming and extension
>of class/new) getting more recent work on irc and the wiki.
>Type libraries are collections of parameterized, reusable
>form fragments, and macros and widget types are a essential
>part of the implementation. These changes do not break
>backwards compatibility either, and type libraries are a
>recurring request, so I think this development effort
>should also occur in the main development branch.
>
>
Right. This is a necessary evolution.
>Compiled templates:
>This is apparently a more controversial proposal, so I am
>discussing it in this separate section. The goal is to
>progress from speeding up the FormsTemplateTransformer
>transformation process by eliminating the repetative
>parsing and interpreting of the form templates by changing
>to a compiled model, similar to the form model's design
>of builder, definition, and widget classes. This may end
>up with either two or three layers, depending on what I
>encounter during the implementation. Because this is such
>a big change, it would have to happen in parallel with
>the existing forms transformer to prevent disturbing
>current users. Given this provision, it seems this should
>also be developed in the main dev branch for the sake of
>feedback and testing.
>
>
The problem is _where_ in the dev branch? What are the areas where this
compiled template stuff is applicable? Is it limited to CForms?
As I understand it, this is a rewrite of the FormsTransformer. This can
happen in the CForms block, but _besides_ the current code. Just as your
EffectPipe lived besides the original FormsTransformer before replacing
it once we all considered it was better. What makes this subject
controversial is that you seem to want to replace the EffectPipe right now.
>Globally optimized template/transform pipelines:
>This is an extension of the previous idea, "compiled
>templates." Because it is of more general use than just
>for cforms, it would probably have to migrate into its
>own block at some point. However, since it would be based
>on the cforms compiled template code and its initial
>driving usecase would be supporting the cforms view layer,
>imho it would not be too out of place to start the
>development on it within the cforms block, so this could
>be resolved when we get to the point of implementing it.
>
>
Mmmh... I don't agree here. What you describe here is a general-purpose
feature, which happens to be applicable to CForms, but to other areas as
well. We can make a parallel here with XSP: there's a general-purpose
core engine, and some blocks who provide their own logicsheet to extend
XSP in particular areas.
>Basically, please delay worrying about this sub-project at
>least until the steps before it are finished :) Because
>I would like to delay any worry about this until we reach
>a point where this could be implemented, and thus would be
>useful to discuss, I will not go into detail here about
>this sub-project.
>
>
What worries me is the fact that you want to explore new directions
which, although they seem really interesting and worth exploring, will
disturb the way to stability of the CForms block *if* they are
developped within that block.
>Widget States (tm):
>Separate control of output, input, styling, and validation:
>It has been discussed that there are times when we need
>separate control of these aspects for individual widgets
>and groups of widgets, but also that the common cases would
>be handy to select via named states that set all these
>aspects at the same time. Various proposals have been
>discussed and now we have an implementation in the stable
>branch that has not undergone any testing in the dev branch
>to see if the design is a good match for our usecases, and
>we are a just few days from releasing the stable branch and
>having to either maintain this new interface or have the
>pain of migrating users to a new interface if problems are
>found.
>
Hey, that's near to FUD: widget states have been discussed many times at
length, and I implemented something we collectively agreed upon. They
are in the stable branch because this is a feature that was identified
as being needed to reach stable state on CForms.
>This seems like a backwards way to develop, and I
>admit to playing a part in landing in this situation, so
>how should we procede? I don't know if I will have enough
>time before the scheduled release to think through the
>effects of the current interface and implementation, so I
>am a bit concerned. I do know that it does not currently
>support some of my usecases, but I have not had time to
>investigate whether or not it could be extended to do so
>in a backwards compatible way.
>
>
If that is so much a concern for you, you can call for a majority vote
so that we decide if it should be removed or commented out for 2.1.6.
>JXTemplates and forms transformer:
>With all this discussion about template engines and
>expression languages, what is the reasoning for starting
>from the JXTemplateTransformer which people say is
>composed of very tangled code (aside: I have not looked
>at its code myself,) instead of on the fairly readable,
>modular code of the FormsTemplateTransformer?
>
Mmmh... we are talking about the JXT _generator_, and not the transformer.
>Even if
>we do follow the current JXTT rehabilitation plan, could
>I not continue to improve the forms transformer?
>
>
Honestly, I don't know if many people use JXTT (please speak up!). It
seems to me that mostly JXTG is used, where compiled templates can be
cached.
>The official Apache line is that we allow for competing
>technology to coexist, as long as they all have potential
>and actively being persued and used. Could I have a
>chance to try to improve the forms transformer past the
>abilities and usage patterns of the JXTT?This would
>involve adding conditionals (choose/when,) macros,
>imports, compilation, etc. I have been careful to not
>make a habit of breaking backwards compatibility or the
>build process for others, and I have been pursuing and
>incorporating feedback from the community via the ml's,
>irc, and wiki, and I have been supporting the components
>that I have added. So could there please be room for
>both approaches to have a chance to prove themselves?
>
>
Tim, I understand your point. You feel frustrated because you don't feel
to have a place for experimenting. Everybody can experiment and many
original features in Cocoon started as experiments. But experiments
start their life *besides* the mainstream code. That's how the
TreeProcessor, flowscript, CForms, and your EffectPipe started their
life. They were at first experiments, one-man shows, revolutions [2].
And they found their way into the community, became mainstream and even
replaced what was there before.
The development branch is for evolutions, and revolutions that are
driven by the community at large, such as real blocks. Revolutions and
experiments led by individuals can happen, and there are some rules for
this [3]. You can do a revolution, and you are even encouraged to if you
really feel the itch to scratch. But this should not be imposed to
others by putting the revolution into the evolutionary code base.
>Sorry this email is so long and covers so many topics,
>but I wanted the community to know where I am trying
>to head, and to eliminate any confusion caused by me
>not explaining myself in a clear enough way. *Please*
>do not take this as directed at any individual.
>
>
I don't take it personally, but I know I'm for a good part responsible
for this and I feel sorry if I somehow hurted you.
Once again, let me state it: there is room for experiments. Either by
developping them collectively in the main dev line, or individually
besides it. By collectively, I mean changes driven by discussions and
consensus among the developpers. But as not everybody likes to explain
before doing, there is also room for people to do their stuff in a more
individual way and have it adopted by the group afterwards.
I hope this explanation will help your frustration to go away and will
even make you feel more free to experiment because you are welcome to do
it, but in a way that doesn't hurt the necessary quest for stability of
the development line.
Sylvain
[1] http://wiki.apache.org/cocoon/WoodyScratchpad
[2] http://incubator.apache.org/learn/glossary.html#Revolution
[3] http://incubator.apache.org/learn/rules-for-revolutionaries.html
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }