cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: [RT] Block usage
Date Thu, 26 May 2005 13:24:11 GMT
Daniel Fagerstrom wrote:
> 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 
> and 
> 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,

you mean a block that contains e.g. Jetty or Tomcat? IMO this could only be an 
option but not a requirement. Cocoon  must be deployable in a J2EE or servlet 

> a block deployer block

Basically the block deployer will be a stand-alone application (Ant task, Maven 
plug-in, Eclipse plug-in, ...). Of course somebody could write a web interface 
for it which could be a cocoon 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,

we can have different distributions

 > 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

called block.xml, no?

  (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.

I remember one or two mails about this some months ago ;-)

> 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 
> 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.

One thing to add: It must be possible that one block depends on another block 
that is under development. I want my custom projects requiring the latest svn 
version of e.g. the forms block. If the forms block changes, this change takes 
effect immediatly on my project without explicit deployment.

Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}



Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden:

View raw message