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
