Re: Forrest history (was Re: svn commit: r384121)

[Maurice Gittens <ma...@salsamarathon.nl>]

Thorsten wrote:

> Actually ATM I am working on a POJO implementation of the dispatcher. I
> started this when Cyriaque asked for a better documentation of each
> component. http://marc.theaimsgroup.com/?l=forrest-dev&m=115528223213446&w=2

Cool.

> 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).

Performance is definitely something we need more of.

> 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). 

Yeah, but I think that the best ideas and code need to get merged somehow.

> 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.

As I see it, getting rid of Cocoon is not a goal. Instead, reducing unneeded 
complexity would be the goal. So if we can find a way to hide Cocoon behind a 
suitable interface that would be a good thing IMO.

> 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.

Yes. Imagine the situation for candidate developers like me.
I am a seasoned programmer in languages like C,C++ and Java. I am
not intimidated by complexity. But I have no motivation to learn Cocoon 
because I am not currently interested in any particular Web Application 
Framework. I am however very interested in generating content in a single 
format and outputting this content in different formats.

> 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. 

So I have noticed. Maybe this discussion is an opportunity work things out.

> 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.

Documentation only goes so far. If I look at the code and I don't "see" it 
happening I tend to loose interest. 

For example; a few years ago I used the Postgresql database on one of my 
projects. I started submitting patches to this project _because_ the code was 
easy to follow. So I could give something back. When my project was finished 
I moved on.

I think it would be a good thing if Forrest were to have such a design that 
scenarios such as presented in my example would be possible. 

> 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.

I look forward to looking at the POJO dispatcher. Like Ross' prototype
implementation I expect that it is relatively easy to understand.
Then all we need to figure out is the best way to integrate them.

> In either way (new/old) the underlying technology should never be from
> interest for an *user*. 
> 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
> API. 

I'm happy to agree with you.

Kind regards,
Maurice
-- 
No pare, sigue, sigue