Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <4295C270.8050306@nada.kth.se>
Date: Thu, 26 May 2005 14:34:56 +0200
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: [RT] Block usage
References: <d6umar$iri$1@sea.gmane.org> <d6vdvq$u1b$1@sea.gmane.org>
 <429353AC.3040802@apache.org> <d6vnn7$6b4$1@sea.gmane.org>
 <42937419.8040900@apache.org> <d70dbc$glb$1@sea.gmane.org>
 <42941299.1070902@apache.org>
 <e11e454da70f039e4532c48d869f62d0@luminas.co.uk>
In-Reply-To: <e11e454da70f039e4532c48d869f62d0@luminas.co.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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