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 }
