Le 7 avr. 04, à 11:33, Carsten Ziegeler a écrit :
...Exactly my point :) But the current idea of blocks is to only retain this possibility inside a sandbox which means it can't be used "inside" blocks. So if I develop my app as a block, I can't use these components inside my app!...
I thought the idea was to provide an ECM-like sandbox *inside* a block (reading Stefano's last message on this thread), in which case you can use your Avalon components inside a Cocoon block, but they cannot be made available to other blocks.
But I might be wrong..
Bertrand is right and Carsten is freaking out for no reason.
Carsten, please, breath and read what I write.
You don't have hotdeployment today so you won't be missing it for sure in your avalon sandbox, would you?
If you have two blocks in the avalon sandbox, you could share them between them, but there is no (easy? elegant?) way you can pass them arond *OUTSIDE* the sandbox and still allow blocks to be hotswappable and runtime polymorphic.
[I would gladly be proven wrong here!]
So, in short:
1) if you have avalon components exposted thru cocoon blocks, these blocks need to run in the avalon sandbox and they cannot be runtime polymorphic because of the nature of avalon. This means that in order to upload/change a block you need to restart the container. If we pass around these components outside the sandbox, we force all blocks that depend on this to be hardwired, loosing, in fact, the soft-wireness.
2) for cocoon components exposted thru cocoon blocks, this is not the case.
Socially, I expect the values of 2) to drive the migration effort away from 1).
This means:
if you avalon components exposed to your cocoon block, these components will be loaded in an avalon sandbox *and* all the cocoon blocks (even those outside the sandbox) that depend on this will not be hotswappable.
Even more explicitly:
you are NOT loosing any functionality!! since hotswappability is not something you had before.
Is this clear enough? if not, I'm glad to keep answering questions.
--
Stefano, wishing people didn't think that innovation always means breaking stuff.
smime.p7s
Description: S/MIME Cryptographic Signature
