cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: [RT] Block usage
Date Sat, 28 May 2005 11:21:12 GMT
David Casal wrote:
> Hello Daniel,
> 
> Thanks for your extremely edifying response. As with Stefano, will it be 
> ok to cite some of your comments in this report? I may not cite you 
> literally, but I need to credit you if I do. Would that be ok?

Sure.

> The report will be published on Techwatch: 
> http://www.jisc.ac.uk/index.cfm?name=techwatch_home
> 
> On 26 May 2005, at 13:34, Daniel Fagerstrom wrote:
> 
> <snip>
> 
>> 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.
> 
> </snip>
> 
> As I read from your May 20th OSGi proposal, the core and block jars are 
> managed within the OSGi framework, is this correct?

Yes.

> Meaning that the 
> directory a potential user is presented with is minimal because of this?

Yes, the blocks the user webapp depends on don't need to be stored 
within the users webapp directory anymore.

>> 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.
> 
> <snip>
> 
>> Also components from the extended block can be overrided.
> 
> Could you explain how?

Say that block E extends block B, block B handle the URLs /foo and /bar 
and block E handle /foo. Then a user of block E (through the block: 
protocol), will get /foo from E and /bar from B.

Furthermore the inheritance is polymorphic, so if the sitemap rule in B 
is defining /bar in terms of (among other things) /foo by using 
"block:/foo", the /foo from E will be used if /bar is used from E.

A more technical description of the block: protocol can be found in 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111265006428803&w=2. 
The most comprehensive discussion about these concepts with some good 
examples can be find in the, not entirelly plessant, threads: 
http://marc.theaimsgroup.com/?t=111177260800002&r=1&w=2 and 
http://marc.theaimsgroup.com/?t=111211349500004&r=1&w=2.

We haven't discussed component handling in any detail. But the idea is 
that component names can be prefixed with the name of the block it 
should be taken from. Extension and polymorphism should probably work in 
the same way as for sitemap resources.

<snip/>

Reinhard answered the rest of the questions.

/Daniel

Mime
View raw message