Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Date: Thu, 4 Nov 2004 18:47:09 +0000
From: Tim Larson <tim@keow.org>
To: dev@cocoon.apache.org
Subject: cforms plans, templating engines, etc.
Message-ID: <20041104184709.GT26283@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.6i

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

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. 

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.

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

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

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?  Even if
we do follow the current JXTT rehabilitation plan, could
I not continue to improve the forms transformer?
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?

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.

--Tim Larson