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