cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Simmons" <deri...@arcor.de>
Subject Cocoon 2.1 the usability release?
Date Sun, 26 Jan 2003 23:23:16 GMT
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
Mime
View raw message