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] JXTG Refactoring
Date Mon, 20 Dec 2004 15:17:14 GMT
Vadim Gritsenko wrote:

> Daniel Fagerstrom wrote:
>
>> Christopher Oliver wrote:
>>
>>> If you ask me, this is mainly a semantic problem, not a technical one.
>>>
>>> If a template is not called from a (Javascript) flowscript, there is 
>>> no FOM, and therefore no FOM variables are available in JXTG. For 
>>> the case where it _is_ called from a flowscript, then the FOM is and 
>>> IMO should be accessible.
>>>
>>> The request, session, etc, variables that are described as 
>>> deprecated are unnecessary and inappropriate when the template is 
>>> called from the flowscript (since they provide no additional 
>>> information beyond the FOM, but yet have an "impedance mismatch" 
>>> with the flowscript model). They are simply carried over from the 
>>> original (pre-FOM) implementation for backward compatibility.
>>
>>
>>
>> Thanks for clarifying. IMO we should just remove the pre-FOM stuff 
>> from the refactored JXTG, we cannot support deprecated things for ever.
>
>
> I'm -1 on this as long as there is no "FOM" in JXTG outside of flow 
> environment. After "FOM" is present in the JXTG, "non-FOM" 
> request/response/etc variables should go through regular deprecation 
> cycle (i.e., 1/2 year or so) according to Cocoon's versioning guide.
>
> Vadim

Ok, this depends on what we want to do about that we both have a JXTG in 
core and one partly refactored in the template block. IMO we have to 
main alternativs, (in both alternatives the new JXTG is supposed to be 
back compatible at all times):

1. We continue to have two versions o.a.c.generation.JXTemplateGenerator 
and o.a.c.template.jxtg.JXTemplateGenerator, at some time we deprecate 
the original and ask people to move to the new one.

2. We rename the refactored JXTG to 
o.a.c.generation.JXTemplateGenerator, rather soon and remove the 
original one (in trunk).

In alt. 1. deprecation of  "non-FOM" request/response/etc variables in 
the refactored JXTG is not that important as they are available in the 
original. In alt. 2. we should do as you say.

Thinking of it, I would prefer alt. 2. as it will increase testing and 
community involvement, and decrease the risk that we diverge from the 
original JXTG whithout recognizing it.

WDYT?

/Daniel


Mime
View raw message