forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thors...@apache.org>
Subject Re: status of "views" development (Was: svn commit: r292072)
Date Wed, 05 Oct 2005 07:29:30 GMT
El mié, 05-10-2005 a las 12:15 +1000, David Crossley escribió:
> 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?

jeje

They can do much more then simple xsl. That is "just" the viewHelper
part. View helper are doing mainly transformation. 

nugget-contracts are used to connect input plugins or any other business
service that provide data. They can e.g. contact your input plugin and
get the aggregate or you can let views collect everything. That is
finally a design decision. The only condition that have to be meet that
you can connect this services through cocoon://something. Where
something can be as well any uri. 

Hope that explains it a bit better, please keep on asking. ;-)

salu2
-- 
thorsten

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


Mime
View raw message