cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RFC] Plugable Expressions
Date Sat, 22 Jan 2005 14:03:18 GMT
Leszek Gawron wrote:
> Finally after 3 weeks I have some spare time that I can assignate for JXTG.


> Daniel Fagerstrom wrote:

>> I like the getNode method even less and would like to get rid of it. I 
>> introduced it as JXPath both has a getNode method that returns the raw 
>> object pointed to and a getValue that does some extra work on it, 
>> (like the irritating xsl:value-of stuff on DOM). Now 
>> Expression.evaluate basically does JXPath getValue and 
>> Expression.getNode does JXPath getNode.
> Could you describe the difference in more detail?

I don't know that much about it, I hoped that someone more knowledgeable 
about JXPath at the list would explain it. I also wonder how JXPath is 
used in the rest of Cocoon is the behaviour of getValue needed somewhere 
or would getNode work everywhere?

The main difference that I know about is that for DOM, getValue behave 
like xsl:value-of i.e. it returns the concatenated text nodes of the DOM 
as a string rather than the whole DOM tree. getNode is like xsl:copy-of 
for a DOM and returns the DOM object.

getNode always returns the actual object that the xpath points to while 
does some kind of transformation of the object for some object types. I 
didn't find any precise description of the difference in the 
documentation so we probably have to read the source to find out.

For JXTG, getNode is used for the value of jx:eval/@select, 
jx:out/@value, x:set/@value and for expressions in element content, 
everywhere else getValue or getIterator is used.

As there is no difference between getValue and getNode for Jexl in JXTG 
  one would assume that getNode could be use everywhere for JXPath, but 
maybe there is a difference for DOM and people don't use Jexl for DOM. 
Maybe getNode returns CharacterNodes instead of strings for DOM. If that 
is the case I would anyway prefer leting expressions always returning 
the actual object pointed to and let the (hopefully) forthcomming 
converter component take care of converting objects to strings.

>> I would prefer to get rid of the Expression.getNode method and have 
>> Let Expression.evaluate basically call JXPath getNode. But I don't 
>> know enough about the consequances for e.g. JXTG, any opinions?
> I see only one place now that could be problematic:
> <jx:set name="var" value="something"/>
> vs.
> <jx:set name="var">something</jx:set>
> Both are allowed and both should be treated differently.

They should, but I don't see how that is related to getNode/getValue? 
jx:set/@value uses getNode and jx:set/* executes the body and put the 
result in a DOM.

>> Questions
>> =========
>> * Is the design reasonable?
>> * Does it work for other ELs?
> There is only one more EL used in cocoon: XReporter EL. Should we take 
> it into account?

Yes we should. I don't know that much about XReporter EL, any volounters 
  for implementing it?


View raw message