cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Larson <...@keow.org>
Subject Re: cforms plans, templating engines, etc.
Date Fri, 05 Nov 2004 21:50:46 GMT
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

Mime
View raw message