forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sina K. Heshmati" <>
Subject Re: Using javax.xml.xpath
Date Tue, 11 Dec 2007 13:15:35 GMT
Thorsten Scherler <> said:

> On Tue, 2007-12-11 at 11:54 +0100, Sina K. Heshmati wrote:
>> Thorsten Scherler said:
>> > On Mon, 2007-12-10 at 19:45 +0100, Sina K. Heshmati wrote:
>> >>
>> >> I've written a contract that generates an issue summary.
>> >
>> > How does this contract look like?
>> >
>> Here's the plugin code [2]. The contract is called 'baetle-issue-summary' and can
>> be found in [3].
> Try with:
>   <forrest:part>
>     <xsl:variable name="node" select="section[@id='issueDetails']"/>
>     <div id="issueDetails">
>       <h3>
>         <xsl:value-of select="$node/title[1]"/>
>       </h3>
>       <xsl:copy-of select="$node/table"/>
>     </div>
>   </forrest:part>
>> >> The result should be dispatched in the sidebar but it fails because it cannot
>> >> create a node --poor XPath support [1].
>> >
>> > How do you call it in your structurer?
>> >
>> <forrest:hook name="sidebar">
>>   <forrest:contract name="baetle-issue-summary"
>>                     dataURI="cocoon://#{$getRequest}.issueSummary.xml"/>
>> </forrest:hook>
> With above code changed, the result of the contract will be injected in
> the place where you call it. Meaning in our case within a <div
> id="sidebar"/>. Exactly what you want, not?
Actually yes, you solution suggesting to remove the @xpath worked quite well and the content
got injected under the right forrest:hook.

> Actually your content-baetle-link contract is doing it very right.
> If you leave the xpath expression the contract violates the philosophy
> of contracts in general since it is not flexible to place anywhere
> I/you/anyone ones. It always wants to be injected in
> "/html/body//div[@id='sidebar']". VERY BAD!
> The only case one is using <forrest:part xpath="/html/head"> is when you
> need to inject something in the head of the page (like your
> baetle-embedded contract).

OK. So I suspect we should stop using an attribute called @xpath as it turns out to be misleading
since there however exists only two possible positions, namely /html/head and /html/body.
Your argument though about not indicating in the contract itself where it will be injected
seems quite valid to me.

But the problem is that [4] and [6] are quite similar and the only difference is that in [6],
an extra contract has been called, but still I had to copy-and-paste all the other contract
calls. How could one avoid ending up maintaining a number of forrest:views with a lot of duplicate
content between them?

> "...
> <!-- forrest:part within this element the actual content is going to.
>    If you use no @xpath then we insert content on the current structurer
> position.-->
> <forrest:part>
>   Content going to the location defined by the structurer.
> </forrest:part>
> <!--If you want to inject the content into a certain DOM position and
>    *not* the current position in the structurer, you can use the @xpath attribute.
> -->
> <forrest:part xpath="/html/head">
>   Content going to a fixed location defined by the contract (here: /html/head).
> </forrest:part>
> .."
>> Notes:
>> (1) The hook is arbitrarily called 'sidebar' and is just an example, however a
>> less generic name e.g. 'baetleIssue' is preferred.
>> (2) The contract now uses the node generated by the wrapping hook to identify the
>> target node.
>> > Can you please outline what are you trying to do?
>> >
>> Now, the dispatcher selects the wrong target node, e.g. right before </body>
as a
>> place to insert the chunk generated by the contract, which is not the desired
>> behaviour. In other words, how can I have my content appear wherever I want and
>> keep the structurer as clean as possible?


>>[3] ${PLUGIN_HOME}/resources/themes/common/html/

View raw message