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
