forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject Re: Lenya and forrest integration
Date Fri, 22 Apr 2005 07:45:15 GMT
On Thu, 2005-04-21 at 21:59 -0400, Gregor J. Rothfuss wrote:
> Thorsten Scherler wrote:
> > A view will be configured by a config file which basically contains the
> > following tags (it is still evolving): 
> > 
> > <forrest:view type="xhtml">
> >   <forrest:css url="default.css"/>
> >   <forrest:contract name="meta"/>
> >   <forrest:hook name="container">
> >    <!--the following tags are not implement yet but will give the idea ;-)-->
> >    <forrest:contract name="deleteUser" nugget="lenya:usecase">
> >     <lenya:usecase name="deleteUser"/>
> >    </forrest:contract>
> >    <!-- 
> >     In forrest that will invoke a businessHelper that connects a lenya usecase
> >     and stores the result of the usecase (in forrest terms: nugget) 
> >     in the presentation model. This part of the presentation model will be
> >     transformed by a forrest:contract (fbit) with the same name.
> >     -->
> >    <forrest:contract name="feedback"/>
> >   </forrest:hook />
> > </forrest:view>
> > 
> > The view tag's @type determines the final output format. The idea is to
> > configure different output formats within a forrest:views. That means a
> > forrest:views can contain n different "forrest:view" configurations for
> > n different formats. 
> i am not sure if i like all these config files and formats. looks a bit 
> like 'programming by config file' to me.

That is not programming! It is a configuration of components. 
I like it very much because I want to develop components that I can
easily reuse *without* copy and paste and afterward changing 1 line of

The format is chosen not to be limited again only on forrest or lenya. I
am sick of having multiple tools doing similar things and I have to find
out the way they work. With a common config file I do not care about the
underlying implementation. 

The idea is to program your own contract implementation without having
to copy and paste (like it is the preferred method in lenya land) a xsl
and finally just changing a couple of lines.

IMO lenya has to follow forrests "copyless" approach. It cannot be that
if I change a xsl I have to rebuild the app. 

That is leading the creation of cocoon in the first place to an absurd.
It was created to change xsl's, hit refresh on the browser and the
changes are there. 

Now you will say that is as well possible, yeah right, in the build, but
I am a dev, it has to work also in the src (like it to in forrest).

The views concept is copyless! It is a configuring file for components. 

...and IMO configuring is better then programming, why should I repeat
implementing the same code over and over again. Think about our user!

Copyless is the future.


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

View raw message