You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Thorsten Scherler <th...@apache.org> on 2005/03/30 10:28:26 UTC
[DISCUSS] feeder plugin contract in the view
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. ;-)
e.g.
<forrest:contract name="feeder">
<forrest:properties contract="feeder">
<forrest:property name="feeder" nugget="get.nugget.feeder">
<feedDescriptor>
<feed id="shows">
<url>http://m11.btefnet.net/torrents/backend.xml</url>
</feed>
<feed id="sf">
<url>http://sourceforge.net/export/rss2_projnews.php?group_id=96589</url>
</feed>
</feedDescriptor>
</forrest:property>
<forrest:property name="feedConfig">
<feed id="planetJava" maxItem="10" descr="false"/>
</forrest:property>
</forrest:properties>
</forrest:contract>
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
content.
What will happening is the following:
<map:match pattern="resolve.nugget.*.*"> gets the properties from the
view.
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
pattern="prepare.view-nugget.*">
WDYT?
Please discuss that because we should find a solution that has framework
character. IMO the implemented solution can be too inflexible.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [DISCUSS] feeder plugin contract in the view
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> On Fri, 2005-04-01 at 00:06 +0100, Ross Gardler wrote:
>
...
> Lets see the way we
> doing it right now as a later entry point in the pipe (after the
> aggregation of *.meta and *.fv). Maybe that feels better ;-)
Yes, lets see how it turns out.
>
> ...and IMO we have to discuss index.meta.xml pretty soon because that
> feels pretty right. ;-)
Aha! This is where I turn into a child again and run round shouting
"told you so! told you so!" :-P
As you say, I think we should come back to the whole meta data thing
when we get the views done, we can always move things around. For now,
just implement it the way you feel most comfortable with.
>>Even more importantly, at least for me, I think I am understanding what
>>you are doing now.
>>
>
>
> gracias, por fin, uno que. ;-)
>
> Actually you are not the only one that told me, (s)he do not understand
> the problematic and how to fit it with my suggestions. Greetings to
> Antonio and CheChe. ;-)
Yes, there is much to be said for writing the code to prove a point. I
must remember that and write more code and less emails.
Ross
Re: [DISCUSS] feeder plugin contract in the view
Posted by Thorsten Scherler <th...@apache.org>.
On Fri, 2005-04-01 at 00:06 +0100, Ross Gardler wrote:
> Thorsten Scherler wrote:
> > On Thu, 2005-03-31 at 18:36 +0100, Ross Gardler wrote:
> >
> > <snip what="lots of agreed stuff"/>
> >
> >>>>Lets return to your observation that "a forrest:view is comparable with
> >>>>a view on a table of a db. It is a subset of data". The key thing about
> >>>>a view in a database is that it does not contain any data, it only
> >>>>contains information about what data should be presented.
> >>>>
> >>>
> >>>
> >>>exactly.
> >>>
> >>>...but you can parse params to the view to specify which sets of data
> >>>you want have returned, right?
> >>
> >>Lets keep it simple at first - no paramaters (yet).
> >
> >
> > Hmm, what about
> > <forrest:contract name="feedback-dyn">
> > <forrest:properties contract="feedback-dyn">
> > <forrest:property name="main">
> > <feedback to="webmaster@foo.com"
> > href="mailto:webmaster@foo.com?subject=Feedback " >
> > Send DYNAMIC feedback about the website to:
> > </feedback>
> > </forrest:property>
> > </forrest:properties>
> > </forrest:contract>
> >
> > That would be a configuration that is used in the implementation
> > (skinning stage).
>
> Isn't that meta-data ("who is the site maintainer")?
>
> Meta-data belongs with the content.
>
> Which makes me think I was right to say:
<snip what="lots of agreed stuff"/>
> >>I guess it should be in the content since the user should be defining
> >>what is going to be displayed.
>
> Given your other example above I am now fairly sure this statement is
> correct, since the URL of the document generated from the feed is also
> site data.
>
> but ...
>
> > It seems you suggesting to add roles to the views. You recommend to keep
> > a shadow xdocs structure of views depending on roles.
>
> Yes, I was suggesting that, but now looking at you explaining it back to
> me I'm not sure I was heading in the right direction. There's too much
> duplication in the file structures. It reminds me of when we had a raw
> content directory and an xdocs directory. We got rid of that becasue it
> was too clunky. Now here I am coming up with the same idea for a
> different use case - not good.
>
> So...
>
> > Another alternative to implement such mechanism would be to add
> > something like the following in the view. In the spirit of
> > http://struts.apache.org/userGuide/struts-logic.html#notPresent
> >
> > <forrest:view type="xhtml">
> > <logic:notPresent name="user">
> > <forrest:contract name="login.form"/>
> > </logic:notPresent>
> > </forrest:view>
>
> This is much nicer and keeps the directory structure cleaner.
>
> ...
>
> > Now we found out that views are separated from skinning but I still
> > think that both stages can (and should) share the same config file.
> >
<snip what="lots of agreed stuff"/>
>
> I have some reservations. But I think you should just do what you need
> to do for now and I'll look for problems in the real code rather than in
> the idea.
>
> (the real meaning of this previous sentence is "it feels wrong, but I
> just tried to explain why it is wrong and got myself all confused" ;-))
>
Seeing your reply and understanding you (hopefully) a wee bit better, I
must say we have a trade off between clean dir structure (view contains
meta and get mocked up) or a clean view and a shadow dir structure of
*.meta (see your concerns above).
You tend to split the things apart to better reuse them. ;-) That means
as logical consequence we not only have a view file for the data but
also a meta data file (forrest:properties would go there and not in the
view).
data: index.xml
view: index.fv
meta: index.meta.xml
The way I have implemented it (metadata in the view) can (and I reckon,
will) be changed in the future if we see the views get to mocked up (I
think they'll tend to do so -> logic:..., ...). Lets see the way we
doing it right now as a later entry point in the pipe (after the
aggregation of *.meta and *.fv). Maybe that feels better ;-)
...and IMO we have to discuss index.meta.xml pretty soon because that
feels pretty right. ;-)
<snip what="lots of agreed stuff"/>
> > Yeah, thanks for you patients (looking on the date of the linked post)
> > to wait for the proof of concept. ;-)
>
> I thought you'd got it together pretty quick. Funny how people see these
> things differently.
>
:)
hmm, yeah I am still learning forrest and plugins, ... besides that if
you know something is not 100% right in your concept you will spend a
great deal of time to understand what it is. Now splitting views from
skins feels way better. ...and hopefully it will be now finished pretty
soon.
> > Your feedback really helped me to understand my problems.
>
> Even more importantly, at least for me, I think I am understanding what
> you are doing now.
>
gracias, por fin, uno que. ;-)
Actually you are not the only one that told me, (s)he do not understand
the problematic and how to fit it with my suggestions. Greetings to
Antonio and CheChe. ;-)
> >>We are witnessing the major addition for Forrest 0.8 (if only we could
> >>get 0.7 out ;-))
> >>
> >
> >
> > Yeah, sorry that I am not a great help for 0.7.
>
> That's not what I meant. I'm annoyed at myself for not finding more time
> for the 0.7 release - it's my usual problem - I'm getting excited by the
> new stuff and not finishing the old.
>
:) I guess that is another reason I was not faster because I am like
this too.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [DISCUSS] feeder plugin contract in the view
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> On Thu, 2005-03-31 at 18:36 +0100, Ross Gardler wrote:
>
> <snip what="lots of agreed stuff"/>
>
>>>>Lets return to your observation that "a forrest:view is comparable with
>>>>a view on a table of a db. It is a subset of data". The key thing about
>>>>a view in a database is that it does not contain any data, it only
>>>>contains information about what data should be presented.
>>>>
>>>
>>>
>>>exactly.
>>>
>>>...but you can parse params to the view to specify which sets of data
>>>you want have returned, right?
>>
>>Lets keep it simple at first - no paramaters (yet).
>
>
> Hmm, what about
> <forrest:contract name="feedback-dyn">
> <forrest:properties contract="feedback-dyn">
> <forrest:property name="main">
> <feedback to="webmaster@foo.com"
> href="mailto:webmaster@foo.com?subject=Feedback " >
> Send DYNAMIC feedback about the website to:
> </feedback>
> </forrest:property>
> </forrest:properties>
> </forrest:contract>
>
> That would be a configuration that is used in the implementation
> (skinning stage).
Isn't that meta-data ("who is the site maintainer")?
Meta-data belongs with the content.
Which makes me think I was right to say:
>>>Does this mean that:
>>><forrest:properties contract="feeder">
>>> <forrest:property name="feeder" nugget="get.nugget.feeder">
>>> <url>/feeds/somefeed.xml
>>> </forrest:property>
>>></forrest:properties>
>>>
...
>>
>>I guess it should be in the content since the user should be defining
>>what is going to be displayed.
Given your other example above I am now fairly sure this statement is
correct, since the URL of the document generated from the feed is also
site data.
but ...
> It seems you suggesting to add roles to the views. You recommend to keep
> a shadow xdocs structure of views depending on roles.
Yes, I was suggesting that, but now looking at you explaining it back to
me I'm not sure I was heading in the right direction. There's too much
duplication in the file structures. It reminds me of when we had a raw
content directory and an xdocs directory. We got rid of that becasue it
was too clunky. Now here I am coming up with the same idea for a
different use case - not good.
So...
> Another alternative to implement such mechanism would be to add
> something like the following in the view. In the spirit of
> http://struts.apache.org/userGuide/struts-logic.html#notPresent
>
> <forrest:view type="xhtml">
> <logic:notPresent name="user">
> <forrest:contract name="login.form"/>
> </logic:notPresent>
> </forrest:view>
This is much nicer and keeps the directory structure cleaner.
...
> Now we found out that views are separated from skinning but I still
> think that both stages can (and should) share the same config file.
>
> The view is requesting a subset of data. This data will be later on
> prepared for presentation. IMO this connection makes it necessary to
> share a configuration file.
I have some reservations. But I think you should just do what you need
to do for now and I'll look for problems in the real code rather than in
the idea.
(the real meaning of this previous sentence is "it feels wrong, but I
just tried to explain why it is wrong and got myself all confused" ;-))
> I would now like to create leather again as skin implementation of the
> view concept. That means I will as well drop the leather-dev skin
> because it will grow to the leather plugin (aka fbits).
WHatever you need to do to explore your ideas is fine by me, I'll do my
best to keep up.
>>This is all starting to feel much more comfortable for me now. I think
>>we are tuning this nicely :-))
>>
>
>
> Yeah, thanks for you patients (looking on the date of the linked post)
> to wait for the proof of concept. ;-)
I thought you'd got it together pretty quick. Funny how people see these
things differently.
> Your feedback really helped me to understand my problems.
Even more importantly, at least for me, I think I am understanding what
you are doing now.
>>We are witnessing the major addition for Forrest 0.8 (if only we could
>>get 0.7 out ;-))
>>
>
>
> Yeah, sorry that I am not a great help for 0.7.
That's not what I meant. I'm annoyed at myself for not finding more time
for the 0.7 release - it's my usual problem - I'm getting excited by the
new stuff and not finishing the old.
Still I got a couple of patches done tonight.
Ross
Re: [DISCUSS] feeder plugin contract in the view
Posted by Thorsten Scherler <th...@apache.org>.
On Thu, 2005-03-31 at 18:36 +0100, Ross Gardler wrote:
<snip what="lots of agreed stuff"/>
>
> >>Lets return to your observation that "a forrest:view is comparable with
> >>a view on a table of a db. It is a subset of data". The key thing about
> >>a view in a database is that it does not contain any data, it only
> >>contains information about what data should be presented.
> >>
> >
> >
> > exactly.
> >
> > ...but you can parse params to the view to specify which sets of data
> > you want have returned, right?
>
> Lets keep it simple at first - no paramaters (yet).
Hmm, what about
<forrest:contract name="feedback-dyn">
<forrest:properties contract="feedback-dyn">
<forrest:property name="main">
<feedback to="webmaster@foo.com"
href="mailto:webmaster@foo.com?subject=Feedback " >
Send DYNAMIC feedback about the website to:
</feedback>
</forrest:property>
</forrest:properties>
</forrest:contract>
That would be a configuration that is used in the implementation
(skinning stage).
>
> >>The project data directories contain the data and meta-data about the site
> >>
> >
> >
> > Does this mean that:
> > <forrest:properties contract="feeder">
> > <forrest:property name="feeder" nugget="get.nugget.feeder">
> > <url>/feeds/somefeed.xml
> > </forrest:property>
> > </forrest:properties>
> >
> > Should go there as well?
> > Or do you think that can be compared with passing param to a view (see
> > above)?
>
> I guess it should be in the content since the user should be defining
> what is going to be displayed. However, it probably doesn't want to get
> all mixed up with the content.
>
> How about:
>
> content/documentation/xdocs
> content/documentation/views/default
> content/documentation/views/user
> content/documentation/views/guest
>
> etc.
>
to get it straight for myself.
The views are working on a per document base with 2 fallback mechanism.
The fallbacks can be compared with the current situation, all sites will
be rendered the same.
1) If there is no view for the requested document the default.fv of the
project will get rendered.
2) If the project do not have this view the views-plugins default one
will be used.
Having this in the back of my head the above structure looks like a nice
extension of this concept.
It seems you suggesting to add roles to the views. You recommend to keep
a shadow xdocs structure of views depending on roles.
content/documentation/xdocs
content/documentation/xdocs/index.xml
content/documentation/xdocs/aboutUs.fv
content/documentation/views/default.fv
content/documentation/views/user/index.fv
content/documentation/views/user/aboutUs.fv
content/documentation/views/{role}/*.fv
Another alternative to implement such mechanism would be to add
something like the following in the view. In the spirit of
http://struts.apache.org/userGuide/struts-logic.html#notPresent
<forrest:view type="xhtml">
<logic:notPresent name="user">
<forrest:contract name="login.form"/>
</logic:notPresent>
</forrest:view>
> This should probably be taken to a vote so lets get something working
> now and we'll decide where it actually lives with a vote against your
> proof of concept.
>
;-) jejeje
ok.
> >>The input plugins convert the input data into the internal format
> >>
> >>The views contain information that describes what data should be
> >>displayed in response to a specific request
> >>
> >
> >
> > <forrest:view type="xhtml"/> -> for xhtml requests
> >
> > Agree, but right now it contains as well information about the placing
> > of elements.
> > <forrest:hook name="branding">
> > <forrest:contract name="projectlogo"/>
> > <forrest:contract name="searchbox"/>
> > <forrest:contract name="nav-main"/>
> > </forrest:hook>
> >
> > <forrest:hook/> is a method to add design information to the outcome. It
> > will be render as <div id="{forrest:hook/@name}"/>.
> >
> > Would that be ok? If not what do you suggest?
>
> This feels like the skinning end of things.
Yes. :) ...and that is where everything started. ;-)
> I can imagine a use case in
> which we define a "user" view and then allow each user to define their
> own layout.
>
:) Actually this is what I want to implement in the near future for my
own private website. That makes it necessary to parse the profiling data
to the view.
> Therefore, I suspect that it should be separated out. What do you think?
>
It is the skinning end but the start of all things. ;-)
The fbits plugin started because leather-dev was a dead-end. I learned
that you cannot force designer to use a specific html-skelleton for
their design.
>>From leather-dev comes the idea of contracts. Snippet of html that the
designer can request and add it to their templates. This should
originally be done by the view with hooks and contracts.
Now we found out that views are separated from skinning but I still
think that both stages can (and should) share the same config file.
The view is requesting a subset of data. This data will be later on
prepared for presentation. IMO this connection makes it necessary to
share a configuration file.
> >>The output plugins are responsible for skinning the data for display
> >>
> >
> >
> > Agree. That means all the *.ft that we have now in the view would have
> > to go to a new output plugin, right?
>
> From what I understand so far, yes.
>
Ok, I actually started the fbits plugin under the name of leather.
http://marc.theaimsgroup.com/?l=forrest-dev&m=109916818117512&w=2
I would now like to create leather again as skin implementation of the
view concept. That means I will as well drop the leather-dev skin
because it will grow to the leather plugin (aka fbits).
> > One question, can I use the view.fv as config file for the skinning
> > stage as well?
>
> Since views are now an internal plugin we can define new document
> schemas for passing information down the pipeline since they will be
> part of the internal system. Therefore, I do not perceive a problem with
> that.
>
ok
> > Resume:
> > project data -> input plugins -> views -> output
> >
> > Request/response circle:
> > 1) The CLIENT requests an url
> > 2) The url is linked to a view which will request
> > 3) the content from an input plugins, which will request the
> > 4) project data
> > 5) then the view sends the aggregation of 3/4 to the
> > 6) skinning stage which will
> > 7) response the CLIENT
> >
> > The next steps would be to move the contracts pipes and implementations
> > to an output plugin. Change the views plugin to an internal plugin.
>
> This is all starting to feel much more comfortable for me now. I think
> we are tuning this nicely :-))
>
Yeah, thanks for you patients (looking on the date of the linked post)
to wait for the proof of concept. ;-)
Your feedback really helped me to understand my problems.
> We are witnessing the major addition for Forrest 0.8 (if only we could
> get 0.7 out ;-))
>
Yeah, sorry that I am not a great help for 0.7.
> Ross
muchas gracias
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [DISCUSS] feeder plugin contract in the view
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> On Thu, 2005-03-31 at 14:53 +0100, Ross Gardler wrote:
>
>>Thorsten Scherler wrote:
>>
<snip what="lots of agreed stuff"/>
>>Lets return to your observation that "a forrest:view is comparable with
>>a view on a table of a db. It is a subset of data". The key thing about
>>a view in a database is that it does not contain any data, it only
>>contains information about what data should be presented.
>>
>
>
> exactly.
>
> ...but you can parse params to the view to specify which sets of data
> you want have returned, right?
Lets keep it simple at first - no paramaters (yet).
>>The project data directories contain the data and meta-data about the site
>>
>
>
> Does this mean that:
> <forrest:properties contract="feeder">
> <forrest:property name="feeder" nugget="get.nugget.feeder">
> <url>/feeds/somefeed.xml
> </forrest:property>
> </forrest:properties>
>
> Should go there as well?
> Or do you think that can be compared with passing param to a view (see
> above)?
I guess it should be in the content since the user should be defining
what is going to be displayed. However, it probably doesn't want to get
all mixed up with the content.
How about:
content/documentation/xdocs
content/documentation/views/default
content/documentation/views/user
content/documentation/views/guest
etc.
This should probably be taken to a vote so lets get something working
now and we'll decide where it actually lives with a vote against your
proof of concept.
>>The input plugins convert the input data into the internal format
>>
>>The views contain information that describes what data should be
>>displayed in response to a specific request
>>
>
>
> <forrest:view type="xhtml"/> -> for xhtml requests
>
> Agree, but right now it contains as well information about the placing
> of elements.
> <forrest:hook name="branding">
> <forrest:contract name="projectlogo"/>
> <forrest:contract name="searchbox"/>
> <forrest:contract name="nav-main"/>
> </forrest:hook>
>
> <forrest:hook/> is a method to add design information to the outcome. It
> will be render as <div id="{forrest:hook/@name}"/>.
>
> Would that be ok? If not what do you suggest?
This feels like the skinning end of things. I can imagine a use case in
which we define a "user" view and then allow each user to define their
own layout.
Therefore, I suspect that it should be separated out. What do you think?
>>The output plugins are responsible for skinning the data for display
>>
>
>
> Agree. That means all the *.ft that we have now in the view would have
> to go to a new output plugin, right?
From what I understand so far, yes.
> One question, can I use the view.fv as config file for the skinning
> stage as well?
Since views are now an internal plugin we can define new document
schemas for passing information down the pipeline since they will be
part of the internal system. Therefore, I do not perceive a problem with
that.
> Resume:
> project data -> input plugins -> views -> output
>
> Request/response circle:
> 1) The CLIENT requests an url
> 2) The url is linked to a view which will request
> 3) the content from an input plugins, which will request the
> 4) project data
> 5) then the view sends the aggregation of 3/4 to the
> 6) skinning stage which will
> 7) response the CLIENT
>
> The next steps would be to move the contracts pipes and implementations
> to an output plugin. Change the views plugin to an internal plugin.
This is all starting to feel much more comfortable for me now. I think
we are tuning this nicely :-))
We are witnessing the major addition for Forrest 0.8 (if only we could
get 0.7 out ;-))
Ross
Re: [DISCUSS] feeder plugin contract in the view
Posted by Thorsten Scherler <th...@apache.org>.
On Thu, 2005-03-31 at 14:53 +0100, Ross Gardler wrote:
> Thorsten Scherler wrote:
> > On Thu, 2005-03-31 at 01:55 +0100, Ross Gardler wrote:
> >
> >>Thorsten Scherler wrote:
> >>
> >>>I wrote a feeder contract for the view plugin.
> >>>
> >>>The feeder plugin provide a way to display feed as xdoc.
> >>>
> >>
> >></snip>
> >>
> >>>WDYT?
> >>>
> >>>Please discuss that because we should find a solution that has framework
> >>>character. IMO the implemented solution can be too inflexible.
> >>
> >>Hmmm... my solution seems far too simple and since I have not had the
> >>time to get into your views work yet I think I must be missing
> >>something. But here goes anyway...
> >>
> >>Use Case
> >>--------
> >>
> >>Create a page like this:
> >>
> >>_______________________________________________
> >>| | | |
> >>| | | |
> >>| | | RSS Feed |
> >>| | | |
> >>| Menu | | |
> >>| | -----------------
> >>| | Content |
> >>| | |
> >>| | |
> >>| | |
> >>| | |
> >>| | |
> >>-----------------------------------------------
> >>
> >>
> >>The Problem
> >>-----------
> >>
> >>How does the view get the RSS content without knowing how to render it
> >>*and* without having a dependency on the plugin that does the rendering
> >>(in this case the feeder plugin)
> >>
> >>Implementation
> >>--------------
> >>
> >>First let us consider what would happen if we were simply requesting a
> >>page where the RSS feed was the main content.
> >>
> >>Forrest would make a request for rssFeed.xml. This request would be
> >>examined by each plugin in turn, skipping over ones that do not know how
> >>to generate an XDoc response for the "rssFeed" document. Eventually we
> >>come to the feeder plugin, which says "hey, I can deal with this
> >>request". It reads a file, processes it with some XSL and returns an XDoc.
> >>
> >>This Xdoc is then processed by the skinning system. First it turns it
> >>into XHTML, then it adds the navigation sections and we are done.
> >>
> >>OK, so no problem so far.
> >
> >
> > Hmm, what happens if that is not matching?
>
> In that case Cocoon throws an error which we can trap in the error
> handling of the sitemap -
> http://cocoon.apache.org/2.1/userdocs/concepts/errorhandling.html
>
> >>Now we want to embed the nugget of RSS data
> >>into a separate part of the page, the main content is no longer the RSS
> >>data.
> >>
> >>However, if we look carefully at this we see that it isn't really any
> >>different at the generation stage, it is only at the skinning stage that
> >>things need to change.
> >
> >
> > Maybe I am to focused.
> >
> >>From the feeder plugin:
> > <map:match pattern="feeder/*.xml">
> > <map:generate src="{project:content.xdocs}/{1}.xml"/>
> > <map:transform src="resources/stylesheets/feedDesc2RSS20.xsl"/>
> > <map:transform src="resources/stylesheets/rss2document.xsl"/>
> > <map:serialize type="xml"/>
> > </map:match>
> >
> > The generation state needs here a feedDescriptor. This descriptor now
> > exists *only* in the view. It is NOT in {project:content.xdocs}/{1}.xml!
>
> That is only the case because that is the way you have implemented it at
> present. In need not stay that way if it causes problems.
>
+1
> I would argue that content should never be described in the view. It
> should only be described in the site contents. The feed descriptor is
> content, or at least it is meta-data telling us where we can find the
> final content. It certainly is not presentation information which is all
> a view should be concerned with.
>
> Before you moved it to the view it was in
> {project:content.xdocs}/{1}.xml. I see no need to move it, simply refer
> to it via the URI in the view:
>
> <forrest:contract name="feeder">
> <forrest:properties contract="feeder">
> <forrest:property name="feeder" nugget="get.nugget.feeder">
> <url>/feeds/somefeed.xml
> </forrest:property>
> </forrest:properties>
> </forrest:contract>
>
> Now instead of pulling the descriptor out of the nugget and transforming
> it with a stylesheet in the feeder plugin we simply generate
> cocoon://feeds/somefeed.xml and let the feeder plugin do the work.
>
+1
very nice. I will implemented like that.
> More on this later.
>
> >>The content to go in the RSS Feed box is still generated by requesting
> >>"rssFeed.xml",
> >
> >
> > no, in our case we cannot do it, better said I do not how. ;-) Any idea
> > how?
>
> In my view we have to find out how, otherwise we end up mixing content
> with layout, that is bad.
>
You just described how. ;-)
> Unfortunately, I still haven't been able to fully understand your work
> so far, so I'm just throwing out ideas. However, the benefit of this is
> that I am not trying to mold my ideas to your implementation, only to
> the concept you have created. The result may be a completely different
> implementation but it may help solve some of the problems you have come
> across so far.
>
Your feedback is perfect, this way we implement the best solution. :)
> >>we still get XDoc back. All that needs to change is how
> >>we skin it.
> >>
> >
> >
> > The part with delivering xdocs back is as well different in the view
> > contract. IMO we should take the change and move to
> > a subset of XHTML2 for the views and not base it on xdocs.
>
> When referring to XDoc I was referring to the Forrest internal format.
Me too.
> I'm happy to start the move to XHTML alongside the move to views. But
> first lets work out how views will work. That means for this test case
> we will should work with XDocs.
agree
>
> When we have 0.7 out the door then we can think about moving to XHTML.
>
> > I guess my definition of view is a wee bit different then yours. For me
> > a forrest:view is comparable with a view on a table of a db. It is a
> > subset of data that then get returned. The forrest:views decides which
> > data are needed. True the last stage is the skinning but that is not the
> > main focus of views.
>
> You raise a good point.
>
> Lets think about what Forrest does:
>
> Input data -> FORREST -> Output data
>
> The plugin architecture is designed to support each of the stages in
> this process. See
> http://forrest.apache.org/docs/dev/plugins/pluginInfrastructure.html#pluginTypes
>
> We are in a transition stage at present that has skins in the core, but
> they should really be in the output stage.
>
+1
> You point out that moving skinning out of core is only *partly* what
> this work is about.
>
Yes.
I think the former skins mechanism has to be split into an internal and
output plugin.
The internal plugin will pull the content (needed for the view) and
deliver it to the output plugin which looks up the implementation for
the specified format and displays it.
> However, in the process we have introduced a new concept. That of a
> forrest:view.
>
> You say "a forrest:view is comparable with a view on a table of a db. It
> is a subset of data" and you say skinning "that is not the main focus of
> views"
>
> I would agree that forrest:views are akin to database views, but I would
> go a step further in the distinction between skinning and a view.
>
> Skinning has *nothing* to do with views. It is a totally separate issue
> altogether. We can see this by looking back at the diagram in the above
> linked document:
>
> internal plugins
> (site.xml, abs-linkmap etc.)
> |
> \|/
> .
> input format --> intermediate format --> output format
> . .
> /|\ /|\
> | |
> input plugin output plugin
> (**.xml) (**.html, **.pdf etc.)
>
>
> Examining this diagram we see that views do not belong in output
> plugins, instead they belong in internal plugins. Only skinning should
> be in the output plugin.
>
> OK, so is the plugin infrastructure incorrect or is it the current
> design of views that are incorrect?
>
The current design of views. ;-)
Ok. The skinning now takes place in the forrest:templates.
Here we are storing the stylesheets that are needed for the last stage (transforming the content
and serialize it to the requested output format).
They belong in a output plugin.
The default.fv now defines which contracts should be rendered but as well defines which data is needed.
> Lets return to your observation that "a forrest:view is comparable with
> a view on a table of a db. It is a subset of data". The key thing about
> a view in a database is that it does not contain any data, it only
> contains information about what data should be presented.
>
exactly.
...but you can parse params to the view to specify which sets of data
you want have returned, right?
> However, in your current implementation you have data in the view. To be
> more accurate you have meta-data in the view. This meta-data is used to
> retrieve the real data, but it is still user data, it has no right in an
> output plugin.
>
> Similarly it has no right in an internal plugin.
> All data and meta-data must be available to Forrest at the very start of
> the pipeline, that is as an input format. There is the exception of
> dynamically generated meta-data such as indexes, but we are not dealing
> with that kind of data here.
>
> To summarise I believe:
>
> The project data directories contain the data and meta-data about the site
>
Does this mean that:
<forrest:properties contract="feeder">
<forrest:property name="feeder" nugget="get.nugget.feeder">
<url>/feeds/somefeed.xml
</forrest:property>
</forrest:properties>
Should go there as well?
Or do you think that can be compared with passing param to a view (see
above)?
> The input plugins convert the input data into the internal format
>
> The views contain information that describes what data should be
> displayed in response to a specific request
>
<forrest:view type="xhtml"/> -> for xhtml requests
Agree, but right now it contains as well information about the placing
of elements.
<forrest:hook name="branding">
<forrest:contract name="projectlogo"/>
<forrest:contract name="searchbox"/>
<forrest:contract name="nav-main"/>
</forrest:hook>
<forrest:hook/> is a method to add design information to the outcome. It
will be render as <div id="{forrest:hook/@name}"/>.
Would that be ok? If not what do you suggest?
> The output plugins are responsible for skinning the data for display
>
Agree. That means all the *.ft that we have now in the view would have
to go to a new output plugin, right?
> So it would appear that the plugins architecture is correct and that we
> have to split the views from the skinning.
>
:) ok agree
One question, can I use the view.fv as config file for the skinning
stage as well?
Resume:
project data -> input plugins -> views -> output
Request/response circle:
1) The CLIENT requests an url
2) The url is linked to a view which will request
3) the content from an input plugins, which will request the
4) project data
5) then the view sends the aggregation of 3/4 to the
6) skinning stage which will
7) response the CLIENT
The next steps would be to move the contracts pipes and implementations
to an output plugin. Change the views plugin to an internal plugin.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [DISCUSS] feeder plugin contract in the view
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> On Thu, 2005-03-31 at 01:55 +0100, Ross Gardler wrote:
>
>>Thorsten Scherler wrote:
>>
>>>I wrote a feeder contract for the view plugin.
>>>
>>>The feeder plugin provide a way to display feed as xdoc.
>>>
>>
>></snip>
>>
>>>WDYT?
>>>
>>>Please discuss that because we should find a solution that has framework
>>>character. IMO the implemented solution can be too inflexible.
>>
>>Hmmm... my solution seems far too simple and since I have not had the
>>time to get into your views work yet I think I must be missing
>>something. But here goes anyway...
>>
>>Use Case
>>--------
>>
>>Create a page like this:
>>
>>_______________________________________________
>>| | | |
>>| | | |
>>| | | RSS Feed |
>>| | | |
>>| Menu | | |
>>| | -----------------
>>| | Content |
>>| | |
>>| | |
>>| | |
>>| | |
>>| | |
>>-----------------------------------------------
>>
>>
>>The Problem
>>-----------
>>
>>How does the view get the RSS content without knowing how to render it
>>*and* without having a dependency on the plugin that does the rendering
>>(in this case the feeder plugin)
>>
>>Implementation
>>--------------
>>
>>First let us consider what would happen if we were simply requesting a
>>page where the RSS feed was the main content.
>>
>>Forrest would make a request for rssFeed.xml. This request would be
>>examined by each plugin in turn, skipping over ones that do not know how
>>to generate an XDoc response for the "rssFeed" document. Eventually we
>>come to the feeder plugin, which says "hey, I can deal with this
>>request". It reads a file, processes it with some XSL and returns an XDoc.
>>
>>This Xdoc is then processed by the skinning system. First it turns it
>>into XHTML, then it adds the navigation sections and we are done.
>>
>>OK, so no problem so far.
>
>
> Hmm, what happens if that is not matching?
In that case Cocoon throws an error which we can trap in the error
handling of the sitemap -
http://cocoon.apache.org/2.1/userdocs/concepts/errorhandling.html
>>Now we want to embed the nugget of RSS data
>>into a separate part of the page, the main content is no longer the RSS
>>data.
>>
>>However, if we look carefully at this we see that it isn't really any
>>different at the generation stage, it is only at the skinning stage that
>>things need to change.
>
>
> Maybe I am to focused.
>
>>>From the feeder plugin:
> <map:match pattern="feeder/*.xml">
> <map:generate src="{project:content.xdocs}/{1}.xml"/>
> <map:transform src="resources/stylesheets/feedDesc2RSS20.xsl"/>
> <map:transform src="resources/stylesheets/rss2document.xsl"/>
> <map:serialize type="xml"/>
> </map:match>
>
> The generation state needs here a feedDescriptor. This descriptor now
> exists *only* in the view. It is NOT in {project:content.xdocs}/{1}.xml!
That is only the case because that is the way you have implemented it at
present. In need not stay that way if it causes problems.
I would argue that content should never be described in the view. It
should only be described in the site contents. The feed descriptor is
content, or at least it is meta-data telling us where we can find the
final content. It certainly is not presentation information which is all
a view should be concerned with.
Before you moved it to the view it was in
{project:content.xdocs}/{1}.xml. I see no need to move it, simply refer
to it via the URI in the view:
<forrest:contract name="feeder">
<forrest:properties contract="feeder">
<forrest:property name="feeder" nugget="get.nugget.feeder">
<url>/feeds/somefeed.xml
</forrest:property>
</forrest:properties>
</forrest:contract>
Now instead of pulling the descriptor out of the nugget and transforming
it with a stylesheet in the feeder plugin we simply generate
cocoon://feeds/somefeed.xml and let the feeder plugin do the work.
More on this later.
>>The content to go in the RSS Feed box is still generated by requesting
>>"rssFeed.xml",
>
>
> no, in our case we cannot do it, better said I do not how. ;-) Any idea
> how?
In my view we have to find out how, otherwise we end up mixing content
with layout, that is bad.
Unfortunately, I still haven't been able to fully understand your work
so far, so I'm just throwing out ideas. However, the benefit of this is
that I am not trying to mold my ideas to your implementation, only to
the concept you have created. The result may be a completely different
implementation but it may help solve some of the problems you have come
across so far.
>>we still get XDoc back. All that needs to change is how
>>we skin it.
>>
>
>
> The part with delivering xdocs back is as well different in the view
> contract. IMO we should take the change and move to
> a subset of XHTML2 for the views and not base it on xdocs.
When referring to XDoc I was referring to the Forrest internal format.
I'm happy to start the move to XHTML alongside the move to views. But
first lets work out how views will work. That means for this test case
we will should work with XDocs.
When we have 0.7 out the door then we can think about moving to XHTML.
> I guess my definition of view is a wee bit different then yours. For me
> a forrest:view is comparable with a view on a table of a db. It is a
> subset of data that then get returned. The forrest:views decides which
> data are needed. True the last stage is the skinning but that is not the
> main focus of views.
You raise a good point.
Lets think about what Forrest does:
Input data -> FORREST -> Output data
The plugin architecture is designed to support each of the stages in
this process. See
http://forrest.apache.org/docs/dev/plugins/pluginInfrastructure.html#pluginTypes
We are in a transition stage at present that has skins in the core, but
they should really be in the output stage.
You point out that moving skinning out of core is only *partly* what
this work is about.
However, in the process we have introduced a new concept. That of a
forrest:view.
You say "a forrest:view is comparable with a view on a table of a db. It
is a subset of data" and you say skinning "that is not the main focus of
views"
I would agree that forrest:views are akin to database views, but I would
go a step further in the distinction between skinning and a view.
Skinning has *nothing* to do with views. It is a totally separate issue
altogether. We can see this by looking back at the diagram in the above
linked document:
internal plugins
(site.xml, abs-linkmap etc.)
|
\|/
.
input format --> intermediate format --> output format
. .
/|\ /|\
| |
input plugin output plugin
(**.xml) (**.html, **.pdf etc.)
Examining this diagram we see that views do not belong in output
plugins, instead they belong in internal plugins. Only skinning should
be in the output plugin.
OK, so is the plugin infrastructure incorrect or is it the current
design of views that are incorrect?
Lets return to your observation that "a forrest:view is comparable with
a view on a table of a db. It is a subset of data". The key thing about
a view in a database is that it does not contain any data, it only
contains information about what data should be presented.
However, in your current implementation you have data in the view. To be
more accurate you have meta-data in the view. This meta-data is used to
retrieve the real data, but it is still user data, it has no right in an
output plugin.
Similarly it has no right in an internal plugin.
All data and meta-data must be available to Forrest at the very start of
the pipeline, that is as an input format. There is the exception of
dynamically generated meta-data such as indexes, but we are not dealing
with that kind of data here.
To summarise I believe:
The project data directories contain the data and meta-data about the site
The input plugins convert the input data into the internal format
The views contain information that describes what data should be
displayed in response to a specific request
The output plugins are responsible for skinning the data for display
So it would appear that the plugins architecture is correct and that we
have to split the views from the skinning.
Ross
Re: [DISCUSS] feeder plugin contract in the view
Posted by Thorsten Scherler <th...@apache.org>.
On Thu, 2005-03-31 at 01:55 +0100, Ross Gardler wrote:
> Thorsten Scherler wrote:
> > I wrote a feeder contract for the view plugin.
> >
> > The feeder plugin provide a way to display feed as xdoc.
> >
>
> </snip>
>
> >
> > WDYT?
> >
> > Please discuss that because we should find a solution that has framework
> > character. IMO the implemented solution can be too inflexible.
>
> Hmmm... my solution seems far too simple and since I have not had the
> time to get into your views work yet I think I must be missing
> something. But here goes anyway...
>
> Use Case
> --------
>
> Create a page like this:
>
> _______________________________________________
> | | | |
> | | | |
> | | | RSS Feed |
> | | | |
> | Menu | | |
> | | -----------------
> | | Content |
> | | |
> | | |
> | | |
> | | |
> | | |
> -----------------------------------------------
>
>
> The Problem
> -----------
>
> How does the view get the RSS content without knowing how to render it
> *and* without having a dependency on the plugin that does the rendering
> (in this case the feeder plugin)
>
> Implementation
> --------------
>
> First let us consider what would happen if we were simply requesting a
> page where the RSS feed was the main content.
>
> Forrest would make a request for rssFeed.xml. This request would be
> examined by each plugin in turn, skipping over ones that do not know how
> to generate an XDoc response for the "rssFeed" document. Eventually we
> come to the feeder plugin, which says "hey, I can deal with this
> request". It reads a file, processes it with some XSL and returns an XDoc.
>
> This Xdoc is then processed by the skinning system. First it turns it
> into XHTML, then it adds the navigation sections and we are done.
>
> OK, so no problem so far.
Hmm, what happens if that is not matching?
> Now we want to embed the nugget of RSS data
> into a separate part of the page, the main content is no longer the RSS
> data.
>
> However, if we look carefully at this we see that it isn't really any
> different at the generation stage, it is only at the skinning stage that
> things need to change.
Maybe I am to focused.
>>From the feeder plugin:
<map:match pattern="feeder/*.xml">
<map:generate src="{project:content.xdocs}/{1}.xml"/>
<map:transform src="resources/stylesheets/feedDesc2RSS20.xsl"/>
<map:transform src="resources/stylesheets/rss2document.xsl"/>
<map:serialize type="xml"/>
</map:match>
The generation state needs here a feedDescriptor. This descriptor now
exists *only* in the view. It is NOT in {project:content.xdocs}/{1}.xml!
from the Views plugin:
<!--
Get the nugget (xml) of the requested contract.
This will e.g. produce the feedDescriptor.
-->
<map:match pattern="resolve.nugget.*.*">
<map:generate src="cocoon:/prepare.view.{2}"/>
<map:transform src="resources/stylesheets/nugget.xsl">
<map:parameter value="{1}" name="contract"/>
</map:transform>
<map:serialize type="xml"/>
</map:match>
<!--This will now transform the e.g. feedDescriptor-->
<map:match pattern="get.nugget.*.*">
<map:generate src="cocoon://resolve.nugget.{1}.{2}"/>
<map:transform src="resources/nuggets/{1}.fn"/>
<map:serialize type="xml"/>
</map:match>
What happen here is that I first prepare the generation stage by
extracting the descriptor from the view and then transform this
descriptor. The result will be saved as new forrest:property for the
final skinning page.
> The content to go in the RSS Feed box is still generated by requesting
> "rssFeed.xml",
no, in our case we cannot do it, better said I do not how. ;-) Any idea
how?
> we still get XDoc back. All that needs to change is how
> we skin it.
>
The part with delivering xdocs back is as well different in the view
contract. IMO we should take the change and move to
a subset of XHTML2 for the views and not base it on xdocs.
I guess my definition of view is a wee bit different then yours. For me
a forrest:view is comparable with a view on a table of a db. It is a
subset of data that then get returned. The forrest:views decides which
data are needed. True the last stage is the skinning but that is not the
main focus of views.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [DISCUSS] feeder plugin contract in the view
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> I wrote a feeder contract for the view plugin.
>
> The feeder plugin provide a way to display feed as xdoc.
>
</snip>
>
> WDYT?
>
> Please discuss that because we should find a solution that has framework
> character. IMO the implemented solution can be too inflexible.
Hmmm... my solution seems far too simple and since I have not had the
time to get into your views work yet I think I must be missing
something. But here goes anyway...
Use Case
--------
Create a page like this:
_______________________________________________
| | | |
| | | |
| | | RSS Feed |
| | | |
| Menu | | |
| | -----------------
| | Content |
| | |
| | |
| | |
| | |
| | |
-----------------------------------------------
The Problem
-----------
How does the view get the RSS content without knowing how to render it
*and* without having a dependency on the plugin that does the rendering
(in this case the feeder plugin)
Implementation
--------------
First let us consider what would happen if we were simply requesting a
page where the RSS feed was the main content.
Forrest would make a request for rssFeed.xml. This request would be
examined by each plugin in turn, skipping over ones that do not know how
to generate an XDoc response for the "rssFeed" document. Eventually we
come to the feeder plugin, which says "hey, I can deal with this
request". It reads a file, processes it with some XSL and returns an XDoc.
This Xdoc is then processed by the skinning system. First it turns it
into XHTML, then it adds the navigation sections and we are done.
OK, so no problem so far. Now we want to embed the nugget of RSS data
into a separate part of the page, the main content is no longer the RSS
data.
However, if we look carefully at this we see that it isn't really any
different at the generation stage, it is only at the skinning stage that
things need to change.
The content to go in the RSS Feed box is still generated by requesting
"rssFeed.xml", we still get XDoc back. All that needs to change is how
we skin it.
Ross