cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Ezkovich <>
Subject Re: [Design] JXTG 2.0 (Just say yes!)
Date Mon, 06 Dec 2004 23:36:20 GMT

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

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

View raw message