Given the recent discussion about the difficulty
getting into cocoon, I am wondering if we should start an initiative to make a
maintenance release for cocoon that would have a focus on usability for new
users. The following is a list of features I propose for this release.
1) A binary distribution stripped of all examples
and documentation. This distribution would have only a single static XML and XSL
file in a subdirectory called welcome that would be set up as a welcome page.
The main sitemap file in the cocoon root directory would have anything not
needed to serve this page as HTML commented out or removed. It would contain the
mount only for that part of the site.
2) A all of the jars are filed into a single
containing jar called cocoon-all.jar and placed in the WEB-INF/lib directory.
This should remove "jar shock" from the users new to the system while retaining
the modularity. A user can always unpack the cocoon-all.jar or replace a jar in
the file if he chooses.
3) A new jar called cocoon-ext.jar. This jar would
contain only the needed classes for compiling extensions (such as generators) to
cocoon. It would be for users to mount in their development IDEs instead of
having to mount the entire cocoon-all.jar. In the distribution, a new directory
called dev-libs would be created and this jar would be placed in there.
4) All properties and xconf files that the user
doesn't need to routinely edit would be packed into the cocoon-all.jar. The code
loading these files would be adapted so that if a user chooses to provide his
own xconf files (at his own risk), he can do so. Perhaps the code looks for
custom-cocoon.xconf in the classpath and if it doesn't find it, then it
loads the default one in the cocoon-all.jar.
5) Creation of all of these parts would be in the
build.xml file, perhaps we can use the target name "golfball" for building the
whole cocoon-all.jar. *smirk*
6) Providing both the full documented kitchen sink
as well as the stripped jar for binary distribution download.
Features id like to see:
a) Replacing logikit with Log4j. Log4j is by far
the most widespread of the logging packages used today and users will typically
want to have all of their logging functioning in one product. That way a network
admin can use a Log4j viewer tool to monitor the health of the system instead of
needing to parse several logs.
b) A reference manual on all the included
generators, actions, serializers and so on: and what they do. The
target audience for this is the sitemap developer who just wants to wire
together pipelines.
b) Reorganization of the documentation to allow a
more coherent approach to learning cocoon. Starting with including basic newbie
guides to get hello-world up in 15 minutes or less. Users that can get it
working fast get excited and go further and faster. Its the hook that draws them
in.
Keep in mind I am coming from a usability point
only. My basic premise is that newbies coming here will mostly not have the
tenaciousness that I do and will be under deadline guns. Hooking them on cocoon
by getting them in the door can only be good for the project and its technology.
-- Robert
|
- Re: Cocoon 2.1 the usability release? Robert Simmons
- Re: Cocoon 2.1 the usability release? Robert Simmons
- Re: Cocoon 2.1 the usability release? Jeff Turner
- Re: Cocoon 2.1 the usability release? Robert Simmons