David Casal wrote:
<snip/>
how do you see the common user approaching the development of new
webapp, considering they might not have a senior level of development
experience? Could you illustrate your ideal use case scenario?
<snip/>
We haven't discussed use case scenarious in a more systematic way for
quite some time. Bits and pieces have been discussed in technical
threads although not in any way that have been easy to follow for those
not involved in the specifics. What's described in
http://wiki.apache.org/cocoon/BlockIntroduction and
http://wiki.apache.org/cocoon/BlocksUseCases still holds. But Cocoon has
changed since then, new technologies have appeared and we have learnt
more by discussing and trying to implement the blocks so it could be
worthwhile to discuss the user experience of blocks again.
I'll mix up the use case with some technical details on how it might be
implemented. The terms block, bundle and plugin are synonymes in this RT.
Ok, here is my current view:
A basic scenario
================
1. A soon to become Cocoon user, downloads the "start kit" distribution
from our site.
It contains the (OSGi) kernel, the Cocoon service block (containing the
Cocoon core), a Cocoon servlet block, a (light weight) web server
block, a block deployer block, a block depoyer webapp block, a "get
started" tutorial block and some basic blocks (template, cforms, xslt,
flow, ...) that the previous blocks depends on.
2. The user double clicks the distribution and answer where to install
it and whether the tutorial webapp should be started.
It is not certain that the distribution contains all the above
physically, it might download its dependencies during this step. Those
thinking about using Maven etc can probably give a better view on this.
If the user chose to start the tutorial webapp, the kernel will be
started and the blocks listed above will be installed into the kernel
and started. The start page for the tutorial will be mounted at e.g. "/"
and will be served through the call chain: web server block -> Cocoon
servlet block -> Cocoon service block -> "Get started" tutorial block.
3. The user points the browser at http://localhost:8888/ and start to
follow the tutorial.
Here we have IMO a lot to learn from Forrest. When you have dowloaded
and installed Forrest you directly gets instructions about how to start
use it.
4. The user can chose between following a number of different wizard
like tutorials, e.g.: Minimal Cocoon app, documentation site (Forrest),
portal, CMS site (Lenya or Daisy), Spring based webapp etc.
In this step the needed blocks (including the specific tutorial/wizard)
will be dowloaded, installed and started. A user block skeleton will be
created. It should be noted that the created user block is much simpler
than what is needed today. It is a directory with a description of what
blocks the block depends on (wiring.xml and the Manifest file), a near
to empty sitemap and that is all.
5. The user start to develop the new application from the skeleton one
and have at all times a working app that can be used from the browser.
I think polymorphic extension will be a key mechanism for making it easy
for users to develop new apps. Let us say that you want to create a
documentation site. Then your skeleton block extends the Forrest block,
which allready contain an example documentation site. By extending the
Forrest block, your new this far empty, block allready delivers content.
The Forrest block is designed in such a way that everything that you
might want to change or extend: content, menues, styling, configuration
etc is available through the blocks sitemap (some of it only
internally). By overiding the URLs of these things in your own sitemap
with own content you can one step at the time adapt the default app to
your own needs. For some of the inherited resources you just want to
modify the original content. This can be done by applying a stylesheet
on "block:super:". Also components from the extended block can be overrided.
6. The new block contain some new and intersting stuff that is not
available before. After a number of refactorings it consists of a number
of blocks that are reusable and solves well defined concerns. Now the
user puts the blocks in a new project in Sourceforge (or cocoondev.org etc).
An important aspect of blocks is that they can make Cocoon development
much more scalable and distributed. To make this possible we must, IMO,
split the Cocoon core of today in a number of blocks. These blocks
should have well defined concern areas, and in some cases own release
cycles. We should also be much more carefull about what is external
interfaces and classes and what is only for internal use.
Above all we should have a lean, mean and rock stable core, containing
the basic mechanisms for the sitemap and (possibly) component management
and the minimal set of core interfaces. This is a must for creating a
stable fundament that external blocks developers can put their trust in.
--- o0o ---
I would assume that we will have an Cocoon Eclipse starting kit distro
as well. With IDE support, the user can get much more support and
guiding in the above described process. The Lepido crew will hopefully
give a view on that.
WDYT?
/Daniel