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: Java components in blocks
Date Mon, 18 Apr 2005 12:35:47 GMT
Reinhard Poetz wrote:

> Daniel Fagerstrom wrote:
>
>> So WDYT, does this make sense for your use cases?
>
>
> Yes, for the pipelines part but that's not the whole story.
> Just two thoughts:  Don't know what we gain when we introduce two 
> separate deployment units (bundles and blocks). Maybe it's more 
> confusing than helping. If necessary we can have different types of 
> blocks.

Sure, I called them bundles and block to make the discussion more 
concrete, we could call them component blocks and sitemap block or 
whatever. From a repository and deployment perspective they will have 
much in common so we should of course use the same mechanism as long as 
possible.

> Second, I don't see our flowscript usecase
>
> var true = cocoon.blocks.myblockA.confirmDialog("Are you sure?") or

This is a page flow and would fall into the reponsibility area of 
blocks. It could be implemented as some flowscript VPC. In that case we 
need to restrict what kind of objects that can be returned to those that 
are part of the "core" classloader. We could also have a more 
request/repsponse oriented approach and make it possible to put the 
true/false and other data in the reponse object, in that case we would 
rather get:

var result = cocoon.sendPageAndWait("block:myblockA://areYouSure");

> var newCustomer = cocoon.blocks.crm.createCustomer()

This falls in the area of "bundles" and component management, if the 
Customer interface is defined in crm, the user of it must have access to 
the Customer interafce from its classloader. We could develop some 
mechanism that makes it possible to implement components in JS but that 
would not be related to flow IMO.

> is covered so far, isn't it?.

Maybe not, but those are areas that are rather vague anyway, we where 
the only ones who thought it had much importance the last time we 
discussed it.

/Daniel


Mime
View raw message