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
