forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <cross...@apache.org>
Subject Re: status of "views" development (Was: svn commit: r292072)
Date Wed, 05 Oct 2005 02:15:44 GMT
Thorsten Scherler wrote:
> David Crossley escribi??:
> > Thorsten Scherler wrote:
> > > David Crossley escribi??:
> > > > Thorsten Scherler wrote:
> > > > > for the new plugins because the contracts have to request all content
> > > > > that they are using. There is no default pipeline anymore. 
> > > > 
> > > > What! Do you mean also the original source which provides
> > > > the main content?
> > > 
> > > Per definition there is no main content anymore. That is why I always
> > > said views are going to change forrest from ground up. In combination
> > > with the lm forrest could be used as renderer only.
> > 
> > What "definition" are you referring to?
> 
> The J2EE dispatcher view pattern.
>
> > I am going by the description at 
> > site-author/content/xdocs/TR/2005/WD-forrest10.html
> > 
> > The first two steps provide the initial content via an
> > input plugin, then views operate from Step 3 onwards
> > adding more content nuggets, functionality, and design.
> 
> No: 
>   request                                                    theme
>      |                                                         |
>     \|/                                                       \|/
> core (views) -> output plugin (views can bypass them) -> output/response
>    |   /|\
>   \|/   |
> +------------------+    +-----------------+
> |forrest:contracts |--->|  input plugin   |
> |forrest:properties|<---|src (+navigation)|
> +------------------+    +-----------------+
> 
> View is the one and only dispatcher that will only request what is
> needed. We do not have a linear processing anymore. Views are
> responsible to contact the src-resolver (1.) and dispatch/filter (2.).
> What I am trying to say (since my work with views started) is that 3. is
> done in the dispatching phase to not carrying content down the pipe that
> is not needed.

> Views are more then a structurer, mainly it is a
> dispatcher.
> 
> IMO it should be:
> 1) Resolver (view)
> 2) Filter (content as dispatched and determined by the view)
> 3) Xifier (content)
> 4) Windower (presentation)
> 5) Themer (presentation)
> 6) Serializer (presentation)

I will need to read and re-read to digest that.

The reason that i got concerned, and still am, is that
i have an input plugin that does pre-processing
of the initial source, e.g. request two different
sources, process them separately and aggregate them
using multiple sitemap matches, and then provide the
unified source as a table for the rest of forrest
to handle. Can views "contracts" do such complex
processing involving Cocoon pipelines, or are they
restricted to simple single xsl tasks?

-David

Mime
View raw message