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
|