Whoops; Sorry I sent this under the wrong subject. I guess I need to subscribe to the list...
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 -- Identity is: - the difference between 'this' and 'that', - not subject to change, - absolutely necessary.
