forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Williams" <william...@gmail.com>
Subject Re: WM2006 - New internal format for the dispatcher
Date Fri, 30 Jun 2006 12:06:13 GMT
On 6/28/06, Thorsten Scherler <thorsten@apache.org> wrote:
> Hi all,
>
> I am playing ATM with extending the dispatcher with an internal format
> but found a sharp corner.
>
> Index:
> whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/internal .xmap
> ===================================================================
> ---
> whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/internal.xm ap     
(revisiĆ³n: 417245)
> +++
> whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/internal.xm ap     
(copia de trabajo)
>
> @@ -161,7 +157,18 @@
>            />
>          <map:serialize type="xhtml" />
>        </map:match>
>
> +      <map:match pattern="**.internal*">
> +        <map:generate src="cocoon:/resolve.structurer.{1}" type="jx">
> +          <map:parameter name="lenient-xpath" value="true" />
> +          <map:parameter name="getRequest" value="{1}" />
> +          <map:parameter name="getRequestExtension"
> value="internal{2}" />
> +        </map:generate>
> +        <map:transform type="dispatcher">
> +          <map:parameter name="request" value="{1}" />
> +          <map:parameter name="type" value="internal{2}" />
> +        </map:transform>
> +        <map:serialize type="xml" />
> +      </map:match>
>
> This lets you use an internal processing for the content. Like:
> <forrest:view type="internal" hooksXpath="/">
>     <forrest:contract name="games-to-document"
>       dataURI="cocoon://wm2006/matches-group.xml">
>       <forrest:property name="teams">
>         <jx:import uri="cocoon://wm2006/teams.xml"/>
>       </forrest:property>
>       <forrest:property name="mode"><jx:out
> value="${mode}"/></forrest:property>
>       <forrest:property name="ko">
>         <jx:import uri="cocoon://wm2006/matches-ko.internal1"/>
>       </forrest:property>
>     </forrest:contract>
>   </forrest:view>
>
> This internal format is our xdoc or xhtml2. The internal format will
> then be contacted by e.g. html contracts.
>
> <forrest:contract name="helper-document-to-html"
> dataURI="cocoon://wm2006/${request}.internal"/>
>
> Sometimes you will need to have some intermediate steps for producing
> the internal format out of your source. Mind the last * on <map:match
> pattern="**.internal*">, meaning if you add internal/, internal1/, ...,
> internalN/ directories and place the corresponding contracts in this
> directories, you can define multiple processing steps within one view.
>
> <forrest:views xmlns:forrest="http://apache.org/forrest/templates/1.0"
>   xmlns:jx="http://apache.org/cocoon/templates/jx/1.0">
>   <jx:template>
>     <jx:set var="getRequest" value="#{$cocoon/parameters/getRequest}"/>
>     <jx:set var="request"
>       value="${getRequest.substring(getRequest.lastIndexOf('/'))}"/>
>     <jx:import uri="cocoon://prepare.tiles.wm"/>
>     <forrest:view type="internal" hooksXpath="/">
>       <forrest:contract name="overview-to-document"
>         dataURI="cocoon://wm2006/standings.internal2"/>
>     </forrest:view>
>     <forrest:view type="internal1" hooksXpath="/">
>       <forrest:contract name="matches-to-standings"
>         dataURI="cocoon://wm2006/matches-group.xml"/>
>     </forrest:view>
>     <forrest:view type="internal2" hooksXpath="/">
>       <forrest:contract name="standings-to-overview"
>         dataURI="cocoon://wm2006/standings.internal1"/>
>     </forrest:view>
>   </jx:template>
> </forrest:views>
>
> The benefit over sitemap processing aka
>     <map:generate src="matches-group.xml" />
>     <map:transform src="{lm:transform.xml.matches-to-standings}" />
>     <map:transform src="{lm:transform.xml.standings-to-overview}" />
>     <map:transform src="{lm:transform.xml.overview-to-document}" />
>     <map:serialize type="xml" />
>
> Is the total re-usability of each step like using
> cocoon://wm2006/standings.internal2 in another view like:
> <forrest:views xmlns:forrest="http://apache.org/forrest/templates/1.0"
>   xmlns:jx="http://apache.org/cocoon/templates/jx/1.0">
>   <forrest:view type="internal1" hooksXpath="/">
>     <forrest:contract name="matches-ko"
>       dataURI="cocoon://wm2006/matches-ko.xml">
>       <forrest:property name="standing">
>         <jx:import uri="cocoon://wm2006/standings.internal2"/>
>       </forrest:property>
>     </forrest:contract>
>   </forrest:view>
> </forrest:views>
>
> The above examples are taken from some views that produces
> http://target-x.de/wm2006/timetable.html and
> http://target-x.de/wm2006/standings.html
>
> Now to the sharp corner is that you need to create multiple internal
> directories. Does not feel right.
>
> src/documentation/resources/themes/common/
> |-- css
> |   |-- another_common.css
> |   |-- common.css
> |   |-- pre_search_common.css
> |   `-- vs.css
> |-- html
> |   |-- blank.ft
> |   |-- bottom.vt.xml
> |   |-- export-link.vt.xml
> |   |-- footer.vt.xml
> |   |-- helper-document-to-html-title.ft
> |   |-- helper-document-to-html.ft
> |   |-- roundLogo.vt.xml
> |   |-- search-engines-main.ft
> |   |-- search-input.ft
> |   |-- searchStrip.vt.xml
> |   |-- standing-overview-to-html.ft
> |   |-- top.vt.xml
> |   `-- wm.vt.xml
> |-- images
> |-- internal
> |   |-- games-to-document.ft
> |   |-- games-to-form.ft
> |   |-- games-to-static.ft
> |   |-- genericMarkup.ft
> |   |-- matches-id.ft
> |   `-- overview-to-document.ft
> |-- internal1
> |   |-- matches-ko.ft
> |   `-- matches-to-standings.ft
> |-- internal2
> |   `-- standings-to-overview.ft
> `-- js
>     `-- search-engine.js
>
> If nobody objects I will commit the changes to the internal.xmap of the
> dispatcher and the dispatcher then supports the *.internal* format.
>
> salu2
> --
> thorsten
>
> "Together we stand, divided we fall!"
> Hey you (Pink Floyd)

So these "internal" formats act essentially like input plugins except
the output isn't necessarily an xdoc?  Either way, I don't see how
modularizing content could be a bad thing, go for it.

I think that it doesn't "feel right" might be because you're naming
them generic "internal1", "internal2", etc.  Other view/@types are
format-specific (e.g. html), right?  Why not stick with something like
that?

On the other hand, it seems that this is a slightly different use of
views (e.g. variable input and output), so a more difficult solution
might be to extend the views grammar to accept a view
type="conversion" with from/to attrs or something.

Just more or less thinking aloud...
--tim

Mime
View raw message