cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
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 
> 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,

ok

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


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

ok

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

ok

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

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}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------

	

	
		
___________________________________________________________ 
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de

Mime
View raw message