cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RFC] "Cocoon Templates": Name and Tag Interface
Date Thu, 02 Dec 2004 13:12:11 GMT
Sylvain Wallez wrote:

> Daniel Fagerstrom wrote:


>> 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)
> +1 The two last items are especially important to implement the CForms 
> template language (see jx-macros.xml).
>> 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
> That's not needed, as it can be looked up in the ServiceManager.

You are refering to the source resolver i guess? Maybe the tag 
repository should be controlled by ServiceManager as well so that 
included and compiled taglibs are inherited to subsitemaps?

>> 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?
> I don't see how we can possibly cache precompiled templates if some 
> tag instances are not threadsafe. So IMO *all* tags should be threadsafe.

You can put a threadsafe tag factory together with the class name of the 
thread unsafe tag and possibly other compile time datainto the script. 
Then the thread unsafe tag is created and instantiated at runtime. Jelly 
work like that, its certainly has some runtime costs, but it is easier 
to write the tags.

Anyway, I agree with you. We start by requireing the tags to be thread 
safe and implement the core tag libraries that way. Then we can 
implement "tag adapters" for other tag life styles later if we feel that 
it is needed.

> If we make the parallel with the TreeProcessor, tags should receive 
> something similar to InvokeContext. This is an object that holds all 
> execution-time data such as the generator's <map:parameter>, the 
> object model (or maybe not as it's available through the Context) and 
> the variable stack.

Sounds good, we have one "CompileContext" and one InvokeContext.

> For some tags to be able to store execution-time data, the invocation 
> object should also be able to hold some arbitrary attributes, possibly 
> associated to the tag instance itself. That provides support for both 
> tag-related data (e.g. some data created on start that is needed on 
> end such as SQL connections) or inter-tag communication such as 
> <ft:class> definitions later used by <ft:new> tags.
> Something like:
>    void setAttribute(String name, Object value);
>    Object getAttribute(String name);
>    void setTagAtttribute(Tag tag, String name, Object value);
>    Object getTagAttribute(Tag tag, String name);

I had some vauge idea about putting such info in the variable stack. But 
it might be better to sstore such info so that it is invisible for the EL.

Thanks for your comments!


View raw message