cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: [RFC] "Cocoon Templates": Name and Tag Interface
Date Thu, 02 Dec 2004 16:51:11 GMT
Sylvain Wallez wrote:

> Daniel Fagerstrom wrote:
>
>> Sylvain Wallez wrote:
>>
>>> Daniel Fagerstrom wrote:
>>
<snip/>

>> 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?
>
> Yes, taglibs should be standard components declared in the service 
> manager. That way, they are automatically inherited in subsitemaps. 
> What we need also is a "standard" set of taglibs that are declared in 
> the top-level service manager, i.e. cocoon.xconf.

Sounds good.

> Now about the SourceResolver, it's available in the ServiceManager 
> using lookup(SourceResolver.ROLE). So it doesn't need to be passed 
> explicitely as part of the runtime setup.
>
> The fact that generator.setup() has a SourceResolver parameter is 
> historical, at a time where it wasn't available through the service 
> manager.

Didn't know that.
<snip/>

>> 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.
>
> Mmmh...
>
> You then achieve something similar to the CForms architecture where a 
> form definition is translated into a cached, immutable and threadsafe 
> FormDefinition object, which acts as a factory for actual Widgets.
>
> This behaviour is needed for CForms as every widget intrinsically have 
> to hold some state information and therefore are specific to a 
> particular usage of the form, and that state must persist across 
> request/response cycles.
>
> Do we need the same for tags? I'm not sure.

Don't think we need it either. I'll try to implement a number of  tags 
and see what I think.

> Thinking further, we don't even need the per-tag attributes I 
> mentioned below, as a tag implementation will drive the execution of 
> its children.
>
> Practically, this means that a Tag should have a single "execute" 
> method invoked at generation-time, that will do its job and invoke its 
> children as part of this job. Any tag-related state can then be 
> represented as local variables.

Sounds good.

/Daniel


Mime
View raw message