forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thors...@apache.org>
Subject DispatcherTransformer.java - Contract injection proposal (was Re: [RT] future of v2)
Date Mon, 21 Nov 2005 11:05:31 GMT
El mié, 16-11-2005 a las 16:24 +0000, Ross Gardler escribió: 
> Thorsten Scherler wrote:
> > El jue, 10-11-2005 a las 16:36 +0100, Thorsten Scherler escribió:
> > 
> >>Hi all,
> >>
> >>I am working on some java classes that should become the dispatcher
> >>core. While doing it I thought about the usage of contracts. We are now
> >>doing a parallel processing which has influence on the performance. 
> >>
> >>Introducing jx:import reduced a wee bit the build time and the recent
> >>update of the lm a lot more. Still it is too slow. Doing some process
> >>consulting on v2 we pointed out that the xsl magic is slowing as well
> >>things down. The idea has to be to slim down the processing. 
> >>
> >>IMO contracts have to work standalone. Meaning that the dispatcher will
> >>call the contract with the given properties and include the *result* and
> >>not raw-data and xsl. 
> > 
> > 

...

I now have a first working DispatcherTransformer.java. It is basically
transforming contracts to the resulting transformation markup. We still
need to decide one thing, see below.

> [WARNING - these are off the top of my head thoughts with very little 
> consideration - beware of deep potholes]

...

> >>d) transform hooks into format specific markup
> >>e) transform all above to the final page
> >>
> >>The question is how can we make contracts more generic. One way is to
> >>get rid of head|body="true|false". I thought that each contract has to
> >>provide this information from the resulting transformation.
> > 
> > 
> > Above contract solved the issue.
> 
> Does it?
> 
> A potential problem with the proposed approach is that it is still quite 
> specific to the final output format, in this case HTML. This is not a 
> problem for Forrest, using XHTML2 as an intermediate format, but you 
> want the contracts to be independent of the format, so I guess something 
> a little more generic may be better.
> 

I totally agree and have implemented like this. Still there are one
thing we have not considered. 

> How about:
> 
> <content xpath="/html/body">
>    <!-- the HTML generated by the contract -->
> </content>
> 
> or an IMS Manifest output:
> 
> <content xpath="/IMSManifest/Items">
>    <!-- the Docbook generated by the contract -->
> </content>
> 
> or FO output:
> 
> <content xpath="/stylesheet">
>    <!-- the XSLT-FO output -->
> </conntent>
> 
> etc.
> 
> The xpath could be sepcified in the contract as above, 

That ignores that some format may have to insert content into a specific
location rather then in the structure defined in the structurer (*.fv).

Let me explain, guess we have following contract:
<xsl:stylesheet version="1.1" 
      xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
      <xsl:param name="nav-main-testing" select="/"/>
      <xsl:param name="nav-main-testing-test1" select="'test'"/>
      <xsl:template match="/" >
        <content xpath="html/body">
          <div id="tabs"> <xsl:comment>+ |start Tabs new
+</xsl:comment> 
            test1: <xsl:value-of select="$nav-main-testing-test1"/>
<xsl:copy-of 

select="$nav-main-testing/navigation/tab/ul[@id='nav-main']"/> 
            <xsl:comment>+ |end Tabs +</xsl:comment> </div>
        </content>
      </xsl:template>
    </xsl:stylesheet>

and following *.fv:
<forrest:view type="html">
    <forrest:css >
/* Extra css */
/* menu */
#leftbar {
  width: 25%;
  float: left;
  background: #CCCCFF;
  border: thin solid #000000;
}
/* The actual content */
#content {
  margin-left: 25%;
  padding: 0 20px 0 20px;
  background: #B9D3EE;
}
    </forrest:css>
    <forrest:hook name="test">
      <forrest:contract name="nav-main-testing" 
        nugget="cocoon://index.navigation.xml">
        <forrest:property name="nav-main-testing-test1"
>x</forrest:property>
        <forrest:property name="nav-main-testing-test2" >
          <foo/>
        </forrest:property>
      </forrest:contract>
    </forrest:hook>
  </forrest:view>

The DispatcherTransformer will output:
<forrest:views xmlns:forrest="http://apache.org/forrest/templates/1.0" 
  xmlns:jx="http://apache.org/cocoon/templates/jx/1.0">
<forrest:css>
/* Extra css */
/* menu */
#leftbar {
  width: 25%;
  float: left;
  background: #CCCCFF;
  border: thin solid #000000;
}
/* The actual content */
#content {
  margin-left: 25%;
  padding: 0 20px 0 20px;
  background: #B9D3EE;
}
  </forrest:css>
  <forrest:hook name="test">
    <content xpath="html/body">
      <div id="tabs"><!--+ |start Tabs new +-->test1: x <ul
id="nav-main"><li 
        class="current"><a class="base-selected" 
        href="index.html">Home</a></li><li><a class="base-not-selected"

        href="samples/index.html">Samples/Tests</a></li></ul><!--+
|end
Tabs +-->
        </div>
    </content>
  </forrest:hook>
</forrest:views>

You see here that the actual location of the content is now:
/forrest:views/forrest:hook/content
telling that @xpath should be xpath="html/body".

Now that would not the right location since it should be insert into 
xpath="html/body{$path-in-structurer}". Here "/forrest:hook/content"

Assuming forrest:hook will be transformed to div id="test" the location
would be
xpath="html/body/div[@id='test']"

I call this <content xpath="html/body"/> xpath structure aware, because
it is more a xpath prefix then a fixed location.

Now think you would add 
<content xpath="html/head">
 <something/>
</content>

That should not be aware of the structure. It should be insert in the
fixed location "html/head" otherwise you would get invalid markup.

To solve this problem I would like to propose to add an attribute
fixedLocation="true|false". So this makes 
<content xpath="html/head" fixedLocation="true">
 <something/>
</content>

I propose to make the default fixedLocation="false". That means the
content will be injected in the overall structure defined by the
structurer (*.fv), the content is structure aware.

If we solve this issue I can check in a first version of the
transformer.


> or could be 
> overidden in the view definition:
> 
> <forrest:contract name="nav-main-testing"
> nugget="cocoon://#{$cocoon/parameters/getRequest}.navigation.xml"
> xpath="/html/body/section[position() = 2]"/>
> 
> (not sure why we would do that, but you never know)
> 

Hmm, ATM I do not see that either because the xpath is defined by the structurer, isn't it?

WDYT?

salu2
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)


Mime
View raw message