Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <41AF3742.9020209@apache.org>
Date: Thu, 02 Dec 2004 16:39:46 +0100
From: Sylvain Wallez <sylvain@apache.org>
Organization: Anyware Technologies
User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RFC] "Cocoon Templates": Name and Tag Interface
References: <41AB2078.3010101@nada.kth.se> <41AEF8E3.80301@apache.org>
 <41AF14AB.9@nada.kth.se>
In-Reply-To: <41AF14AB.9@nada.kth.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Daniel Fagerstrom wrote:

> Sylvain Wallez wrote:
>
>> Daniel Fagerstrom wrote:
>
>
> <snip/>
>
>>> 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?


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.

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.

>>> 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.


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. 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.

<snip/>

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }