cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: cforms plans, templating engines, etc.
Date Sun, 07 Nov 2004 20:29:40 GMT
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.
>>>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.


>>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
>>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)?


>>>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

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.


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 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message