cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: [Design] JXTG 2.0 (Just my opinion)
Date Sun, 05 Dec 2004 07:14:06 GMT
Roy G. Biv wrote:

> However useless the action may be, calling sendPage* on a pipeline 
> without JXTG still produces (generates) output doesn't it?  I'm not 
> trying to be difficult, even though it may seem so.

To be honest, I wouldn't know. I haven't coded flowscript, and my 
coworkers who have use Velocity, not JXTG. They find it difficult to 
generate XML since the template has to be well formed XML.  We do use 
JXTG in other circumstances, but not with flow.

> If you can have a pipeline that ignores the object model passed from 
> Flow, how can that object model be automatically considered an 
> intrinsic part of generation?

Because once you invoked sendPage you switched from accessing the model 
to generating the view.

> The Flow object model is available to components further down the 
> pipeline too isn't it?

So what? I don't mean to be argumentative, but I think you are looking 
at this way to granularly.  We have some complicated pipelines, but when 
you look at them the MVC pattern is still there, both in the overall 
structure and in individual pipelines. 

>>> With XSLT/STX, the stylesheet is the manipulative/transformative 
>>> vector.  With a flow template transformer, it's the flow object 
>>> model.  With the i18n transformer, it's the l10n catalog(s).
>> I don't understand this. With these examples the 
>> "manipulative/ransformative vector" is the template, not the object 
>> model. That is what is being operated upon. All of the above are 
>> transformers and the all operate the same way; they are fed SAX 
>> events and output SAX events based upon the XSLT Stylesheet, the 
>> template, or the I18n elements.
> Okay, aside from my obfuscated terminology, how is that true of the 
> I18Transformer?  It takes SAX events (just like a template transformer 
> would if the template file were read in from the FileGenerator), but 
> it's catalog data, while stored on the filesystem in XML files, is not 
> read in as a SAX stream; it's an injected data model.  The fact that 
> the catalog files are stored as XML is an implentation detail, not 
> part of the SAX processing pipeline.

I would argue that in transformers the model is always the incoming SAX 
events. The fact that catalog data is accessed by the I18nTransformer 
doesn't make it part of the model any more than saying the html embedded 
in an XSLT stylesheet is part of the model.  

> If you were to load a .jx template in the FileGenerator, it's still 
> data.  It's still a starting point whether or not there's a Flow bean 
> awaiting iteration.  Does JXTG start processing by handling the Flow 
> objects or by reading and parsing the template file.

All generators generate SAX events from a model. They have to do that 
based upon instructions. I use Betwixt to convert beans into XML. That 
doesn't make Betwixt's processing rules part of the model.  The JX 
template is nothing more than the rules the generator is to use to 
generate SAX events from the model.  The starting point is the model, 
not the template.  Also, when loading the template in a generator it is 
the model at that point. However, it could then be passed through 
transforms and must be serialized before being used by JXTG. In other 
words, the template is the model in the pipeline where it is passed to 
JXTG, but it has been fully rendered (usually identically) when it is 
used by JXTG.

While this discussion is important in the overall scheme of things, I 
don't think it helps at all with determing what the syntax for the 
template processor should look like or how it should operate. Except, I 
guess, in pointing out that the major flaw in XSP (and JSP) is that they 
are simply too powerful in that they encourage too much mixing of 
concerns.  Frankly, I have worries about Flow for the same reason.


View raw message