Re: [Design] JXTG 2.0 (Just my opinion)
Stefano Mazzocchi wrote:
Bertrand Delacretaz wrote:
Le 4 déc. 04, à 21:03, Glen Ezkovich a écrit :
On Dec 4, 2004, at 3:37 AM, Bertrand Delacretaz wrote:
...Currently we have JXTG for the first step, and mostly XSLT for
the second. Having something that could cover both steps and be
usable by either programmers working on the first step or designers
working on the second would be a Really Good Thing.
I'm not really sure what you mean by having something that could
cover both steps. JXTG covers both steps in the sense that many
people are using it to inject their data into their html. Now, to
have a template transformer, that is something with which I would
really like to play. I'm not very found of XSL. A simpler
alternative could be a Really, Really Good Thing.
That's what I mean - having a transformer that can use the same
template syntax as used in the generator, so that the template
language can be used for both the generation and transformation steps.
My FS detector is out of scale!!
Ring, ring, ring :-)
This is *exactly* what the XSLT WG did and failed miserably. XSLT can
be used for both generation and tranformation. But it looks right for
one (besides the stupid XML-ish syntax) and totally ackward for the
other. XQuery is the same thing, only reversed: it can be used as a
template language, and as a transformation language. If feels better
for the first one (only ackward because, as usual, the XSLT WG starts
with one name and ends up defining something else) and totally wrong
for the second.
Look at my eyes and repeat with me: I DO NOT WANT TO REPEAT THE
MISTAKES THAT THE XSTL WG DOES OVER AND OVER YEAR AFTER YEAR.
Generation and transformation are two different things, done often by
different people and for different goals and with different constaints.
Having one language for both will do only harm, because it will make
it harder for people to decide when to use generation and when to use
transformation.
Although I agree that using XSLT as a generator feels awkward, the
context of Cocoon is different. XSLT as a transfomer uses an input
document, and XSLT as a generator has no input which makes it look
strange (although it can load data with the infamous document() function).
Now what is the input document equivalent in Cocoon? It depends:
- it can be the view data passed to cocoon.sendPage()
- it can also be the output of the generator.
So in the first case, the template is a generator, and in the second
case, the template is a transformer. And in all cases, the template
actually does *transform* a set of data.
So having a template language used either as a generator or a
transformer doesn't seem so awkward to me, as contrarily to W3C specs,
it is always a transformation of some data given by some previous layer
in the processing chain (either the controller or the generator).
Note however that JXTemplateTransformer seems really weird to me as its
input data *is* the template.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [Design] JXTG 2.0 (Just my opinion)
Le 5 déc. 04, à 06:14, Stefano Mazzocchi a écrit : Bertrand Delacretaz wrote: Le 4 déc. 04, à 21:03, Glen Ezkovich a écrit : On Dec 4, 2004, at 3:37 AM, Bertrand Delacretaz wrote: ...Currently we have JXTG for the first step, and mostly XSLT for the second. Having something that could cover both steps and be usable by either programmers working on the first step or designers working on the second would be a Really Good Thing. I'm not really sure what you mean by having something that could cover both steps. JXTG covers both steps in the sense that many people are using it to inject their data into their html. Now, to have a template transformer, that is something with which I would really like to play. I'm not very found of XSL. A simpler alternative could be a Really, Really Good Thing. That's what I mean - having a transformer that can use the same template syntax as used in the generator, so that the template language can be used for both the generation and transformation steps. My FS detector is out of scale!! This is *exactly* what the XSLT WG did and failed miserably. XSLT can be used for both generation and tranformation. But it looks right for one (besides the stupid XML-ish syntax) and totally ackward for the other. XQuery is the same thing, only reversed: it can be used as a template language, and as a transformation language. If feels better for the first one (only ackward because, as usual, the XSLT WG starts with one name and ends up defining something else) and totally wrong for the second. Look at my eyes and repeat with me: I DO NOT WANT TO REPEAT THE MISTAKES THAT THE XSTL WG DOES OVER AND OVER YEAR AFTER YEAR. Generation and transformation are two different things, done often by different people and for different goals and with different constaints. Having one language for both will do only harm, because it will make it harder for people to decide when to use generation and when to use transformation. -- Stefano. -- Bertrand Delacretaz independent consultant, Lausanne, Switzerland http://www.codeconsult.ch smime.p7s Description: S/MIME cryptographic signature
Re: [Design] JXTG 2.0 (Just my opinion)
(please ignore my previous message, hit send too soon ;-) Le 6 déc. 04, à 07:27, Bertrand Delacretaz a écrit : ... smime.p7s Description: S/MIME cryptographic signature
Re: [Design] JXTG 2.0 (Just my opinion)
Le 3 déc. 04, à 21:40, Glen Ezkovich a écrit : ...I'm not sure I agree that templates as being part of the view. I look at them more as providing XML structure to the data We need both actually - if you work with the two-step view pattern (which is very natural with Cocoon), you need a first set of templates to generate XML out of your data, and a second set to transform the XML into the final presentation format. Currently we have JXTG for the first step, and mostly XSLT for the second. Having something that could cover both steps and be usable by either programmers working on the first step or designers working on the second would be a Really Good Thing. -Bertrand [1] http://www.martinfowler.com/eaaCatalog/twoStepView.html smime.p7s Description: S/MIME cryptographic signature
The danger of overseparating concerns (was Re: [Design] JXTG 2.0 (Just my opinion))
Bertrand Delacretaz wrote:
Le 3 déc. 04, à 21:40, Glen Ezkovich a écrit :
...I'm not sure I agree that templates as being part of the view. I
look at them more as providing XML structure to the data
We need both actually - if you work with the two-step view pattern
(which is very natural with Cocoon), you need a first set of templates
to generate XML out of your data, and a second set to transform the
XML into the final presentation format.
Currently we have JXTG for the first step, and mostly XSLT for the
second. Having something that could cover both steps and be usable by
either programmers working on the first step or designers working on
the second would be a Really Good Thing.
-Bertrand
[1] http://www.martinfowler.com/eaaCatalog/twoStepView.html
The two-step-view pattern is good when it doesn't degenerate into
three-step-view pattern, in which case it becomes highly
counter-productive. Let me tell you a story from my own experience in my
company when writing web applications (with lot of forms - publishing is
a different use case).
We (Anyware) have used a similar approach to TAL years ago, starting
with Cocoon1 (yes, _years_ ago!). The XSP was doing/calling the
controller (remember, we could redirect in XSP at that time) and
producing an XML representation of the data. Next was a XSL
transformation producing the HTML. That XSL was the result of the
compilation of a DW-compatible HTML page with either some additional
tags or some attributes like in TAL. We had a DW plugin to edit the
additional tags (see [1] for some rough explanation of it).
We had a good separation of concerns, DW-friendlyness. That seemed good
as long as our applications weren't complex. It has to be noted though
that the produced XSL was a simplfied stylesheet [2], i.e. with no
pattern-driven rules.
But there was a problem: each XSL, even if generated from annotated
HTML, contained a lot of graphic stuff, and the graphical layout of the
application was duplicated in all these HTML pages. Adding some data to
a page required some web designer skills to edit the HTML template, and
modifying the overall look of the application required to modify each
and every page. Painful.
Enter Cocoon 2.0, with its sitemaps and actions. We refactored our
framework so that the controller was an action, and the XSP was
therefore only producing data. Now our two-step view had degenerated
into a three-step view, as the controller was preparing some data
(objects) for the view, and the first step of the view was merly just
converting that data to XML. Adding some data to a page required to
modify 3 files: the action, the XSP and the XSL that formats the XML
data. Painful again.
With Cocoon 2.1 came flowscript and CForms, and we started using a
totally different scheme that I find highly productive. At the beginning
of a project, a prototype GUI is built to ensure that all requirements
have been taken into account and that we agree on the overall usability
(this happened previously also). Then, the work can happen in parallel:
- a web designer builds a set of static pages containing all graphical
structures that are needed for the application,
- the application developpers write the logic and page templates (JXTG)
containing only _structural_ HTML or other page description language.
The web designer's work is then XSL-ified to a full-blown
template-driven stylesheet, reacting either to elements (e.g.
fieldset) or class attributes, and is no more a simplified stylesheet
like we had in our previous approach. The XSL is now really for styling
and not for templating. Furthemore, we only have one XSL for all forms
(or one per screen type) instead of one per form (even if generated).
This approach is very productive as the webdesigner and application
writers work in parallel, and there is abolutely no overlap between
their respective work. Furthermore, the web design work is highly
reduced. Of course, this is related to our organisation where template
writers have more a developer background.
The conclusion of this is that we must be careful of not overseparating
concerns, as it may actually require more work without real
architectural benefit.
Note however, that the approach you suggest where the generator produces
only XML data is valid in publishing-oriented applications where there's
no controller, as the generator has to perform the data acquisition
(until we have lightweight controllers that don't require 2 separate
sitemap executions as flowscript does).
Sylvain
[1] http://marc.theaimsgroup.com/?t=9924427873r=1w=2
[2] http://www.w3.org/TR/xslt#result-element-stylesheet
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: The danger of overseparating concerns (was Re: [Design] JXTG 2.0 (Just my opinion))
Le 4 déc. 04, à 19:24, Sylvain Wallez a écrit : snip interesting experiences/ ...Of course, this is related to our organisation where template writers have more a developer background. Right. And the problem now is that there is no simple way for people to move from designer-friendly environments to Cocoon-based publishing in small steps. They have to do a big jump, where many probably fall on their face ;-) ...The conclusion of this is that we must be careful of not overseparating concerns, as it may actually require more work without real architectural benefit... Agreed. OTOH your view is very html-centric IIUC. In situations where multi-channel output (web, mobile, print for example) is required, a two-step view brings many benefits. But you're right that in such case the first step is rarely pure XML, it's often biased towards the most common/preferred output format. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [Design] JXTG 2.0 (Just my opinion)
On Dec 4, 2004, at 3:37 AM, Bertrand Delacretaz wrote: Le 3 déc. 04, à 21:40, Glen Ezkovich a écrit : ...I'm not sure I agree that templates as being part of the view. I look at them more as providing XML structure to the data We need both actually - if you work with the two-step view pattern (which is very natural with Cocoon), you need a first set of templates to generate XML out of your data, and a second set to transform the XML into the final presentation format. Currently we have JXTG for the first step, and mostly XSLT for the second. Having something that could cover both steps and be usable by either programmers working on the first step or designers working on the second would be a Really Good Thing. I'm not really sure what you mean by having something that could cover both steps. JXTG covers both steps in the sense that many people are using it to inject their data into their html. Now, to have a template transformer, that is something with which I would really like to play. I'm not very found of XSL. A simpler alternative could be a Really, Really Good Thing. -Bertrand [1] http://www.martinfowler.com/eaaCatalog/twoStepView.html One of my favorites books. ;-) http://www.martinfowler.com/books.html#eaa Glen Ezkovich HardBop Consulting glen at hard-bop.com http://www.hard-bop.com A Proverb for Paranoids: If they can get you asking the wrong questions, they don't have to worry about answers. - Thomas Pynchon Gravity's Rainbow
Re: The danger of overseparating concerns (was Re: [Design] JXTG 2.0 (Just my opinion))
On Dec 4, 2004, at 12:24 PM, Sylvain Wallez wrote: Note however, that the approach you suggest where the generator produces only XML data is valid in publishing-oriented applications where there's no controller, as the generator has to perform the data acquisition (until we have lightweight controllers that don't require 2 separate sitemap executions as flowscript does). This where we are currently having problems. When a site is more of an application then just a publication. Mainly our problems are with forms, we would like to use CForms but are finding it difficult to integrate with the rest of our architecture (and its a lot of XML). I'm sure we will find a way ... eventually. But the point you make is well taken and becoming painfully obvious. Glen Ezkovich HardBop Consulting glen at hard-bop.com http://www.hard-bop.com A Proverb for Paranoids: If they can get you asking the wrong questions, they don't have to worry about answers. - Thomas Pynchon Gravity's Rainbow
Re: [Design] JXTG 2.0 (Just my opinion)
Le 4 déc. 04, à 21:03, Glen Ezkovich a écrit : On Dec 4, 2004, at 3:37 AM, Bertrand Delacretaz wrote: ...Currently we have JXTG for the first step, and mostly XSLT for the second. Having something that could cover both steps and be usable by either programmers working on the first step or designers working on the second would be a Really Good Thing. I'm not really sure what you mean by having something that could cover both steps. JXTG covers both steps in the sense that many people are using it to inject their data into their html. Now, to have a template transformer, that is something with which I would really like to play. I'm not very found of XSL. A simpler alternative could be a Really, Really Good Thing. That's what I mean - having a transformer that can use the same template syntax as used in the generator, so that the template language can be used for both the generation and transformation steps. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [Design] JXTG 2.0 (Just my opinion)
Bertrand Delacretaz wrote:
That's what I mean - having a transformer that can use the same
template syntax as used in the generator, so that the template
language can be used for both the generation and transformation steps.
Aren't you really talking about just a transformer then? The current
role of generator would be handled by a FileGenerator loading the
template for processing by the transformer. The processing model would
be kept with the SourceValidity object -- possiblity for reuse whenever
the previous parts of the pipeline are cacheable.
Then the generator simply becomes a virtual one:
map:generator name=template
map:absolutize param=templatename/
map:generate type=file src={templatename}.xml/
map:transform type=template/
/map:generator
A two for one! Only one codebase to maintain. Nothing to keep in sync.
- Miles Elam
Re: [Design] JXTG 2.0 (Just my opinion)
On Dec 4, 2004, at 2:49 PM, Bertrand Delacretaz wrote: Le 4 déc. 04, à 21:03, Glen Ezkovich a écrit : On Dec 4, 2004, at 3:37 AM, Bertrand Delacretaz wrote: ...Currently we have JXTG for the first step, and mostly XSLT for the second. Having something that could cover both steps and be usable by either programmers working on the first step or designers working on the second would be a Really Good Thing. I'm not really sure what you mean by having something that could cover both steps. JXTG covers both steps in the sense that many people are using it to inject their data into their html. Now, to have a template transformer, that is something with which I would really like to play. I'm not very found of XSL. A simpler alternative could be a Really, Really Good Thing. That's what I mean - having a transformer that can use the same template syntax as used in the generator, so that the template language can be used for both the generation and transformation steps. Thats what I assumed based on previous post. Just making sure. :-) -Bertrand Glen Ezkovich HardBop Consulting glen at hard-bop.com http://www.hard-bop.com A Proverb for Paranoids: If they can get you asking the wrong questions, they don't have to worry about answers. - Thomas Pynchon Gravity's Rainbow
Re: [Design] JXTG 2.0 (Just my opinion)
Le 4 déc. 04, à 22:11, Roy G. Biv a écrit :
Aren't you really talking about just a transformer then?...
...Then the generator simply becomes a virtual one:
map:generator name=template
map:absolutize param=templatename/
map:generate type=file src={templatename}.xml/
map:transform type=template/
/map:generator
A two for one! Only one codebase to maintain. Nothing to keep in
sync.
I see the idea, but I think the same thing can be done quite easily in
code by reusing the same processing code in the generator and
transformer.
-Bertrand
smime.p7s
Description: S/MIME cryptographic signature
Re: [Design] JXTG 2.0 (Just my opinion)
Bertrand Delacretaz wrote: I see the idea, but I think the same thing can be done quite easily in code by reusing the same processing code in the generator and transformer. To what advantage? - Miles Elam
Re: The danger of overseparating concerns (was Re: [Design] JXTG 2.0(Just my opinion))
On Sab, 4 de Diciembre de 2004, 12:24, Sylvain Wallez dijo: Note however, that the approach you suggest where the generator produces only XML data is valid in publishing-oriented applications where there's no controller, as the generator has to perform the data acquisition (until we have lightweight controllers that don't require 2 separate sitemap executions as flowscript does). More and more I am convinced that the pain is more related to a reporting (publishing?) tool than to a new language. Best Regards, Antonio Gallardo
Re: [Design] JXTG 2.0 (Just my opinion)
Glen Ezkovich wrote: On Dec 4, 2004, at 3:37 AM, Bertrand Delacretaz wrote: Le 3 déc. 04, à 21:40, Glen Ezkovich a écrit : ...I'm not sure I agree that templates as being part of the view. I look at them more as providing XML structure to the data We need both actually - if you work with the two-step view pattern (which is very natural with Cocoon), you need a first set of templates to generate XML out of your data, and a second set to transform the XML into the final presentation format. Currently we have JXTG for the first step, and mostly XSLT for the second. Having something that could cover both steps and be usable by either programmers working on the first step or designers working on the second would be a Really Good Thing. I'm not really sure what you mean by having something that could cover both steps. JXTG covers both steps in the sense that many people are using it to inject their data into their html. Now, to have a template transformer, that is something with which I would really like to play. I'm not very found of XSL. A simpler alternative could be a Really, Really Good Thing. we are *NOT* trying to redesign XSLT, nor we are trying to solve the problem of creating a more friendly and scriptable SAX transformer then the XSLT/STX family. That is a very interesting problem, but a huge one nevertheless. Let's start with the generator stage first: we'll attack the transformer stage after we are done with this one :-) -- Stefano.
Re: [Design] JXTG 2.0 (Just my opinion)
Bertrand Delacretaz wrote: Le 4 déc. 04, à 21:03, Glen Ezkovich a écrit : On Dec 4, 2004, at 3:37 AM, Bertrand Delacretaz wrote: ...Currently we have JXTG for the first step, and mostly XSLT for the second. Having something that could cover both steps and be usable by either programmers working on the first step or designers working on the second would be a Really Good Thing. I'm not really sure what you mean by having something that could cover both steps. JXTG covers both steps in the sense that many people are using it to inject their data into their html. Now, to have a template transformer, that is something with which I would really like to play. I'm not very found of XSL. A simpler alternative could be a Really, Really Good Thing. That's what I mean - having a transformer that can use the same template syntax as used in the generator, so that the template language can be used for both the generation and transformation steps. My FS detector is out of scale!! This is *exactly* what the XSLT WG did and failed miserably. XSLT can be used for both generation and tranformation. But it looks right for one (besides the stupid XML-ish syntax) and totally ackward for the other. XQuery is the same thing, only reversed: it can be used as a template language, and as a transformation language. If feels better for the first one (only ackward because, as usual, the XSLT WG starts with one name and ends up defining something else) and totally wrong for the second. Look at my eyes and repeat with me: I DO NOT WANT TO REPEAT THE MISTAKES THAT THE XSTL WG DOES OVER AND OVER YEAR AFTER YEAR. Generation and transformation are two different things, done often by different people and for different goals and with different constaints. Having one language for both will do only harm, because it will make it harder for people to decide when to use generation and when to use transformation. -- Stefano.
Re: [Design] JXTG 2.0 (Just my opinion)
Roy G. Biv wrote:
Bertrand Delacretaz wrote:
That's what I mean - having a transformer that can use the same
template syntax as used in the generator, so that the template
language can be used for both the generation and transformation steps.
Aren't you really talking about just a transformer then? The current
role of generator would be handled by a FileGenerator loading the
template for processing by the transformer. The processing model would
be kept with the SourceValidity object -- possiblity for reuse whenever
the previous parts of the pipeline are cacheable.
Then the generator simply becomes a virtual one:
map:generator name=template
map:absolutize param=templatename/
map:generate type=file src={templatename}.xml/
map:transform type=template/
/map:generator
A two for one! Only one codebase to maintain. Nothing to keep in sync.
No, I disagree: there is a place for generation and there is a place for
transformation. They are different things and both have a reason to exist.
--
Stefano.
Re: [Design] JXTG 2.0 (Just my opinion)
Stefano Mazzocchi wrote: No, I disagree: there is a place for generation and there is a place for transformation. They are different things and both have a reason to exist. I see where the statement comes from, but doesn't processing begin by loading the template file? Data injection from flow is step 2. Loading the template file seems like the generation step to me, not the data injection. 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). Your dividing line seems somewhat arbitrary. What am I missing? - Miles Elam
Re: [Design] JXTG 2.0 (Just my opinion)
Roy G. Biv wrote: Stefano Mazzocchi wrote: No, I disagree: there is a place for generation and there is a place for transformation. They are different things and both have a reason to exist. I see where the statement comes from, but doesn't processing begin by loading the template file? Data injection from flow is step 2. Loading the template file seems like the generation step to me, not the data injection. Why would it begin with loading the template? The process begins with the controller accessing the model and then making a determination of what to do next. It might need to go back to the model to obtain another piiece of information to display an alternate screen before displaying the one it collected the inital data for, for example. The template should only be accessed when the data is ready to be manipulated, not before. 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. Your dividing line seems somewhat arbitrary. What am I missing? I don't think it is arbitrary at all. Ralph
Re: [Design] JXTG 2.0 (Just my opinion)
Ralph Goers wrote: Why would it begin with loading the template? The process begins with the controller accessing the model and then making a determination of what to do next. It might need to go back to the model to obtain another piiece of information to display an alternate screen before displaying the one it collected the inital data for, for example. The template should only be accessed when the data is ready to be manipulated, not before. 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. 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? The Flow object model is available to components further down the pipeline too isn't it? 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. 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. Data injection is secondary. Important, but secondary. - Miles Elam
Re: [Design] JXTG 2.0 (Just my opinion)
On Dec 4, 2004, at 11:06 PM, Stefano Mazzocchi wrote: Glen Ezkovich wrote: On Dec 4, 2004, at 3:37 AM, Bertrand Delacretaz wrote: Currently we have JXTG for the first step, and mostly XSLT for the second. Having something that could cover both steps and be usable by either programmers working on the first step or designers working on the second would be a Really Good Thing. I'm not really sure what you mean by having something that could cover both steps. JXTG covers both steps in the sense that many people are using it to inject their data into their html. Now, to have a template transformer, that is something with which I would really like to play. I'm not very found of XSL. A simpler alternative could be a Really, Really Good Thing. we are *NOT* trying to redesign XSLT, nor we are trying to solve the problem of creating a more friendly and scriptable SAX transformer then the XSLT/STX family. That is a very interesting problem, but a huge one nevertheless. I didn't assume that you were. Let's start with the generator stage first: we'll attack the transformer stage after we are done with this one :-) Agreed. I just think that a refactoring of JXTG will make it easier to implement a transformer. Glen Ezkovich HardBop Consulting glen at hard-bop.com http://www.hard-bop.com A Proverb for Paranoids: If they can get you asking the wrong questions, they don't have to worry about answers. - Thomas Pynchon Gravity's Rainbow
Re: [Design] JXTG 2.0 (Just my opinion)
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
Re: [Design] JXTG 2.0 (Just my opinion)
On Dec 4, 2004, at 11:14 PM, Stefano Mazzocchi wrote: Bertrand Delacretaz wrote: Le 4 déc. 04, à 21:03, Glen Ezkovich a écrit : On Dec 4, 2004, at 3:37 AM, Bertrand Delacretaz wrote: ...Currently we have JXTG for the first step, and mostly XSLT for the second. Having something that could cover both steps and be usable by either programmers working on the first step or designers working on the second would be a Really Good Thing. I'm not really sure what you mean by having something that could cover both steps. JXTG covers both steps in the sense that many people are using it to inject their data into their html. Now, to have a template transformer, that is something with which I would really like to play. I'm not very found of XSL. A simpler alternative could be a Really, Really Good Thing. That's what I mean - having a transformer that can use the same template syntax as used in the generator, so that the template language can be used for both the generation and transformation steps. My FS detector is out of scale!! This is *exactly* what the XSLT WG did and failed miserably. XSLT can be used for both generation and tranformation. But it looks right for one (besides the stupid XML-ish syntax) and totally ackward for the other. XQuery is the same thing, only reversed: it can be used as a template language, and as a transformation language. If feels better for the first one (only ackward because, as usual, the XSLT WG starts with one name and ends up defining something else) and totally wrong for the second. Look at my eyes and repeat with me: I DO NOT WANT TO REPEAT THE MISTAKES THAT THE XSTL WG DOES OVER AND OVER YEAR AFTER YEAR. Generation and transformation are two different things, done often by different people and for different goals and with different constaints. Having one language for both will do only harm, because it will make it harder for people to decide when to use generation and when to use transformation. But in both cases here we are talking about templates. I like a two pass approach. Inject the data into an XML template, then take that data and inject it into an XHTML template. I prefer this approach precisely because different people do each each job. Developers handle generation and designers handle what would be the transformation but in this case it would/could be pure injection. I don't see a template transformer as a replacement for XSLT, just as an alternative. It hopefully will be much simpler. Glen Ezkovich HardBop Consulting glen at hard-bop.com http://www.hard-bop.com A Proverb for Paranoids: If they can get you asking the wrong questions, they don't have to worry about answers. - Thomas Pynchon Gravity's Rainbow
Re: [Design] JXTG 2.0 (Just my opinion)
Stefano Mazzocchi said:
-- stuff removed --
${myDate as month}
-- stuff removed --
--
Stefano.
Not that I disagree with you, but why don't you consider your example to
be a taglib? Perhaps I'm just reading more generality into the
discussions than is really there, but I haven't seen anyone state that
taglibs must be of the form namespace:op namespace:attr=token, etc.
Frankly, the part that has worried me the most is the discussion of SQL
and templates in the same email. From my perspective SQL queries are
part, of or simply are, the model. Templates, on the other hand are
generally part of the view. Although they may be used in an intermediate
step to reformat the data in the model, this is just a smaller version of
MVC where the view is the reformatted data.
In other words, templates that do anything other than accessing already
available data and rendering formatted data should a) not be possible,
or b) be discouraged. Notice already available data. That means you
shouldn't have tag libraries or whatever that do the SQL query, invoke
business methods or whatever. That should all be done via business methods
invoked by actions or flow (i.e. the controller).
Ralph
Ralph
Re: [Design] JXTG 2.0 (Just my opinion)
On Dec 3, 2004, at 1:33 PM, Ralph Goers wrote:
Stefano Mazzocchi said:
-- stuff removed --
${myDate as month}
-- stuff removed --
--
Stefano.
Not that I disagree with you, but why don't you consider your example
to
be a taglib? Perhaps I'm just reading more generality into the
discussions than is really there, but I haven't seen anyone state that
taglibs must be of the form namespace:op namespace:attr=token,
etc.
Frankly, the part that has worried me the most is the discussion of SQL
and templates in the same email. From my perspective SQL queries are
part, of or simply are, the model. Templates, on the other hand are
generally part of the view. Although they may be used in an
intermediate
step to reformat the data in the model, this is just a smaller version
of
MVC where the view is the reformatted data.
I'm not sure I agree that templates as being part of the view. I look
at them more as providing XML structure to the data.
In other words, templates that do anything other than accessing already
available data and rendering formatted data should a) not be
possible,
or b) be discouraged.
Most definitely agreeded.
Notice already available data. That means you
shouldn't have tag libraries or whatever that do the SQL query, invoke
business methods or whatever. That should all be done via business
methods
invoked by actions or flow (i.e. the controller).
Usually, I can see an SQLTemplateGenerator that uses no flow. It
connects and queries the database, i.e. generates the data, and then
injects into a template.
Here is a reasonable replacement for XSP and ESQL. Hopefully there will
be no view. (But you know there will be. :-( )
Glen Ezkovich
HardBop Consulting
glen at hard-bop.com
http://www.hard-bop.com
A Proverb for Paranoids:
If they can get you asking the wrong questions, they don't have to
worry about answers.
- Thomas Pynchon Gravity's Rainbow
