On 12 Apr 2005, at 15:46, Stefano Mazzocchi wrote:
Pier Fumagalli wrote:
On 11 Apr 2005, at 15:50, Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
Ok, I had some remembrance that we had decided to have a particular
directory structure on the COBs, but I couldn't find any
documentation on that, do
Pier Fumagalli wrote:
SNIP/
If on the other hand we separate entirely components and java code from
blocks, the implementation becomes _much_ more easy...
My idea would be that a block (for example, our ForrestSkin
implementation) _requires_ a component (not a block) that performs
Carsten Ziegeler wrote:
Pier Fumagalli wrote:
SNIP/
If on the other hand we separate entirely components and java code from
blocks, the implementation becomes _much_ more easy...
My idea would be that a block (for example, our ForrestSkin
implementation) _requires_ a component (not a block)
Reinhard Poetz wrote:
Have you tried integrating Hibernate with 2.2 using the new sitemap
classloader?
Hmm, no as we are using 2.1.7 we didn't try it. But yes, that should
have solved the problem as well - at least in theory.
Carsten
--
Carsten Ziegeler - Open Source Group, SN AG
Carsten Ziegeler wrote:
Pier Fumagalli wrote:
classloading cumbersomeness...
(probably you meant flexibility here? ;-P)
snip/
Ok, long story, short question: do we plan to support such scenaries
with real blocks? I really hope so :)
As Pier outlined in snipped parts above, it's achievable goal. We
On 13 Apr 2005, at 14:14, Carsten Ziegeler wrote:
Pier Fumagalli wrote:
SNIP/
If on the other hand we separate entirely components and java code
from
blocks, the implementation becomes _much_ more easy...
My idea would be that a block (for example, our ForrestSkin
implementation) _requires_ a
On 13 Apr 2005, at 15:07, Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
Pier Fumagalli wrote:
classloading cumbersomeness...
(probably you meant flexibility here? ;-P)
snip/
Ok, long story, short question: do we plan to support such scenaries
with real blocks? I really hope so :)
As Pier outlined
Pier Fumagalli wrote:
Absolutely we do, but not in the very first phase of blocks. Blocks,
in my view, addess separate concerns from the classes they require for
the implementation of the virtual sitemap components that they expose
to other blocks.
At the beginning, and that's what we agreed a
On Mar, 12 de Abril de 2005, 0:59, Reinhard Poetz dijo:
Geoff Howard wrote:
On Apr 11, 2005 4:57 PM, Vadim Gritsenko [EMAIL PROTECTED] wrote:
Reinhard Poetz wrote:
I don't know why we named it COB-INF but there was (still is?) a good
reason for this because I remember some long discussion.
Antonio Gallardo wrote:
Is posible to change the name from:
block.xml - cob.xml
ATM everything is possible ;-)
I see the analogy to WEB-INF/ -- web.xml.
IMHO this is to keep the same name and avoid confusions. ;-)
WDYT?
fine for me too, so we have
Le 12 avr. 05, à 08:33, Reinhard Poetz a écrit :
...
--
[cocoon block] [DIR]
+-- COB-INF [DIR]
+-- cob.xml
+-- classes [DIR]
+-- lib [DIR]
--
+1, sounds
On 11 Apr 2005, at 15:50, Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
Ok, I had some remembrance that we had decided to have a particular
directory structure on the COBs, but I couldn't find any
documentation on that, do you have any link or example?
no. But AFAIK there aren't many rules.
Pier Fumagalli wrote:
--
[cocoon block] [DIR]
|
+-- BLOCK-INF [DIR]
+-- block.xml
+-- classes [DIR]
+-- lib [DIR]
--
WDYT?
Again, to sound stupid, but why in
On Apr 12, 2005 2:33 AM, Reinhard Poetz [EMAIL PROTECTED] wrote:
Antonio Gallardo wrote:
Is posible to change the name from:
block.xml - cob.xml
ATM everything is possible ;-)
I see the analogy to WEB-INF/ -- web.xml.
IMHO this is to keep the same name and avoid confusions. ;-)
On Mar, 12 de Abril de 2005, 7:17, Geoff Howard dijo:
On Apr 12, 2005 2:33 AM, Reinhard Poetz [EMAIL PROTECTED] wrote:
Antonio Gallardo wrote:
Is posible to change the name from:
block.xml - cob.xml
ATM everything is possible ;-)
I see the analogy to WEB-INF/ -- web.xml.
IMHO this
Pier Fumagalli wrote:
On 11 Apr 2005, at 15:50, Reinhard Poetz wrote:
[cocoon block] [DIR]
|
+-- BLOCK-INF [DIR]
+-- block.xml
+-- classes [DIR]
+-- lib [DIR]
Again, to sound stupid, but why in the world a cocoon block would
contain classes and libraries? Those should be
Reinhard Poetz wrote:
Thanks Geoff and Vadim
as we already had a vote, we should respect the result and have
following intra-block file-system structure:
--
[cocoon block] [DIR]
|
+-- COB-INF [DIR]
+-- block.xml
+--
Ralph Goers wrote:
Reinhard Poetz wrote:
Thanks Geoff and Vadim
as we already had a vote, we should respect the result and have
following intra-block file-system structure:
--
[cocoon block] [DIR]
|
+-- COB-INF [DIR]
+--
Reinhard Poetz wrote:
Ralph Goers wrote:
Reinhard Poetz wrote:
Thanks Geoff and Vadim
as we already had a vote, we should respect the result and have
following intra-block file-system structure:
--
[cocoon block] [DIR]
|
+-- COB-INF
Reinhard Poetz wrote:
Ralph Goers wrote:
Question. What else is in a block that requires that COB-INF exist at
all? Why can't it just be:
[cocoon block] [DIR]
+--block.xml
+--classes [DIR]
+--lib [DIR]
Ralph
IMO its as usefull/useless as WEB-INF for web archives.
Presumably the case for
Pier Fumagalli wrote:
On 11 Apr 2005, at 15:50, Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
Ok, I had some remembrance that we had decided to have a particular
directory structure on the COBs, but I couldn't find any
documentation on that, do you have any link or example?
no. But AFAIK there
Geoff Howard wrote:
On Apr 12, 2005 2:33 AM, Reinhard Poetz [EMAIL PROTECTED] wrote:
Antonio Gallardo wrote:
Is posible to change the name from:
block.xml - cob.xml
ATM everything is possible ;-)
I see the analogy to WEB-INF/ -- web.xml.
IMHO this is to keep the same name and avoid confusions.
Ralph Goers wrote:
Reinhard Poetz wrote:
Thanks Geoff and Vadim
as we already had a vote, we should respect the result and have
following intra-block file-system structure:
--
[cocoon block] [DIR]
|
+-- COB-INF [DIR]
+--
Daniel Fagerstrom wrote:
Ok, I had some remembrance that we had decided to have a particular
directory structure on the COBs, but I couldn't find any documentation
on that, do you have any link or example?
no. But AFAIK there aren't many rules. Those that I know of are:
Blocks have a block.xml
Reinhard Poetz wrote:
I don't know why we named it COB-INF but there was (still is?) a good
reason for this because I remember some long discussion.
IIRC, reason was to avoid conflict with avalon/phoenix/somesuch
BLOCK-INF/block.xml, hence COB (Cocoon Block).
Vadim
On Apr 11, 2005 4:57 PM, Vadim Gritsenko [EMAIL PROTECTED] wrote:
Reinhard Poetz wrote:
I don't know why we named it COB-INF but there was (still is?) a good
reason for this because I remember some long discussion.
IIRC, reason was to avoid conflict with avalon/phoenix/somesuch
Geoff Howard wrote:
On Apr 11, 2005 4:57 PM, Vadim Gritsenko [EMAIL PROTECTED] wrote:
Reinhard Poetz wrote:
I don't know why we named it COB-INF but there was (still is?) a good
reason for this because I remember some long discussion.
IIRC, reason was to avoid conflict with avalon/phoenix/somesuch
27 matches
Mail list logo
