You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Daniel Fagerstrom <da...@nada.kth.se> on 2004/11/24 20:50:07 UTC
[Design] JXTG 2.0
Here are some ideas about how to implement JXTG 2.0. I will not have
time do start doing any implementation work in the next week or so. But
I write down my ideas this far if somebody else (Leszek or Jonas e.g.)
feels like starting the work (and above that happen to be interested in
my design ideas ;).
I'll focus on describing how pre-compilation can be implemented and how
to connect to Java written executable tags.
After having evaluated Jelly and taglib, I don't think it is worthwhile
to trying to implement JXTG2 on top of them. It is certainly a good idea
to reuse ideas and code from JXTG. One could possibly start from JXTG
and go to JXTG2 through a sequence of refactoring steps, but the
monsterous size of the implementation of JXTG makes that less atractive,
at least for me. I would probably start from Jonas taglib as it contains
some things that we are going to need any way and is a good starting
point. Anyway it is IMHO a good idea to take a look at it, and see that
a taglib implementation can be small and lean and does not have to be
+150kB source code.
---o0o---
I'll continue to describe a possible design of a template generator (TG)
that uses pre-compilation and has customer tags. This will be done in
three steps: We start with a trivial pre-compiled template language (TL)
_without_ expressions ;) In the next step we add an expression language
to it and we finish by adding executable tags.
A Trivial Pre-Compiled "Template Generator"
===========================================
This step is not that useful in it self, the result will just be an
unnesecarilly complicated implementation of the file generator. This is
for introducing some ideas.
The pre-compiling TG works in two steps: First it compiles the content
of the input source to a script, and store the script in its cache
together with an approriate cache key. Then the cached script will be
used as long as the cache key is valid. It is important that the script
is thread safe otherwise it will be unsafe to reuse. As store, Cocoon's
transient store could be used.
In the second step the script is executed and SAX output is generated.
The Trivial Script
------------------
The task of the trivial "template generator" is to output its input
template document as is :) For this task there allready is a feature
complete script implementation in Cocoon; o.a.c.xml.SAXBuffer.
The SAXBuffer contains a list of SAXBits where each SAXBit is an
(immutable) representation of a SAX event. The SAXBit interface contains
the method "send(ContentHandler)". And the SAXBuffer contains an inner
class implementing SAXBit for each SAX event type.
The SAXBuffer implements XMLConsumer which records the input events as
list of SAXBits. It also implements XMLizable with the method
"toSAX(ContentHandler)" that iterates through the recorded SAXBits and
execute "send(ContentHandler)" on them.
This far compiling a script means sending the input source to a
SAXBuffer and executing a script means calling the "toSAX" method on the
SAX buffer.
JXTG contains code that is similar to the SAXBuffer.
A Real Template Generator
=========================
The defining property of an XML TL is that you can embed expressions in
the XML attributes and text. These expression are replaced with the
result of evaluating the expressions in some context. To add this to our
TG we need to define the context, get a expression evaluator and handle
the expression embeding in the script.
Expression Language
-------------------
It would be best if we could decide to use JXPath everywhere in Cocoon
;) But as that not is going to happen we need to support several
expression languages (EL). This is not just a need in JXTG but also in
CForms, input modules and many other places. So we have a need for
plugable EL in Cocoon.
Dmitri Plotnikov, the main author of JXPath have written a common API
for EL http://www.plotnix.com/jex/index.html, and commited the code to
Jakarta Commons Sandbox
http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/jex/. AFAICS
the project never took off so we shouldn't use it. But we could probably
steal some good ideas from it, although I think that we should keep it
much simpler.
ELs often has the possibility to create a compiled expression object
from the expression string. When that is possible, (and given that the
compiled expression is thread safe), we can get better performance by
storing compiled expressions in the script.
Besides plugable EL we also want to be able to plug in a locale
sensitive and configurable convertor
component for handling the results from the EL.
Now, we don't have to implement everything at once. We can start with
suporting one EL and refactor to using the plugable EL, when/if someone
implements it.
Expression Context
------------------
The expresion must be evaluated in some context. JXTG have a lot of code
that package the different objects in the Cocoon object model so that it
looks the same way as in flowscripts, but from JXPath or JEXL. Carsten
have factored out the code from JXTG to
o.a.c.environment.TemplateObjectModelHelper in scratchpad. It is marked
as "work in progress" and I don't know the current state of it. But IMHO
we should base JXTG2 on that (and possibly improve it) rather than
having still another implementation of the script object model.
Embeding Expressions in the Template Language
---------------------------------------------
In the TL we are using expressions like this:
<tag attr1="text ${expr1} text ${expr2}">
Text ${expr3} more text ${expr4}, even more text.
</tag>
We can see that it is the SAX startElement and the characters events
that are affected. During compilation of the TL into a script, we need
to parse the attribute content and characters content and create a list
of text elements and compiled expression elements.
During execution of the script the expression context must be available
when executing the EL parts of the script.
In JXTG this is implemented in the TextEvent and the StartElement
classes, where both contains list with interspersed expression and text
objects.
If we continue to base our script implementation on the SAXBuffer, we
need to extend it with new handling of startEvent and characters like in
JXTG. We need new StartElement and Characters classes that can handle
expressions like I described above. During script compilation time they
need a EL factory. During script execution time they need a expression
context, so their interface must be extended with something like
"send(ContentHandler, ExpressionContext)" and simillary the script
(extended SAXBuffer) need a method "toSAX(ContentHandler,
ExpressionContext)".
Adding Executable Tags
======================
There are numerous ways to add executable tags (ET) to a TL. Of those I
have seen I prefer Jelly's way, and therefore I'll describe how to
implement something similar. Take a look on the implementation of some
Jelly tags
http://cvs.apache.org/viewcvs.cgi/jakarta-commons/jelly/src/java/org/apache/commons/jelly/tags/core/
and compare them with the corresponding tags in e.g. taglib and decide
for yourself what you prefer.
For concretenes lets say that we have a for-tag in our TL (example from
Jonas):
<core:for var="index" begin="0" end="8" step="2">
<p>${index}</p>
</core:for>
We have a TagRepository where URI and tag name is mapped to a tag
object. Tags that are registred in the TagRepository (executable tags)
gets special treatment. All others are handled as described in the
previous sections.
When a ET is executed it will have access to:
* the execution context (including the current expression context)
* the content of its attributes
* its body in form of a script
* the current XMLConsumer for output
* its parent ET (this is less important, but is used for implementing
e.g. choose/when, take a look at the Jelly tags)
Execution Context
-----------------
The execution context contains the expression context as before but now
we want the expression context to be implemented as a stack of (variable
name, value) bindings, searched from top and downwards for a variable
binding, (see Jonas code e.g. for details). This is needed for creating
local variables in template "macros" and for handling context info in
recursive templates. Recursive templates are needed as soon as you have
recurively defined data structures like the class stuff in CForms.
The execution context gives access to the tag repository so that it is
possible to add tags and use tags in user defined tags. It might also
contain access to Cocoon components, and the source resover.
The Executable Tag
------------------
The most complicated question in deciding how the ETs should work is if
we should require them to be thread safe or not. If they are thread safe
they can be made part of the script and be completely prepared at
compile time. But OTH they will be harder to write as one cannot use
member variables for state info.
For the moment I think not requireing thread safety would be enough and
that we can see more efficient treatment of thread safe tags as a future
optimization. In Jelly, tags can implement CompilableTag, which give
them the possiblity to do some work at compile time, I've no idea about
how it work though.
Anyway the tag will be created at execute time and need access to the
different data specified above.
Jelly uses the following inteface for tags:
public interface Tag {
public Tag getParent();
public void setParent(Tag parent);
public Script getBody();
public void setBody(Script body);
public JellyContext getContext();
public void setContext(JellyContext context) throws JellyTagException;
public void doTag(XMLOutput output) throws MissingAttributeException, JellyTagException;
public void invokeBody(XMLOutput output) throws JellyTagException;
}
and setter injection for the attributes. Or this is rather the default
way, Jelly also use various reflection based tricks and tries to handle
almost any bean as a tag.
The "for" tag above would be implemented like this:
public class For extends TagSupport {
String var;
int begin, end, step;
public void setBegin(int begin) { this.begin = begin }
// other setters and getters
public void doTag(XMLOutput output) throws JellyTagException {
getContext().variables().push();
for (int i = begin; i <= end; i+= step) {
if (var != null)
getContext().variables().put(var, new Integer(i));
invokeBody(output);
}
variables.pop();
}
}
(I'm using Jelly interfaces, so the example isn't completely consistent
with other discussion about intefaces in the mail).
I have no strong opinions about if we should user setter injection,
getAttribute methods in doTag, etc.
Compiling the Script
--------------------
Now we continue to extend our script implementation so that it can
contain an ExecutableTag element as well as the previous ones. An
ExecutableTag object is set up with attributes, the script for its body,
its parent and a reference to the factory for creating its tag bean
during compile time. During execution we need a "send(ContentHandler,
Context)" method that creates and instantiates the tag object (as
described above) and then call its doTag method. The script also need a
"toSAX(ContentHandler, Context)" for executing all of the script.
Now we need a template parser its not enough to feed the input source
into the SAXBuffer anymore as we are going to create a new script for
every body of an executable tag. The parser need stacks for keeping
track of the current tag and the current script, take a look at e.g.
Jonas TemplateTransformer to get an idea about how such parsing can be
implemented.
Implementing the Tags
---------------------
The idea is that all tags in JXTG are implemented as executable tags in
the above described framework. Also tags for defining new tags e.g. macros.
Besides implementing the JXTG tags, we would need to implement the ESQL
tags (or a replacement of them), and porting (if that is needed) the
CForms tags. After that we would have a replacement for XSP, AFAIU :)
---o0o---
Having written all this I start wondering if I wouldn't have been better
to start actually implement it ;)
Anyway, thanks for having read this far.
WDYT?
/Daniel
Re: [Design] JXTG 2.0 (Just say no!)
Posted by Sylvain Wallez <sy...@apache.org>.
Daniel Fagerstrom wrote:
> Sylvain Wallez wrote:
>
>> Miles Elam wrote:
>
>
> <snip/>
>
>>> <friend jx:context="${people}" jx:test="${name != 'Mean
>>> Mike'}">${name}</friend>
>>
>>
> <snip/>
>
>> Ok. My conclusion about this is twofold:
>> - taglibgs should be triggered by attributes and not only by elements,
>
>
> It's ok with me. Question is how do we interprete the construction
> above. From commons sense we can infer that the test for the name
> should be performed for each person in th sequence of people.
Yes. Actually, it would be clearer if written something like
<friend jx:forEach="${people}" jx:if="${name != 'Mean
Mike'}">${name}</friend>
where attributes are actually the same as tag names.
This of course works only for tags having a single attribute.
> We could maybe infer the same thing by studying the input data
> structure. What if I want a double loop over two sets?
You cannot using tags-as-attributes as there cannot be two attributes
with the same name. In that case, you either use tags-as-elements, or
use some container element.
> Any ideas about how to implement it? What would jx:context and
> jx:people correspond to? If we just allow one "programatic" attribute
> per element, the code connected to it could be allowed to do whatever
> it want to when its parent element is called but its more complicated
> when there are several "programatic" attributes, how do we control
> their relative nesting.
IMO, the resolution of tags-as-attributes should follow a priority order
that will be built into the taglib. That can be implemented using a
filter that transforms tags-as-attributes into tags-as-elements in a
predefined order.
There's still a problem however, when tags-as-attributes coming from
several taglibs exist on a single element, as we must know the relative
order of the taglibs.
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 say no!)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Sylvain Wallez wrote:
> Miles Elam wrote:
<snip/>
>> <friend jx:context="${people}" jx:test="${name != 'Mean
>> Mike'}">${name}</friend>
>
<snip/>
> Ok. My conclusion about this is twofold:
> - taglibgs should be triggered by attributes and not only by elements,
It's ok with me. Question is how do we interprete the construction
above. From commons sense we can infer that the test for the name should
be performed for each person in th sequence of people. We could maybe
infer the same thing by studying the input data structure. What if I
want a double loop over two sets? Any ideas about how to implement it?
What would jx:context and jx:people correspond to? If we just allow one
"programatic" attribute per element, the code connected to it could be
allowed to do whatever it want to when its parent element is called but
its more complicated when there are several "programatic" attributes,
how do we control their relative nesting.
<snip/>
/Daniel
Re: [Design] JXTG 2.0 (Just say no!)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Stefano Mazzocchi wrote:
<snip/>
> Now there are two approaches:
>
> 1) model 1: taglibs
> 2) model 2: controller + view
3) model 3: taglibs + view
> Model 1 removes all the "underlying machinery" but leaves the "glueing"
> to the one that does the template design, or forces two people to work
> on the same file (which is bad).
>
> Model 2 removes both the underlying machinery and the gluing (request ->
> order, birth-date -> age) and leaves the template designer with iteration.
We always use the 3:rd model. The first taglibs part contains the same
stuff as you put in the controller but it is written by people who are
skilled in SQL but they are in most cases not programmers. The view is
written in XSLT, it might be designed by a designer in Dreamweaver, but
then a developer typically embed it in XSLT so that we can use the same
design for many pages.
> So, result: Model 2 is a clear winner in terms of SoC analysis, no
> matter what interfaces the taglibs exhibit, no matter what syntax the
> templates or the controller have.
>
> Why? because Model 1 removes the machinery but leaves the programmatic
> glueing (which template designers' mindset don't contemplate).
>
> Model 2 does not.
>
> Result: taglibs are to be considered harmful, no matter what syntax.
Come on, with such comparisons you can prove anything. Don't you
remember that you based Cocoon on xml-pipelines any more?
/Daniel
Re: [Design] JXTG 2.0 (Just say no!)
Posted by Tim Larson <ti...@keow.org>.
On Thu, Dec 02, 2004 at 01:27:09PM -0500, Stefano Mazzocchi wrote:
> Sylvain Wallez wrote:
>
> >You miss an important point here: many Cocoon users are not able to
> >write Java code, and even less a Tag implementation. The purpose of
> >taglibs and template languages is to provide pre-packaged higher-level
> >constructs that hide the underlying complexity.
>
> I'm sorry but I can't take this argument any longer.
>
> Programming is not just learning a syntax, but it's the mapping of a
> mental model. Mental model that people that write templates simple *DO
> NOT* have, nor care to have.
Thank you, Stefano, for emphasizing the split between
the "mental model" of the programmer versus that of
the template designer. I would like to now accentuate
another aspect of our problem and solution space.
Babel-Driven Separation of Concerns (BDSoC)
versus
Graduated Complexity Separation of Concerns (GCSoC)
We are currently using Babel (different languages)
to enforce separation of concerns, and this has its
merits, in that it creates a high barrior between
different concerns, but also carries an obvious price.
Another (complementary?) route would be to separate
concerns via Graduated Complexity (same languages,
with different levels of feature-sets available.)
This would at least allow the people assigned to the
different concerns to talk the same languages, with
just the specific vocabularies varying.
For example, picture a generic tag engine with sets
of tag libraries. Configure one instance of the
tag engine, giving it access to only the "programming"
tags (such as to duplicate ESQL functionality.)
Configure another instance of the (same) tag engine
with access to only the "templating" tags. The
framework development community now is in the easier
position of supporting one instead of two "languages",
while the separation of concerns is still enforced
upon the framework users.
A side effect in this example is that the programmers
and template makers gain a common base language,
possibly making their needs easier to express to each
other, maybe even leading to cross-pollination between
their skillsets, allowing them to work more smoothly
together while working on their respective concerns.
WDYT?
--Tim Larson
Re: [Design] JXTG 2.0 (Just say no!)
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
> You miss an important point here: many Cocoon users are not able to
> write Java code, and even less a Tag implementation. The purpose of
> taglibs and template languages is to provide pre-packaged higher-level
> constructs that hide the underlying complexity.
I'm sorry but I can't take this argument any longer.
Programming is not just learning a syntax, but it's the mapping of a
mental model. Mental model that people that write templates simple *DO
NOT* have, nor care to have.
> Take a look at ESQL for an extreme example in this area :-)
In a perfect world, templates wouldn't need conditionals and iterations,
they would come streight out of photoshop, pixel-perfect and flexible at
the same time.
Too bad that doesn't apply.
So there is somebody that does the skeleton layout, somebody that does
the photoshop prettyfication, and somebody that populates the data the
pages need and somebody that mounts the pieces together.
Sometimes, depending on their skills and time availability, a person
does more than one of the above tasks. But it's expremely rare (and, by
consequence, expensive!) that a single person is able to do all 4 and
excel at it.
We are subscribed here because we understand the above perfectly and
that's why we believe in framework-enforced SoC.
Now, let's apply that reasoning to the current discussion and let's make
the following, very simple, stateless yet dynamic page:
a page that shows the names and ages of the current employees as a table
and has the ability to order them by name or by age. The database model
is "name, birth-date".
Now, let's take the above situation and write the taglibs that are
general enough and simple enough for the people doing the HTML layout to
understand.
Now let's analyze what the above would mean in terms of SoC:
1) the "order type" has to be passed to the page, either as a request
parameter or as a URL type. In the first case, the sitemap doesn't have
to be touched, in the second it does, but pages need to be duplicates,
so the template designers will prefer the first.
2) the database model does not contain the age, so that needs to be
calculated from the database results
3) the ordering is done either at the database level, or at the page
level. in either case, there must be a conditional between the different
type of orderings
4) the results need to be iterated, since their number is not known.
Now there are two approaches:
1) model 1: taglibs
2) model 2: controller + view
Model 1 removes all the "underlying machinery" but leaves the "glueing"
to the one that does the template design, or forces two people to work
on the same file (which is bad).
Model 2 removes both the underlying machinery and the gluing (request ->
order, birth-date -> age) and leaves the template designer with iteration.
So, result: Model 2 is a clear winner in terms of SoC analysis, no
matter what interfaces the taglibs exhibit, no matter what syntax the
templates or the controller have.
Why? because Model 1 removes the machinery but leaves the programmatic
glueing (which template designers' mindset don't contemplate).
Model 2 does not.
Result: taglibs are to be considered harmful, no matter what syntax.
--
Stefano.
Re: [Design] JXTG 2.0 (Just say no!)
Posted by Sylvain Wallez <sy...@apache.org>.
Miles Elam wrote:
> Ummm... Hold on second while I don my flame-resistant underwear.
<snip what="history of template languages"/>
> Why tag libraries? To deal with the excessive code in the markup. If
> you really need code in markup for your corner case, tag libraries
> aren't going to help the situation much. You need code.
>
> So here we stand discussing how to go back to big balls of tag library
> mud. We have a glimpse of better things with Flow. Why aren't we
> examining that model for further direction? Why are we going
> backwards? Arbitrary Java code executing in the markup but with a
> prettier face? Great. I'm so happy, I could eat the six month old
> leftovers rotting in my friend's tupperware.
>
> CAN' T WE COME UP WITH A BETTER IDEA!?! There are some really smart
> people on this list. C'mon!
>
> What have tag libraries been used for?
>
> 1. A macro language
> 2. Data generation
> 3. Data formatting
> 4. Backend processing
> 5. Making programming languages out of markup
> 6. Data replacement
>
> Let's go down the list.
>
> 1. A macro language
>
> XSLT or any of the other markup transformation syntaxes can handle
> this. No code or tag API needed. STX: an easy-to-use syntax enabling
> a SAX stream with a minimal memory footprint. Side effect-free.
> Highly cacheable. The cached SAX events for JXTemplateGenerator are
> put in the cache for future use -- same story with a
> JXTemplateTransformer or any JXTemplate* successor or whatever.
> Nothing lost by using a simple transformation language. The best
> part? It's simple.
>
> 2. Data generation
>
> Raise your hands. Let's see who you are that still thinks after all
> that we've learned from web development history that
> <esql:execute>SELECT * FROM MYTABLE WHERE COLUMN1 = 0</esql:execute>
> is a good idea and the best we can come up with? I admit that I was
> one of "those" people that was trying to get a standard relational
> database API in Flow. So wrong. SO WRONG. I would like to thank the
> developers on this list for their insight and wisdom on this point.
>
> If you are savvy enough to write a Java class that implements the Tag
> interface, you are certainly smart enough to write a POJO for use with
> Hibernate (or whichever object persistence mechanism you prefer). In
> fact, the way things are going and with the tools being made
> available, the Tag interface is *harder*. And an implementation of
> Tag verses a Javascript object or data structure? The difference in
> complexity level isn't even funny.
You miss an important point here: many Cocoon users are not able to
write Java code, and even less a Tag implementation. The purpose of
taglibs and template languages is to provide pre-packaged higher-level
constructs that hide the underlying complexity.
Take a look at ESQL for an extreme example in this area :-)
> 3. Data formatting
>
> Let's call a spade a spade here. We've got how many variations that
> need to be handled?
>
> boolean, integer types, floating point types, dates/timestamps,
> strings, XML fragments, selection from limited choices (if 0, say
> "none" -- if 1, say "one" -- if more, say "many"), and objects (which
> are basically .toString() calls unless it has properties that are
> plain old datatypes -- in which case you use the other handlers).
>
> That's what? Seven different formatters? Done. Finished. Do we
> really need a tag library for that? Make them reusable components
> that transformers can use as needed.
AFAIK, this is exacly the idea: have a set of Formatters (or Convertors)
and share them between template engines, and CForms.
> 4. Backend processing
>
> We don't like to admit it, but we've all wondered, "What if this
> custom tag could trigger a cache invalidation or do some workflow
> or..." Bad idea. Bad idea. Backend processing in your markup
> template is a horrible idea. Do it in an action or better yet in Flow.
I partially agree here. When a pipeline is used to produce the view,
i.e. what is sent back to the user, then there should be no side effects.
Now there are times where pipelines are used as part of the application
logic, and is such cases having components with side-effects is allowed.
Such pipelines can be thought of as business logic functions implemented
with pipelines rather than with traditional programming languages.
> 5. Making programming languages out of markup
>
> <foo:if>, <foo:for-each>, <foo:eval>, etc. Why the foreplay? If
> you're gonna write a programming language, at least have the decency
> to not base it on markup. These aren't really different from saying
>
> <% if (test.isTrue()) { %>
> <foo/>
> <% } %>
>
> or XSP's
>
> <xsp:logic>
> if (test.isTrue()) {
> <foo/>
> }
> </xsp:logic>
>
> IMO constructs like this should be context-dependent on the task at
> hand. For example, wouldn't it have been easier if instead of
>
> <jx:for-each var="person" items="${people}">
> <jx:if test="${person.name != 'Mean Mike'} ">
> <friend>${person.name}</friend>
> </jx:if>
> </jx:for-each>
>
> you had
>
> <friend jx:context="${people}" jx:test="${name != 'Mean
> Mike'}">${name}</friend>
>
> Same thing. Not a programming language though. Data injection
> tailored to the task at hand. This is the problem domain that
> JXTemplateGenerator is made to solve.
Know what? This is a form of taglib also, although it's driven by
attributes rather than elements.
We use this technique to inject some XSLT-like instructions in HTML
pages as attributes, and these annotated HTML pages can then be compiled
to regular XSLs.
So yes, both forms are strictly equivalent, although the attribute-based
syntax allows for more compact notation and is more Dreamweaver-friendly.
> What is the for-each doing? Setting a scope -- a context. Look back
> in the templates you've made. How many <jx:if> elements wrapped more
> than one element? I have found in my general usage that well over 90%
> of the time it's just the one child element. And those
> <jx:chose/when/otherwise>... Be honest, how many times have you used
> that for data formatting rather than structural changes to the
> markup? Listing stuff like "yesterday" or "today" or "last week"
> instead of the raw date. That's a boatload of markup to do what
> amounts to a java.text.ChoiceFormat method call.
>
> If it's that complex, why isn't it reflected in your data model
> instead of your markup's wannabe programming language?
Because the choice of displaying "yesterday", "today" or "last week" is
not a concern of the data model: the model only holds a java.util.Date.
> 6. Data replacement
>
> And here we come to the meat. This is where the I18nTransformer does
> its magic. This where JXTemplateGenerator does its thing. One hit
> wonders where the markup has been altered to fit the problem at hand,
> not the general definition of a tag library. Where does the following
> I18nTransformer example fit in?
>
> <input type="submit" value="Submit" i18n:attr="value"/>
>
> It can if all it does it translate <foo:i18n-submit/> to the above for
> "real" processing. Stylesheet.
Or tags as attributes, as outlined above.
> Data injection. That's what custom markup is really good for. It's a
> domain-specific problem. Tag libraries are for general case
> problems. But the general case is already handled by the existing
> transformers' API.
>
>
> -------------------------- o0O0o -------------------------
>
>
> So what are the use cases that require tag libraries? More
> specifically, what are the use cases that require tag libraries that
> will be made cleaner by skipping XSP?
>
> What would I prefer? Keep XSP as it is. It's shite, but it's
> powerful shite. It's for the edge; those pesky corner-cases that
> refuse to go away; the last 1%.
>
> * XSP is Cocoon's mod_rewrite. *
Yes. And that's why it won't be deprecated soon, IMO :-)
It's a gun that may allow you to shoot in your foot, but may also save
your like in extraordinary conditions.
> Don't code around mod_rewrite. Let it be the method of last resort.
> Find a model that allows the logic, data structures and code to live
> elsewhere.
Well, pushing the comparison, why do we have a mod_proxy when
mod_rewrite can do it also? Simply because mod_proxy does only one
thing, but does it in a more understandable way. It provides a proxy
feature for those you want proxying without risking to shoot themselves
in the feet.
> Leave data injection and formatting to the template
> generator/transformer. Look at Flow and find something like it.
> Maybe not exactly Flow, but a lot closer to it than the world of
> ASP/PHP/JSP and tag libraries.
>
> I would prefer something like
>
> <Cats xmlns:data="http://org.apache/cocoon/data">
> <Cat data:context="${cats}" name="${name}" sex="${sex}" age="${age}"/>
> </Cats>
>
> and/or
>
> <Cats xmlns:data="http://org.apache/cocoon/data">
> <Cat data:context="${cats}">
> <Sex>${sex}</Sex>
> <Name data:test="${name}">${name}</Name>
> <Age data:test="${age != -1}">${age}</Age>
> </Cat>
> </Cats>
>
> I would prefer this to the current situation of
>
> <Cats xmlns:jx="http::">
> <jx:for-each var="cat" items="${cats}">
> <Cat name="${name}" sex="${sex}" age="${age}">
> </jx:for-each>
> </Cats>
>
> or
>
> <Cats xmlns:jx="http::">
> <jx:for-each var="cat" items="${cats}">
> <Cat>
> <Sex>${sex}</Sex>
> <jx:if test="${cat.name != null}">
> <Name>${cat.name}</Name>
> </jx:if>
> <jx:if test="${cat.age != -1}">
> <Name>${cat.age}</Name>
> </jx:if>
> </Cat>
> </jx:for-each>
> </Cats>
>
> Sure, macros can alleviate this. But macros are band-aids on a
> usability/design defect. This talk of macros and tag libraries I
> think has more to do with our frustrations with the current models
> than actual demonstrated need. So instead of a discussion about how
> the tag library API should be defined, why not make the simplest
> interface for the outside world first. And only after that's done,
> talk about implementation details like tag libraries.
Ok. My conclusion about this is twofold:
- taglibgs should be triggered by attributes and not only by elements,
- we need a Convertor/Formatter service
The second point is already agreed upon, and I personally like the first
one.
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 say no!)
Posted by ag...@agssa.net.
Hi Miles:
Many thanks. Because you sound the bell.
Some days ago, I told Tim Larson in the #cocoon IRC channel that I have the
same feelings as you have. I started a mail to explain why I felt this is not
a good move and suddenly you wrote it. You explanation is far better than the
once I started to write.
I am +1 with you.
Best Regards,
Antonio Gallardo.
El Miércoles, 1 de Diciembre de 2004 16:24, Miles Elam escribió:
> Ummm... Hold on second while I don my flame-resistant underwear.
>
> Okay folks, why are we making tag libraries/interfaces *at all*? I
> mean it. I feel like a lemming being driven off a cliff.
>
> Before continuing, I want to take a look at the history of web
> technologies and major milestones. In the beginning, you had files and
> web servers. Then people starting writing extensions to the web
> servers and the dynamic web was born.
>
> But the problems with patching your web server for even the slightest
> dynamism were immediately obvious even in the early days of "a patchy
> server". So CGI (Common Gateway Interface) was born and Perl rose up
> as the dominant web language. Process creation overhead became an
> issue as the web took off so techniques fro mitigating this were put in
> like mod_perl, servlets, etc., but overall the process stayed the same.
>
> While an improvement over what came before and most definitely useful,
> embedding markup was an absolute pain. All sorts of hacks rose up to
> programmatically write markup. But then a lot of people noticed at the
> same time that a lot of their dynamic pages were mostly static markup
> with only a token amount of logic. Thus the age of ASP, PHP, JSP, et
> al. was born, and it was cool runnings for a while. If you needed a
> lot of logic, you wrote code with a markup generation library. If you
> only needed a little logic, you wrote a markup file with code markers
> for logic.
>
> Things started going south when people with no programming experience
> started learning from those ASP, PHP, and JSP examples. They gleefully
> added huge tracts of code in these files, giving new life to a much
> maligned design pattern known as "big ball of mud". Soon everyone
> starting getting stuck in the ever-increasing balls of mud. Simplify!
> Encapsulate! Componentize!
>
> We'll just add new markup. We'll call them "tag libraries" and put all
> the code snippets into these markup fragments. Brilliant! Now the
> people who don't know how to program can just write markup and coders
> can write stuff further up the chain.
>
> XSP was born at about this point, tag libraries and embedded Java in
> all their splendor, enforcing well-formedness and driving popular usage
> of Cocoon.
>
> People still wrote logic in their markup though. And even the tag
> libraries became more and more monstrous. A tag library for databases.
> A tag library for data formatting. A tag library to make more tags.
> A tag library to perform backend workflow. A tag library to do the
> laundry and wash the dishes. Just to add insult to injury, some
> academic gadflies coined the acronym MVC (Model-View-Controller) and
> starting going on about something called SoC (Separation of Concerns).
> Everything started going gonzo at that point. HTML was no longer
> supposed to have styling info; that is now CSS's job. Our data
> repositories may change -- and may or may not be relational databases
> anymore. Hard-coding database connection strings, table names and
> column names were frowned upon. Then this brilliant individual named
> Ovidiu thought about how nice it would be to have continuations in web
> development.
>
> Flowscript has entered the building! (*enter angelic chorus*) Here we
> had logic in a separate file that generated data structures for display
> and formatting by the templating language.
>
> -------------------------- o0O0o -------------------------
>
> Why tag libraries? To deal with the excessive code in the markup. If
> you really need code in markup for your corner case, tag libraries
> aren't going to help the situation much. You need code.
>
> So here we stand discussing how to go back to big balls of tag library
> mud. We have a glimpse of better things with Flow. Why aren't we
> examining that model for further direction? Why are we going
> backwards? Arbitrary Java code executing in the markup but with a
> prettier face? Great. I'm so happy, I could eat the six month old
> leftovers rotting in my friend's tupperware.
>
> CAN' T WE COME UP WITH A BETTER IDEA!?! There are some really smart
> people on this list. C'mon!
>
> What have tag libraries been used for?
>
> 1. A macro language
> 2. Data generation
> 3. Data formatting
> 4. Backend processing
> 5. Making programming languages out of markup
> 6. Data replacement
>
> Let's go down the list.
>
> 1. A macro language
>
> XSLT or any of the other markup transformation syntaxes can handle
> this. No code or tag API needed. STX: an easy-to-use syntax enabling
> a SAX stream with a minimal memory footprint. Side effect-free.
> Highly cacheable. The cached SAX events for JXTemplateGenerator are
> put in the cache for future use -- same story with a
> JXTemplateTransformer or any JXTemplate* successor or whatever.
> Nothing lost by using a simple transformation language. The best part?
> It's simple.
>
> 2. Data generation
>
> Raise your hands. Let's see who you are that still thinks after all
> that we've learned from web development history that
> <esql:execute>SELECT * FROM MYTABLE WHERE COLUMN1 = 0</esql:execute> is
> a good idea and the best we can come up with? I admit that I was one
> of "those" people that was trying to get a standard relational database
> API in Flow. So wrong. SO WRONG. I would like to thank the
> developers on this list for their insight and wisdom on this point.
>
> If you are savvy enough to write a Java class that implements the Tag
> interface, you are certainly smart enough to write a POJO for use with
> Hibernate (or whichever object persistence mechanism you prefer). In
> fact, the way things are going and with the tools being made available,
> the Tag interface is *harder*. And an implementation of Tag verses a
> Javascript object or data structure? The difference in complexity
> level isn't even funny.
>
> 3. Data formatting
>
> Let's call a spade a spade here. We've got how many variations that
> need to be handled?
>
> boolean, integer types, floating point types, dates/timestamps,
> strings, XML fragments, selection from limited choices (if 0, say
> "none" -- if 1, say "one" -- if more, say "many"), and objects (which
> are basically .toString() calls unless it has properties that are plain
> old datatypes -- in which case you use the other handlers).
>
> That's what? Seven different formatters? Done. Finished. Do we
> really need a tag library for that? Make them reusable components that
> transformers can use as needed.
>
> 4. Backend processing
>
> We don't like to admit it, but we've all wondered, "What if this custom
> tag could trigger a cache invalidation or do some workflow or..." Bad
> idea. Bad idea. Backend processing in your markup template is a
> horrible idea. Do it in an action or better yet in Flow.
>
> 5. Making programming languages out of markup
>
> <foo:if>, <foo:for-each>, <foo:eval>, etc. Why the foreplay? If
> you're gonna write a programming language, at least have the decency to
> not base it on markup. These aren't really different from saying
>
> <% if (test.isTrue()) { %>
> <foo/>
> <% } %>
>
> or XSP's
>
> <xsp:logic>
> if (test.isTrue()) {
> <foo/>
> }
> </xsp:logic>
>
> IMO constructs like this should be context-dependent on the task at
> hand. For example, wouldn't it have been easier if instead of
>
> <jx:for-each var="person" items="${people}">
> <jx:if test="${person.name != 'Mean Mike'} ">
> <friend>${person.name}</friend>
> </jx:if>
> </jx:for-each>
>
> you had
>
> <friend jx:context="${people}" jx:test="${name != 'Mean
> Mike'}">${name}</friend>
>
> Same thing. Not a programming language though. Data injection
> tailored to the task at hand. This is the problem domain that
> JXTemplateGenerator is made to solve.
>
> What is the for-each doing? Setting a scope -- a context. Look back
> in the templates you've made. How many <jx:if> elements wrapped more
> than one element? I have found in my general usage that well over 90%
> of the time it's just the one child element. And those
> <jx:chose/when/otherwise>... Be honest, how many times have you used
> that for data formatting rather than structural changes to the markup?
> Listing stuff like "yesterday" or "today" or "last week" instead of the
> raw date. That's a boatload of markup to do what amounts to a
> java.text.ChoiceFormat method call.
>
> If it's that complex, why isn't it reflected in your data model instead
> of your markup's wannabe programming language?
>
> 6. Data replacement
>
> And here we come to the meat. This is where the I18nTransformer does
> its magic. This where JXTemplateGenerator does its thing. One hit
> wonders where the markup has been altered to fit the problem at hand,
> not the general definition of a tag library. Where does the following
> I18nTransformer example fit in?
>
> <input type="submit" value="Submit" i18n:attr="value"/>
>
> It can if all it does it translate <foo:i18n-submit/> to the above for
> "real" processing. Stylesheet.
>
> Data injection. That's what custom markup is really good for. It's a
> domain-specific problem. Tag libraries are for general case problems.
> But the general case is already handled by the existing transformers'
> API.
>
>
> -------------------------- o0O0o -------------------------
>
>
> So what are the use cases that require tag libraries? More
> specifically, what are the use cases that require tag libraries that
> will be made cleaner by skipping XSP?
>
> What would I prefer? Keep XSP as it is. It's shite, but it's powerful
> shite. It's for the edge; those pesky corner-cases that refuse to go
> away; the last 1%.
>
> * XSP is Cocoon's mod_rewrite. *
>
> Don't code around mod_rewrite. Let it be the method of last resort.
> Find a model that allows the logic, data structures and code to live
> elsewhere. Leave data injection and formatting to the template
> generator/transformer. Look at Flow and find something like it. Maybe
> not exactly Flow, but a lot closer to it than the world of ASP/PHP/JSP
> and tag libraries.
>
> I would prefer something like
>
> <Cats xmlns:data="http://org.apache/cocoon/data">
> <Cat data:context="${cats}" name="${name}" sex="${sex}" age="${age}"/>
> </Cats>
>
> and/or
>
> <Cats xmlns:data="http://org.apache/cocoon/data">
> <Cat data:context="${cats}">
> <Sex>${sex}</Sex>
> <Name data:test="${name}">${name}</Name>
> <Age data:test="${age != -1}">${age}</Age>
> </Cat>
> </Cats>
>
> I would prefer this to the current situation of
>
> <Cats xmlns:jx="http::">
> <jx:for-each var="cat" items="${cats}">
> <Cat name="${name}" sex="${sex}" age="${age}">
> </jx:for-each>
> </Cats>
>
> or
>
> <Cats xmlns:jx="http::">
> <jx:for-each var="cat" items="${cats}">
> <Cat>
> <Sex>${sex}</Sex>
> <jx:if test="${cat.name != null}">
> <Name>${cat.name}</Name>
> </jx:if>
> <jx:if test="${cat.age != -1}">
> <Name>${cat.age}</Name>
> </jx:if>
> </Cat>
> </jx:for-each>
> </Cats>
>
> Sure, macros can alleviate this. But macros are band-aids on a
> usability/design defect. This talk of macros and tag libraries I think
> has more to do with our frustrations with the current models than
> actual demonstrated need. So instead of a discussion about how the tag
> library API should be defined, why not make the simplest interface for
> the outside world first. And only after that's done, talk about
> implementation details like tag libraries.
>
> Do you logic in a real programming language. When you finish, pass the
> result to the template for styling/formatting.
>
> Or am I alone in these feelings? Pretty interfaces being stuck in the
> middle of big balls of mud!
>
> - Miles Elam
Re: [Design] JXTG 2.0 (Just say you're sorry!)
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Miles Elam wrote:
> First of all, I would like to apologize for my inflammatory tone. My
> ire was directed toward the proposal, not the people proposing it. That
> said, I went over the top. Too many arguments with young Earth
> Creationists lately and it spilled over into my writing on this list.
> To Leszek in particular, I am sorry for the reckless criticism. To
> Stefano, I'm sorry for putting you in the position of agreeing with
> someone who did not conduct himself well.
No hard feelings Mr. Bond :). I am not even half experienced as you all
are and participating in cocoon development is a pure pleasure - even
listening to criticism. I learn from it A LOT.
One thing only to clarify: I am to blame for the commit. But I am not
the creator of the base cocoon-block-template implementation. I just
cleaned up Jonas Ekstedt's work - the credit for the effort goes to him.
> But I have seen taglibs go terribly wrong in real-world situations far
> more often than they've worked out. I'm a firm believer in defining the
> interface first through use cases and only afterward discussing the
> implementation/design. Granted, my primary experience with taglibs is
> JSP's flavor. That may have colored my view of the technology unfairly
> in general.
As I have said in other post: The taglib word may be very dangerous for
whole effort here. I think about this as of the renderers of the model
with no side effects. As for other taglibs - we should not host them in
cocoon distribution to give users bad impression of the direction they
should follow.
ESQL should not be implemented in new template. It has too much side
effect and is a powerful weapon in anti-template camp hands' :)
> Granted, but citing that JXTG is a monolithic headache doesn't mean that
> the deconstruction must be total. Modularization can happen in
> degrees. For example, just by making a common interface between lookup
> libraries (JXPath, JEXL, etc.) would remove HUGE amounts of code from
> JXTG. The switch back and forth between object lookup mechanisms is
> probably the biggest reason for JXTG's complexity.
Sure. But JXTG mainly suffers from the lack of extendibility. You can
see a lot of JXTG hacks in cocoon samples even right now.
There are two hacks that I use for JXTG all the time:
- use a external function (static method, flowscript function) in jxtg
that accepts a bean and xml consumer to generate sax events:
${Packages.com.something.Utils.prettyPrint( bean.value,
cocoon.consumer )}
- use a hash map and a set of macros to handle dynamic tags:
> <jx:set var="tags" value="${java.util.HashMap()}"/>
> <jx:macro name="dynamic-tag">
> <jx:parameter name="id"/>
> <jx:set var="ignored" value="${tags.put(id, macro.body)}"/>
> </jx:macro>
declare a dynamic tag:
> <dynamic-tag id="resultRow">
> <td><a href="/nTer/projectDetails.do?projectId=${project.id}"><b>${project.name}</b></a></td>
> <td>
> <radeox-string value="${project.description}"/>
> </td>
> </dynamic-tag>
later on use it in macro for example:
> <jx:forEach var="${item}" items="${items}" varStatus="status">
> <colouredRow rowNo="${status.index}" odd="floralwhite" even="#eaeaea">
> <jx:eval select="${tags.resultRow}"/>
> </colouredRow>
> </jx:forEach>
*I just found that we promote this hack on cocoon site*:
http://cocoon.apache.org/2.1/userdocs/flow/jxtemplate.html#eval
Both cases indicate that JXTG allows for a great amount of dirty tricks.
The users will use them as long as we do not give them a better tool.
> I'm a big proponent of "make the better decision easier than the worse
> decision." Quick and dirty, ESQL works. For limited obscure cases,
> ESQL is great. But the better decision would be to use object mapping
> (Hibernate, JDO, et al.) and CForms in Flow. Tag libraries seem to me
> to promote an excessive shift of logic to the templating language
> instead of in the backend data processing architecture. Not forcing but
> encouraging people to move as much logic as possible to Flow seems like
> it would allow more flexibility while remaining more maintainable and
> clear. "Clear" not in the sense that the individual template and app is
> understandable but that the hundredth template and app is understandable.
The user should be informed of the danger of mixing the concerns. But
it's his/hers choice to break the rules. Cocoon should promote good
practices not enforce them.
>> For those of us who use CForms it is very convenient to be able to use
>> the template tags together with JXTG constructs.
>>
>> So we need a template generator with three sets of tags "jx:", "esql:"
>> and "ft:" thats it.
>>
>> We also discused how to use a separate conversion layer to remove the
>> need for formating constructs from the template layer.
>
>
> I'm not following. If you are using CForms (and thus Flow), why would
> you make template calls to a database? Why not do the persistence logic
> in Flow right next to where you are sending and receiving form data?
> From a logical point of view, I would think that these would be better
> served next to one another.
The whole conversation got totally polluted with ESQL. Templating is
very useful for CForms dependent on model data. I.e. render the delete
button only if model says you are allowed to invoke that action.
<snip what="even more esql pros and cons"/>
my regards
--
Leszek Gawron lgawron@mobilebox.pl
Project Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [Design] JXTG 2.0 (Just say you're sorry!)
Posted by Torsten Curdt <tc...@apache.org>.
<snip type="a very interesting discussion"/>
..now let me chime in
Having spent quite some time with XSP and ESQL
(and friends) I have to admit: XSP can become a
PITA. But usually because of taglibs (...as
already mentioned in the thread)
The very basic XSP is not much more but using
java as your templating language. Well, the
thing is java and XML just don't mix very well.
...but that's just a question of the syntax.
Yes... I do think that taglibs are the evil
of XSP. The compilation part ...not nice but
more or less depends on how you deal with it.
The good and the bad is that XSP gives the
full power of java. ...full access to every-
thing available in the jvm.
> But is ESQL is the best choice? Data input becomes a big deal when
> you use ESQL for output and then a stream generator combined with
> transformation combined with sqltransformer combined with...
>
> I'm a big proponent of "make the better decision easier than the
> worse decision." Quick and dirty, ESQL works. For limited obscure
> cases, ESQL is great.
Hm... I am wondering what you mean by the big
deal of the input. Fact is that ESQL has some
very unique features. ..that are needed in not
so obscure cases.
I might not be up-to-date with object mapping
frameworks but even if you say that they all
support query time row limitations ...so tables
of a million+ rows are still page-able without
having the data shuffled across the network by
the stupid JDBC driver implementation ...there
still is the question if *you* do the database
design. Mapping to a bad designed database can
be also be no big fun.
Anyway what I was trying to say ...sometimes
SQL can be a very concise syntax for what your
framework might make even more complicated.
Sometimes...
...it just depends!
I think a much bigger problem of ESQL (and also
the SQLTransformer) is the time when the database
processing is happening. ...just too late.
Inside the view ...to bring the MVC up again.
It should better be inside the controller.
Which would be most likely flow. But noone
wants to pollute the flow with SQL statements
(does someone)? ...that's the real beauty of
flow with a relational mapping IMHO.
my 2 cents
--
Torsten
Re: [Design] JXTG 2.0 (Just say you're sorry!)
Posted by Miles Elam <mi...@pcextremist.com>.
First of all, I would like to apologize for my inflammatory tone. My
ire was directed toward the proposal, not the people proposing it.
That said, I went over the top. Too many arguments with young Earth
Creationists lately and it spilled over into my writing on this list.
To Leszek in particular, I am sorry for the reckless criticism. To
Stefano, I'm sorry for putting you in the position of agreeing with
someone who did not conduct himself well.
--------
But I have seen taglibs go terribly wrong in real-world situations far
more often than they've worked out. I'm a firm believer in defining
the interface first through use cases and only afterward discussing the
implementation/design. Granted, my primary experience with taglibs is
JSP's flavor. That may have colored my view of the technology unfairly
in general.
On Dec 2, 2004, at 12:54 PM, Daniel Fagerstrom wrote:
> Let me re-iterate: there have for a long time been a concesus at the
> list among those who have cared enough to discuss it that JXTG is a
> well working way of creating views, but that the implementation is
> very hard to maintain.
Granted, but citing that JXTG is a monolithic headache doesn't mean
that the deconstruction must be total. Modularization can happen in
degrees. For example, just by making a common interface between lookup
libraries (JXPath, JEXL, etc.) would remove HUGE amounts of code from
JXTG. The switch back and forth between object lookup mechanisms is
probably the biggest reason for JXTG's complexity.
In addition, I've had virtual sitemap component possibilities floating
through my head lately. Having a generator like:
<map:generator name="example">
<map:absolutize param="templatename"/>
<map:generate type="file" src="{templatename}.xml"/>
<map:transform type="stx" src="macros.stx"/>
<map:transform type="datainject"/><!-- Yes, I know this doesn't exist
now -->
</map:generator>
This strikes me as doing very much what is expected from taglibs. The
advantages I see are that (a) it's easier for a site administrator to
see at a glance what goes on and (b) keeps things sane from an
implementation standpoint. What do I mean by 'b'? From my experiences
with JSP taglibs, any taglib must either be absolutely self-contained
or fundamentally aware of all other taglibs in use. Mixing them in the
same document blows some assumptions about use out the window in
certain cases. Debugging and reworking them ends up being
fundamentally similar to writing raw code.
Other than for the purposes of mixing logic from different sources
simultaneously and praying they cause no mutual compatibility/state
problems, I don't see the advantage over transformers. In addition, if
attributes were trigger items (attrlibs?), what determines precedence
when there are two different attrlibs at work?
<foo data:bar="action" macro:bar="action"/>
XML parsers are under no obligation to enforce the document order of
attributes. What happens either way? Does data injection happen first
or macro expansion? What if the element is dynamically renamed or
conditional? On the other hand, if you predetermine precedence, what
advantage is there over transformers? Remember, tag apis are no less
code than transformer code. Programming is programming. Only the API
varies.
> There has also been an agreement about that ESQL is the only reason
> (besides back compability) to care about XSP, you said so youself a
> week ago or so.
But is ESQL is the best choice? Data input becomes a big deal when you
use ESQL for output and then a stream generator combined with
transformation combined with sqltransformer combined with...
I'm a big proponent of "make the better decision easier than the worse
decision." Quick and dirty, ESQL works. For limited obscure cases,
ESQL is great. But the better decision would be to use object mapping
(Hibernate, JDO, et al.) and CForms in Flow. Tag libraries seem to me
to promote an excessive shift of logic to the templating language
instead of in the backend data processing architecture. Not forcing
but encouraging people to move as much logic as possible to Flow seems
like it would allow more flexibility while remaining more maintainable
and clear. "Clear" not in the sense that the individual template and
app is understandable but that the hundredth template and app is
understandable.
> For those of us who use CForms it is very convenient to be able to use
> the template tags together with JXTG constructs.
>
> So we need a template generator with three sets of tags "jx:", "esql:"
> and "ft:" thats it.
>
> We also discused how to use a separate conversion layer to remove the
> need for formating constructs from the template layer.
I'm not following. If you are using CForms (and thus Flow), why would
you make template calls to a database? Why not do the persistence
logic in Flow right next to where you are sending and receiving form
data? From a logical point of view, I would think that these would be
better served next to one another.
Regarding an earlier comment that not everyone knows Java but may know
SQL, ESQL is indeed a programming language. Just because it doesn't
use '{' and '}' characters doesn't alleviate that fact. A simple
example of iterating a result set in Java or JavaScript would be as
useful to a newcomer as the equivalent ESQL sample. IMHO of course.
Redirecting via sendPage() on error also strikes me as simpler to grok
and much more flexible than the error handling qualities of ESQL.
Note: I'm not trying to knock ESQL. I'm just saying that I think that
most of the time, I don't think it's the best solution.
> --- o0o ---
>
> Given these general requirements that have been discussed again and
> again at the list and also some more technical, performance driven
> requirments, I steped forward and proposed a possible way of
> implementing it. This design is based on a rather far going SoC in the
> interest of keeping it maintainable. We have also identified a number
> of templateing components that are needed in other places in Cocoon.
> E.g. expression language and object model and therefore are worth
> implementing as separate components. I also proposed implementing the
> three sets of tags discussed above as taglibs instead of making their
> interpretation being part of a huge monolitic SAX event handler as in
> JXTG. Implementing it that way it is must easier to write test code
> for the tags and generally easier to understand what is going on.
Individual tags, yes. What about the interaction of several tag
libraries?
> --- o0o ---
>
> Given this background, I was quite suprised when Miles Elam whent
> ballistic about that I mentioned the word taglib and draw conclsions
> about my intensions that are far and in several cases oposite from
> what I feel and have written anything about.
>
> Anyway, if you have better suggestions about how to solve the above
> requirements I'm all ears.
I was not justified in going ballistic. I should have used a more even
tone. This is not a crusade. It is a technical discussion. I
temporarily lost sight of that. I hope to be more collaborative from
here on.
> --- o0o ---
>
> Now over to commenting what you have written.
>
>> So, my other side thinks that having a scripted controller invoquing
>> different templated views is a better solution.
>> In this case, do we need taglibs at all? no we don't.
>> <esql:query>select * from blah</esql:query> sounds easy enough, but
>> in real life it's more something like
>> <esql:connection>
>> <esql:pool>gump</esql:pool>
>> <esql:execute-query>
>> <esql:query>
>> SELECT name,description FROM projects ORDER BY name
>> </esql:query>
>> <esql:results>
>> <esql:row-results>
>> <li>
>> <a><xsp:attribute
>> name="href">projects?name=<esql:get-string
>> column="name"/></xsp:attribute><esql:get-string column="name"/></a> -
>> <esql:get-string column="description"/>
>> </li>
>> </esql:row-results>
>> </esql:results>
>> </esql:execute-query>
>> </esql:connection>
>> and *THIS IS THE SIMPLES QUERY I CAN THINK OF*!!!
Also note that the example doesn't have strong error handling
capabilities either.
> In the general case I would rather write just the query with some
> surrounding tags like in the SQLTransformer, get a simple standardized
> XML serialization of the row set and then transform it to HTML in
> XSLT. The only difference compared to the SQLTransformer would be that
> I can combine it with JXTG constructions and insert query params in a
> convinient way.
>
> If I would like to do everything in one step as you suggest above it
> might look more like:
>
> <esql:connection>
> <esql:pool>gump</esql:pool>
> <esql:execute-query>
> <esql:query>
> SELECT name,description FROM projects WHERE
> projectleader=${cocoon.request-param.id}ORDER BY name
> </esql:query>
> <esql:results>
> <esql:row-results>
> <li>
> <a href="projects?name=${$row.name}"/>${$row.name}</a> -
> ${$row.description}
> </li>
> </esql:row-results>
> </esql:results>
> </esql:execute-query>
> </esql:connection>
>
> As we are using the same kind of expression template mechanisms as in
> JXTG. We could probably make the syntax more efficient and take away
> some of the tag layers if we feel like that.
What are the advantages over a series of transformers that handle their
specific problem spaces?
>> What I want is something like this:
>> - request comes
>> - sitemap gets it
>> - matcher matches
>> - controller is executed and populates beans in the request context
>> - pipeline is invoqued with access to the request context
>> - response goes
>> Now, this can happen right now in flow and JXtemplate. If we don't
>> need state management, this is just like having a better action model
>> with XSP-like code recompilation.
>
> Sure, I agree with all that. Only question is: where do I put my SQL
> queries in the above scenario?
Flow (the controller) during processing and populating beans in the
request context.
> As said above my only purpose with introducing taglibs is to increase
> maintainability and the ability to test things. Take a look at the
> Cocoon code base. Tons of code that hide what it does beyond all this
> SAX event handling code. If we could refactor away some of that
> intermingling, we would IMO make a step forward.
Complete agreement with the periodic need to refactor. I just question
that taglibs are the solution to the code hiding and intermingling
problems. Referring to the ESQL samples above, I even more strongly
believe this today than I did yesterday. If relational database access
is that hard/lengthy to write, I am inclined to question the technique
rather than the technology used to implement that technique.
Another question: how do you effectively cache templates with tag
library implementations like ESQL? With transformers, they only have
one problem to deal with at a time.
- Miles Elam
P.S. Did I mention yet that I was sorry?
Re: [Design] JXTG 2.0 (Just say yes!)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
peter royal wrote:
> On Dec 4, 2004, at 8:19 AM, Daniel Fagerstrom wrote:
>
>>> With that said, a usable taglib-driven system already exists. Jelly.
>>> If you need taglibs, go with that. No need to re-invent something
>>> different in cocoon.
>>
>>
>> Both I and Carsten have tried to use Jelly in Cocoon but the fit isn't
>> that good. See our posts in
>> http://marc.theaimsgroup.com/?t=109932680200001&r=1&w=2.
>
>
> Ah, I missed that thread :)
>
> I have Jelly working pretty well in Cocoon. You can modify the
> JellyContext to take a Source object and use that to create the
> template. And the templates are thread-safe, its just that each template
> invocation will require a new JellyContext object.
>
> There are a few edges where usages of URL could be replaced with Source,
> but not that many.
>
> The implementation is just a few adapter classes and works great! I'm
> happy to share with anyone interested in pursuing this further.
> -pete
Thanks for your offer, but I've joined the NIH camp, so its to late for
me ;) Furthermore, Jelly doesn't seem like such an active project
anymore. The script compilation is just a part of the project, factoring
out and solidifying contracts for expression handling and other stuff is
at least as important. To me it just didn't seem worthwhile enough to
fight with Jelly's interfaces and implementation to get it to do what I
wanted.
And it also takes time and engagement to convince another community
about adopting your suggestions. I mean its hard enough for me in the
Cocoon community ;) And also you know what we Cocooners think about
basing our core stuff on others code ;)
/Daniel
Re: [Design] JXTG 2.0 (Just say yes!)
Posted by peter royal <pr...@apache.org>.
On Dec 4, 2004, at 8:19 AM, Daniel Fagerstrom wrote:
>> With that said, a usable taglib-driven system already exists. Jelly.
>> If you need taglibs, go with that. No need to re-invent something
>> different in cocoon.
>
> Both I and Carsten have tried to use Jelly in Cocoon but the fit isn't
> that good. See our posts in
> http://marc.theaimsgroup.com/?t=109932680200001&r=1&w=2.
Ah, I missed that thread :)
I have Jelly working pretty well in Cocoon. You can modify the
JellyContext to take a Source object and use that to create the
template. And the templates are thread-safe, its just that each
template invocation will require a new JellyContext object.
There are a few edges where usages of URL could be replaced with
Source, but not that many.
The implementation is just a few adapter classes and works great! I'm
happy to share with anyone interested in pursuing this further.
-pete
Re: [Design] JXTG 2.0 (Just say yes!)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
peter royal wrote:
> On Dec 2, 2004, at 4:47 PM, Stefano Mazzocchi wrote:
>
>> Sure, that's a better syntax, but the fundamental problem remains:
>> template designers don't know nothing about SQL, nor care, nor know
>> anything about request parameters, not know anything about dynamic
>> tags nor know how to debug something in case somebody screws up with
>> the order of those tags!
>
>
> taglibs are *very* useful for applications. a programmer (that may or
> may not have knowledge of how to use tags) can construct a form using a
> tag library.
>
> the constructed document can then be rendered to multiple mediums.. rich
> browser UI, static PDF, tables to XLS, simple HTML for handhelds.
>
> the "template designer" just creates one master template for each output
> medium. a programmer actually writes the implementation of that template.
>
>
> With that said, a usable taglib-driven system already exists. Jelly. If
> you need taglibs, go with that. No need to re-invent something different
> in cocoon.
Both I and Carsten have tried to use Jelly in Cocoon but the fit isn't
that good. See our posts in
http://marc.theaimsgroup.com/?t=109932680200001&r=1&w=2.
/Daniel
Re: [Design] JXTG 2.0 (Just say yes!)
Posted by peter royal <pr...@apache.org>.
On Dec 2, 2004, at 4:47 PM, Stefano Mazzocchi wrote:
> Sure, that's a better syntax, but the fundamental problem remains:
> template designers don't know nothing about SQL, nor care, nor know
> anything about request parameters, not know anything about dynamic
> tags nor know how to debug something in case somebody screws up with
> the order of those tags!
taglibs are *very* useful for applications. a programmer (that may or
may not have knowledge of how to use tags) can construct a form using a
tag library.
the constructed document can then be rendered to multiple mediums..
rich browser UI, static PDF, tables to XLS, simple HTML for handhelds.
the "template designer" just creates one master template for each
output medium. a programmer actually writes the implementation of that
template.
With that said, a usable taglib-driven system already exists. Jelly. If
you need taglibs, go with that. No need to re-invent something
different in cocoon.
For document-centric production, sure, what's your fighting against is
totally valid. But taglibs have their place too (even if the idea may
be used in inappropriate places)
-pete
Re: [Design] JXTG 2.0 (Just say yes!)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Stefano Mazzocchi wrote:
> Daniel Fagerstrom wrote:
>
>> Stefano Mazzocchi wrote:
>>
>> Let me re-iterate: there have for a long time been a concesus at the
>> list among those who have cared enough to discuss it that JXTG is a
>> well working way of creating views, but that the implementation is
>> very hard to maintain.
>
> Fair enough. A template language has nothing to do with taglibs, per se.
>
>> There has also been an agreement about that ESQL is the only reason
>> (besides back compability) to care about XSP, you said so youself a
>> week ago or so.
>
> After using it for a little while, I changed my mind. :-)
Ok
>> For those of us who use CForms it is very convenient to be able to
>> use the template tags together with JXTG constructs.
>
> I believe the best template system does not use tags at all. It either
> uses content (as in velocity) or it uses attributes (as in tapestry).
In our previous discussion at the list our conclusion was that JXTG is
ok and that although there might be slightly "better" approaches or
ideas in one way or another, the general feeling was that it would be
better to evolve from JXTG than to do something completely different. We
must protect our users investments in Cocoon technology. Of course we
should do new and revolutionary stuff when we find a much better way of
doing things. But that something is slightly better is not a good enough
reason, IMO.
Having said that, I'm happy to keep the template framework open enough
to make it possible to plug in an attribute driven approach or parsers
for content driven approaches. It should be quite easy to do that AFAIK.
Now, these are no itches that I have, but if you or some one else come
upp with a design proposal for such a template language, I can take part
in adapting the framework for it.
<snip/>
>> In the general case I would rather write just the query with some
>> surrounding tags like in the SQLTransformer, get a simple
>> standardized XML serialization of the row set and then transform it
>> to HTML in XSLT.
>
> That works only for trivial monolythic cases. For any serious
> reporting application (for example, where order is parameter
> dependable) that doesn't work.
I assumed the context of the having both SQL and JX tags in the
generator step, then you can do serious reporting. I even happen to know
that, as I and my coleagues have done serious repporting in numerous
applications for a number of years in that way.
>> The only difference compared to the SQLTransformer would be that I
>> can combine it with JXTG constructions and insert query params in a
>> convinient way.
>
> This is exactly the point that makes me say "just say no to taglibs"
> because, as I explained before, no matter what syntax, putting query
> parameters in a SQL string is not something that should be in a template!
Ok, I start to realize that you assume that I suggest that everything
should be done in the template step. No I don't, I do what you refer to
as the controler concern, i.e. put together and execute the SQL query
based on request params in the template. All view related stuff is done
in the next step, typically XSLT.
<snip/>
> Sure, that's a better syntax, but the fundamental problem remains:
> template designers don't know nothing about SQL, nor care, nor know
> anything about request parameters, not know anything about dynamic
> tags nor know how to debug something in case somebody screws up with
> the order of those tags!
>
> let me rewrite the above:
>
> controller.script:
>
> var query = "SELECT name,description " +
> "FROM projects " +
> "WHERE project= " + request.id +
> "ORDER BY name ";
> var results = cocoon.datasources.gump.execute(query);
> request.context.set("projects",results);
>
> view.template (content style):
>
> <ul>
> #foreach project in projects
> <li><a href="projects?name=${project.name}">${project.name}</a> -
> ${project.description}</li>
> #end
> </ul>
>
> or view.template (attribute style):
>
> <ul x:foreach="project in projects">
> <li><a href="projects?name=${project.name}">${project.name}</a> -
> ${project.description}</li>
> </ul>
>
> note how SoC also allows you to use a different technology (example,
> O/R or straight OODBMS or even RDF triple stores!) to populate the
> beans without the template designers know anything about this!
>>> What I want is something like this:
>>>
>>> - request comes
>>> - sitemap gets it
>>> - matcher matches
>>> - controller is executed and populates beans in the request context
>>> - pipeline is invoqued with access to the request context
>>> - response goes
>>>
>>> Now, this can happen right now in flow and JXtemplate. If we don't
>>> need state management, this is just like having a better action
>>> model with XSP-like code recompilation.
>>
Concerning SoC I agree completely, It is a good idea to separate the
query composition and execution from the result set rendering, I have
always done it that way and have never recomended anyone to mix them.
Concerning writing code for query composition and execution in an action
variant of flowscript I also agree :), I think that its better than
doing it in a generator step.
So why are we not allready doing that? Booth allow the use of
flowscripts as actions (after having inactivated web continuations) and
providing DB functions for flowscripts have been discussed a number of
times at the list. And every time a number of committers (you included),
have explained (for both of the ideas) that: its not needed, its mix of
concern and it is generally bad practice.
If you succeed in convincing the community that (flow)script actions and
flowscript support for DB is ok, and should be our "official
recomendation" for db reporting stuff, I have no need for SQL-tags
anymore. Until that happens they fill a clear need.
<snip/>
> No, not only that: I think that the person responsible for doing
> writing the logic that drives the flow *and* the content population of
> the page is *NOT* the same person that does the design of the template.
>
> Taglibs force template designers to do the job of content population
> or force two different people to work on the same file.
Let me tell a story from real life. I and some others have worked hard
on enforcing SoC, enterprise design patterns and generally layered
designs in all our projects. That have been excelent for ensuring the
success for larger project. But a less excelent side effect is that a
number of people who was quite productive in small projects using php
and the like have become very frustrated over the, in their view, overly
abstract way of doing things. And a few of them even hate Cocoon based
on that.
My conclusion from this is that its counter productive and destructive
to force people to follow your own rigid idea about the "ideal" SoC. Do
simple things in simple ways. If the project grows, introduce the needed
design and refactor.
> In both cases, they are suboptimal from what I wrote above, where
> content population and content presentation are kept completely
> isolated and the only contract between the two is:
>
> 1) the shape of the objects in the context
> 2) how to perform simple variable espansion, list iteration and
> conditioning.
We also need recursive application of named templates, othewise you
cannot render menu trees, folders and the like.
<snip/>
> One concern is to come up with a unified template language. This implies:
>
> 1) understanding the features we want (and we don't want!) from a
> template language
> 2) come up with a syntax
> 3) implement it
>
> Another and completely separate concern is how to factor out existing
> bits so that #3 is easier.
>
> You are attacking #3 before attacking #1 and #2 and that's why
> everybody here is feeling frustration: there is no consensus on #1 and
> #2 so attacking #3 now is more harmful than useful.
We went over #1 and #2 a number of times at the list, and the design
this far is based on the results of these discussions, and every design
issue has been repported at the list and in some cases discussed. Please
resarch the archives, if you doubt it.
When you wrote the letter that I'm responding to, you and Miles where
the only ones that had expressed any frustration at all. Now everybody
are frustrated, it says something interesting about mail list dynamic
doesn't it.
Anyway we can take a new itteration with #1 and #2 if you and others
feel like that. Please write an RT where you give more details about
your view.
/Daniel
Re: [Design] JXTG 2.0 (Just say yes!)
Posted by Sylvain Wallez <sy...@apache.org>.
Stefano Mazzocchi wrote:
> Leszek Gawron wrote:
>
>> Jonas Ekstedt wrote:
>>
>>> I think the reason for taglibs are that rendering an object is often
>>> more complicated than simply outputting a value. For example, suppose
>>> you want to render a calendar covering the current month. This is a
>>> typical component that would lend itself well as a tag class. The
>>> template writer would simply do:
>>>
>>> <calendar:month current-date="${myDate}"/>
>>>
>>> The tag might output something like this:
>>>
>>> <month value="2">
>>> <week value="12">
>>> <day value="5" name="Monday"/>
>>> <day value="6" name="Tuesday" current="true"/>
>>> <day value="7" name="Wednesday"/>
>>> ...
>>> </week>
>>> ...
>>> </month>
>>>
>>> Later transformations would transform it into a table or whatever. This
>>> type of calendar would be very hard to do for a template author without
>>> the help of a tag library.
>>
>>
>> I have completely no time these days so I was just waiting for the
>> single post to say: Cannot agree more here :)
>
>
> I cannot disagree more.
>
> ${myDate as month}
>
> will do the above without mentioning tags (and will be much more
> Dreamweaver-friendly).
Hehe, this is exactly what I outlined in my "What do we need taglibs
for?" post. The fight is merely about tags vs brace-expansion syntax,
but not about the underlying feature.
<snip/>
>> * wiki renderers
>> currently I do something like to parse wiki syntax:
>>
>>> function radeoxToSAX( str, consumer ) {
>>> var radeoxStr = radeoxEngine.render( str, radeoxContext );
>>> var buffer = new java.lang.StringBuffer("<root>" );
>>> buffer.append( radeoxStr )
>>> buffer.append( "</root>" );
>>> var is = new Packages.org.xml.sax.InputSource( new
>>> java.io.StringReader( buffer.toString() ) );
>>>
>>> var parser = null;
>>> var includeConsumer = new
>>> org.apache.cocoon.xml.IncludeXMLConsumer( consumer, consumer );
>>> includeConsumer.setIgnoreRootElement( true );
>>> try { parser = cocoon.getComponent(
>>> Packages.org.apache.excalibur.xml.sax.SAXParser.ROLE );
>>> parser.parse( is, includeConsumer ); } finally {
>>> if ( parser != null ) cocoon.releaseComponent( parser );
>>> }
>>> }
>>
>>
>> <jx:macro name="radeox-string">
>> <jx:parameter name="value"/>
>> <jx:set var="ignored" value="${cocoon.session.radeox( value,
>> cocoon.consumer )}"/>
>> </jx:macro>
>
>
> OH COME ON! you can do a generator and cinclude a subpipeline for that.
Or ${wikistring as radeox} :-)
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 say yes!)
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Leszek Gawron wrote:
> Stefano Mazzocchi wrote:
>> ${bean.startDate as YYYY-MM-DD}
>
> Sure. Still I would like to render my date specially if the date is
> before some point in time. My syntax would be:
>
> <dateutils:pretty-enhanced-date value="${bean.startDate}"
> turning-point="2004-01-01"/>
>
> This way I can achieve same formatting across the whole project.
In the replying-to-hard-topic-stress(tm) I forgot about the question:
How would you pass additional parameters? Or maybe you are considering
it harmful?
--
Leszek Gawron lgawron@mobilebox.pl
Project Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [Design] JXTG 2.0 (Just say yes!)
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Stefano Mazzocchi wrote:
> Leszek Gawron wrote:
>
>> Jonas Ekstedt wrote:
>>
>>> I think the reason for taglibs are that rendering an object is often
>>> more complicated than simply outputting a value. For example, suppose
>>> you want to render a calendar covering the current month. This is a
>>> typical component that would lend itself well as a tag class. The
>>> template writer would simply do:
>>>
>>> <calendar:month current-date="${myDate}"/>
>>>
>>> The tag might output something like this:
>>>
>>> <month value="2">
>>> <week value="12">
>>> <day value="5" name="Monday"/>
>>> <day value="6" name="Tuesday" current="true"/>
>>> <day value="7" name="Wednesday"/>
>>> ...
>>> </week>
>>> ...
>>> </month>
>>>
>>> Later transformations would transform it into a table or whatever. This
>>> type of calendar would be very hard to do for a template author without
>>> the help of a tag library.
>>
>>
>> I have completely no time these days so I was just waiting for the
>> single post to say: Cannot agree more here :)
>
>
> I cannot disagree more.
>
> ${myDate as month}
>
> will do the above without mentioning tags (and will be much more
> Dreamweaver-friendly).
Sure - but - isn't this only a change at syntax level?. You are
describing a convertor here - something that has been discussed a few
threads before and what Jonas implemented as
#{myDate#full}.
>
>>> The current discussion about taglibs have focused very much on esql and
>>> whether SQL belongs in templates or not. I agree that SQL in templates
>>> are a bad idea, but that is really beside the point in regards to the
>>> virtues of taglibs.
>>
>>
>> Exactly. Everyone concentrated on ESQL as a taglib while this is the
>> WORST example there is. ESQL does a lot of persistence logic and can
>> have enormous side effects. Taglibs should have no side effects at all.
>
>
> excuse me? what side effect does a SELECT have?
these:
<esql:query>insert into task values ( something, something ); select
@@identity</esqu:query>
still a select from template point of view.
>>> Taglibs (in my view) are primarily about converting
>>> objects to SAX.
>
>
> If this is the case, then "taglib" is a *VERY BAD* name. I agree that
This mainly is the case. At least for me.
> some objects might be "sax-ified" differently, depending on user needs,
> but the name "taglibs" makes the syntactic and the semantic concern
> overlap and annoys people (like me) that ended up hating dynamic XML
> tags after promoting them for so long.
>
>> Here are a few ideas for taglibs that only deals with
>>
>>> presentation of objects (as opposed to esql which also populates).
>>>
>>> * Bean renderers
>>
>>
>> <jx:set var="ignored"
>> value="${Packages.com.something.DateUtil.emitPrettyDate(
>> bean.startDate, cocoon.consumer"/> - is this one better than the
>> taglib? Or should I implement a stylesheet that would parse my 100kB
>> xml file just to look for <dateutils:prettydate value="2003-01-01"/> ?
>
>
> I completely agree that the transformation stage is overkill, that's not
> my point.
>
> I think that better than both you can do
>
> ${bean.startDate as YYYY-MM-DD}
Sure. Still I would like to render my date specially if the date is
before some point in time. My syntax would be:
<dateutils:pretty-enhanced-date value="${bean.startDate}"
turning-point="2004-01-01"/>
This way I can achieve same formatting across the whole project.
>
>>> * DOM renderers
>
>
> excuse me?
not going to defent examples that I did not give. Jonas? :)
>
>>> * ResultSet renderers (ie renders a query made in flow)
>
>
> are you kidding? regular iteration is all you need.
agree here
>
>>> * Menus * Page navigation * Tabs (similar to tabs in CForm)
>
>
> what?
Jooonas? :))
>> * wiki renderers
>> currently I do something like to parse wiki syntax:
>>
>>> function radeoxToSAX( str, consumer ) {
>>> var radeoxStr = radeoxEngine.render( str, radeoxContext );
>>> var buffer = new java.lang.StringBuffer("<root>" );
>>> buffer.append( radeoxStr )
>>> buffer.append( "</root>" );
>>> var is = new Packages.org.xml.sax.InputSource( new
>>> java.io.StringReader( buffer.toString() ) );
>>>
>>> var parser = null;
>>> var includeConsumer = new
>>> org.apache.cocoon.xml.IncludeXMLConsumer( consumer, consumer );
>>> includeConsumer.setIgnoreRootElement( true );
>>> try { parser = cocoon.getComponent(
>>> Packages.org.apache.excalibur.xml.sax.SAXParser.ROLE );
>>> parser.parse( is, includeConsumer ); } finally {
>>> if ( parser != null ) cocoon.releaseComponent( parser );
>>> }
>>> }
>>
>>
>> <jx:macro name="radeox-string">
>> <jx:parameter name="value"/>
>> <jx:set var="ignored" value="${cocoon.session.radeox( value,
>> cocoon.consumer )}"/>
>> </jx:macro>
>
>
> OH COME ON! you can do a generator and cinclude a subpipeline for that.
OH COME ON! :) Transformation to pretty print a date is an overkill.
CInclude for string pretty printing is not?
Moreover imagine you have a simple table:
| project name | project description |
there are 100 rows out of which every description is wikified. that
means 1 generator for the template and 1 for each description. Total 101
generators invoked. Neat.
>
>> <snip/>
>>
>> <radeox-string value="${project.description}"/>
>> This clearly is a hack and should be implemented as taglib.
>
>
> You will have to step on my dead body before that's the case.
${project.description as radeox-string} would be any better?
>
>> * ValueList renderers
>> a taglib that supports displaying a narrowed list of values,
>> searchable, paginable and so on
>>
>>> The items above are in my view better examples of the benefits of
>>> taglibs. They're all about how to render an object. The object is
>>> populated in flow but how to render it is implemented in the tag
>>> classes.
>>
>>
>> Maybe we should stop using "taglib" word. What we're trying to do may
>> simply be harmed by the emotions that this phrase carries.
>
>
> No matter what you call it, if you want to have dynamic XML tags, you
> will hurt yourself, your wiki example is the kind of things that gives
> me the creeps.
The dynamic tags in my use case are used for data injection. Could be as
well rendered by a stylesheet and just as in previous cases I won't do
it for reasons I outlined above.
My regards
PS. Please do not take is as fighting back. Out of my small experiences
these are real use cases where I needed convertors and advanced macros
badly. If I am wrong just show me a better way.
--
Leszek Gawron lgawron@mobilebox.pl
Project Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [Design] JXTG 2.0 (Just my opinion)
Posted by Glen Ezkovich <ge...@mac.com>.
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)
Posted by Ralph Goers <Ra...@dslextreme.com>.
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)
Posted by "Roy G. Biv" <mi...@pcextremist.com>.
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)
Posted by Ralph Goers <Ra...@dslextreme.com>.
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)
Posted by "Roy G. Biv" <mi...@pcextremist.com>.
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)
Posted by Stefano Mazzocchi <st...@apache.org>.
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)
Posted by "Roy G. Biv" <mi...@pcextremist.com>.
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: [Design] JXTG 2.0 (Just my opinion)
Posted by Bertrand Delacretaz <bd...@apache.org>.
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
Re: [Design] JXTG 2.0 (Just my opinion)
Posted by "Roy G. Biv" <mi...@pcextremist.com>.
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)
Posted by Sylvain Wallez <sy...@apache.org>.
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 (generator and transformer, same template syntax?)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 6 déc. 04, à 10:10, Daniel Fagerstrom a écrit :
<big-snip cause="fully agree"/>
> ...BTW: I'm becoming more and more worried about the attribute
> template sytax that you used in your examples ;)
I hope the syntax in my examples is so bad that people just dismiss it
and focus on the rest of the story ;-)
-Bertrand
Re: [Design] JXTG 2.0 (generator and transformer, same template syntax?)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Bertrand Delacretaz wrote:
...
> Advantages:
...
I agree with your motivation. I would also like to add that when we have
introduced a separate formating layer and enforced side effect free
templates, the conceptual difference between transforming XML input in a
transformer and reading from, e.g. a rowset in a template generator,
will be quite small. In both cases we have read only access to tree
structured data.
Of course can we use different languages in generation and
transformation if there are important conceptual differences, but I fail
to see them and need more motivation and examples to understand why
having the same language would be bad rather than an advantage. But I'm
one of thoose people who regulary use XSLT as generator so I might not
understand what is best for my own good anyway ;)
For those who has been concerned of that I'm (and others) are trying to
introduce to much flexibility in templates (I'm not only talking with
you Stefano ;) ), I would like to stress that I'm serious about
forbiding side effects in templates. And this is a quite severe
restriction in what you can do in templates. As far as I'm able to
influence it, JXTG2 will _not_ contain the jx:set instruction. We can
have an jx:let instruction for giving a local name for something, but no
assignment. Before anyone got upset, we will of course have a JXTG1 back
compability mode. But by taking away the side effects we can do some
fairly radical optimizations in the pipeleine processing. It also
enforces the "correct" SoC between view and control.
> Disadvantages:
> D1) The XYZTransformer is probably slower than a well-written XSLT
> transform. But it's also much faster than the XSLT transform that Bob
> tried to write. He's only been doing XSLT for four weeks and just
> plain hates it.
This is purely at the RT stage: But by writing our own transformer we
can actually use some pull driven lazy evaluating methods in the
transformer (this should trigger an alarm in Peter Hunsberger's mail
filter ;) ), that allow for really radical optimizations.So we could
actually end up with something that is much more efficient than
conventional XSLT implementations. But it requires side effect free
pipelines.
> D2) The XYZTransformer is a memory hog on large documents, as it loads
> the document in memory so that the expression evaluator can process it
> easily (AFAIK the current XSLT processors do the same in many cases,
> however, so this might not really be a problem).
AFAIK current XSLT processors buffers input in all cases. With our own
transformer we can do much better.
> D3) Why so many steps? Generating XHTML directly could have saved
> some. But it doesn't help for RSS or WAP/WML, and the generation is
> actually much more complicated than what we see here, as configuration
> files and site menu definitions need to be aggregated in the page,
> with different variants depending on the final presentation target.
IMHO, the number of steps should depend on the result from ones analysis
of what concern area that are involved in the problem area at hand,
rather on some predefined idea about that an pipeline _always_ should
consist of one generator, one transformer and one serializer.
<snip/>
> XSLT is *the* stumbling block today,
Yes, many people hate it.
--oo--
BTW: I'm becoming more and more worried about the attribute template
sytax that you used in your examples ;)
/Daniel
Re: [Design] JXTG 2.0 (generator and transformer, same template syntax?)
Posted by Stefano Mazzocchi <st...@apache.org>.
Roy G. Biv wrote:
> I'm almost afraid to bring this up since I'm coming from a point of view
> where I actually like XSLT. Yes, I'm one of *those* people. ;-)
>
> But when I saw this:
>
>> Bertrand Delacretaz wrote:
>>
>>> Then, Bob, who's in charge of the final presentation, writes another
>>> template to convert this logical document to, say, "lightweight
>>> HTML", for an embedded terminal (no CSS). This gets processed by the
>>> XYZTransformer, which uses the same template and expression engines,
>>> and the same syntax as the XYZGenerator (again, don't worry about
>>> syntax details):
>>>
>>> <html>
>>> <head><title>${page/title}</title></head>
>>> <body>
>>> <table>
>>> <tr tl:iter="p in page/person-list">
>>> <td>${p/name}</td>
>>> <td>${p/age}</td>
>>> </tr>
>>> </table>
>>> </body>
>>> </html>
>>
>>
>
> Aside from missing the "tl" namespace declaration, I was curious if
> people are keeping in mind that the equivalent XSLT stylesheet is:
>
> <html xsl:version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
> <head><title><xsl:value-of select="page/title"/></title></head>
> <body>
> <table>
> <xsl:for-each select="page/person-list">
> <tr>
> <td><xsl:value-of select="name"/></td>
> <td><xsl:value-of select="age"/></td>
> </tr>
> </xsl:for-each>
> </table>
> </body>
> </html>
>
> This is an XSLT 1.0 literal result element as stylesheet.
> (http://www.w3.org/TR/xslt#result-element-stylesheet)
>
> I wanted to point out that XSLT can be used in the same (procedural)
> model as is being proposed in the two-step template models. More
> elements and fewer dollar signs though. It also leaves the door open
> for more complex transformations if needed (using full XSLT) and allows
> the documentation load to be distributed by other projects. That and
> XSLT transformers have already been performance tuned.
>
> Don't get me wrong, I like the attribute syntax as much as the next guy.
>
> Just saying...
Yes, we are aware of this. It does feel askward, to be honest, to have
an XSLT generator, some groups really should buy my FS alarms ;-)
[Bertrand, I just built a new one, and it's way more sensible and
resistent too, and recharges itself when spots signs of FS... it will
never run out of batteries overhere ;-)]
--
Stefano.
Re: [Design] JXTG 2.0 (generator and transformer, same template syntax?)
Posted by "Roy G. Biv" <mi...@pcextremist.com>.
I'm almost afraid to bring this up since I'm coming from a point of view
where I actually like XSLT. Yes, I'm one of *those* people. ;-)
But when I saw this:
> Bertrand Delacretaz wrote:
>
>> Then, Bob, who's in charge of the final presentation, writes another
>> template to convert this logical document to, say, "lightweight
>> HTML", for an embedded terminal (no CSS). This gets processed by the
>> XYZTransformer, which uses the same template and expression engines,
>> and the same syntax as the XYZGenerator (again, don't worry about
>> syntax details):
>>
>> <html>
>> <head><title>${page/title}</title></head>
>> <body>
>> <table>
>> <tr tl:iter="p in page/person-list">
>> <td>${p/name}</td>
>> <td>${p/age}</td>
>> </tr>
>> </table>
>> </body>
>> </html>
>
Aside from missing the "tl" namespace declaration, I was curious if
people are keeping in mind that the equivalent XSLT stylesheet is:
<html xsl:version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<head><title><xsl:value-of select="page/title"/></title></head>
<body>
<table>
<xsl:for-each select="page/person-list">
<tr>
<td><xsl:value-of select="name"/></td>
<td><xsl:value-of select="age"/></td>
</tr>
</xsl:for-each>
</table>
</body>
</html>
This is an XSLT 1.0 literal result element as stylesheet.
(http://www.w3.org/TR/xslt#result-element-stylesheet)
I wanted to point out that XSLT can be used in the same (procedural)
model as is being proposed in the two-step template models. More
elements and fewer dollar signs though. It also leaves the door open
for more complex transformations if needed (using full XSLT) and allows
the documentation load to be distributed by other projects. That and
XSLT transformers have already been performance tuned.
Don't get me wrong, I like the attribute syntax as much as the next guy.
Just saying...
- Miles Elam
Re: [Design] JXTG 2.0 (generator and transformer, same template syntax?)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 7 déc. 04, à 00:41, Stefano Mazzocchi a écrit :
> Bertrand Delacretaz wrote:
>
...
>> -oo-
>> Advantages:
>> A1) There's only one implementation of the template and expression
>> evaluation mechanisms.
>
> Ok
>
>> A2) Bob can ask Alice for help with the templates, she knows them in
>> and out as that's what she's using as well.
>
> Fair enough.
>
>> A3) Bob, coming from a ColdFusion/ASP/PHP background, quickly became
>> productive with the template language, which looks familiar. In a
>> pinch, he can ask the trainee to make minor changes in DreamWeaver,
>> in fact they saved a bunch by doing the prototype in this way.
>
> Again, fair enough.
>
>> A4) The XML logical document will "never" change once it's done, as
>> it contains all the data in presentation-independent format. Write
>> it, test it, forget about it. Alice doesn't want the critical parts
>> of their system to change too often.
>
> Yes, good strategy. It also allows this stage to be reused for another
> channel (say RSS feeds and the like).
>
>> A5) The XML logical document can be reused to publish the RSS feed,
>> the mobile WAP/WML version, the full-blown XHTML/CSS version, without
>> bothering Alice who's a busy and expensive person.
>
> Damn, should read all of it before replying ;-)
>
>> A6) Alice doesn't have to deal with the final customer who's always
>> asking for "just a small change in the page layout". She leaves this
>> to Bob for now, but they've considered training the customer to do
>> this on his own, the templates are simple and isolated enough that he
>> couldn't break anything anyway.
>
> Right.
>
> I have to say, as much as you arguments are convincing A4/A5/A6 are
> simply indicating why pipelines are useful, not why a common syntax
> between a generator and a transformer is ;-)
Ok, but A6 is also a strong argument for having a *simple to use*
template mechanism that can be used for presentation stuff.
> ...Your point (and interestingly enough Miles') is that having the
> same syntax for generation and transformation allows for A2 and A3...
Yes, and also - this is very important - a *single implementation* for
both of Alice's and Bob's concern. One set of tests, one set of docs,
big savings overall. You just said OK to A1 but for me it's "great -
big savings" ;-)
> ....My point is not if it's a good thing, my question is: can it be
> achievable without reinventing XSLT/STX and therefore without coming
> across with the same problems that it has and making it ackward to use
> for one side because we forced it to be the same on the other side?..
Very true. I believe it is doable *with some limitations*.
If the new template language covers 95% of the use cases, we still have
XSLT and custom (java) generators for the remaining 5%. Me, I *love*
XSLT for complex stuff that deserves using it, but it took me a while
to really grasp it.
The new template language just needs to be good enough to enable the
Alice and Bob scenario in common cases, no need to cover everything, as
there are alternatives for the really complex cases.
>> Disadvantages:
>> D1) The XYZTransformer is probably slower than a well-written XSLT
>> transform. But it's also much faster than the XSLT transform that Bob
>> tried to write. He's only been doing XSLT for four weeks and just
>> plain hates it.
>
> :-)
>
> Fair enough. But really, here your real point is that XSLT is painful
> and I can't agree more. But do you really think we can come up with
> something that doesn't end up looking just like STX?
I think so - if we take TAL [1] as an example (for the available
operations, I don't care about the syntax details at this point), I
don't see anything missing, knowing that the pipeline is meant to start
with Flowscript where you can prepare data if needed to make things
easier.
>> ...D4) Bob was initially confused about this generator/transformer
>> thing, why both? Alice told him not to worry, generators are not his
>> business anyway, he's only a Cocoon Transformer Template Designer
>> (but a good one after only four weeks here). He'll understand when he
>> grows up ;-)
>
> Sure, but the question is: once the syntax starts to get ugly for both
> because of changes we made to the language that make sense only on
> transformation and not on generation, would it still be the case?
>
> remember that the generation stage has a scripted population stage
> first, the transformation stage does not!...
Not sure what you mean by scripted population stage. In both cases we
need iterations, if statements and output/formatting expressions,
anything more?
Do you see anything missing in Daniel's proposal at
http://wiki.apache.org/cocoon/AttributeTemplates ? I see stuff that we
might not need (for loops maybe), but nothing missing IMHO.
>> ... -oo-
>> So, what's wrong with this? Where's the FS?
>
> The FS is in what I wrote above: it would be *nice* to have a *simple*
> language that was able to do both, but I've seen many people trying
> and failing because the details make it look ugly fast, and if you
> make it prettier for one stage you make it uglier for the other.
>
> But you are right on one thing: I should not criticize before having
> seen such a language ;-)
Agreed. Given the energy poured into this recently, it looks like we're
not far from an actual implementation. Then we can see how nice or ugly
it looks in the Alice/Bob scenario.
>
>> ...I might be overlooking something but this could pave a much easier
>> path for people to jump into Cocoon and *stay*, not run away scared
>> by XSLT.
>
> As I said previously, I very much agree that we need an easier (read:
> simpler and non turing-complete) xml transformation language,
> something that was more procedural than declarative...
Good, /me happy. I'd just add that it must not look like a language,
but like *page-based templates*. Makes a big difference for people
coming from "dynamic web publishing tools" country. We must get people
to write XML transformations without knowing it ;-)
> ...Whether or not this needs to use the exact same syntax of the
> template system is yet to be decided...
Right, but as we seem to agree that having the same syntax and more
importantly sharing components is a plus, we should keep this in the
back of our collective mind in the design discussions.
> BTW, this whole discussion reminds me of DVSL:
>
> [http://jakarta.apache.org/velocity/dvsl/users-guide.html]...
Hmmm...IIUC DVSL uses the same "event template" model as XSLT, which
confuses many people. Moving to a "page template" model makes the
transformation process much more natural for people, although it won't
cover all transformation cases. But XSLT is still there when we need
it.
>> ...XSLT is *the* stumbling block today, and IMHO we don't have a good
>> alternative to suggest. I don't mean to reinvent it, but as people
>> are working on improved templates anyway, this looks like a cheap but
>> very welcome addition.
>
> All right, I rest my case: I'll see what we can come up with, but I
> hope that you guys are able to cut the rope between the generator and
> the transformer if it gets ugly enough...
Good, something to keep in mind: same generator/transformer template
syntax would be good if it's not too costly in terms of implementation
and "language coolness".
-Bertrand
[1] http://www.zope.org/Wikis/DevSite/Projects/ZPT/TAL
[RT] MVC Contexts (Was Re: [Design] JXTG 2.0 (generator and transformer,
same template syntax?))
Posted by "Roy G. Biv" <mi...@pcextremist.com>.
This one is long folks. Sorry, can't be helped.
Sylvain Wallez wrote:
> Stefano Mazzocchi wrote:
>
>> Sure, but the question is: once the syntax starts to get ugly for
>> both because of changes we made to the language that make sense only
>> on transformation and not on generation, would it still be the case?
>>
>> remember that the generation stage has a scripted population stage
>> first, the transformation stage does not!
>
> I don't see this distinction: if you look at the global processing
> chain, there is always a population stage in front of the template
> engine:
>
> 1/ template as a generator
>
> +------------+ +-----------+
> + Flowscript |--(objects)-->| Template |----> ...
> + data | | generator |
> +------------+ +-----------+
> ^
> |
> Template file
>
> 2/ template as a transformer
>
> +-----------+ +-------------+
> | Generator |--(xml data)-->| Template |----> ...
> | | | transformer |
> +-----------+ +-------------+
> ^
> |
> Template file
>
> Where is the difference? The template lays out some data. In the case
> of the generator, it's controller-provided data, in the case of the
> transformer, it's pipeline-produced data. Note that is not limited to
> a generator, but can also be aggregation, prior transformation, etc,
> or even some preliminary processing of some controller-provided data.
>
> <snip/>
Is this indeed the case? The flow data is, strictly speaking in this
case, the model? The template *may or may not* follow the flow data
structure closely. In fact, the flow data is merely a hint or an
indicator. The template file has the final say on the data structure.
You can send the exact same flow data via sendPage* to two different
JXTG template pipelines and get functionally different XML structures
(depending on which objects are accessed and how).
MVC contexts. That's my new buzzword for the day.
When you pull an RSS feed from another site for inclusion in your own
site, what is that RSS feed to you? A model right? But to the remote
site, the RSS is a view (to a remote database for example), not a
model. It's the final form for others to use. But it's still RSS data
isn't it? How can it be both a model and a view? Because it's used in
a different context. The web browser is the same thing. To Cocoon,
HTML is absolutely the view. But to a web browser, it's the model. The
HTML renderer+CSS is the view, and the client-side Javascript is clearly
the controller. Isn't this all true and MVC is actually dependant upon
the scope of the problem at hand.
In a high-level view of Cocoon, the model is the object model (Hibernate
et al.), the view is the pipeline, and the controller is Flow. But what
is a generator in a pipeline? The model? But the model from Cocoon
came from Flow? But the pipeline is under no obligation to use that
data from Flow. It can use a subset of that data, iterate a data
structure multiple times or ignore the data altogether. In addition, it
has access to data that Flow didn't give it (Actions).
So while it is the view for Cocoon at large, it is in fact it's own MVC
context that grabs data as needed just as a client-side Javascript can
grab updated information from the server without refreshing the main
page (GMail). Who decides if that data is to be used? The pipeline
logic as controller. (Ack!) The generator determines which template to
use. In the case of JXTG, it loads the template file *and* injects
data. The difference between displaying a template file raw or with
data is the choice of pipeline components in the sitemap, not Flow.
Flow can only produce it's "view" of the working data set and request a
particular pipeline that presumably would put that data structure to
good use. The pipeline is the controller here.
A browser makes separate requests for the HTML, Javascript files and CSS
stylesheets to produce the final view for your pleasure. You don't see
the MVC in a browser, you see the result of the MVC, the view. Wasn't
this the entire point of the last ten years of the W3C? To specify HTML
as a model, Javascript as a controller and CSS as a view? In a
different MVC context of course. ;-)
So in a pipeline MVC context you have a model, the inital XML (static or
a template) that determines the initial structure of the data events
(generating SAX events where there previously were none), the controller
with modular logic (pipeline-specified transformers and actions), and
the serializer as view (what the outside world sees).
Cocoon had MVC before the advent of Flow. It simply had a single
complete MVC context. Flow gave rise to a new concept I've heard on
this list repeatedly, MVC+. But are we really defining M, V, C and some
new, unnamed letter/symbol? I think rather a new MVC context has been
born -- or rather that the high level view of Cocoon has finally
achieved true MVC -- and it's highly unusual because it occurs within
the same application server context rather than in separate
processes/machines as was the case with extenal RSS feeds and web browsers.
When you specify the following pipeline matcher
<map:match pattern="*.html">
<map:generate type="file" src="{1}.xml"/>
<map:transform type="xslt" src="xml2html"/>
<map:serialize type="xhtml"/>
</map:match>
What's the controller? I believe it's the pipeline assembly. The
actions and the transformers. The view? The serializer. The model?
Why, the XML document of course. But can't XSLT stylesheets put in all
sorts of new data either through includes or just by putting the data
hard-coded in the primary stylesheet? The above pipeline doesn't cover
the case where a stylesheet simply produces other non-presentational XML
as part of processing -- injecting new data into the model. Doesn't
I18nTransformer commonly get locale information from an input module and
grab data from external catalogs to augment what's already there? And
actions? Generating new data and injecting it into the pipeline at
arbitrary points.
The generator defines the data model, right. The template file is the
initial data structure model though. Sure, it's "waiting" for data
injection, but isn't a template with i18n attributes doing the same?
Once again, if the pipeline is changed in the sitemap to a static
pipeline as listed above, doesn't the call to sendPage* still work?
Hell, if anything, the template generator is it's own MVC context. The
Flow objects as model, the template as controller and the output as view.
But the sitemap doesn't reflect this.
<map:generate type="jx" src="mytemplate.jx"/>
In every other context, "src" refers to the model. Now that it's being
called by Flow, it's the controller. Well... If you use JXTG, it's the
controller. Otherwise, it's still specifying the model -- the input source.
So what were the advantages of template transformers again?
<map:match pattern="*.html">
<map:generate type="file" src="{1}.xml"/>
<map:transform type="macro-expansion"/>
<map:transform type="template"/>
<map:transform type="lenses"/>
<map:transform type="xslt" src="doc2html"/>
<map:serialize type="xhtml"/>
</map:match>
And what is lost? Well, complexity for one. The template transformer
has to worry about data -- values and iteration -- and nothing else.
The macro expansion, taglib, Eugene engine can be a Tag java inteface
with a lookup catalog, a set of stylesheets, or whatever is technically
superior without having to muck with the template component code. Not
just making them more modular and easily "pluggable". Pulling them out
altogether and letting the site administrator sort it out through the
sitemap. Letting the site administrator determine how data goes through
the pipeline and gets processed was the management intention behind the
sitemap, wasn't it?
Sticking with the "template processor must be a generator" mindset I
think misses the fact that it has already lost the strictly clean MVC
war. While I think what I've suggested would be better, it's actually
immaterial. I'm simply saying that we shouldn't necessarily be locking
ourselves into past decisions because I'm not entirely convinced they
were the right ones or based on logical necessity. This is true because
of the use of the "src" attribute, the fact that MVC is in fact
compartmentalized and Flow's data injection role in the pipeline
architecture.
- Miles "More Fuel For the Fire" Elam
Re: [Design] JXTG 2.0 (generator and transformer, same template syntax?)
Posted by Sylvain Wallez <sy...@apache.org>.
Stefano Mazzocchi wrote:
> Bertrand Delacretaz wrote:
<snip/>
>> D4) Bob was initially confused about this generator/transformer
>> thing, why both? Alice told him not to worry, generators are not his
>> business anyway, he's only a Cocoon Transformer Template Designer
>> (but a good one after only four weeks here). He'll understand when he
>> grows up ;-)
>
>
> Sure, but the question is: once the syntax starts to get ugly for both
> because of changes we made to the language that make sense only on
> transformation and not on generation, would it still be the case?
>
> remember that the generation stage has a scripted population stage
> first, the transformation stage does not!
I don't see this distinction: if you look at the global processing
chain, there is always a population stage in front of the template engine:
1/ template as a generator
+------------+ +-----------+
+ Flowscript |--(objects)-->| Template |----> ...
+ data | | generator |
+------------+ +-----------+
^
|
Template file
2/ template as a transformer
+-----------+ +-------------+
| Generator |--(xml data)-->| Template |----> ...
| | | transformer |
+-----------+ +-------------+
^
|
Template file
Where is the difference? The template lays out some data. In the case of
the generator, it's controller-provided data, in the case of the
transformer, it's pipeline-produced data. Note that is not limited to a
generator, but can also be aggregation, prior transformation, etc, or
even some preliminary processing of some controller-provided data.
<snip/>
> BTW, this whole discussion reminds me of DVSL:
>
> [http://jakarta.apache.org/velocity/dvsl/users-guide.html]
There is a huge difference with DVSL: just like XSLT, DVSL is a
rule-driven declarative language. This is what scares most people in
XSLT (although from my trainer's experience, it's not that hard to
learn). The template language we're talking about is purely procedural.
>> -Bertrand, enjoying the debate...
>
Me too, even if it's hard to follow :-)
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 (generator and transformer, same template syntax?)
Posted by Stefano Mazzocchi <st...@apache.org>.
Bertrand Delacretaz wrote:
> Le 5 déc. 04, à 06:14, Stefano Mazzocchi a écrit :
>
>> 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.
>>
>>
>> My FS detector is out of scale!!
>
> Hmmm...maybe it needs a battery change after working too hard in the
> last few days ;-)
Better yet: I'll buy a new one since the old one, as you pointed out,
exploded ;-)
[mental image of stefano, smoked head and gray face, all covered in dust]
> Let me clarify with a concrete story: we start with a few beans passed
> to sendPage, including a Collection of Person objects.
All right, here we go...
> Alice writes a template for the XYZGenerator (our new attribute-based
> template language), which receives the beans and generates an XML
> document based on this template (syntax details are irrelevant for this
> discussion):
>
> <page title="Persons">
> <person-list tl:iter="p in personCollection">
> <person>
> <name>${p/name}</name>
> <age>${p/age}</age>
> </person>
> </person-list>
> </page>
>
> At which point she gets an XML "data view" or "logical document" and
> passes it downstream for publishing.
Great.
> Then, Bob, who's in charge of the final presentation, writes another
> template to convert this logical document to, say, "lightweight HTML",
> for an embedded terminal (no CSS). This gets processed by the
> XYZTransformer, which uses the same template and expression engines, and
> the same syntax as the XYZGenerator (again, don't worry about syntax
> details):
>
> <html>
> <head><title>${page/title}</title></head>
> <body>
> <table>
> <tr tl:iter="p in page/person-list">
> <td>${p/name}</td>
> <td>${p/age}</td>
> </tr>
> </table>
> </body>
> </html>
hmmmm
> The XYZTransformer receives the XML produced by the XYZGenerator, reads
> the above template from disk (or from the output of another pipeline),
> and generates the HTML.
Right.
> -oo-
>
> Advantages:
> A1) There's only one implementation of the template and expression
> evaluation mechanisms.
Ok
> A2) Bob can ask Alice for help with the templates, she knows them in and
> out as that's what she's using as well.
Fair enough.
> A3) Bob, coming from a ColdFusion/ASP/PHP background, quickly became
> productive with the template language, which looks familiar. In a pinch,
> he can ask the trainee to make minor changes in DreamWeaver, in fact
> they saved a bunch by doing the prototype in this way.
Again, fair enough.
> A4) The XML logical document will "never" change once it's done, as it
> contains all the data in presentation-independent format. Write it, test
> it, forget about it. Alice doesn't want the critical parts of their
> system to change too often.
Yes, good strategy. It also allows this stage to be reused for another
channel (say RSS feeds and the like).
> A5) The XML logical document can be reused to publish the RSS feed, the
> mobile WAP/WML version, the full-blown XHTML/CSS version, without
> bothering Alice who's a busy and expensive person.
Damn, should read all of it before replying ;-)
> A6) Alice doesn't have to deal with the final customer who's always
> asking for "just a small change in the page layout". She leaves this to
> Bob for now, but they've considered training the customer to do this on
> his own, the templates are simple and isolated enough that he couldn't
> break anything anyway.
Right.
I have to say, as much as you arguments are convincing A4/A5/A6 are
simply indicating why pipelines are useful, not why a common syntax
between a generator and a transformer is ;-)
Don't try to throw smoke at my eyes, it doesn't work on these things.
Your point (and interestingly enough Miles') is that having the same
syntax for generation and transformation allows for A2 and A3.
Now, let me discuss about that since this is the exact same argument
that I had with Scott Boag when he was saying that we didn't need XSP
because XSLT was capable of doing the exact same (it just neede
extensions... just another name for taglibs <grin>).
First, I do think that A1 (therefore A2 and A3) is a loudable goal. No
questions about it.
My point is not if it's a good thing, my question is: can it be
achievable without reinventing XSLT/STX and therefore without coming
across with the same problems that it has and making it ackward to use
for one side because we forced it to be the same on the other side?
> Disadvantages:
> D1) The XYZTransformer is probably slower than a well-written XSLT
> transform. But it's also much faster than the XSLT transform that Bob
> tried to write. He's only been doing XSLT for four weeks and just plain
> hates it.
:-)
Fair enough. But really, here your real point is that XSLT is painful
and I can't agree more. But do you really think we can come up with
something that doesn't end up looking just like STX?
> D2) The XYZTransformer is a memory hog on large documents, as it loads
> the document in memory so that the expression evaluator can process it
> easily (AFAIK the current XSLT processors do the same in many cases,
> however, so this might not really be a problem).
Right. Xalan can do streaming mode (and STX should make it easier, in
theory) but both are theoretical.
> D3) Why so many steps? Generating XHTML directly could have saved some.
> But it doesn't help for RSS or WAP/WML, and the generation is actually
> much more complicated than what we see here, as configuration files and
> site menu definitions need to be aggregated in the page, with different
> variants depending on the final presentation target.
No, we don't need to debate that. I personally like to use XHTML even
for the first stage and do a bunch of copyovers in the stylesheets down
the road, but that's just me (I'm lazy)
> D4) Bob was initially confused about this generator/transformer thing,
> why both? Alice told him not to worry, generators are not his business
> anyway, he's only a Cocoon Transformer Template Designer (but a good one
> after only four weeks here). He'll understand when he grows up ;-)
Sure, but the question is: once the syntax starts to get ugly for both
because of changes we made to the language that make sense only on
transformation and not on generation, would it still be the case?
remember that the generation stage has a scripted population stage
first, the transformation stage does not!
> -oo-
>
> So, what's wrong with this? Where's the FS?
The FS is in what I wrote above: it would be *nice* to have a *simple*
language that was able to do both, but I've seen many people trying and
failing because the details make it look ugly fast, and if you make it
prettier for one stage you make it uglier for the other.
But you are right on one thing: I should not criticize before having
seen such a language ;-)
> I might be overlooking something but this could pave a much easier path
> for people to jump into Cocoon and *stay*, not run away scared by XSLT.
As I said previously, I very much agree that we need an easier (read:
simpler and non turing-complete) xml transformation language, something
that was more procedural than declarative.
Whether or not this needs to use the exact same syntax of the template
system is yet to be decided.
BTW, this whole discussion reminds me of DVSL:
[http://jakarta.apache.org/velocity/dvsl/users-guide.html]
> XSLT is *the* stumbling block today, and IMHO we don't have a good
> alternative to suggest. I don't mean to reinvent it, but as people are
> working on improved templates anyway, this looks like a cheap but very
> welcome addition.
All right, I rest my case: I'll see what we can come up with, but I hope
that you guys are able to cut the rope between the generator and the
transformer if it gets ugly enough.
> -Bertrand, enjoying the debate...
Happy that's the case ;-)
--
Stefano.
Re: [Design] JXTG 2.0 (generator and transformer, same template syntax?)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 5 déc. 04, à 06:14, Stefano Mazzocchi a écrit :
> 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.
>
> My FS detector is out of scale!!
Hmmm...maybe it needs a battery change after working too hard in the
last few days ;-)
Let me clarify with a concrete story: we start with a few beans passed
to sendPage, including a Collection of Person objects.
Alice writes a template for the XYZGenerator (our new attribute-based
template language), which receives the beans and generates an XML
document based on this template (syntax details are irrelevant for this
discussion):
<page title="Persons">
<person-list tl:iter="p in personCollection">
<person>
<name>${p/name}</name>
<age>${p/age}</age>
</person>
</person-list>
</page>
At which point she gets an XML "data view" or "logical document" and
passes it downstream for publishing.
Then, Bob, who's in charge of the final presentation, writes another
template to convert this logical document to, say, "lightweight HTML",
for an embedded terminal (no CSS). This gets processed by the
XYZTransformer, which uses the same template and expression engines,
and the same syntax as the XYZGenerator (again, don't worry about
syntax details):
<html>
<head><title>${page/title}</title></head>
<body>
<table>
<tr tl:iter="p in page/person-list">
<td>${p/name}</td>
<td>${p/age}</td>
</tr>
</table>
</body>
</html>
The XYZTransformer receives the XML produced by the XYZGenerator, reads
the above template from disk (or from the output of another pipeline),
and generates the HTML.
-oo-
Advantages:
A1) There's only one implementation of the template and expression
evaluation mechanisms.
A2) Bob can ask Alice for help with the templates, she knows them in
and out as that's what she's using as well.
A3) Bob, coming from a ColdFusion/ASP/PHP background, quickly became
productive with the template language, which looks familiar. In a
pinch, he can ask the trainee to make minor changes in DreamWeaver, in
fact they saved a bunch by doing the prototype in this way.
A4) The XML logical document will "never" change once it's done, as it
contains all the data in presentation-independent format. Write it,
test it, forget about it. Alice doesn't want the critical parts of
their system to change too often.
A5) The XML logical document can be reused to publish the RSS feed, the
mobile WAP/WML version, the full-blown XHTML/CSS version, without
bothering Alice who's a busy and expensive person.
A6) Alice doesn't have to deal with the final customer who's always
asking for "just a small change in the page layout". She leaves this to
Bob for now, but they've considered training the customer to do this on
his own, the templates are simple and isolated enough that he couldn't
break anything anyway.
Disadvantages:
D1) The XYZTransformer is probably slower than a well-written XSLT
transform. But it's also much faster than the XSLT transform that Bob
tried to write. He's only been doing XSLT for four weeks and just plain
hates it.
D2) The XYZTransformer is a memory hog on large documents, as it loads
the document in memory so that the expression evaluator can process it
easily (AFAIK the current XSLT processors do the same in many cases,
however, so this might not really be a problem).
D3) Why so many steps? Generating XHTML directly could have saved some.
But it doesn't help for RSS or WAP/WML, and the generation is actually
much more complicated than what we see here, as configuration files and
site menu definitions need to be aggregated in the page, with different
variants depending on the final presentation target.
D4) Bob was initially confused about this generator/transformer thing,
why both? Alice told him not to worry, generators are not his business
anyway, he's only a Cocoon Transformer Template Designer (but a good
one after only four weeks here). He'll understand when he grows up ;-)
-oo-
So, what's wrong with this? Where's the FS?
I might be overlooking something but this could pave a much easier path
for people to jump into Cocoon and *stay*, not run away scared by XSLT.
XSLT is *the* stumbling block today, and IMHO we don't have a good
alternative to suggest. I don't mean to reinvent it, but as people are
working on improved templates anyway, this looks like a cheap but very
welcome addition.
-Bertrand, enjoying the debate...
Re: [Design] JXTG 2.0 (Just my opinion)
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
(please ignore my previous message, hit send too soon ;-)
Le 6 déc. 04, à 07:27, Bertrand Delacretaz a écrit :
...
Re: [Design] JXTG 2.0 (Just my opinion)
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
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
Re: [Design] JXTG 2.0 (Just my opinion)
Posted by Glen Ezkovich <ge...@mac.com>.
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)
Posted by Stefano Mazzocchi <st...@apache.org>.
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)
Posted by Bertrand Delacretaz <bd...@apache.org>.
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
Re: [Design] JXTG 2.0 (Just my opinion)
Posted by Glen Ezkovich <gl...@hard-bop.com>.
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)
Posted by Stefano Mazzocchi <st...@apache.org>.
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)
Posted by Glen Ezkovich <ge...@mac.com>.
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))
Posted by Glen Ezkovich <gl...@hard-bop.com>.
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: The danger of overseparating concerns (was Re: [Design] JXTG
2.0(Just my opinion))
Posted by Antonio Gallardo <ag...@agssa.net>.
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: The danger of overseparating concerns (was Re: [Design] JXTG 2.0 (Just my opinion))
Posted by Bertrand Delacretaz <bd...@apache.org>.
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
The danger of overseparating concerns (was Re: [Design] JXTG 2.0
(Just my opinion))
Posted by Sylvain Wallez <sy...@apache.org>.
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=99244278700003&r=1&w=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: [Design] JXTG 2.0 (Just my opinion)
Posted by Bertrand Delacretaz <bd...@apache.org>.
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
Re: [Design] JXTG 2.0 (Just my opinion)
Posted by Glen Ezkovich <gl...@hard-bop.com>.
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
Re: [Design] JXTG 2.0 (Just my opinion)
Posted by Ralph Goers <Ra...@dslextreme.com>.
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 say yes!)
Posted by Stefano Mazzocchi <st...@apache.org>.
Leszek Gawron wrote:
> Jonas Ekstedt wrote:
>
>> I think the reason for taglibs are that rendering an object is often
>> more complicated than simply outputting a value. For example, suppose
>> you want to render a calendar covering the current month. This is a
>> typical component that would lend itself well as a tag class. The
>> template writer would simply do:
>>
>> <calendar:month current-date="${myDate}"/>
>>
>> The tag might output something like this:
>>
>> <month value="2">
>> <week value="12">
>> <day value="5" name="Monday"/>
>> <day value="6" name="Tuesday" current="true"/>
>> <day value="7" name="Wednesday"/>
>> ...
>> </week>
>> ...
>> </month>
>>
>> Later transformations would transform it into a table or whatever. This
>> type of calendar would be very hard to do for a template author without
>> the help of a tag library.
>
> I have completely no time these days so I was just waiting for the
> single post to say: Cannot agree more here :)
I cannot disagree more.
${myDate as month}
will do the above without mentioning tags (and will be much more
Dreamweaver-friendly).
>> The current discussion about taglibs have focused very much on esql and
>> whether SQL belongs in templates or not. I agree that SQL in templates
>> are a bad idea, but that is really beside the point in regards to the
>> virtues of taglibs.
>
> Exactly. Everyone concentrated on ESQL as a taglib while this is the
> WORST example there is. ESQL does a lot of persistence logic and can
> have enormous side effects. Taglibs should have no side effects at all.
excuse me? what side effect does a SELECT have?
>> Taglibs (in my view) are primarily about converting
>> objects to SAX.
If this is the case, then "taglib" is a *VERY BAD* name. I agree that
some objects might be "sax-ified" differently, depending on user needs,
but the name "taglibs" makes the syntactic and the semantic concern
overlap and annoys people (like me) that ended up hating dynamic XML
tags after promoting them for so long.
> Here are a few ideas for taglibs that only deals with
>> presentation of objects (as opposed to esql which also populates).
>>
>> * Bean renderers
>
> <jx:set var="ignored"
> value="${Packages.com.something.DateUtil.emitPrettyDate( bean.startDate,
> cocoon.consumer"/> - is this one better than the taglib? Or should I
> implement a stylesheet that would parse my 100kB xml file just to look
> for <dateutils:prettydate value="2003-01-01"/> ?
I completely agree that the transformation stage is overkill, that's not
my point.
I think that better than both you can do
${bean.startDate as YYYY-MM-DD}
>> * DOM renderers
excuse me?
>> * ResultSet renderers (ie renders a query made in flow)
are you kidding? regular iteration is all you need.
>> * Menus * Page navigation * Tabs (similar to tabs in CForm)
what?
>> * CForm tags
the above ${var as flavor} will do
>> * cinclude
no way
>> * Calendars (showing week, month etc.)
see above
> * wiki renderers
> currently I do something like to parse wiki syntax:
>
>> function radeoxToSAX( str, consumer ) {
>> var radeoxStr = radeoxEngine.render( str, radeoxContext );
>> var buffer = new java.lang.StringBuffer("<root>" );
>> buffer.append( radeoxStr )
>> buffer.append( "</root>" );
>> var is = new Packages.org.xml.sax.InputSource( new
>> java.io.StringReader( buffer.toString() ) );
>>
>> var parser = null;
>> var includeConsumer = new
>> org.apache.cocoon.xml.IncludeXMLConsumer( consumer, consumer );
>> includeConsumer.setIgnoreRootElement( true );
>> try { parser = cocoon.getComponent(
>> Packages.org.apache.excalibur.xml.sax.SAXParser.ROLE );
>> parser.parse( is, includeConsumer ); } finally {
>> if ( parser != null ) cocoon.releaseComponent( parser );
>> }
>> }
>
> <jx:macro name="radeox-string">
> <jx:parameter name="value"/>
> <jx:set var="ignored" value="${cocoon.session.radeox( value,
> cocoon.consumer )}"/>
> </jx:macro>
OH COME ON! you can do a generator and cinclude a subpipeline for that.
> <snip/>
>
> <radeox-string value="${project.description}"/>
> This clearly is a hack and should be implemented as taglib.
You will have to step on my dead body before that's the case.
> * ValueList renderers
> a taglib that supports displaying a narrowed list of values,
> searchable, paginable and so on
>
>> The items above are in my view better examples of the benefits of
>> taglibs. They're all about how to render an object. The object is
>> populated in flow but how to render it is implemented in the tag
>> classes.
>
> Maybe we should stop using "taglib" word. What we're trying to do may
> simply be harmed by the emotions that this phrase carries.
No matter what you call it, if you want to have dynamic XML tags, you
will hurt yourself, your wiki example is the kind of things that gives
me the creeps.
--
Stefano.
Re: [Design] JXTG 2.0 (Just say yes!)
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Jonas Ekstedt wrote:
> I think the reason for taglibs are that rendering an object is often
> more complicated than simply outputting a value. For example, suppose
> you want to render a calendar covering the current month. This is a
> typical component that would lend itself well as a tag class. The
> template writer would simply do:
>
> <calendar:month current-date="${myDate}"/>
>
> The tag might output something like this:
>
> <month value="2">
> <week value="12">
> <day value="5" name="Monday"/>
> <day value="6" name="Tuesday" current="true"/>
> <day value="7" name="Wednesday"/>
> ...
> </week>
> ...
> </month>
>
> Later transformations would transform it into a table or whatever. This
> type of calendar would be very hard to do for a template author without
> the help of a tag library.
I have completely no time these days so I was just waiting for the
single post to say: Cannot agree more here :)
> The current discussion about taglibs have focused very much on esql and
> whether SQL belongs in templates or not. I agree that SQL in templates
> are a bad idea, but that is really beside the point in regards to the
> virtues of taglibs.
Exactly. Everyone concentrated on ESQL as a taglib while this is the
WORST example there is. ESQL does a lot of persistence logic and can
have enormous side effects. Taglibs should have no side effects at all.
> Taglibs (in my view) are primarily about converting
> objects to SAX. Here are a few ideas for taglibs that only deals with
> presentation of objects (as opposed to esql which also populates).
>
> * Bean renderers
<jx:set var="ignored"
value="${Packages.com.something.DateUtil.emitPrettyDate( bean.startDate,
cocoon.consumer"/> - is this one better than the taglib? Or should I
implement a stylesheet that would parse my 100kB xml file just to look
for <dateutils:prettydate value="2003-01-01"/> ?
> * DOM renderers
> * ResultSet renderers (ie renders a query made in flow)
> * Menus
> * Page navigation
> * Tabs (similar to tabs in CForm)
> * CForm tags
> * cinclude
> * Calendars (showing week, month etc.)
* wiki renderers
currently I do something like to parse wiki syntax:
> function radeoxToSAX( str, consumer ) {
> var radeoxStr = radeoxEngine.render( str, radeoxContext );
> var buffer = new java.lang.StringBuffer("<root>" );
> buffer.append( radeoxStr )
> buffer.append( "</root>" );
> var is = new Packages.org.xml.sax.InputSource( new java.io.StringReader( buffer.toString() ) );
>
> var parser = null;
> var includeConsumer = new org.apache.cocoon.xml.IncludeXMLConsumer( consumer, consumer );
> includeConsumer.setIgnoreRootElement( true );
> try {
> parser = cocoon.getComponent( Packages.org.apache.excalibur.xml.sax.SAXParser.ROLE );
> parser.parse( is, includeConsumer );
> } finally {
> if ( parser != null ) cocoon.releaseComponent( parser );
> }
> }
<jx:macro name="radeox-string">
<jx:parameter name="value"/>
<jx:set var="ignored" value="${cocoon.session.radeox( value,
cocoon.consumer )}"/>
</jx:macro>
<snip/>
<radeox-string value="${project.description}"/>
This clearly is a hack and should be implemented as taglib.
* ValueList renderers
a taglib that supports displaying a narrowed list of values,
searchable, paginable and so on
> The items above are in my view better examples of the benefits of
> taglibs. They're all about how to render an object. The object is
> populated in flow but how to render it is implemented in the tag
> classes.
Maybe we should stop using "taglib" word. What we're trying to do may
simply be harmed by the emotions that this phrase carries.
Sure all taglibs/convertors/renderers could be implemented as
stylesheets or custom transformers. But creating a pipeline with 15
transformations (which by the way mainly would do identity
transformations and expand only specific tags) is neither performant nor
elegant. In case of custom transformers it's also never easy.
--
Leszek Gawron lgawron@mobilebox.pl
Project Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [Design] JXTG 2.0 (Just say yes!)
Posted by Jonas Ekstedt <ek...@ibg.uu.se>.
On Thu, 2004-12-02 at 16:47 -0500, Stefano Mazzocchi wrote:
snip...
> In both cases, they are suboptimal from what I wrote above, where
> content population and content presentation are kept completely isolated
> and the only contract between the two is:
>
> 1) the shape of the objects in the context
> 2) how to perform simple variable espansion, list iteration and
> conditioning.
>
> #2 is the only thing that should be exposed to a template language (just
> like velocity does), everything else should be dealt with at the view
> population level. Which is going to be code, written by coders and
> people that deal a lot better with code than with anything else.
I think the reason for taglibs are that rendering an object is often
more complicated than simply outputting a value. For example, suppose
you want to render a calendar covering the current month. This is a
typical component that would lend itself well as a tag class. The
template writer would simply do:
<calendar:month current-date="${myDate}"/>
The tag might output something like this:
<month value="2">
<week value="12">
<day value="5" name="Monday"/>
<day value="6" name="Tuesday" current="true"/>
<day value="7" name="Wednesday"/>
...
</week>
...
</month>
Later transformations would transform it into a table or whatever. This
type of calendar would be very hard to do for a template author without
the help of a tag library.
The current discussion about taglibs have focused very much on esql and
whether SQL belongs in templates or not. I agree that SQL in templates
are a bad idea, but that is really beside the point in regards to the
virtues of taglibs. Taglibs (in my view) are primarily about converting
objects to SAX. Here are a few ideas for taglibs that only deals with
presentation of objects (as opposed to esql which also populates).
* Bean renderers
* DOM renderers
* ResultSet renderers (ie renders a query made in flow)
* Menus
* Page navigation
* Tabs (similar to tabs in CForm)
* CForm tags
* cinclude
* Calendars (showing week, month etc.)
The items above are in my view better examples of the benefits of
taglibs. They're all about how to render an object. The object is
populated in flow but how to render it is implemented in the tag
classes.
Cheers Jonas
Re: [Design] JXTG 2.0 (Just say yes!)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Stefano Mazzocchi wrote:
<snip/>
> I would be very helpful if we could agree on the above two points with a
> vote (and a summary, of course) before moving on.
Stefano,
Unstable blocks doesn't need a vote, and the template one is the result
of unusually extensive mail discussions and also on a general agrement
about the direction. Everything is in the mail-archives and I and others
have written numerous summaries with vast references to the relevant
writings. If you care to check the archives you can see that I and
others had all reasons to believe that we did something that was agreed
about and wanted by the community.
Obviously we don't have an agreement anymore and I'm not going to start
any vote about anything until we have found a solution that we can agree
about again. Neither will I continue any design or implementation
activities in the template area until we can find a constructive way out
of this.
What I have proposed should be rather clear from my writings and it is
quite distant from what I'm accused to propose in your and others reactions.
Anyway, I'll wait for your and other critics constructive stated
alternatives. An emmotinally over heated crusade against things that
neither I or anyone else has proposed will not lead us anywhere.
I'll urge you and others that have constructive ideas about what we
should do in the templating area to post your ideas. And please focus on
what you want rather then what you hate.
I'll be happy to continue my involvement in finding, designing and
implementing a good template solution that we as a community feel happy
about after that.
/Daniel
Re: [Design] JXTG 2.0 (Just say yes!)
Posted by Stefano Mazzocchi <st...@apache.org>.
Reinhard Poetz wrote:
> Stefano Mazzocchi wrote:
>
>> One concern is to come up with a unified template language. This implies:
>>
>> 1) understanding the features we want (and we don't want!) from a
>> template language
>> 2) come up with a syntax
>> 3) implement it
>>
>> Another and completely separate concern is how to factor out existing
>> bits so that #3 is easier.
>>
>> You are attacking #3 before attacking #1 and #2 and that's why
>> everybody here is feeling frustration: there is no consensus on #1
>
> I don't think so. There were tons of mails and IMHO we agreed on a list
> of features (maybe a final summary is missing)
I would be very helpful if we could agree on the above two points with a
vote (and a summary, of course) before moving on.
--
Stefano.
Re: [Design] JXTG 2.0 (Just say yes!)
Posted by Sylvain Wallez <sy...@apache.org>.
Niclas Hedhman wrote:
>On Monday 06 December 2004 23:00, Sylvain Wallez wrote:
>
>
>>In that case, a single EL is just painful.
>>Furthermore, specifying the language in the component declaration
>>doesn't help readability nor reuse of templates between projects.
>>
>>
>
>Is it only me? I like Java a lot, and how come I can't construct the page
>parts in Java as well? Is it that people really love to learn 15 different
>programming languages when one can do more than enough?
>
>Tapestry, IMHO, have got a lot of things right. Let the programmers use Java
>and let the designers use Dreamweaver (or whatever their personal choice is).
>Having the programmers crank out some <tr> statements isn't that much of a
>deal, but blurring the pitcure of who is in charge of the template is. The
>designer knows shit-all about any programming construct and the programmer
>knows shit-all about design (pardon my french).
>
>
Well, I for one hate writing tons of Java to build a screen, despite
being a Java developer since JDK 1.1.x. A screen is a declarative thing
to me, and the natural language to build it is some kind of XML.
Furthermore, I want to organize it as I want, without having to ask a
webdesigner to change the location of a button. That's why I love
templates that produce structural layout markup (e.g. html with classes)
that is styled down the pipeline by various transformations and CSS.
>Maybe this community is a lot about people who think that they are in the
>middle and can do both... no offense :o) , most real-world projects are not
>organized in that manner.
>
>
Be careful: the concept of "real-world project" is a highly varying
concept here :-)
Tapestry provides only one way to do things, meaning its users have to
accept this way or switch to another framework. Cocoon is at the other
end by providing so many ways of doing things that there cannot be a
single imposed way. Like it or not, that part of what makes Cocoon so
special and used in so many different contexts. And the kilometer-long
thread on JXTG 2.0 clearly shows this :-)
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 say yes!)
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 06 December 2004 23:00, Sylvain Wallez wrote:
> In that case, a single EL is just painful.
> Furthermore, specifying the language in the component declaration
> doesn't help readability nor reuse of templates between projects.
Is it only me? I like Java a lot, and how come I can't construct the page
parts in Java as well? Is it that people really love to learn 15 different
programming languages when one can do more than enough?
Tapestry, IMHO, have got a lot of things right. Let the programmers use Java
and let the designers use Dreamweaver (or whatever their personal choice is).
Having the programmers crank out some <tr> statements isn't that much of a
deal, but blurring the pitcure of who is in charge of the template is. The
designer knows shit-all about any programming construct and the programmer
knows shit-all about design (pardon my french).
Maybe this community is a lot about people who think that they are in the
middle and can do both... no offense :o) , most real-world projects are not
organized in that manner.
Cheers
Niclas
--
+------//-------------------+
/ http://www.dpml.net /
/ http://niclas.hedhman.org /
+------//-------------------+
Re: [Design] JXTG 2.0 (Just say yes!)
Posted by Sylvain Wallez <sy...@apache.org>.
Daniel Fagerstrom wrote:
> Bertrand Delacretaz wrote:
>
>> Le 6 déc. 04, à 15:41, Glen Ezkovich a écrit :
>>
>>> On Dec 6, 2004, at 8:14 AM, Bertrand Delacretaz wrote:
>>>
>>>> Le 6 déc. 04, à 15:07, Vadim Gritsenko a écrit :
>>>>
>>>>> Reinhard Poetz wrote:
>>>>>
>>>>>> IIRC we aggreed that we like the current syntax of JXTemplate.
>>>>>> Exception: We deprecate the #{} notation in favour of ${xpath:....}.
>>>>>
>>>>>
>>>>> If nobody said this already (I have 150 or so mails to go ...),
>>>>> more than one EL per template is clear FS to me. I'd be in favor
>>>>> of specifying EL at the TemplateGenerator declaration time, and
>>>>> would not go more granular than this...
>>>>
>>>>
>>>> +1, it might be good to have pluggable languages but run-time
>>>> switching is definitely FS - and confusing as well.
>>>
>>>
>>> Thank you. Think this approach is applicable to the tag vs.
>>> attribute debate?
>>
>>
>> Sure. Having mixed languages or mixed tag/attributes templating
>> mechanisms in the same template sounds equally confusing.
>
>
> What about being able to mix Groovy's XML sytax with the the ordinary
> one, wouldn't that be nice ;)
Ring! Ring! Ring! (Stefano's FS alarm bells)
:-)
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 say yes!)
Posted by Stefano Mazzocchi <st...@apache.org>.
Bertrand Delacretaz wrote:
> Le 6 déc. 04, à 15:57, Daniel Fagerstrom a écrit :
>
>> ...What about being able to mix Groovy's XML sytax with the the
>> ordinary one, wouldn't that be nice ;)
>
>
> (you just forgot to add the sound of Stefano's FS detector exploding in
> the background)
ROTFL
I love you guys :-)
--
Stefano.
Re: [Design] JXTG 2.0 (Just say yes!)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 6 déc. 04, à 15:57, Daniel Fagerstrom a écrit :
> ...What about being able to mix Groovy's XML sytax with the the
> ordinary one, wouldn't that be nice ;)
(you just forgot to add the sound of Stefano's FS detector exploding in
the background)
-Bertrand
Re: [Design] JXTG 2.0 (Just say yes!)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Bertrand Delacretaz wrote:
> Le 6 déc. 04, à 15:41, Glen Ezkovich a écrit :
>
>> On Dec 6, 2004, at 8:14 AM, Bertrand Delacretaz wrote:
>>
>>> Le 6 déc. 04, à 15:07, Vadim Gritsenko a écrit :
>>>
>>>> Reinhard Poetz wrote:
>>>>
>>>>> IIRC we aggreed that we like the current syntax of JXTemplate.
>>>>> Exception: We deprecate the #{} notation in favour of ${xpath:....}.
>>>>
>>>> If nobody said this already (I have 150 or so mails to go ...),
>>>> more than one EL per template is clear FS to me. I'd be in favor of
>>>> specifying EL at the TemplateGenerator declaration time, and would
>>>> not go more granular than this...
>>>
>>> +1, it might be good to have pluggable languages but run-time
>>> switching is definitely FS - and confusing as well.
>>
>> Thank you. Think this approach is applicable to the tag vs. attribute
>> debate?
>
> Sure. Having mixed languages or mixed tag/attributes templating
> mechanisms in the same template sounds equally confusing.
What about being able to mix Groovy's XML sytax with the the ordinary
one, wouldn't that be nice ;)
/Daniel
Re: [Design] JXTG 2.0 (Just say yes!)
Posted by Glen Ezkovich <ge...@mac.com>.
On Dec 6, 2004, at 8:49 AM, Bertrand Delacretaz wrote:
> Le 6 déc. 04, à 15:41, Glen Ezkovich a écrit :
>
>> On Dec 6, 2004, at 8:14 AM, Bertrand Delacretaz wrote:
>>
>>> Le 6 déc. 04, à 15:07, Vadim Gritsenko a écrit :
>>>
>>>> Reinhard Poetz wrote:
>>>>> IIRC we aggreed that we like the current syntax of JXTemplate.
>>>>> Exception: We deprecate the #{} notation in favour of
>>>>> ${xpath:....}.
>>>>
>>>> If nobody said this already (I have 150 or so mails to go ...),
>>>> more than one EL per template is clear FS to me. I'd be in favor of
>>>> specifying EL at the TemplateGenerator declaration time, and would
>>>> not go more granular than this...
>>>
>>> +1, it might be good to have pluggable languages but run-time
>>> switching is definitely FS - and confusing as well.
>>
>> Thank you. Think this approach is applicable to the tag vs. attribute
>> debate?
>
> Sure. Having mixed languages or mixed tag/attributes templating
> mechanisms in the same template sounds equally confusing.
LOL. It did seem obvious to me. Should never have phrased it as a
question.
I think this might also work in other ways as well. Considering the
heat of the taglib debate (where, I think a lot of misunderstanding
occurred on both sides), this might be able to get the benefits of
using a taglib like approach to the implementation of template
generators/transformers. Same basic component gets a tag/attribute
library evaluator (excuse the phrase, brain freeze occurred concerning
the proper term ... or maybe I got it right ;-)). Seems that this way
the only difference between a JXTG and a SQLTG would be the way they
were configured in the sitemap and the library they were configured to
use.
The approach could be flexible enough to allow any combination to be
configured, allowing those who think they have such a use case, to
commit virtual suicide. Saner minds can do their best to prevent abuse
by threatening immediate termination upon such egregious configuration
of components. ;-)
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 say yes!)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 6 déc. 04, à 15:41, Glen Ezkovich a écrit :
> On Dec 6, 2004, at 8:14 AM, Bertrand Delacretaz wrote:
>
>> Le 6 déc. 04, à 15:07, Vadim Gritsenko a écrit :
>>
>>> Reinhard Poetz wrote:
>>>> IIRC we aggreed that we like the current syntax of JXTemplate.
>>>> Exception: We deprecate the #{} notation in favour of
>>>> ${xpath:....}.
>>>
>>> If nobody said this already (I have 150 or so mails to go ...), more
>>> than one EL per template is clear FS to me. I'd be in favor of
>>> specifying EL at the TemplateGenerator declaration time, and would
>>> not go more granular than this...
>>
>> +1, it might be good to have pluggable languages but run-time
>> switching is definitely FS - and confusing as well.
>
> Thank you. Think this approach is applicable to the tag vs. attribute
> debate?
Sure. Having mixed languages or mixed tag/attributes templating
mechanisms in the same template sounds equally confusing.
-Bertrand
Re: [Design] JXTG 2.0 (Just say yes!)
Posted by Glen Ezkovich <ge...@mac.com>.
On Dec 6, 2004, at 8:14 AM, Bertrand Delacretaz wrote:
> Le 6 déc. 04, à 15:07, Vadim Gritsenko a écrit :
>
>> Reinhard Poetz wrote:
>>> IIRC we aggreed that we like the current syntax of JXTemplate.
>>> Exception: We deprecate the #{} notation in favour of ${xpath:....}.
>>
>> If nobody said this already (I have 150 or so mails to go ...), more
>> than one EL per template is clear FS to me. I'd be in favor of
>> specifying EL at the TemplateGenerator declaration time, and would
>> not go more granular than this...
>
> +1, it might be good to have pluggable languages but run-time
> switching is definitely FS - and confusing as well.
Thank you. Think this approach is applicable to the tag vs. attribute
debate?
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 say yes!)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 6 déc. 04, à 15:07, Vadim Gritsenko a écrit :
> Reinhard Poetz wrote:
>> IIRC we aggreed that we like the current syntax of JXTemplate.
>> Exception: We deprecate the #{} notation in favour of ${xpath:....}.
>
> If nobody said this already (I have 150 or so mails to go ...), more
> than one EL per template is clear FS to me. I'd be in favor of
> specifying EL at the TemplateGenerator declaration time, and would not
> go more granular than this...
+1, it might be good to have pluggable languages but run-time switching
is definitely FS - and confusing as well.
-Bertrand
[NET] JXTG 2.0
Posted by Ralph Goers <Ra...@dslextreme.com>.
In case you are wondering, I just randomly chose NET. It stands for Never
Ending Topic.
At the risk of raising Stefano's alarm, what is so wrong with creating a
general template transformer as well as a generator that support pluggable
expression languages. That isn't really much different than what we do in
the rest of Cocoon where components are specified as Interfaces that must
be implemented and the actual implementation is configured in cocoon.xconf
or the sitemap.
In this case, however, instead of configuring them in the sitemap
(although one certainly could do it that way) I would anticipate something
like:
use jexl;
use jelly;
Where jexl and jelly might be roles defined in cocoon.xconf that must
implement the "expression language interface", whatever that is.
Ralph
Re: [Design] JXTG 2.0 (Just say yes!)
Posted by Jonas Ekstedt <ek...@ibg.uu.se>.
On Tue, 2004-12-07 at 00:45 +0100, Jonas Ekstedt wrote:
> On Mon, 2004-12-06 at 22:32 +0100, Sylvain Wallez wrote:
> > Glen Ezkovich wrote:
> >
> > >
> > > On Dec 6, 2004, at 9:00 AM, Sylvain Wallez wrote:
> > >
> > >>
> > >>> Reinhard Poetz wrote:
> > >>
> > >>
> > >> Yeah, cocoon-dev has gone crazy during the week-end :-)
> > >>
> > >>> more than one EL per template is clear FS to me. I'd be in favor of
> > >>> specifying EL at the TemplateGenerator declaration time, and would
> > >>> not go more granular than this.
> > >>
> > >>
> > >>
> > >> I don't agree: it happens quite often to have mixed view data
> > >> combining java objects and XML.
> > >
> > >
> > > Hmmm... why does this happen? It seems that the java could be injected
> > > by by one component and the XML by another.
> >
> >
> > Not always, e.g. when you have an XML document and objects describing
> > its metadata which are both managed by a flowscript.
>
> Fully agree. Restricting expressions to only one type would be quite bad
> I think. In addition to xpath and jelly it would also be cool with
> formatting expressions (ie ${format:<jelly-expression>#type}). As an
> example of all three types (xpath, jelly and format) consider a site
> with some articles and a calendar on it:
>
> <body>
> <p>Your last login: ${format:user.lastLogin#short}</p>
>
> <h3>This months calendar</h3>
> <calendar:month currentDate="${jelly:today}"/>
>
> <h3>Articles</h3>
> <dom:out select="${xpath:/domVariable/articles/article}
> </body>
>
> Cheers Jonas
Oops! jelly -> jexl
// jonas
Re: [Design] JXTG 2.0 (Just say yes!)
Posted by Jonas Ekstedt <ek...@ibg.uu.se>.
On Mon, 2004-12-06 at 22:32 +0100, Sylvain Wallez wrote:
> Glen Ezkovich wrote:
>
> >
> > On Dec 6, 2004, at 9:00 AM, Sylvain Wallez wrote:
> >
> >>
> >>> Reinhard Poetz wrote:
> >>
> >>
> >> Yeah, cocoon-dev has gone crazy during the week-end :-)
> >>
> >>> more than one EL per template is clear FS to me. I'd be in favor of
> >>> specifying EL at the TemplateGenerator declaration time, and would
> >>> not go more granular than this.
> >>
> >>
> >>
> >> I don't agree: it happens quite often to have mixed view data
> >> combining java objects and XML.
> >
> >
> > Hmmm... why does this happen? It seems that the java could be injected
> > by by one component and the XML by another.
>
>
> Not always, e.g. when you have an XML document and objects describing
> its metadata which are both managed by a flowscript.
Fully agree. Restricting expressions to only one type would be quite bad
I think. In addition to xpath and jelly it would also be cool with
formatting expressions (ie ${format:<jelly-expression>#type}). As an
example of all three types (xpath, jelly and format) consider a site
with some articles and a calendar on it:
<body>
<p>Your last login: ${format:user.lastLogin#short}</p>
<h3>This months calendar</h3>
<calendar:month currentDate="${jelly:today}"/>
<h3>Articles</h3>
<dom:out select="${xpath:/domVariable/articles/article}
</body>
Cheers Jonas
Re: [OT] [Design] JXTG 2.0 (Just say yes!)
Posted by Glen Ezkovich <gl...@hard-bop.com>.
On Dec 7, 2004, at 4:19 AM, Leszek Gawron wrote:
>>>
>> Well, if you omit polish, this is no problem for me :-)
>> And if each phrase is prefixes with the language name, making the
>> mental switch between ELs (or realizing that I must learn polish) is
>> not a problem.
> Where did that "polish" example came from ? :)
Just thinking of you.
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
[OT] [Design] JXTG 2.0 (Just say yes!)
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Sylvain Wallez wrote:
> Glen Ezkovich wrote:
>
>>
>> On Dec 6, 2004, at 9:00 AM, Sylvain Wallez wrote:
>>
>>>
>>>> Reinhard Poetz wrote:
>>>
>>>
>>>
>>> Yeah, cocoon-dev has gone crazy during the week-end :-)
>>>
>>>> more than one EL per template is clear FS to me. I'd be in favor of
>>>> specifying EL at the TemplateGenerator declaration time, and would
>>>> not go more granular than this.
>>>
>>>
>>>
>>>
>>> I don't agree: it happens quite often to have mixed view data
>>> combining java objects and XML.
>>
>>
>>
>> Hmmm... why does this happen? It seems that the java could be injected
>> by by one component and the XML by another.
>
>
>
> Not always, e.g. when you have an XML document and objects describing
> its metadata which are both managed by a flowscript.
>
>>> In that case, a single EL is just painful. Furthermore, specifying
>>> the language in the component declaration doesn't help readability
>>> nor reuse of templates between projects.
>>
>>
>>
>> Readability of what, the sitemap or the template.
>
>
>
> Reusability of the template, since you don't know just by reading the
> template source file what EL was used to write it.
>
>> Frankly, while it adds complexity to the sitemap, it only does so for
>> template generators/transformers. I think understandability will be
>> more affected by naming choices then the configuration complexity.
>> Only needing to interpret a single EL in a template undoubtedly
>> improves readability. Imagine me writing this using french, polish and
>> english phrases randomly interspersed.
>
>
>
> Well, if you omit polish, this is no problem for me :-)
>
> And if each phrase is prefixes with the language name, making the mental
> switch between ELs (or realizing that I must learn polish) is not a
> problem.
Where did that "polish" example came from ? :)
--
Leszek Gawron lgawron@mobilebox.pl
Project Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [Design] JXTG 2.0 (Just say yes!)
Posted by Glen Ezkovich <gl...@hard-bop.com>.
On Dec 6, 2004, at 3:32 PM, Sylvain Wallez wrote:
>> Hmmm... why does this happen? It seems that the java could be
>> injected by by one component and the XML by another.
>
>
> Not always, e.g. when you have an XML document and objects describing
> its metadata which are both managed by a flowscript.
I did think about this and a few other similar cases. Because we are
considering template generation and template transformation it would be
possible to use the metadata to construct the template that will be
used by the transformer. I'm not sure I like this, but that is one of
the ideas that has been mentioned. Also I think its possible for one
expression language to be used to work with both Java and XML using
appropriate syntax. It seems that something like ${/abc/def/ghi} and
${myObject.myMethod();} could coexist in a single EL. What would need
to be invalid are expressions like ${/abc/def/myobject.myMethod()}. I'm
not sure I like it. Its not completely aesthetically pleasing but it is
better then document(@href)/*/node(). ;-) (maybe it is possible to use
the current XPath and Jexl implementations and just do some syntax
validation up front)
> Readability of what, the sitemap or the template.
>> Reusability of the template, since you don't know just by reading the
>> template source file what EL was used to write it.
So you are saying that if you have two expression languages its going
to be easier ;-) As it is, you know that it is either XPath or Jexl.
Well, that is assuming you are using JXTG. If you are not, what EL is
being used? If you can understand it I think you'd have a pretty good
idea what the EL was. This like saying if you pick up an novel in
english you can't tell what language is used. Granted multiple
expression languages can have similar syntaxes and be semantically
different. Wouldn't it be odd (and wonderful) if templates written in
one would produce correct but totally different results in the other.
Talk about reusability. Not that I think this would happen. My point
is, if it makes sense, then you probably know what EL is being used. If
you are wrong and it still works correctly, who cares. :P
>
>> Frankly, while it adds complexity to the sitemap, it only does so for
>> template generators/transformers. I think understandability will be
>> more affected by naming choices then the configuration complexity.
>> Only needing to interpret a single EL in a template undoubtedly
>> improves readability. Imagine me writing this using french, polish
>> and english phrases randomly interspersed.
>
>
> Well, if you omit polish, this is no problem for me :-)
Maybe not the best example :-) It's usually not a problem for me either
when I know that multiple languages are used. Syntactically, two or
more ELs could be quite similar and thus hard to always know which you
are reading. I really don't have a problem with the fact that someone
wants to use two or more ELs in the same template. I can see use cases
where having two, three or more ELs available could be a very useful
thing. I also think with the ability to generate a template, these use
cases will become fewer.
>
> And if each phrase is prefixes with the language name, making the
> mental switch between ELs (or realizing that I must learn polish) is
> not a problem.
No its not. However, one of the things I have learned over the years is
that not everyone is capable of making context switches quickly. I do
believe that if you wish to use multiple ELs, you should be able to...
by configuring your component to do so. I just would like to prevent my
team from doing so unless no acceptable alternative exists.
>
>> I don't see how this affects reusability.
>
>
> Yes it does, since moving templates around require to be sure that the
> component they're processed with is configured for the right
> expression language.
I agree. But the same is true with any component. This is where
documentation and testing come in.
I think the out of the box cocoon should be as simple as possible. When
you are at the point of having your metadata in java objects and your
data in XML I would think that 15 minutes to configure a generator or
transformer would be a worth while investment of your time.
I don't see how things are damaged that much by having to configure
your components in the sitemap. I know XPer's believe that the
documentation is the code and Cocooners tend to hate writing doc
comments. For both the constraints and power of configurable components
I don't think its to much to ask of your template designers to list the
ELs used in the template in some comments.
Now after all this, I'm going to take the advice of the subject line
and just say YES. Refactor JXTG. Then 90% of the battle will be won by
us all. I think all of this is tangential to the real task at hand.
Clean elegant code makes me happy.
Didn't all this start with an effort to stabilize CForms? Its been so
long I forget.
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 say yes!)
Posted by Sylvain Wallez <sy...@apache.org>.
Glen Ezkovich wrote:
>
> On Dec 6, 2004, at 9:00 AM, Sylvain Wallez wrote:
>
>>
>>> Reinhard Poetz wrote:
>>
>>
>> Yeah, cocoon-dev has gone crazy during the week-end :-)
>>
>>> more than one EL per template is clear FS to me. I'd be in favor of
>>> specifying EL at the TemplateGenerator declaration time, and would
>>> not go more granular than this.
>>
>>
>>
>> I don't agree: it happens quite often to have mixed view data
>> combining java objects and XML.
>
>
> Hmmm... why does this happen? It seems that the java could be injected
> by by one component and the XML by another.
Not always, e.g. when you have an XML document and objects describing
its metadata which are both managed by a flowscript.
>> In that case, a single EL is just painful. Furthermore, specifying
>> the language in the component declaration doesn't help readability
>> nor reuse of templates between projects.
>
>
> Readability of what, the sitemap or the template.
Reusability of the template, since you don't know just by reading the
template source file what EL was used to write it.
> Frankly, while it adds complexity to the sitemap, it only does so for
> template generators/transformers. I think understandability will be
> more affected by naming choices then the configuration complexity.
> Only needing to interpret a single EL in a template undoubtedly
> improves readability. Imagine me writing this using french, polish and
> english phrases randomly interspersed.
Well, if you omit polish, this is no problem for me :-)
And if each phrase is prefixes with the language name, making the mental
switch between ELs (or realizing that I must learn polish) is not a problem.
> I don't see how this affects reusability.
Yes it does, since moving templates around require to be sure that the
component they're processed with is configured for the right expression
language.
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 say yes!)
Posted by Glen Ezkovich <gl...@hard-bop.com>.
On Dec 6, 2004, at 9:00 AM, Sylvain Wallez wrote:
>
>> Reinhard Poetz wrote:
>
> Yeah, cocoon-dev has gone crazy during the week-end :-)
>
>> more than one EL per template is clear FS to me. I'd be in favor of
>> specifying EL at the TemplateGenerator declaration time, and would
>> not go more granular than this.
>
>
> I don't agree: it happens quite often to have mixed view data
> combining java objects and XML.
Hmmm... why does this happen? It seems that the java could be injected
by by one component and the XML by another.
> In that case, a single EL is just painful. Furthermore, specifying the
> language in the component declaration doesn't help readability nor
> reuse of templates between projects.
Readability of what, the sitemap or the template.
Frankly, while it adds complexity to the sitemap, it only does so for
template generators/transformers. I think understandability will be
more affected by naming choices then the configuration complexity. Only
needing to interpret a single EL in a template undoubtedly improves
readability. Imagine me writing this using french, polish and english
phrases randomly interspersed.
I don't see how this affects reusability.
>
> Sylvain
>
> --
> Sylvain Wallez Anyware Technologies
> http://www.apache.org/~sylvain http://www.anyware-tech.com
> { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
>
>
>
>
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 say yes!)
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Sylvain Wallez wrote:
> Vadim Gritsenko wrote:
>
>> Sylvain Wallez wrote:
...
>>> Furthermore, specifying the language in the component declaration
>>> doesn't help readability nor reuse of templates between projects.
>>
>>
>>
>> If you don't see any better way out, I'd go as far as allowing to
>> choose EL in template itself, using attribute on the root element. I'd
>> not go further, though.
>
>
> Mmmh... like XSP does...
>
> BTW, isn't it you that added Python and JavaScript support to XSP? ;-)
But... But... But see, I had never suggested to use several languages in the
same page, at once! :-P
Vadim
Re: [Design] JXTG 2.0 (Just say yes!)
Posted by Sylvain Wallez <sy...@apache.org>.
Vadim Gritsenko wrote:
> Sylvain Wallez wrote:
>
>> Vadim Gritsenko wrote:
>>
>>> Reinhard Poetz wrote:
>>>
>>>> IIRC we aggreed that we like the current syntax of JXTemplate.
>>>> Exception: We deprecate the #{} notation in favour of ${xpath:....}.
>>>
>>>
>>>
>>> If nobody said this already (I have 150 or so mails to go ...),
>>
>>
>>
>> Yeah, cocoon-dev has gone crazy during the week-end :-)
>>
>>> more than one EL per template is clear FS to me. I'd be in favor of
>>> specifying EL at the TemplateGenerator declaration time, and would
>>> not go more granular than this.
>>
>>
>> I don't agree: it happens quite often to have mixed view data
>> combining java objects and XML. In that case, a single EL is just
>> painful.
>
>
> It just says a lot about state of the art in the expression language
> arena but does not demonstrate a need for more than one! :)
Well, go back to the threads about ELs and check the ugly XPath syntax
for object method calls chains and the impossibility to correctly
traverse an XML document with Jexl!
>> Furthermore, specifying the language in the component declaration
>> doesn't help readability nor reuse of templates between projects.
>
>
> If you don't see any better way out, I'd go as far as allowing to
> choose EL in template itself, using attribute on the root element. I'd
> not go further, though.
Mmmh... like XSP does...
BTW, isn't it you that added Python and JavaScript support to XSP? ;-)
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 say yes!)
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Sylvain Wallez wrote:
> Vadim Gritsenko wrote:
>
>> Reinhard Poetz wrote:
>>
>>> IIRC we aggreed that we like the current syntax of JXTemplate.
>>> Exception: We deprecate the #{} notation in favour of ${xpath:....}.
>>
>>
>>
>> If nobody said this already (I have 150 or so mails to go ...),
>
>
> Yeah, cocoon-dev has gone crazy during the week-end :-)
>
>> more than one EL per template is clear FS to me. I'd be in favor of
>> specifying EL at the TemplateGenerator declaration time, and would not
>> go more granular than this.
>
>
> I don't agree: it happens quite often to have mixed view data combining
> java objects and XML. In that case, a single EL is just painful.
It just says a lot about state of the art in the expression language arena but
does not demonstrate a need for more than one! :)
> Furthermore, specifying the language in the component declaration
> doesn't help readability nor reuse of templates between projects.
If you don't see any better way out, I'd go as far as allowing to choose EL in
template itself, using attribute on the root element. I'd not go further, though.
Vadim
Re: [Design] JXTG 2.0 (Just say yes!)
Posted by Sylvain Wallez <sy...@apache.org>.
Vadim Gritsenko wrote:
> Reinhard Poetz wrote:
>
>> IIRC we aggreed that we like the current syntax of JXTemplate.
>> Exception: We deprecate the #{} notation in favour of ${xpath:....}.
>
>
> If nobody said this already (I have 150 or so mails to go ...),
Yeah, cocoon-dev has gone crazy during the week-end :-)
> more than one EL per template is clear FS to me. I'd be in favor of
> specifying EL at the TemplateGenerator declaration time, and would not
> go more granular than this.
I don't agree: it happens quite often to have mixed view data combining
java objects and XML. In that case, a single EL is just painful.
Furthermore, specifying the language in the component declaration
doesn't help readability nor reuse of templates between projects.
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 say yes!)
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Reinhard Poetz wrote:
> IIRC we aggreed that we like the current syntax of JXTemplate.
> Exception: We deprecate the #{} notation in favour of ${xpath:....}.
If nobody said this already (I have 150 or so mails to go ...), more than one EL
per template is clear FS to me. I'd be in favor of specifying EL at the
TemplateGenerator declaration time, and would not go more granular than this.
Given the above, no need for prefixes (which look ugly to me), and you can
always use same syntax.
Vadim
Re: [Design] JXTG 2.0 (Just say yes!)
Posted by Reinhard Poetz <re...@apache.org>.
Stefano Mazzocchi wrote:
> One concern is to come up with a unified template language. This implies:
>
> 1) understanding the features we want (and we don't want!) from a
> template language
> 2) come up with a syntax
> 3) implement it
>
> Another and completely separate concern is how to factor out existing
> bits so that #3 is easier.
>
> You are attacking #3 before attacking #1 and #2 and that's why everybody
> here is feeling frustration: there is no consensus on #1
I don't think so. There were tons of mails and IMHO we agreed on a list of
features (maybe a final summary is missing)
> and #2 so
IIRC we aggreed that we like the current syntax of JXTemplate. Exception: We
deprecate the #{} notation in favour of ${xpath:....}.
> attacking #3 now is more harmful than useful.
hmmm, IMO #1 and #2 was done ...
--
Reinhard
Re: [Design] JXTG 2.0 (Just say yes!)
Posted by "Roy G. Biv" <mi...@pcextremist.com>.
Stefano Mazzocchi wrote:
>> The only difference compared to the SQLTransformer would be that I
>> can combine it with JXTG constructions and insert query params in a
>> convinient way.
>
> This is exactly the point that makes me say "just say no to taglibs"
> because, as I explained before, no matter what syntax, putting query
> parameters in a SQL string is not something that should be in a template!
Thank you.
> Sure, that's a better syntax, but the fundamental problem remains:
> template designers don't know nothing about SQL, nor care, nor know
> anything about request parameters, not know anything about dynamic
> tags nor know how to debug something in case somebody screws up with
> the order of those tags!
>
> let me rewrite the above:
>
> controller.script:
>
> var query = "SELECT name,description " +
> "FROM projects " +
> "WHERE project= " + request.id +
> "ORDER BY name ";
> var results = cocoon.datasources.gump.execute(query);
> request.context.set("projects",results);
>
> view.template (content style):
>
> <ul>
> #foreach project in projects
> <li><a href="projects?name=${project.name}">${project.name}</a> -
> ${project.description}</li>
> #end
> </ul>
>
> or view.template (attribute style):
>
> <ul x:foreach="project in projects">
> <li><a href="projects?name=${project.name}">${project.name}</a> -
> ${project.description}</li>
> </ul>
>
> note how SoC also allows you to use a different technology (example,
> O/R or straight OODBMS or even RDF triple stores!) to populate the
> beans without the template designers know anything about this!
Thank you! If this isn't a case study of what to do with simple
queries, I don't know what is.
Personally I like:
<ul x:test="projects">
<li x:context="projects"><a href="projects?name=${name}">${name}</a> -
${description}</li>
</ul>
Where each item in projects becomes the reference scope. ;-) If there
are no projects, no list tags are written. But then, I'm one of those
weird guys who doesn't mind seeing things like ${.} occasionally to
refer to the current iterated item. I also have to admit a love for
test conditionals that don't require the explicit "!= null" grammar.
Hey! We can all dream, right?
One concern though: Is that results variable a result set or just a
collection of data. If the former, how is the database connection
handled (closing or returning to the pool)? If the latter, how can
large result sets be returned without exhausting memory from a few
queries? That's the one case where I see ESQL winning out. All other
cases where you aren't dumping the contents of a table, this seems like
an excellent idea. If a web developer can't handle that much scripting,
what chance do they have with an ESQL taglib?
>> Sure, I agree with all that. Only question is: where do I put my SQL
>> queries in the above scenario?
>
> this is the whole stinking point: *never* in the template!
Thank you.
>>> But the whole point of this discussion is: do we need taglibs?
>>>
>>> I'm sorry, but I agree with Miles, we don't: all we need is a
>>> velocity/garbage-like template system and recompilable java
>>> controllers.
>>
>>
>> If you by this mean that you don't see any need in writing special
>> purpose taglibs as a typical part of normal webapp development, I
>> couldn't agree more.
>
>
> No, not only that: I think that the person responsible for doing
> writing the logic that drives the flow *and* the content population of
> the page is *NOT* the same person that does the design of the template.
Thank you.
- Miles Elam
Re: [Design] JXTG 2.0 (Just say yes!)
Posted by Glen Ezkovich <ge...@mac.com>.
I was working on an extremely long e-mail about this but Torsten,
Stefano and a repentant Miles covered most of my points. Thanks for the
help and for allowing me to waste my time :-P
However...
It seems that you are trying to do more then just replace the current
functionality JXTG. You want to include the possibility processing the
kitchen sink. I think this is what's bothering many of us. This will
lead to breaking the separation of concerns. While implementing this in
a template may seem better then implementing it in an XSP, in the end I
suspect it will be just as ugly. The only thing that will change is the
syntax. Semantically, it will be just as ugly. There is already too
much power in the existing JXTG.
On the other hand, I find the idea of a general template generator
intriguing. I think you might be on to something, but I think you are
missing it. Ok so you want a replacement for JXTG, create a tag library
and have the template generator use it. You want the functionality of
ESQL without XSP, create a tag library for it. Want to process CSVs,
write a tag library for it. Want to process excel spreadsheets, create
a tag library.
The problem is that generally you declare the libraries in the document
in which they are used and can use as many libraries as you want. This
is where the evil part of tag libs comes in. It allows you to do
anything and everything in one place. No separation of concerns can be
enforced. View, controller, model all can be intermingled. Suppose,
that instead of allowing all Tag Libraries to be used by the generator,
each generator could only use one library. That is JXTG could only
process JXTG tags, SQLTG could only process ESQL tags, ExcelTG could
only process EXCEL tags, etc.
TemplateGenerator is a perfect candidate for an abstract class. Each
subclass just needs to have a Tag Library with which to work. This
makes it much easier to implement other template generators just
implement a new Tag Library and some constructors. Of course nothing
prevents someone from adding multiple libraries to their generator
should they choose to do so. They can deal with the consequences.
This gives you the flexibility in design you want. It gives you the
functionality that you want, since it is unlikely that you will want to
access java objects and then access a database. It also helps limit the
abuse that tag libraries can engender.
Just my 0.02 €.
Now if I could just come up with a way to keep all html tags out of the
JX templates.
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 say yes!)
Posted by Stefano Mazzocchi <st...@apache.org>.
Daniel Fagerstrom wrote:
> Stefano Mazzocchi wrote:
>
> Let me re-iterate: there have for a long time been a concesus at the
> list among those who have cared enough to discuss it that JXTG is a well
> working way of creating views, but that the implementation is very hard
> to maintain.
Fair enough. A template language has nothing to do with taglibs, per se.
> There has also been an agreement about that ESQL is the only reason
> (besides back compability) to care about XSP, you said so youself a week
> ago or so.
After using it for a little while, I changed my mind. :-)
> For those of us who use CForms it is very convenient to be able to use
> the template tags together with JXTG constructs.
I believe the best template system does not use tags at all. It either
uses content (as in velocity) or it uses attributes (as in tapestry).
> So we need a template generator with three sets of tags "jx:", "esql:"
> and "ft:" thats it.
I disagree, we don't need a set of tags *AT ALL*.
> We also discused how to use a separate conversion layer to remove the
> need for formating constructs from the template layer.
>
> --- o0o ---
>
> Given these general requirements that have been discussed again and
> again at the list and also some more technical, performance driven
> requirments, I steped forward and proposed a possible way of
> implementing it. This design is based on a rather far going SoC in the
> interest of keeping it maintainable. We have also identified a number of
> templateing components that are needed in other places in Cocoon. E.g.
> expression language and object model and therefore are worth
> implementing as separate components. I also proposed implementing the
> three sets of tags discussed above as taglibs instead of making their
> interpretation being part of a huge monolitic SAX event handler as in
> JXTG. Implementing it that way it is must easier to write test code for
> the tags and generally easier to understand what is going on.
Very well, you just picked the wrong name: a refactoring of common
services into reusable components has nothing to do with enforcing the
use of tags into a template language.
But more on this later.
> --- o0o ---
>
> Given this background, I was quite suprised when Miles Elam whent
> ballistic about that I mentioned the word taglib and draw conclsions
> about my intensions that are far and in several cases oposite from what
> I feel and have written anything about.
keep reading and you might understand why.
> Anyway, if you have better suggestions about how to solve the above
> requirements I'm all ears.
Here I am.
> --- o0o ---
>
> Now over to commenting what you have written.
Bring it on :-)
>> So, my other side thinks that having a scripted controller invoquing
>> different templated views is a better solution.
>>
>> In this case, do we need taglibs at all? no we don't.
>> <esql:query>select * from blah</esql:query> sounds easy enough, but in
>> real life it's more something like
>>
>> <esql:connection>
>> <esql:pool>gump</esql:pool>
>> <esql:execute-query>
>> <esql:query>
>> SELECT name,description FROM projects ORDER BY name
>> </esql:query>
>> <esql:results>
>> <esql:row-results>
>> <li>
>> <a><xsp:attribute
>> name="href">projects?name=<esql:get-string
>> column="name"/></xsp:attribute><esql:get-string column="name"/></a> -
>> <esql:get-string column="description"/>
>> </li>
>> </esql:row-results>
>> </esql:results>
>> </esql:execute-query>
>> </esql:connection>
>>
>> and *THIS IS THE SIMPLES QUERY I CAN THINK OF*!!!
>
> In the general case I would rather write just the query with some
> surrounding tags like in the SQLTransformer, get a simple standardized
> XML serialization of the row set and then transform it to HTML in XSLT.
That works only for trivial monolythic cases. For any serious reporting
application (for example, where order is parameter dependable) that
doesn't work.
> The only difference compared to the SQLTransformer would be that I can
> combine it with JXTG constructions and insert query params in a
> convinient way.
This is exactly the point that makes me say "just say no to taglibs"
because, as I explained before, no matter what syntax, putting query
parameters in a SQL string is not something that should be in a template!
> If I would like to do everything in one step as you suggest above it
> might look more like:
>
> <esql:connection>
> <esql:pool>gump</esql:pool>
> <esql:execute-query>
> <esql:query>
> SELECT name,description FROM projects WHERE
> projectleader=${cocoon.request-param.id}ORDER BY name
> </esql:query>
> <esql:results>
> <esql:row-results>
> <li>
> <a href="projects?name=${$row.name}"/>${$row.name}</a> -
> ${$row.description}
> </li>
> </esql:row-results>
> </esql:results>
> </esql:execute-query>
> </esql:connection>
>
> As we are using the same kind of expression template mechanisms as in
> JXTG. We could probably make the syntax more efficient and take away
> some of the tag layers if we feel like that.
Sure, that's a better syntax, but the fundamental problem remains:
template designers don't know nothing about SQL, nor care, nor know
anything about request parameters, not know anything about dynamic tags
nor know how to debug something in case somebody screws up with the
order of those tags!
let me rewrite the above:
controller.script:
var query = "SELECT name,description " +
"FROM projects " +
"WHERE project= " + request.id +
"ORDER BY name ";
var results = cocoon.datasources.gump.execute(query);
request.context.set("projects",results);
view.template (content style):
<ul>
#foreach project in projects
<li><a href="projects?name=${project.name}">${project.name}</a> -
${project.description}</li>
#end
</ul>
or view.template (attribute style):
<ul x:foreach="project in projects">
<li><a href="projects?name=${project.name}">${project.name}</a> -
${project.description}</li>
</ul>
note how SoC also allows you to use a different technology (example, O/R
or straight OODBMS or even RDF triple stores!) to populate the beans
without the template designers know anything about this!
>> What I want is something like this:
>>
>> - request comes
>> - sitemap gets it
>> - matcher matches
>> - controller is executed and populates beans in the request context
>> - pipeline is invoqued with access to the request context
>> - response goes
>>
>> Now, this can happen right now in flow and JXtemplate. If we don't
>> need state management, this is just like having a better action model
>> with XSP-like code recompilation.
>
> Sure, I agree with all that. Only question is: where do I put my SQL
> queries in the above scenario?
this is the whole stinking point: *never* in the template!
>> But the whole point of this discussion is: do we need taglibs?
>>
>> I'm sorry, but I agree with Miles, we don't: all we need is a
>> velocity/garbage-like template system and recompilable java controllers.
>
> If you by this mean that you don't see any need in writing special
> purpose taglibs as a typical part of normal webapp development, I
> couldn't agree more.
No, not only that: I think that the person responsible for doing writing
the logic that drives the flow *and* the content population of the page
is *NOT* the same person that does the design of the template.
Taglibs force template designers to do the job of content population or
force two different people to work on the same file.
In both cases, they are suboptimal from what I wrote above, where
content population and content presentation are kept completely isolated
and the only contract between the two is:
1) the shape of the objects in the context
2) how to perform simple variable espansion, list iteration and
conditioning.
#2 is the only thing that should be exposed to a template language (just
like velocity does), everything else should be dealt with at the view
population level. Which is going to be code, written by coders and
people that deal a lot better with code than with anything else.
>> Everything else is making a step backwards.
>
> As said above my only purpose with introducing taglibs is to increase
> maintainability and the ability to test things. Take a look at the
> Cocoon code base. Tons of code that hide what it does beyond all this
> SAX event handling code. If we could refactor away some of that
> intermingling, we would IMO make a step forward.
You keep mixing concerns.
One concern is to come up with a unified template language. This implies:
1) understanding the features we want (and we don't want!) from a
template language
2) come up with a syntax
3) implement it
Another and completely separate concern is how to factor out existing
bits so that #3 is easier.
You are attacking #3 before attacking #1 and #2 and that's why everybody
here is feeling frustration: there is no consensus on #1 and #2 so
attacking #3 now is more harmful than useful.
--
Stefano.
Re: [Design] JXTG 2.0 (Just say yes!)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Stefano Mazzocchi wrote:
Let me re-iterate: there have for a long time been a concesus at the
list among those who have cared enough to discuss it that JXTG is a well
working way of creating views, but that the implementation is very hard
to maintain.
There has also been an agreement about that ESQL is the only reason
(besides back compability) to care about XSP, you said so youself a week
ago or so.
For those of us who use CForms it is very convenient to be able to use
the template tags together with JXTG constructs.
So we need a template generator with three sets of tags "jx:", "esql:"
and "ft:" thats it.
We also discused how to use a separate conversion layer to remove the
need for formating constructs from the template layer.
--- o0o ---
Given these general requirements that have been discussed again and
again at the list and also some more technical, performance driven
requirments, I steped forward and proposed a possible way of
implementing it. This design is based on a rather far going SoC in the
interest of keeping it maintainable. We have also identified a number of
templateing components that are needed in other places in Cocoon. E.g.
expression language and object model and therefore are worth
implementing as separate components. I also proposed implementing the
three sets of tags discussed above as taglibs instead of making their
interpretation being part of a huge monolitic SAX event handler as in
JXTG. Implementing it that way it is must easier to write test code for
the tags and generally easier to understand what is going on.
--- o0o ---
Given this background, I was quite suprised when Miles Elam whent
ballistic about that I mentioned the word taglib and draw conclsions
about my intensions that are far and in several cases oposite from what
I feel and have written anything about.
Anyway, if you have better suggestions about how to solve the above
requirements I'm all ears.
--- o0o ---
Now over to commenting what you have written.
> So, my other side thinks that having a scripted controller invoquing
> different templated views is a better solution.
>
> In this case, do we need taglibs at all? no we don't. <esql:query>select
> * from blah</esql:query> sounds easy enough, but in real life it's more
> something like
>
> <esql:connection>
> <esql:pool>gump</esql:pool>
> <esql:execute-query>
> <esql:query>
> SELECT name,description FROM projects ORDER BY name
> </esql:query>
> <esql:results>
> <esql:row-results>
> <li>
> <a><xsp:attribute
> name="href">projects?name=<esql:get-string
> column="name"/></xsp:attribute><esql:get-string column="name"/></a> -
> <esql:get-string column="description"/>
> </li>
> </esql:row-results>
> </esql:results>
> </esql:execute-query>
> </esql:connection>
>
> and *THIS IS THE SIMPLES QUERY I CAN THINK OF*!!!
In the general case I would rather write just the query with some
surrounding tags like in the SQLTransformer, get a simple standardized
XML serialization of the row set and then transform it to HTML in XSLT.
The only difference compared to the SQLTransformer would be that I can
combine it with JXTG constructions and insert query params in a
convinient way.
If I would like to do everything in one step as you suggest above it
might look more like:
<esql:connection>
<esql:pool>gump</esql:pool>
<esql:execute-query>
<esql:query>
SELECT name,description FROM projects WHERE
projectleader=${cocoon.request-param.id}ORDER BY name
</esql:query>
<esql:results>
<esql:row-results>
<li>
<a href="projects?name=${$row.name}"/>${$row.name}</a> -
${$row.description}
</li>
</esql:row-results>
</esql:results>
</esql:execute-query>
</esql:connection>
As we are using the same kind of expression template mechanisms as in
JXTG. We could probably make the syntax more efficient and take away
some of the tag layers if we feel like that.
> What I want is something like this:
>
> - request comes
> - sitemap gets it
> - matcher matches
> - controller is executed and populates beans in the request context
> - pipeline is invoqued with access to the request context
> - response goes
>
> Now, this can happen right now in flow and JXtemplate. If we don't need
> state management, this is just like having a better action model with
> XSP-like code recompilation.
Sure, I agree with all that. Only question is: where do I put my SQL
queries in the above scenario?
> But the whole point of this discussion is: do we need taglibs?
>
> I'm sorry, but I agree with Miles, we don't: all we need is a
> velocity/garbage-like template system and recompilable java controllers.
If you by this mean that you don't see any need in writing special
purpose taglibs as a typical part of normal webapp development, I
couldn't agree more.
> Everything else is making a step backwards.
As said above my only purpose with introducing taglibs is to increase
maintainability and the ability to test things. Take a look at the
Cocoon code base. Tons of code that hide what it does beyond all this
SAX event handling code. If we could refactor away some of that
intermingling, we would IMO make a step forward.
/Daniel
Re: [Design] JXTG 2.0 (Just say no!)
Posted by Upayavira <uv...@upaya.co.uk>.
Stefano Mazzocchi wrote:
<snip/>
> What I want is something like this:
>
> - request comes
> - sitemap gets it
> - matcher matches
> - controller is executed and populates beans in the request context
> - pipeline is invoqued with access to the request context
> - response goes
>
> Now, this can happen right now in flow and JXtemplate. If we don't
> need state management, this is just like having a better action model
> with XSP-like code recompilation.
>
> But the whole point of this discussion is: do we need taglibs?
>
> I'm sorry, but I agree with Miles, we don't: all we need is a
> velocity/garbage-like template system and recompilable java controllers.
>
> Everything else is making a step backwards.
Stefano, for those that skipped taglibs in their path to Cocoon (e.g
me!), can you explain what you don't like about them? I presume you're
okay with a jxtemplate like syntax, but what you don't like is the fact
that I can write my own taglib, thus hiding logic not in my controller,
but in a taglib class somewhere. Is that it? Presumably, you wouldn't
also be against, for example, implementing the FormsTransformer as a
part of a templating system? i.e. having the template put the widget
values straight into the SAX stream.
Have I understood, or are you getting at something else?
Regards, Upayavira
Re: [Design] JXTG 2.0 (Just say no!)
Posted by Stefano Mazzocchi <st...@apache.org>.
Daniel Fagerstrom wrote:
> Miles Elam wrote:
[a little too emotional fight that brings the danger of moving the
important points discussed on the bottom and the rants at the top,
hiding the signal]
A little story first.
I'm writing a thing called Dynagump these days. It's a web application
and it's supposed to do reports out of a database that gump populates
every night. It's supposed to replace the static web pages that gump
generates today and that don't keep historical information.
Concerned by bootstrappability, I tried with Python stuff and found out
that Python is literarely 5 years behind in web technologies. They are
all thinking that CGI-BIN is good enough (example, MoinMoin) or, if not,
they build their own web server (example, Zope).
Some people had the brilliant idea to write Servlets for Python (d'oh!)
in a thing called WebKit. Pretty cool. It feels like JServ 0.9.11. 7
years ago would have been a compliment.
So I decided I didn't want to spend 3 years of my life to rewrite (one
more time!) the history of servlets in python and I switched back to java.
Also, I tried to be as simple as possible: velocity templates and a
resultset as a bean.
It turns out that velocity iterates only on iterators and resultset
don't implement iterators. So, either I write my own iterators or I do
something else. Since I never used it, I tried Hibernate. Took me a few
hours, but I had it: I was able to show my projects on a web page.
Uhuh!!
Ok, now, let's write a real userful page.
Hmmm, well, oh, yeah, URL management... web.xml... crap. One servlet and
all as parameters? nah, too 90's. one servlet that does URL management?
all right.
so I start writing what turns out to look like a sitemap-like URL
matching system. nono, stop that. back to the templates.
hmmmm, all right, I know I have to display the results of
SELECT
builds.id,
builds.result,
builds.start_time,
project_versions.project,
results.name
FROM
builds,
project_versions,
results
WHERE
builds.run = $ID
AND
builds.project_version = project_versions.id
AND
builds.result = results.id
ORDER BY
builds.start_time
ASC
but how in hell is this translated into O/R mappings? I look around and
it seems that I have to do the whole joins by myself...
Wait a second!
This is a publishing application. No roundtripping. Multichanneled.
URL-space problems, SQL describing the data results perfectly.
Screw that, I'm using cocoon.
Thanks to SVN, I moved the hibernate version somewhere else and started
over with cocoon.
First, I tried to do the same thing that I did with velocity+hibernate
in cocoon.... if I wanted to use velocity, I needed to have a way to
invoque the controller... but I didn't have state to manage, so why
should I use flowscript for that?
I tried with a simpler SQLTransformer. Worked fine, but then, I
thought... well, sometimes, the queries change depending on the request
parameters.... hmmmm, so, how do I do that in SQLTransformer? an XSLT
stage between the generator and the transformer? nah, gross.
All right, let's use XSP.
- o -
Now I find myself in this weird limbo.
One side of me still likes XSP. The syntax is ugly since XML and Java
don't mix that well (and it will be even worse with 1.5 generics!), but
the power is incredible. If you know what you are doing it's like
writing servlets at 100x the speed but without all the crap that JSP
forces you since you don't have a pipeline after you.
The only taglibs I'm using are ESQL and request. I do the if/then/else
in java code.
It works just fine, but I'm afraid that this will stop non-xsp-users
from being able to contribute to my effort once it starts and this
scares me.
So, my other side thinks that having a scripted controller invoquing
different templated views is a better solution.
In this case, do we need taglibs at all? no we don't. <esql:query>select
* from blah</esql:query> sounds easy enough, but in real life it's more
something like
<esql:connection>
<esql:pool>gump</esql:pool>
<esql:execute-query>
<esql:query>
SELECT name,description FROM projects ORDER BY name
</esql:query>
<esql:results>
<esql:row-results>
<li>
<a><xsp:attribute
name="href">projects?name=<esql:get-string
column="name"/></xsp:attribute><esql:get-string column="name"/></a> -
<esql:get-string column="description"/>
</li>
</esql:row-results>
</esql:results>
</esql:execute-query>
</esql:connection>
and *THIS IS THE SIMPLES QUERY I CAN THINK OF*!!!
What I want is something like this:
- request comes
- sitemap gets it
- matcher matches
- controller is executed and populates beans in the request context
- pipeline is invoqued with access to the request context
- response goes
Now, this can happen right now in flow and JXtemplate. If we don't need
state management, this is just like having a better action model with
XSP-like code recompilation.
But the whole point of this discussion is: do we need taglibs?
I'm sorry, but I agree with Miles, we don't: all we need is a
velocity/garbage-like template system and recompilable java controllers.
Everything else is making a step backwards.
--
Stefano.
Re: [Design] JXTG 2.0 (Just say no!)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Miles Elam wrote:
> Ummm... Hold on second while I don my flame-resistant underwear.
>
> Okay folks, why are we making tag libraries/interfaces *at all*?
Take a look at the implementation of JXTemplateGenerator, and the
implementation of ESQL and then on the implementations of a couple of
the various transformers that interpret different tag languages. Not
that pretty. They where certainly not easy to write, they are not easy
to read and they are even harder to maintain. Neither the less they do a
good work although some of them could need to be updated to reflect our
current ideas about how to do things.
The main reason to implement tag libs from my POV is to be able to
refactor things like JXTG and ESQL as taglibs so that they become easier
to support and improve. And so that we can avoid those endless
horrendous listings of the methods in the SAX interface as soon as some
one want to let a tag doing something.
Concerning interfaces for tag libs: they are important as they controll
what you can do (and what you are forbidden to do) from you tags. The
design of the intefaces will also effect how easy it eill be to write
readable tags.
> I mean it. I feel like a lemming being driven off a cliff.
Its just web server code if you avoid using any taglibs in life support
system or stearing systems in aeroplanes, your physical safety shoudn't
be affected ;)
<snip/>
> Why tag libraries? To deal with the excessive code in the markup.
No, the reasons are those that I gave above: maintainabillity for those
"taglibs" that we allready have in Cocoon.
Then I'm certain that some users are going to do things that I consider
ugly and counter productive with the help of taglibs. But people are
creative so someone is going to find a missuse for any technology.
> If you really need code in markup for your corner case, tag
> libraries aren't going to help the situation much. You need code.
> So here we stand discussing how to go back to big balls of tag library
> mud.
We are not! From my POV we are going to reimplement the declarative and
side effect free parts of JXTG, ESQL, the CForms tags and possibly other
_declarative and side effect free_ tags.
> We have a glimpse of better things with Flow.
Sure flow logic, business logic binding and side efects in flowscripts
and side effect free presentation oriented stuff in (e.g.) template,
clear SoC.
> Why aren't we examining that model for further direction? Why are
> we going backwards? Arbitrary Java code executing in the markup but
> with a prettier face? Great. I'm so happy, I could eat the six month
> old leftovers rotting in my friend's tupperware.
You could spend some of your creativity on finding reasonable contracts
on what we want to be able to do in template instead of just ranting.
> CAN' T WE COME UP WITH A BETTER IDEA!?! There are some really smart
> people on this list. C'mon!
We are happy if you find and maybe even implement a better idea.
Requring others to comme up with smart ideas are like requiring them to
implement the features that you need or write the documentation you
would like to have:
Don't ask your open source community what it can do for you, ask
yourself what you can do for your open source community!
> What have tag libraries been used for?
>
> 1. A macro language
> 2. Data generation
> 3. Data formatting
> 4. Backend processing
> 5. Making programming languages out of markup
> 6. Data replacement
>
> Let's go down the list.
>
> 1. A macro language
>
> XSLT or any of the other markup transformation syntaxes can handle
> this. No code or tag API needed. STX: an easy-to-use syntax enabling
> a SAX stream with a minimal memory footprint. Side effect-free.
> Highly cacheable. The cached SAX events for JXTemplateGenerator are
> put in the cache for future use -- same story with a
> JXTemplateTransformer or any JXTemplate* successor or whatever.
> Nothing lost by using a simple transformation language. The best
> part? It's simple.
Honestly, have you followed the discussion that my design document was
based on? Everyone that ever have tried to fix something in (or tried to
understand) JXTG seem to agree about the need of refactoring it, to make
it supportable. I have given some suggestions about how to achieve this,
better ideas are always welcome.
I would prefer to use XSLT or XQuery as a template language, although it
doesn't solve how to handle things like ESQL. I spent some effort on
doing that one and half year ago
http://marc.theaimsgroup.com/?t=104930795600004&r=1&w=2,
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104998241710064&w=2,
http://marc.theaimsgroup.com/?t=105016536400004&r=1&w=2 and
http://marc.theaimsgroup.com/?t=105178446600003&r=1&w=2.
But it is quite complicated although possible to make an XSLT or XQuery
processor read Java bean structures in an efficient way. Saxon that
would be the most attractive choice is MPL 1.0 that was supposed to be
incompatible with APL. And then Christopher implemented JXTG which
solved the most important requirements.
> 2. Data generation
>
> Raise your hands. Let's see who you are that still thinks after all
> that we've learned from web development history that
> <esql:execute>SELECT * FROM MYTABLE WHERE COLUMN1 = 0</esql:execute>
> is a good idea and the best we can come up with? I admit that I was
> one of "those" people that was trying to get a standard relational
> database API in Flow. So wrong. SO WRONG. I would like to thank the
> developers on this list for their insight and wisdom on this point.
>
> If you are savvy enough to write a Java class that implements the Tag
> interface, you are certainly smart enough to write a POJO for use with
> Hibernate (or whichever object persistence mechanism you prefer). In
> fact, the way things are going and with the tools being made
> available, the Tag interface is *harder*. And an implementation of
> Tag verses a Javascript object or data structure? The difference in
> complexity level isn't even funny.
You are mixing things up. The ESQL like tags are written once by a Java
savvy person and then they can be reused as often as wanted by people
who are not, but who know SQL. I'm certain that object relational tools
are very usefull if you when you build enterprise systems in Java. But I
fail to understand why it would help anyone who don't to write simple DB
reporting. Neither do I understand why people who use Hibernate etc have
such strong urge to again and again inform the rest of us that they have
found _the truth_ and that we should convert to _the right way_
immediatly to save our souls.
Personally I start to believe that the "apply OO enterprise design
patterns on everything" attitude, is an anti pattern. Use scaleable
methods when you need it and avoid the complexity from such methods when
you do something simple. And if you need to scale your simple
application, refactor it to use the enterprise patterns you need.
For many simple cases:
<esql:execute>SELECT * FROM MYTABLE WHERE COLUMN1 = 0</esql:execute>
is an excelent and easy to understand idea.
> 3. Data formatting
>
> Let's call a spade a spade here. We've got how many variations that
> need to be handled?
>
> boolean, integer types, floating point types, dates/timestamps,
> strings, XML fragments, selection from limited choices (if 0, say
> "none" -- if 1, say "one" -- if more, say "many"), and objects (which
> are basically .toString() calls unless it has properties that are
> plain old datatypes -- in which case you use the other handlers).
>
> That's what? Seven different formatters? Done. Finished. Do we
> really need a tag library for that? Make them reusable components
> that transformers can use as needed.
Thats the idea, read
http://marc.theaimsgroup.com/?t=109941988300003&r=1&w=2. Hoppefully we
can remove the need for data formatting tags.
> 4. Backend processing
>
> We don't like to admit it, but we've all wondered, "What if this
> custom tag could trigger a cache invalidation or do some workflow
> or..." Bad idea. Bad idea. Backend processing in your markup
> template is a horrible idea. Do it in an action or better yet in Flow.
Sure.
> 5. Making programming languages out of markup
>
> <foo:if>, <foo:for-each>, <foo:eval>, etc. Why the foreplay? If
> you're gonna write a programming language, at least have the decency
> to not base it on markup. These aren't really different from saying
>
> <% if (test.isTrue()) { %>
> <foo/>
> <% } %>
>
> or XSP's
>
> <xsp:logic>
> if (test.isTrue()) {
> <foo/>
> }
> </xsp:logic>
IMNSHO, this is totaly wrong. As soon as you have sequences or
recursively defined data structures from business logic, e.g. lists or
trees, you need conditionals, iteration constructs and recursively
applicable templates. Say that you get an item list, a menu tree or a
folder structure e.g. from your business layer, how are you going to
render them without such control structures? Adding side effects, write
access to your business model or Cocoon environment or even allowing
full fledged Java constructions, is something completely different.
In a template language you need the same controll structures as in XSLT,
but they must be applicable on other input (read only) data structures
than XML, Java beans or SQL row sets e.g.
> IMO constructs like this should be context-dependent on the task at
> hand. For example, wouldn't it have been easier if instead of
>
> <jx:for-each var="person" items="${people}">
> <jx:if test="${person.name != 'Mean Mike'} ">
> <friend>${person.name}</friend>
> </jx:if>
> </jx:for-each>
>
> you had
>
> <friend jx:context="${people}" jx:test="${name != 'Mean
> Mike'}">${name}</friend>
>
> Same thing. Not a programming language though. Data injection
> tailored to the task at hand. This is the problem domain that
> JXTemplateGenerator is made to solve.
My intension is to make "template" an open framework as well as an
application, so that you can reuse parts of it for developing own ideas.
So if you want to develop something like what you suggest above you can
think about and discuss what mechanisms you need for implementing that.
I focus on taglibs as it is a well known, understand and easy to
implement technology.
> What is the for-each doing? Setting a scope -- a context. Look back
> in the templates you've made. How many <jx:if> elements wrapped more
> than one element? I have found in my general usage that well over 90%
> of the time it's just the one child element. And those
> <jx:chose/when/otherwise>... Be honest, how many times have you used
> that for data formatting rather than structural changes to the
> markup? Listing stuff like "yesterday" or "today" or "last week"
> instead of the raw date. That's a boatload of markup to do what
> amounts to a java.text.ChoiceFormat method call.
>
> If it's that complex, why isn't it reflected in your data model
> instead of your markup's wannabe programming language?
>
> 6. Data replacement
>
> And here we come to the meat. This is where the I18nTransformer does
> its magic. This where JXTemplateGenerator does its thing. One hit
> wonders where the markup has been altered to fit the problem at hand,
> not the general definition of a tag library. Where does the following
> I18nTransformer example fit in?
>
> <input type="submit" value="Submit" i18n:attr="value"/>
>
> It can if all it does it translate <foo:i18n-submit/> to the above for
> "real" processing. Stylesheet.
>
> Data injection. That's what custom markup is really good for. It's a
> domain-specific problem. Tag libraries are for general case
> problems. But the general case is already handled by the existing
> transformers' API.
Again take a look at the implementations of transformers that interprete
tags or on the sitemap complexity when you want to use tags from several
domain-specific areas. The transformers are quite complex beasts and
you need very detailed knowledge in using SAX to write them besides your
domain specific knowledge.
It would be much easier to implement and support such stuff as taglibs.
> -------------------------- o0O0o -------------------------
>
>
> So what are the use cases that require tag libraries? More
> specifically, what are the use cases that require tag libraries that
> will be made cleaner by skipping XSP?
>
> What would I prefer? Keep XSP as it is. It's shite, but it's
> powerful shite. It's for the edge; those pesky corner-cases that
> refuse to go away; the last 1%.
>
> * XSP is Cocoon's mod_rewrite. *
We are not going to depricate XSP anytime soon, use what you want.
> Don't code around mod_rewrite. Let it be the method of last resort.
> Find a model that allows the logic, data structures and code to live
> elsewhere. Leave data injection and formatting to the template
> generator/transformer. Look at Flow and find something like it.
> Maybe not exactly Flow, but a lot closer to it than the world of
> ASP/PHP/JSP and tag libraries.
Look, if you use a tool where taglibs is your main instrument for using
all kinds of problems you are certainly going to misuse it. But from the
fact that it is bad idea to use taglibs for everything you cannot infer
that it always is bad. IMO it is very useful for the kinds of cases I
have described earlier.
> I would prefer something like
>
> <Cats xmlns:data="http://org.apache/cocoon/data">
> <Cat data:context="${cats}" name="${name}" sex="${sex}" age="${age}"/>
> </Cats>
As allready said, if you participate in the development of template and
you flesh out some more details about how it is supposed to work, it
might be possible to allow such constructions in "template".
<snip/>
> Sure, macros can alleviate this. But macros are band-aids on a
> usability/design defect. This talk of macros and tag libraries I
> think has more to do with our frustrations with the current models
> than actual demonstrated need. So instead of a discussion about how
> the tag library API should be defined, why not make the simplest
> interface for the outside world first.
Please suggest such an interface.
> And only after that's done, talk about implementation details like
> tag libraries.
It's based on some rather lengthy email discussions please re-read the
archives http://marc.theaimsgroup.com/?l=xml-cocoon-dev&r=1&w=2 ;) We
cannot discuss lofty ideas for ever, sooner or later it is time to
actually make chices, design and implement things. There will allways be
better ideas in the future (or some otherware), but in the end of the
day you must see what your current set ideas leads in practice and learn
from that.
> Do you logic in a real programming language. When you finish, pass
> the result to the template for styling/formatting.
>
> Or am I alone in these feelings? Pretty interfaces being stuck in the
> middle of big balls of mud!
I agree with many of your requirements, but I think that your
interpretation of what we are trying to acomplish is rather unfair.
Anyway, it is important that we are clear about what the big picture is
and not only about the technical details. And your questions (and
ramblings) give us a good oportunity to find out about that.
/Daniel
Re: [Design] JXTG 2.0 (Just say no!)
Posted by Miles Elam <mi...@pcextremist.com>.
Ummm... Hold on second while I don my flame-resistant underwear.
Okay folks, why are we making tag libraries/interfaces *at all*? I
mean it. I feel like a lemming being driven off a cliff.
Before continuing, I want to take a look at the history of web
technologies and major milestones. In the beginning, you had files and
web servers. Then people starting writing extensions to the web
servers and the dynamic web was born.
But the problems with patching your web server for even the slightest
dynamism were immediately obvious even in the early days of "a patchy
server". So CGI (Common Gateway Interface) was born and Perl rose up
as the dominant web language. Process creation overhead became an
issue as the web took off so techniques fro mitigating this were put in
like mod_perl, servlets, etc., but overall the process stayed the same.
While an improvement over what came before and most definitely useful,
embedding markup was an absolute pain. All sorts of hacks rose up to
programmatically write markup. But then a lot of people noticed at the
same time that a lot of their dynamic pages were mostly static markup
with only a token amount of logic. Thus the age of ASP, PHP, JSP, et
al. was born, and it was cool runnings for a while. If you needed a
lot of logic, you wrote code with a markup generation library. If you
only needed a little logic, you wrote a markup file with code markers
for logic.
Things started going south when people with no programming experience
started learning from those ASP, PHP, and JSP examples. They gleefully
added huge tracts of code in these files, giving new life to a much
maligned design pattern known as "big ball of mud". Soon everyone
starting getting stuck in the ever-increasing balls of mud. Simplify!
Encapsulate! Componentize!
We'll just add new markup. We'll call them "tag libraries" and put all
the code snippets into these markup fragments. Brilliant! Now the
people who don't know how to program can just write markup and coders
can write stuff further up the chain.
XSP was born at about this point, tag libraries and embedded Java in
all their splendor, enforcing well-formedness and driving popular usage
of Cocoon.
People still wrote logic in their markup though. And even the tag
libraries became more and more monstrous. A tag library for databases.
A tag library for data formatting. A tag library to make more tags.
A tag library to perform backend workflow. A tag library to do the
laundry and wash the dishes. Just to add insult to injury, some
academic gadflies coined the acronym MVC (Model-View-Controller) and
starting going on about something called SoC (Separation of Concerns).
Everything started going gonzo at that point. HTML was no longer
supposed to have styling info; that is now CSS's job. Our data
repositories may change -- and may or may not be relational databases
anymore. Hard-coding database connection strings, table names and
column names were frowned upon. Then this brilliant individual named
Ovidiu thought about how nice it would be to have continuations in web
development.
Flowscript has entered the building! (*enter angelic chorus*) Here we
had logic in a separate file that generated data structures for display
and formatting by the templating language.
-------------------------- o0O0o -------------------------
Why tag libraries? To deal with the excessive code in the markup. If
you really need code in markup for your corner case, tag libraries
aren't going to help the situation much. You need code.
So here we stand discussing how to go back to big balls of tag library
mud. We have a glimpse of better things with Flow. Why aren't we
examining that model for further direction? Why are we going
backwards? Arbitrary Java code executing in the markup but with a
prettier face? Great. I'm so happy, I could eat the six month old
leftovers rotting in my friend's tupperware.
CAN' T WE COME UP WITH A BETTER IDEA!?! There are some really smart
people on this list. C'mon!
What have tag libraries been used for?
1. A macro language
2. Data generation
3. Data formatting
4. Backend processing
5. Making programming languages out of markup
6. Data replacement
Let's go down the list.
1. A macro language
XSLT or any of the other markup transformation syntaxes can handle
this. No code or tag API needed. STX: an easy-to-use syntax enabling
a SAX stream with a minimal memory footprint. Side effect-free.
Highly cacheable. The cached SAX events for JXTemplateGenerator are
put in the cache for future use -- same story with a
JXTemplateTransformer or any JXTemplate* successor or whatever.
Nothing lost by using a simple transformation language. The best part?
It's simple.
2. Data generation
Raise your hands. Let's see who you are that still thinks after all
that we've learned from web development history that
<esql:execute>SELECT * FROM MYTABLE WHERE COLUMN1 = 0</esql:execute> is
a good idea and the best we can come up with? I admit that I was one
of "those" people that was trying to get a standard relational database
API in Flow. So wrong. SO WRONG. I would like to thank the
developers on this list for their insight and wisdom on this point.
If you are savvy enough to write a Java class that implements the Tag
interface, you are certainly smart enough to write a POJO for use with
Hibernate (or whichever object persistence mechanism you prefer). In
fact, the way things are going and with the tools being made available,
the Tag interface is *harder*. And an implementation of Tag verses a
Javascript object or data structure? The difference in complexity
level isn't even funny.
3. Data formatting
Let's call a spade a spade here. We've got how many variations that
need to be handled?
boolean, integer types, floating point types, dates/timestamps,
strings, XML fragments, selection from limited choices (if 0, say
"none" -- if 1, say "one" -- if more, say "many"), and objects (which
are basically .toString() calls unless it has properties that are plain
old datatypes -- in which case you use the other handlers).
That's what? Seven different formatters? Done. Finished. Do we
really need a tag library for that? Make them reusable components that
transformers can use as needed.
4. Backend processing
We don't like to admit it, but we've all wondered, "What if this custom
tag could trigger a cache invalidation or do some workflow or..." Bad
idea. Bad idea. Backend processing in your markup template is a
horrible idea. Do it in an action or better yet in Flow.
5. Making programming languages out of markup
<foo:if>, <foo:for-each>, <foo:eval>, etc. Why the foreplay? If
you're gonna write a programming language, at least have the decency to
not base it on markup. These aren't really different from saying
<% if (test.isTrue()) { %>
<foo/>
<% } %>
or XSP's
<xsp:logic>
if (test.isTrue()) {
<foo/>
}
</xsp:logic>
IMO constructs like this should be context-dependent on the task at
hand. For example, wouldn't it have been easier if instead of
<jx:for-each var="person" items="${people}">
<jx:if test="${person.name != 'Mean Mike'} ">
<friend>${person.name}</friend>
</jx:if>
</jx:for-each>
you had
<friend jx:context="${people}" jx:test="${name != 'Mean
Mike'}">${name}</friend>
Same thing. Not a programming language though. Data injection
tailored to the task at hand. This is the problem domain that
JXTemplateGenerator is made to solve.
What is the for-each doing? Setting a scope -- a context. Look back
in the templates you've made. How many <jx:if> elements wrapped more
than one element? I have found in my general usage that well over 90%
of the time it's just the one child element. And those
<jx:chose/when/otherwise>... Be honest, how many times have you used
that for data formatting rather than structural changes to the markup?
Listing stuff like "yesterday" or "today" or "last week" instead of the
raw date. That's a boatload of markup to do what amounts to a
java.text.ChoiceFormat method call.
If it's that complex, why isn't it reflected in your data model instead
of your markup's wannabe programming language?
6. Data replacement
And here we come to the meat. This is where the I18nTransformer does
its magic. This where JXTemplateGenerator does its thing. One hit
wonders where the markup has been altered to fit the problem at hand,
not the general definition of a tag library. Where does the following
I18nTransformer example fit in?
<input type="submit" value="Submit" i18n:attr="value"/>
It can if all it does it translate <foo:i18n-submit/> to the above for
"real" processing. Stylesheet.
Data injection. That's what custom markup is really good for. It's a
domain-specific problem. Tag libraries are for general case problems.
But the general case is already handled by the existing transformers'
API.
-------------------------- o0O0o -------------------------
So what are the use cases that require tag libraries? More
specifically, what are the use cases that require tag libraries that
will be made cleaner by skipping XSP?
What would I prefer? Keep XSP as it is. It's shite, but it's powerful
shite. It's for the edge; those pesky corner-cases that refuse to go
away; the last 1%.
* XSP is Cocoon's mod_rewrite. *
Don't code around mod_rewrite. Let it be the method of last resort.
Find a model that allows the logic, data structures and code to live
elsewhere. Leave data injection and formatting to the template
generator/transformer. Look at Flow and find something like it. Maybe
not exactly Flow, but a lot closer to it than the world of ASP/PHP/JSP
and tag libraries.
I would prefer something like
<Cats xmlns:data="http://org.apache/cocoon/data">
<Cat data:context="${cats}" name="${name}" sex="${sex}" age="${age}"/>
</Cats>
and/or
<Cats xmlns:data="http://org.apache/cocoon/data">
<Cat data:context="${cats}">
<Sex>${sex}</Sex>
<Name data:test="${name}">${name}</Name>
<Age data:test="${age != -1}">${age}</Age>
</Cat>
</Cats>
I would prefer this to the current situation of
<Cats xmlns:jx="http::">
<jx:for-each var="cat" items="${cats}">
<Cat name="${name}" sex="${sex}" age="${age}">
</jx:for-each>
</Cats>
or
<Cats xmlns:jx="http::">
<jx:for-each var="cat" items="${cats}">
<Cat>
<Sex>${sex}</Sex>
<jx:if test="${cat.name != null}">
<Name>${cat.name}</Name>
</jx:if>
<jx:if test="${cat.age != -1}">
<Name>${cat.age}</Name>
</jx:if>
</Cat>
</jx:for-each>
</Cats>
Sure, macros can alleviate this. But macros are band-aids on a
usability/design defect. This talk of macros and tag libraries I think
has more to do with our frustrations with the current models than
actual demonstrated need. So instead of a discussion about how the tag
library API should be defined, why not make the simplest interface for
the outside world first. And only after that's done, talk about
implementation details like tag libraries.
Do you logic in a real programming language. When you finish, pass the
result to the template for styling/formatting.
Or am I alone in these feelings? Pretty interfaces being stuck in the
middle of big balls of mud!
- Miles Elam
Re: [Design] JXTG 2.0
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Leszek Gawron wrote:
> Daniel Fagerstrom wrote:
>
>> Leszek Gawron wrote:
>
<snip/>
>>> Should we create a separate block for JXTG 2.0? I think scratchpad
>>> would be enough for now. WDYT?
>>
>> Create a separate block. We will add taglibs for JXTG1 functionality,
>> CForms and maybe ESQL2 to it. So a separate block certainly make
>> sense. Scratchpad is IMO just for isolated components, not for
>> collections of components that work together like in this case.
>
> Should we vote on that? If not I'll create a new block on Monday.
No need to vote for creating an unstable block AFAIK. Asking for peoples
opinion when creating a new block is of course a good idea. But in the
current case we already have had a lot of discussion about the need for
JXTG replacement, so just go ahead and add the block.
I would propose that you call the block "template" rather than "jxtg".
JXTG doesn't say that much and it is not that relevant as we not are
going to depend on having only JXPath as expression language. If someone
have a better proposal than "template", we can take that instead, but it
is easy to change names in SVN so we can change later in that case.
/Daniel
Re: [Design] JXTG 2.0
Posted by Jonas Ekstedt <ek...@ibg.uu.se>.
On Sun, 2004-11-28 at 21:17 +0100, Leszek Gawron wrote:
Snip...
> Should we vote on that? If not I'll create a new block on Monday.
Just thought I'd mention that I added a new version of the jxtg block to
the bug yesterday. It supports expressions in templates.
The download contains both the jxtg block (with some updates) as well as
an el block (expression language). Currently only jexl is supported.
Cheers Jonas
Re: [Design] JXTG 2.0
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Daniel Fagerstrom wrote:
> Leszek Gawron wrote:
>
>> Jonas Ekstedt wrote:
>>
>>> On Wed, 2004-11-24 at 20:50 +0100, Daniel Fagerstrom wrote:
>>> Hello. I have made an attempt to implement what you describe above
>>> (filed it in bugzilla http://issues.apache.org/bugzilla/show_bug.cgi?
>>> id=25288). The block contains a JXTemplateGenerator that compiles a
>>> template to a script, caches it and then invokes it.
>>
>>
>> Gosh you're fast.
>
> +1000 ;)
>
> Although I envy you a little that you got first. After having written
> about the design I realized that it would be great fun to implement it :)
>
> I'll be away during the weekend so I will not be able to take a look at
> the code and give any comments until after that.
>
> But from your work this far I assume that it is cool stuff.
>
>> Should we create a separate block for JXTG 2.0? I think scratchpad
>> would be enough for now. WDYT?
>
>
> Create a separate block. We will add taglibs for JXTG1 functionality,
> CForms and maybe ESQL2 to it. So a separate block certainly make sense.
> Scratchpad is IMO just for isolated components, not for collections of
> components that work together like in this case.
Should we vote on that? If not I'll create a new block on Monday.
--
Leszek Gawron lgawron@mobilebox.pl
Project Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [Design] JXTG 2.0
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Leszek Gawron wrote:
> Jonas Ekstedt wrote:
>
>> On Wed, 2004-11-24 at 20:50 +0100, Daniel Fagerstrom wrote:
>> Hello. I have made an attempt to implement what you describe above
>> (filed it in bugzilla http://issues.apache.org/bugzilla/show_bug.cgi?
>> id=25288). The block contains a JXTemplateGenerator that compiles a
>> template to a script, caches it and then invokes it.
>
> Gosh you're fast.
+1000 ;)
Although I envy you a little that you got first. After having written
about the design I realized that it would be great fun to implement it :)
I'll be away during the weekend so I will not be able to take a look at
the code and give any comments until after that.
But from your work this far I assume that it is cool stuff.
> Should we create a separate block for JXTG 2.0? I think scratchpad would
> be enough for now. WDYT?
Create a separate block. We will add taglibs for JXTG1 functionality,
CForms and maybe ESQL2 to it. So a separate block certainly make sense.
Scratchpad is IMO just for isolated components, not for collections of
components that work together like in this case.
/Daniel
Re: [Design] JXTG 2.0
Posted by Jonas Ekstedt <ek...@ibg.uu.se>.
On Fri, 2004-11-26 at 22:23 +0100, Leszek Gawron wrote:
snip...
> > A difference with SaxBuffer is that SaxBuffer stores separate objects
> > for open and close event (eg startElement/endElement). The reason for
> > doing it this way is that it is now much easier to play parts of the
> > buffer. Eg if we want to play the body of the root element we know that
> > we should invoke the tokens between bodyStart and end (ie 1 to 7
> > inclusive)
> Can you differentiate <item></item> and <item/> in your implementation?
Not sure, it depends on whether SAX can differentiate between the two.
snip...
> > * I would really appreciate comments on exception handling as I don't
> > really know what is considered best practices.
> Which exceptions are you talking about?
I meant comments about how the exception handling could be refined in
the implementation. In order to make the code simpler to read my
strategy so far has been to either rethrow exceptions as
RuntimeException or declare that methods throws Exception just to make
the problem go away. However for a real implementation this could
perhaps be done better.
>
> One more thing: ScriptCompiler should store locator info for every tag
> so if the compilation error or runtime error gets thrown user can be
> informed of the exact place where problem occured.
I'll look into that.
Cheers Jonas
Re: [Design] JXTG 2.0
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Jonas Ekstedt wrote:
> On Wed, 2004-11-24 at 20:50 +0100, Daniel Fagerstrom wrote:
> Hello. I have made an attempt to implement what you describe above
> (filed it in bugzilla http://issues.apache.org/bugzilla/show_bug.cgi?
> id=25288). The block contains a JXTemplateGenerator that compiles a
> template to a script, caches it and then invokes it.
Gosh you're fast. This week I hadn't even time to keep up with the
mailing list.
> Script compilation
> ------------------
>
> A template is compiled into a Script by a ScriptCompiler. The script
> compiler consumes SAX events and stores tokens representing those events
> in the Script. Here's the Token interface:
>
> public interface Token {
> public int getStart();
> public void setStart(int start);
>
> public int getEnd();
> public void setEnd(int end);
> }
>
> As an example of what a Script might look like, consider the following
> xml snippet:
>
> <root>
> <item attr="1">
> Some text
> </item>
> <item attr="2">
> </root>
>
> If we disregard whitespace this will be translated to the following
> Script.
>
> PlainElementToken start=0, end=8, bodyStart=1, localname="root"
> PlainElementToken start=1, end=5, bodyStart=4, localname="item"
> AttributeToken start=2, end=4, localname="attr"
> CharactersToken start=3, end=4, characters="1"
> CharactersToken start=4, end=5, characters="Some text"
> PlainElementToken start=5, end=8, bodyStart=7, localname="item"
> AttributeToken start=6, end=8, localname="attr"
> CharactersToken start=7, end=8, characters="2"
>
> A difference with SaxBuffer is that SaxBuffer stores separate objects
> for open and close event (eg startElement/endElement). The reason for
> doing it this way is that it is now much easier to play parts of the
> buffer. Eg if we want to play the body of the root element we know that
> we should invoke the tokens between bodyStart and end (ie 1 to 7
> inclusive)
Can you differentiate <item></item> and <item/> in your implementation?
> Another difference that can be seen above is that attributes are stored
> as tokens in the script just like any other type of SAX event. The
> beauty of this approach is that when expression tokens are introduced
> there will be no difference between how expressions in body content are
> stored to expressions in attributes. For example:
>
> <root attr="AA ${1+1} BB">
> CC ${2+2} DD
> </root>
tricky ! :)
> Tags
> ----
>
> In addition to the tokens mentioned in the samples above a user can make
> custom tags by implementing the Tag interface.
>
> public interface Tag extends ElementToken {
> public void invoke(JXTGContext context) throws Exception;
> }
>
> public interface ElementToken extends Token {
> public int getBodyStart();
> public void setBodyStart(int bodyStart);
> }
>
> A Tag is a Token and is placed inside the Script just like other tokens
> (so they need to be thread safe). The ScriptCompiler uses a
> TagRepository (configured in the generator entry in sitemap.xmap) to
> differentiate between registered tags (stored as TagS in the Script) and
> normal elements (stored as PlainElementTokenS).
>
>
> Script invokation
> -----------------
>
> When the script has been compiled and cached it is then invoked by a
> ScriptInvoker. The ScriptInvoker walks through the script and fires of
> the appropriate SAX events. When it stumbles upon a Tag it executes
> Tag.invoke(context). The tag has the choice of firing off SAX of its own
> or invoking its body through AbstractTag.invokeBody(context).
>
>
> Cache handling
> --------------
>
> Unfortunately I don't know all that much about how cacheing works so the
> implementation can best be described as naive in that respect.
The script should be able to store a map of directives/processing
instructions.
<root>
<core:processing-instruction name="cache-key"
value="${bizData.calculateCacheKey()}"/>
<core:processing-instruction name="cache-validity"
value="${bizData.calculateCacheValidity()}"/>
Via a processing instruction the user defines the cache-key and
cache-validity. It is user's responsibility to implement appropriate
logic. Cocoon queries the generator for caching info and the generator
returns what the user has set up. That's all.
I will take care of that as I have implemented the first (faulty :))
caching in JXTG.
> * I would really appreciate comments on exception handling as I don't
> really know what is considered best practices.
Which exceptions are you talking about?
One more thing: ScriptCompiler should store locator info for every tag
so if the compilation error or runtime error gets thrown user can be
informed of the exact place where problem occured.
> * What does JX stand for?
Good question.
This is I think the first post about JXTG:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105112321916125&w=2
Should we create a separate block for JXTG 2.0? I think scratchpad would
be enough for now. WDYT?
--
Leszek Gawron lgawron@mobilebox.pl
Project Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [Design] JXTG 2.0
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 26 nov. 04, à 21:24, Jonas Ekstedt a écrit :
> ...* Do you have any pointers on load testing? I tried JMeter but
> couldn't
> get it to work, are there any alternatives you could recommend? I..
Either wget [1] or ab [2] can be very useful for simple performance
testing.
Running several instances of ab in parallel can give you meaningful
figures in a very simple way - but you'll have to find out if your
pages are cached or not (maybe switch to noncaching pipelines to be
sure) to know what you're measuring.
-Bertrand
[1] http://www.gnu.org/software/wget/wget.html
[2] http://httpd.apache.org/docs-2.0/programs/ab.html
Re: [Design] JXTG 2.0
Posted by Jonas Ekstedt <ek...@ibg.uu.se>.
On Fri, 2004-11-26 at 21:24 +0100, Jonas Ekstedt wrote:
>
> Issues, questions
> -----------------
Forgot to mention which tokens I haven't implemented yet:
ExpressionToken
PrefixMappingToken
DocumentToken
IgnorableWhitespaceToken
ProcessingInstructionToken
SkippedEntityToken
All lexical events tokens
Cheers Jonas
Re: [Design] JXTG 2.0
Posted by Upayavira <uv...@upaya.co.uk>.
Jonas Ekstedt wrote:
> * I would really appreciate comments on exception handling as I don't
>
>really know what is considered best practices.
>
>
To my mind, the "best practice" is telling the user what was wrong, in a
clear and precise way. Take for example an error a colleague had today:
Right in the midst of jexl code, he had a NPE. I sat with him for 20
minutes hunting, only to find that he was doing <jx:forEach> on an
object that wasn't a collection. Now why didn't it say "you can only use
forEach on collection objects"?
JXTemplate is pretty awful in this way, in terms of its error reporting
(or lack thereof). A replacement that has error handling and reporting
built in from the ground up (including location details in the original
file - get that info into your compiled scripts), would be a huge leap
forwards in Cocoon usability.
>* What does JX stand for?
>
>
Based upon JXPath (or that's what I assume).
Regards, Upayavira
Re: [Design] JXTG 2.0
Posted by Jonas Ekstedt <ek...@ibg.uu.se>.
On Wed, 2004-11-24 at 20:50 +0100, Daniel Fagerstrom wrote:
snip
> I'll continue to describe a possible design of a template generator (TG)
> that uses pre-compilation and has customer tags. This will be done in
> three steps: We start with a trivial pre-compiled template language (TL)
> _without_ expressions ;) In the next step we add an expression language
> to it and we finish by adding executable tags.
>
>
> A Trivial Pre-Compiled "Template Generator"
> ===========================================
>
> This step is not that useful in it self, the result will just be an
> unnesecarilly complicated implementation of the file generator. This is
> for introducing some ideas.
>
> The pre-compiling TG works in two steps: First it compiles the content
> of the input source to a script, and store the script in its cache
> together with an approriate cache key. Then the cached script will be
> used as long as the cache key is valid. It is important that the script
> is thread safe otherwise it will be unsafe to reuse. As store, Cocoon's
> transient store could be used.
>
> In the second step the script is executed and SAX output is generated.
>
> The Trivial Script
> ------------------
>
> The task of the trivial "template generator" is to output its input
> template document as is :) For this task there allready is a feature
> complete script implementation in Cocoon; o.a.c.xml.SAXBuffer.
>
> The SAXBuffer contains a list of SAXBits where each SAXBit is an
> (immutable) representation of a SAX event. The SAXBit interface contains
> the method "send(ContentHandler)". And the SAXBuffer contains an inner
> class implementing SAXBit for each SAX event type.
>
> The SAXBuffer implements XMLConsumer which records the input events as
> list of SAXBits. It also implements XMLizable with the method
> "toSAX(ContentHandler)" that iterates through the recorded SAXBits and
> execute "send(ContentHandler)" on them.
>
> This far compiling a script means sending the input source to a
> SAXBuffer and executing a script means calling the "toSAX" method on the
> SAX buffer.
Hello. I have made an attempt to implement what you describe above
(filed it in bugzilla http://issues.apache.org/bugzilla/show_bug.cgi?
id=25288). The block contains a JXTemplateGenerator that compiles a
template to a script, caches it and then invokes it.
Script compilation
------------------
A template is compiled into a Script by a ScriptCompiler. The script
compiler consumes SAX events and stores tokens representing those events
in the Script. Here's the Token interface:
public interface Token {
public int getStart();
public void setStart(int start);
public int getEnd();
public void setEnd(int end);
}
As an example of what a Script might look like, consider the following
xml snippet:
<root>
<item attr="1">
Some text
</item>
<item attr="2">
</root>
If we disregard whitespace this will be translated to the following
Script.
PlainElementToken start=0, end=8, bodyStart=1, localname="root"
PlainElementToken start=1, end=5, bodyStart=4, localname="item"
AttributeToken start=2, end=4, localname="attr"
CharactersToken start=3, end=4, characters="1"
CharactersToken start=4, end=5, characters="Some text"
PlainElementToken start=5, end=8, bodyStart=7, localname="item"
AttributeToken start=6, end=8, localname="attr"
CharactersToken start=7, end=8, characters="2"
A difference with SaxBuffer is that SaxBuffer stores separate objects
for open and close event (eg startElement/endElement). The reason for
doing it this way is that it is now much easier to play parts of the
buffer. Eg if we want to play the body of the root element we know that
we should invoke the tokens between bodyStart and end (ie 1 to 7
inclusive)
Another difference that can be seen above is that attributes are stored
as tokens in the script just like any other type of SAX event. The
beauty of this approach is that when expression tokens are introduced
there will be no difference between how expressions in body content are
stored to expressions in attributes. For example:
<root attr="AA ${1+1} BB">
CC ${2+2} DD
</root>
=>
PlainElementToken start=0, end=8, bodyStart=5, localname="root"
AttributeToken start=1, end=5, localname="attr"
CharactersToken start=2, end=3, characters="AA"
ExpressionToken start=3, end=4, expression="1+1"
CharactersToken start=4, end=5, characters="BB"
CharactersToken start=5, end=6, characters="CC"
ExpressionToken start=6, end=7, expression="2+2"
CharactersToken start=7, end=8, characters="DD"
Note that I have made some simplifications regarding whitespace above.
Tags
----
In addition to the tokens mentioned in the samples above a user can make
custom tags by implementing the Tag interface.
public interface Tag extends ElementToken {
public void invoke(JXTGContext context) throws Exception;
}
public interface ElementToken extends Token {
public int getBodyStart();
public void setBodyStart(int bodyStart);
}
A Tag is a Token and is placed inside the Script just like other tokens
(so they need to be thread safe). The ScriptCompiler uses a
TagRepository (configured in the generator entry in sitemap.xmap) to
differentiate between registered tags (stored as TagS in the Script) and
normal elements (stored as PlainElementTokenS).
Script invokation
-----------------
When the script has been compiled and cached it is then invoked by a
ScriptInvoker. The ScriptInvoker walks through the script and fires of
the appropriate SAX events. When it stumbles upon a Tag it executes
Tag.invoke(context). The tag has the choice of firing off SAX of its own
or invoking its body through AbstractTag.invokeBody(context).
Cache handling
--------------
Unfortunately I don't know all that much about how cacheing works so the
implementation can best be described as naive in that respect.
Issues, questions
-----------------
* Do you have any pointers on load testing? I tried JMeter but couldn't
get it to work, are there any alternatives you could recommend? I
compared the generator to the original JXTemplateGenerator on a plain
document (no expressions or custom tags). It was a wee bit faster but I
checked it using the time comment generated on each page and I don't
know how reliable that is. Also I would suspect that the simplifications
in cache handling and lack of expression handling would affect the
result.
* The interfaces will probably have to undergo major changes to allow
for expression handling.
* I would really appreciate comments on exception handling as I don't
really know what is considered best practices.
* What does JX stand for?
Cheers Jonas