forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject RE: [RT] A new Forrest implementation?
Date Thu, 17 Aug 2006 23:40:15 GMT
El jue, 17-08-2006 a las 18:37 +0200, Maurice Gittens escribió:
> Gav ... wrote:
> > Thanks for popping in and giving this update. This post along with David's
> > Sees me swinging towards taking a better look at Cocoon, what more it has
> > To offer that we have not yet utilised, and improving on what we already
> > Have.
> I would urge you to hesitate before you swing :-) for three reasons:
> 1. We have not yet seen Ross' prototype implementation.
> Even as a prototype it might provide grounds to further consider it as an 
> option.

Actually ATM I am working on a POJO implementation of the dispatcher. I
started this when Cyriaque asked for a better documentation of each

I am developing a clearer API. I said many times that the dispatcher is
designed not to be only usable in cocoon. Even now it would be possible
to use the dispatcher in a POJO environment. The pojo implementation is
using StAX (it is pretty fast and very cool).

Actually it strikes me a wee bit awkward that we brought up something
new instead enhancing e.g. the dispatcher as "new" implementation
(adding Ross ideas). 

> 2. We have not yet heard from Thorsten
> He might just provide us with a perspective not yet presented.

To be honest I am still not sure. Actually I did not want to answer
before I finished and committed the pojo dispatcher. I totally agree
that we need a total clean rewrite of forrest but do not clearly see the
benefit of dropping cocoon.

The real problem I see is best outlined by David. We do not have enough
samples nor documentation of *our* use of cocoon. The infamous i18n
example pretty much is a symptom of this. Like stated in some answer of
this thread it is not the "standard" usage as in cocoon, but we put a
wee bit more complexity to it (not documented it) and even cocoon
veterans are now having problem to understand our implementation.

Further we as community have failed to work to fully resolve 
differences of opinion. Best example is the dispatcher vs. skins. We are
not having the same direction. 

I do not see a new forrst implementation being different under the
current circumstances. We are still an open source project, still few
people enhance the docu and the samples, still ...  

The limited discussion about e.g. forrest-core.xconf shows that there
are parts of our code that are neither documented nor are there many
people familiar with. Yes, the complexity of *our* usage of cocoon is
quite heavy, but documentation will reduce this complexity. Removing
obsolete code even more.

See Carsten and Ross talking about the same thing with different words.
Yes, cocoon will change (and is), but does this automatically solve our
problems? I doubt it. Cocoon is trying to get on the diet for long time
now, they are aware of it and would welcome a helping hand.

The discussion between Tim and Ross about the measurement of complexity
comparing cocoon with xyz does not compute. In the end if we drop cocoon
another underlying framework will bring its part of complexity. Still
you need to dig in the internals of the framework to write optimal code.
In the end we as developer need to document our code in the same moment
we add it. If we do not add something but we understood an undocumented
part we need to write a paragraph about it. That reduces complexity.

I understand Ross point of what we have ATM can be made with less
overhead, agree to it and am interested in code samples.

> 3. It is my impression that the Forrest users can be partitioned into
> those with Cocoon skills and those lacking them.
> It seems that folks most inclined to give Cocoon the benefit of the doubt
> tend to be those with Cocoon skills. 

Can be. I have now some years of experience with cocoon and just like
it. Sure there are sharp corners, but the next new thing will have even
more in the beginning. Sure there are *a lot* of components that we *do
not* need, so why not remove them from our code base?

> I think we might want to discuss weather or not we feel that Cocoon skills 
> should be a prerequisite for non-trivial usage of Forrest.

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.

If you want to add new components to your project then you get in touch
with cocoon. That is right, but then you are a dev.

> > I was of the mind before that I didn't much care whether Cocoon stays or
> > Goes, but I'm thinking now we should at least take another good look at it.
> Is this not what we are doing as part of our current discussion?
> 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. ;)

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. 

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. 

> Currently, one needs to get up to speed with Cocoon before it is possible to 
> do non trivial things with Forrest and IMO this is not a good thing. 

That depends from where you coming from. For cocoonies that is heaven,
for other that is hard work. The new implementation will mixed it all up
again. Fair enough. 

> If we feel that the dependence of Forrest on Cocoon should be maintained then
> maybe we should indeed consider turning Forrest into a Cocoon component of 
> some kind.

We can create a pure block out of it and keep on focusing on cocoon,

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.

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. 

> However, unless we can insure that advanced Forrest usage does not require the 
> Forrest user to be a skilled Cocoon user I think we should depend less on 
> Cocoon and not more.

I think advanced user per definition should still only touch config
files (like a user but the power-user options). Meaning the user should
be limited to read the manual for all options and then fine tune its
installation. Yes, advanced Forrest usage should not require a skilled
Cocoon user. 

In either way (new/old) the underlying technology should never be from
interest for an *user*. 

> So, do we feel that Cocoon skills should be a prerequisite for non-trivial 
> usage of Forrest?

I think Java skills should be a prerequisite for non-trivial usage of
Forrest. How to connect new components to forrest should have a clear

For now this is certainly the cocoon one, but we can provide our one API
and component connectors. See the lenya usecase framework in 1.4 for an
example of such connectors.

...but we hardly have java code here in forrest in comparison with e.g.
lenya. Nor have we our one API.


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

View raw message