cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralph Goers" <Ralph.Go...@dslextreme.com>
Subject Re: [RFC] "Cocoon Templates": Name and Tag Interface
Date Mon, 29 Nov 2004 16:33:14 GMT
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



Mime
View raw message