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
