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.
But...
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
cases).
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"
value="org.apache.forrest.document.HTMLSourceDocument"/>
<property name="xslt"
value="org.apache.forrest.plugin.input.xslt.html-to-docuemnt.xsl"/>
</bean>
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.
Ross
