Merdes, Matthias pisze:
hi,
i agree with the last post.
both, better documentation and tool support are very much needed.
we are currently in a situation where we have to decide what to do with our
cocoon 'legacy' app:
-port to cocoon 2.2 (we want spring in the service layer anyway)
-port to another web framework altogether (struts, spring mvc/webflow,
tapestry, wicket, rife, what have you)
(staying with the old avalon-based architecture is not an option)
this is obviously a very hard decision involving a lot of risk and effort.
from my point of view the lack of
-internal documentation (getting started with with c2.2, how to migrate to c2.2 etc)
It really improves last days, special kudos to Reinhard.
-third-party technical articles
It's really hard to expect third-party technical articles for the stuff that
wasn't released yet...
-recent books, especially for c2.2 (there is a german one announced for fall...)
There are rumours that if it was successful it would be translated into
English. :-)
the same holds for eclipse tool support.
It's laughable that XML-oriented framework like Cocoon had no XML Schemas for all the syntax it uses. Really, from my expierience decent XML
editor (WTP in Eclipse, for example) powered by schemas can really boost development. We are aware of it and that's why we _have_ schemas in
C2.2.
a recent post mentioned the issue of winning new users for cocoon.
however, keeping legacy users from migrating to competing frameworks should be
considered as well.
The problem with providing structured documentation for migration process is that there were so many different approaches for developing
applications in C2.1. What is more, they are not covered in the existing documentation.
I would be happy to spend some time at the end of June (I'll be free at that time) and describe how to migrate but I would really like to
know the starting point for the migration process. If you provide details about blocks and libraries you use, how many your own components
and their role is in your application I can do my best to ease your migration process.
In short: The more input I get about your current architectures the more output
(as documentation) you can expect.
cocoon is no doubt extremely powerful and flexible.
it would be a pity if this power could only be understood and hence used by a
few initiated people (basically the committers) because of the lack of
documentation and general visibility in the broader java/web community.
the very responsive, informed, and helpful mailing list is a big plus (thanks
to everyone contributing)
but imho cannot be used as a replacement for proper documentation.
+1
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
