----- Original Message -----
Sent: Thursday, October 10, 2002 3:13
AM
Subject: [Tapestry-developer] Component
definitions in the template
Let's have a quick look at what happens when we add the ability to
define components in the template. I will try to expand a little on Howard's
suggestion so that we can have a better look at what the costs of that
approach are.
First of all, I assume that the format will be something like this:
<tag jwcid="[ComponentID]:ComponentType" parameter1="ognlExpression"
parameter2="ognlExpression" ...>
Here ComponentID could be missing, in which case we get an anonymous
component. The parameters could be either formal or informal. As Howard
pointed out in an earlier email, the new OGNL expressions allow you to do the
equivalents of static-binding and field-binding, so the above format pretty
much covers all bases.
What are the implications?
- First of all this definitely does not do away with the JWC file
(which is what Marc seemed to want as well), since one still has to
be able to define parameters, assets, etc. It only moves some component
definitions into the template.
- Second, in Tapestry the inner components must be created and initialized
(bindings, etc) at page/component creation during the loading phase. This
means that during that time the template must be read and the components
in there must be loaded and initialized. (reasons for this: combined with
pooling, it allows initializations to be done only a few times in the whole
system, rather than every time)
- A consequence of the above is that it will be hard (or impractical) to
have more than one template per page/component. Since the layout of the
components may change with each template (e.g. Chinese pages could look very
differently), using Component IDs would become not optional,
but obligatory, so that the framework knows which component is which. In
addition, it would make sense to define the parameter values in only a single
component, otherwise the maintenance costs would be tremendous.
Are multple templates per page/component feasable in this case then? Using
anonymous components essentially means a single template
only, fullstop. If named components are created within a template, it
makes sense to have a single "special" template that holds the parameter
values to avoid nightmarish scenarios, but it seems to me that if the goal is
to make things "simpler", having a single template here would be a good idea
as well.
In short, the current BaseComponent approach would be practically
incompatible with such a feature. Adding this seems to make sense only as a
new implementation of AbstractComponent, parallel to BaseComponent.
So, can it be done? Certainly.
Would it make things easier? It would probably be a blessing for people
used to JSP or other scripting languages (as Marc seems to be), and it would
probably make things easier for new users of Tapestry who cannot use Spindle
for one reason or another (btw, perhaps Spindle must be printed with large
letters in the docs -- people must know about it. the difference in download
counts seems to indicate that a lot of people do not) As Richard pointed out
just now, however, the long term costs in development are higher when using
this approach (without counting the limitations).
What we are essentially witnessing here is the creation of Tapestry Model 1
and Tapestry Model 2. (in analogy to JSP)
Model 1 is easy for newbies and is okay for slapping together a page
quickly (which is what Marc seems to want to do -- the PHP approach). If
you use anything but Model 2 in professional development, however, you'll have
your hands broken very quickly. (and I am referring to JSP here, not
Tapestry)
So what is my personal opinion? I think that the sole advantage of making
things easier for newbies and hence bringing in more people by smoothing the
learning curve may be worth it, even accounting for the costs. On the other
hand the clear implementation incompatibility between the two appoaches
implies that this new AbstractComponent implementation will have to be
targeted towards low-end users only and that is not simply a result of
my "exclusive either-or mentality".
There is certainly a middle road that I mentioned in my previous email, but
it may not go far enough to satisfy either group -- hard coding a selection of
common components, such as Insert, in the same way <span key=""> was
implemented. This is both limited and a hack, but it will be compatible with
the current approach.
Best regards,
-mb
Do you Yahoo!?
Faith Hill - Exclusive
Performances, Videos, & more
faith.yahoo.com
