On 06 Dec 2005, at 09:59, Sylvain Wallez wrote:
Struts has Shale
Meeep. Buzzzz. Wrong.
Struts has Craig.
It's a telltale of Cocoon's problem that we're off discussing marketing
techniques and branding again, without having any design, code, nor
dedication to boot with. A busy thread just in time for ACon.
Currently, I see more community than project in Cocoon.
I'm game for any sort of progress, as long as:
* there's a core set of functionality which is documented through
maintained API (or conventions) and scripture
* there's a mechanism which enables us to separate the unmaintained
one-off's aka blocks into separate release and deprecation cycles
* there's more than one actual coder who actually lives through this
until the end
Maybe this might show people something. This is the reality of someone
building an application (Daisy) with a UI using Cocoon:
#include.block.batik=false
#include.block.fop=false
#include.block.ajax=false
#include.block.apples=false
#include.block.forms=false
#include.block.serializers=false
, with ajax currently only being included since forms apparently depend
on it. And Batik is just there to render images in FOP. That's all.
Furthermore, in
http://svn.cocoondev.org/viewsvn/trunk/daisy/applications/daisywiki/
frontend/src/cocoon/webapp/daisy/sitemap.xmap:
org.outerj.daisy.frontend.QueryGenerator
org.outerj.daisy.frontend.ErrorGenerator
org.outerj.daisy.frontend.DaisyLinkTransformer
org.outerj.daisy.frontend.FopImageSrcTransformer
org.outerj.daisy.frontend.TableHelperTransformer
org.outerj.daisy.frontend.IncludePreparedDocumentsTransformer
org.outerj.daisy.frontend.ExternalIncludeTransformer
org.outerj.daisy.frontend.PublisherTransformer
org.outerj.daisy.frontend.IDAbsolutizerTransformer
org.outerj.daisy.frontend.SerializeTransformer
org.outerj.daisy.frontend.CrossRefParserTransformer
org.outerj.daisy.repository.DocumentReadDeniedException
org.outerj.daisy.repository.DocumentNotFoundException
org.outerj.daisy.repository.DocumentVariantNotFoundException
org.outerj.daisy.frontend.util.HttpMethodNotAllowedException
org.outerj.daisy.frontend.SetRequestAttributeAction
org.outerj.daisy.frontend.LocaleAction
org.outerj.daisy.frontend.MountPointAction
org.outerj.daisy.frontend.InitSkinAction
org.outerj.daisy.frontend.SkinsDirAction
org.outerj.daisy.frontend.HandleSiteAction
org.outerj.daisy.frontend.PartReader
org.outerj.daisy.frontend.components.reading.CachingReader
Looking at that sitemap and the tiny list of used blocks, I see a
number of things:
* there's a need for solid programming interfaces in Cocoon
* there's lots of stuff we don't use
Maybe, when we start from scratch, building solid interfaces, throwing
away undermaintained legacy, this is a good time to reinvent Cocoon
into a workable environment again. But IMNSHO, we'll never get there
with the current approach, effort and dedication. It's the amount of
community and legacy tax that is putting innovation efforts into
starvation.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought Open Source Java & XML
stevenn at outerthought.org stevenn at apache.org
