Daniel Fagerstrom said:
> Naming
> ======
>
> The goal is that the new template framework should replace JXTG and XSP
> as the "recomended" template system for Cocoon users. It is a community
> effort rather than a one man show. It is based on our previous experince
> of templating solutions.
>
> This should IMO be reflected in the naming. The name should reflect the
> intended purpose rather than being a "brand" name. "JX" in
> JXTemplateGenerator comes from JXPath and as we are going to provide
> support for other expression languages as well, JXTG 2.0 would not be a
> logical name for the framework IMHO.
> I would propose that we (analogous with CForms) refer to it as
> "template" in block name, package name, name spaces and so on. When it
> actually delivers what is promised, we can refer to it as Cocoon
> Template or CTemplate.
I like template. It is simple and to the point.
>
> To show that we care about our users previous investments in Cocoon
> technology, we can say that JXTG has been re-implemented as a Cocoon
> Template tag lib.
>
> Of course other and better naming sugestions are most welcome.
>
>
> Tag "Interface"
> ===============
>
> What data should be available for the taglib writer and how should it be
> made accessible? What about thread safety?
Why wouldn't it be thread safe? I would think this would need to be a
requirement.
>
> Expressions
> -----------
>
> This is somewhat OT in the current context but IMO expressions, (the
> stuff inside ${}), should only have access to FOM and preferably just
> read access. IMHO expressions should not have side effects.
There should be a way to register objects for use by the template so that
flow is not a requirement. Of course, the template should also be able to
access the request and response.
>
> What Data in Tags?
> ------------------
>
> A tag need access to:
>
> * FOM
> * The current XMLConsumer for output
> * The content of its attributes
> * The content of its body (the possibility of executing the body and
> geting the result)
>
> The following data is also useful for some tag libs:
>
> * A variable stack for handling local variables in tags or macros
> * The tag repository
> * The source resolver
> * The component manager (e.g. for geting a DB connection)
> * Its parent tag
> * The content of its body (the possiblity to get the body unevaluated)
>
> IMHO tags should behave as if they are side effect free. Side efects
> should be performed in flowscripts. From this we can infer that we only
> should have read access to the above data. But in practice it might be
> hard to enforce and furthermore even if the tag behave as it is side
> effect free, it might be better (or the only possiblity) to implement it
> in terms of side effects.
>
> Implementation details are discussed in the section "Adding Executable
> Tags" in
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110132582421156&w=2.
>
> Have I forgotten something or should we remove something?
>
> How to Make Data Accessible in Tags
> -----------------------------------
>
> There are two main type of events in the life cycle of a tag: setup and
> execution. For a thread safe tag, the setup phase can be divided in:
> script compile time setup and execution time setup.
>
> The relation between the tag and the framework has many parallels with
> the relation between a component and a component manager, so similar
> solutions are possible.
>
> We can have reflection based solution with setter injection of
> attributes and possibly the rest of data also. We can have interface
> driven injection, (Avalon framework style), where the tag implements
> various interfaces for geting the various input data types.
>
> We can also have more "static" solutions where the tag has to implement
> a certain interface and get all the data with methods in the interface
> or in one large context object.
>
> Reflection based methods are more flexible, but should probably only be
> performed during script compile time setup, due to keep good performance.
>
> See the above reference for examples and more details.
>
> Thread Safe or Not?
> -------------------
>
> Thread safe tags can have better performance as more work can be done
> during script compile time, but they might be harder to write. What
> should we chose or should we support both types?
Thread-safe. If need be, the there can be a setup method that returns an
object that is passed back to all other methods. Since the framework
"owns" the returned object it can decide when to drop the reference.
Ralph
