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 Fri, 05 Nov 2004 20:58:43 GMT
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

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 

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

View raw message