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: sitemap, jx and flow design (was: servicemanager and jxtg)
Date Tue, 25 Jan 2005 21:36:21 GMT
Stefano Mazzocchi wrote:
> Daniel Fagerstrom wrote:
>> Stefano Mazzocchi wrote:
<snip/>
>> Stefano,
>>
>> The last two paragraphs are a little bit vague to me. I need your and 
>> others opinions about how we should handle this in the refactored 
>> JXTG. We are in the progress of factoring out the, (hopefully 
>> neutrally enough named), instructions from the template execution 
>> engine and compiler. This is for increasing maintainability, SOC and 
>> give the possiblity to implement an attribute template language that 
>> reuse some of the parts. We are also factoring out: expression 
>> language, parsing of strings with embeded expressions and the object 
>> model.
> 
> 
> Daniel, thanks for the summary. Read my comments below.
> 
>> Instruction Inclusion
>> =====================
>>
>> Now for the instructions (jx:forEach etc) we have the question if they 
>> should be choosed:
>>
>> 1. Programatically: There is an abstract base class with common 
>> template generator functionality. To implement e.g. JXTG this base 
>> class is extended. And the extended class enumerates the instructions 
>> that should be used and also choose parsing strategy etc.
>>
>> 2. Configuration: Instructions or set of instructions are made 
>> components and connected to the template generator in the configuration.
>>
>> 3. Within the template language: There are special instructions in 
>> some common base template language that allow the user to include sets 
>> of (Java written) instructions.
>>
>> I would prefer the configuration way find the programatic way ok and 
>> be against the within the template language way.
>> WDYT?
> 
> 
> This really looks like just an implementation detail... I would think 
> that the configuration way makes it easier (psycologically) for people 
> to add their own instructions than the other two. #1 is cleaner than #3 
> and less avalonish than #2.
> 
> I'm not thrilled with the idea of people adding their own keywords to 
> the template language... just like the sitemap, it should be possible 
> but not easy, so that people would feel discouradged to do it. So 
> probably #1 would be my choice.

Ok, if no one protests I think we go for #1. It give us more flexiblity 
in refining the instruction interface than if we publish it as an 
"external" interface. We can always do it configurable later if the need 
is feeled.

> 
>> Instruction Access
>> ==================
>>
>> What objects should instructions and macros be able to access? 
>> Curently for the needs of the JXTG instructions, the instructions has 
>> access to a ExpressionContext that contains the FOM "view" that is 
>> available in expressions in JXTG. They also have access to an 
>> ExecutionContext that currently contains a script manager and a map 
>> with macros, we might need a SourceResolver also. There are also some 
>> other stuff that not are relevant for the current discussion.
>>
>> The questions are:
>>
>> * Should the ExecutionContext also contain a ServiceManager?
>>
>> * Should the ExpressionContext also contain a ServiceManager? (makes 
>> the ServiceManager available in expressions)
>>
>> IMO the ExecutionContext should have access to the ServiceManager and 
>> the ExpressionContext shouldn't.
>> WDYT?
> 
> Agreed. Seems reasonable.

Ok, good.

/Daniel


Mime
View raw message