forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject [DISCUSS] feeder plugin contract in the view
Date Wed, 30 Mar 2005 08:28:26 GMT
Hello devs,

I wrote a feeder contract for the view plugin. 

The feeder plugin provide a way to display feed as xdoc. 

I wanted to extend on that. I wanted just a small box where only the
title of the item appear (till need some polishing). 

I wanted to configure how many item titles will be displayed (still to
be implemented).

 ... and all from the view (working fine). Why from the view? Because
you may have different rss-feeds for different sites. ;-)

<forrest:contract name="feeder">
      <forrest:properties contract="feeder">
        <forrest:property name="feeder" nugget="get.nugget.feeder">
            <feed id="shows">
	    <feed id="sf">
        <forrest:property name="feedConfig">
          <feed id="planetJava" maxItem="10" descr="false"/>

REMARK: I used the above urls because ApachePlanet is providing
malformed rss feed. :( I found out after a couple of hours debuging
time. ;-) The feeder plugin should validate that and give feedback about
it (just a remark).

That brings me to the actual problems. 
The feeder plugin provide content (nuggets) that I can use in my site
BESIDES the actual document. 

Now I would have to 
a) alter the generating pipeline and add the feed to the aggregation to
then use it in my contract or
b) request it as a "normal" xdoc or 
c) add the content to the view with a transformation.

I ended up to add it to the view (c). I actually did not use the feeder
plugin but rather copied one xsl from it, but that leads us to more
important questions that need discussion:

How should a contract request content other then the xdoc specific one?
How do we control that? I mean I am using the feeder plugin, that means
the user needs this plugin added to his properties. 

That will bring back an old discussion back about whether or not plugins
can have dependencies. IMO we have to consider this. 

Each plugin (e.g. feeder) can provide contracts for the view where
appropriate. Should I then create the contract in the view or in the
(e.g. feeder) plugin? If in the feeder plugin, how does the views plugin
knows the contract (and whether e.g. the feeder plugin is installed)?

One way would be that the plugin will copy the contract implementation
into the project implementation dir and the views is using it from
there. Now that leads us to nuggets.

Nuggets are extra content which are not coming from the xdocs (as main
content). This nuggets can be used by the contract. Nuggets has to be
requested by the contract. Nugget can need prior transformation before
processing it in the last step of the view processing.

I extended the views plugin to allow this BUT this is just an example
implementation to be able to better discuss possible solutions!!!

*Implemented solution*
I added a trigger (@nugget) to <forrest:property name="feeder"
nugget="get.nugget.feeder">. This is the resolving pipeline for the

What will happening is the following:
<map:match pattern="resolve.nugget.*.*"> gets the properties from the

This properties are the input pipeline for the transformation of the
feeder.fn (original feedDesc2RSS20.xsl). This is happening in <map:match
pattern="get.nugget.*.*">. The actual pipe is defined in the
forrest:property with @nugget="get.nugget.feeder".

Now we have the content that we need to transform with our feeder.ft in
the view as property by calling <map:match


Please discuss that because we should find a solution that has framework
character. IMO the implemented solution can be too inflexible.


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

View raw message