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
|