forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: [RT] A new Forrest implementation?
Date Fri, 18 Aug 2006 01:16:48 GMT
Thorsten Scherler wrote:
> Some in this thread are talking about the typical user and the typical
> dev. If there is the typical user of forrest, it would be the one
> downloading the release, install it and following our docu to create a
> simple documentation. In this process she does not have to touch cocoon.

This overlooks the point that the "average user" has to install this 
behemoth somewhere and they simply do not want to. I can list my 
clients, but I won't I'll just point you to the ASF itself.

>>I am certain you will agree that unneeded complexity in a resource drain and 
>>significantly inhibits progress. 
> Not sure whether we can find an underlying framework with no unneeded
> complexity. That is having the cake and eating it. ;)

The problem is *visible* and unnecessary complexity. Users should see no 
complexity. We have hear from some users in this thread that they feel 
Forrest is complex. However, that is not my main driving force in this 
RT. I don't see the user side of Forrest as complex - not for what can 
be achieved with a little effort.

No, my problem is when you want to do something as a dev. The learning 
curve is just too damn large. Sure, I build generators and transformers. 
I can knock them off in minutes. It really feels simple.


It is not simple to my clients. Therefore it is not simple to potential 
new devs.

> Seriously, there are a couple of fundamental components that we need to
> develop ourselves when dropping cocoon. Cocoon still is a MVC component
> itself. Not lets say we will use Struts instead. Comparing the sitemap
> with the struts.xml regarding mapping gives me the shiver. Cocoon really
> has awesome stuff. 

Why does Forrest, a publishing framework, need an MVC webapp framework?

If someone has a use case that needs and MVC webapp then Forrest should 
not force them into using Cocoon (or any other framework). I agree 
Cocoon kicks Struts ass, but then Wicket kicks Cocoons ass. This month I 
want to use Wicket, last month I was using Struts - it all depends n 
what the client wants.

I can, and in the past I have, used Forrest as a server and simply made 
requests from whatever webapp framework the client has. But they resist 
installing and maintaining yet another server when they do not see the 
need. Add to this the *very* steep learning curve to adding a new 
document type after I have left for another contract and they flat out 
refuse to accept the design.

My clients are no different to other potential users and devs of Forrest.

> Paul said one of his favorite feature is forrest run and yes I agree. It
> is coming for free. The underlying copyless idea (build does not
> senseless copy files around) gives you a change/refresh cycle directly
> in the source. I do not want to miss stuff like this. 

My prototype already has it :-P (see my next mail) It is not Cocoon that 
provides this stuff.

> Further (independent from cocoon vs. new)  develop wrapper code and
> reusable helper classes apart from cocoon. That is the point I want to
> prove with the POJO dispatcher. I develop in POJO and then will write a
> generator/transformer that connects to my components/classes. This way
> the implementation is usable regardless how this discussion ends.

This is similar to what David suggests, only the other way around. David 
said create a generic Cocoon input and output plugin and this allows 
Cocoon to be used by those who love it (which includes me in some use 

I like that you are removing the Dispatchers dependency on Cocoon. I 
should be able to plug it straight into my prototype as an output plugin 
(would be a good test case for us both).

> As soon you are trying to do something not trivial you will touch java
> code. You will always develop your components against an API that you
> have to be familiar with. Be it Avalon or Spring. 

There is no need to know anything of the container API. You do need to 
know how to write the XML to inject a new plugin into the application 
which is something like:

<bean id="htmlInputPlugin"
   class="org.apache.forrest.plugin.input.xslt.Generic" >
     <property name="type"
     <property name="xslt" 

As for the Forrests API, that only needs to be really simple. Forrest is 
doing something really simple (input -> internal -> output) so it 
doesn't need a huge API.

See my next mail for more info on this.


View raw message