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
