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 component. http://marc.theaimsgroup.com/?l=forrest-dev&m=115528223213446&w=2 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, yes. 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 API. 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. salu2 -- thorsten "Together we stand, divided we fall!" Hey you (Pink Floyd)
