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 shouldDuring the merge, I have not touched at it choose/when in trunk.
be reinstated in at least the dev branch (svn 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 backwardsOk. 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.
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.
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):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.
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.
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 competingTim, 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.
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?
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,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.
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.
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 }
