Stefano Mazzocchi wrote:
Daniel Fagerstrom wrote:
Stefano Mazzocchi wrote:
I disagree. You have a world-wide unique identifier (the URI) and a
local name in a well isolated context, and a wiring table to glue
these together (using the URIs) that's all you need.
Consider the following case: One
Daniel Fagerstrom wrote:
Stefano Mazzocchi wrote:
I disagree. You have a world-wide unique identifier (the URI) and a
local name in a well isolated context, and a wiring table to glue
these together (using the URIs) that's all you need.
Consider the following case: One of my applications use a r
Stefano Mazzocchi wrote:
Daniel Fagerstrom wrote:
in the connection section, where
"http://mycompany.com/skins/corporate/34.3.345"; uniquely identifies
the specific skin implementation that has been choosen at deploy time.
Is the URI unique enough? What if I want several variants of the
skin
Reinhard Poetz wrote:
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Ralph Goers wrote:
Daniel Fagerstrom wrote:
Portal block
- requires "MyProfile" that implements "profile"
Correction:
- Requires implementation of "profile" interface.
"profile" is implemented by "MyProfile1",
Daniel Fagerstrom wrote:
You probably meant here "BlocksManager"
No I meant BlockManager. In my discussion I assumed that a BlockManager
is responsible for the information within a block element in the wiring
(http://wiki.apache.org/cocoon/BlocksWiring) and that the BlocksManager
"correspond" t
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Ralph Goers wrote:
Daniel Fagerstrom wrote:
Portal block
- requires "MyProfile" that implements "profile"
Correction:
- Requires implementation of "profile" interface.
"profile" is implemented by "MyProfile1",
"MyProfile2", ..., "
Daniel Fagerstrom wrote:
Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
Inter block access
--
An URI to another block "skin" e.g. looks like:
block:skin:/foo/bar
the BlockManager
You probably meant here "BlocksManager"
No I meant BlockManager. In my discussion I assumed that a
Reinhard Poetz wrote:
Ralph Goers wrote:
Daniel Fagerstrom wrote:
Portal block
- requires "MyProfile" that implements "profile"
Correction:
- Requires implementation of "profile" interface.
"profile" is implemented by "MyProfile1",
"MyProfile2", ..., "MyProfileN".
..
Ralph Goers wrote:
Daniel Fagerstrom wrote:
is resolved in the same way as an ordinary external block URI. To
make this possible the role of being a super block must be
identifiable among the connections in the wiring info. Maybe by
reserving the name "super" for this case.
WDYT?
/Daniel
A few
Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
--- o0o ---
Just some sidenotes...
The main involved components are the BlocksManager that in turn has
access to one BlockManager for each block.
(From [1] BlockManager is the ServiceManager of the block)
Yes it is. We
Le 5 avr. 05, à 09:10, Reinhard Poetz a écrit :
...I will revise http://wiki.apache.org/cocoon/Blocks (this weekend or
next week)
Thanks - wiki pages also make good "discussion checkpoints", and might
allow more people to give feedback on the design.
-Bertrand
--
Bertrand Delacretaz
independ
Ralph Goers wrote:
Daniel Fagerstrom wrote:
is resolved in the same way as an ordinary external block URI. To make
this possible the role of being a super block must be identifiable
among the connections in the wiring info. Maybe by reserving the name
"super" for this case.
WDYT?
/Daniel
A few
Bertrand Delacretaz wrote:
Le 5 avr. 05, à 04:42, Ralph Goers a écrit :
...When the email gets to be long or quotes previous nested emails in
their entirety I tend to just move on and ignore the post...
FWIW, it is exactly my case: not enough time to follow these lng
emails. The mailing-lis
Le 5 avr. 05, à 04:42, Ralph Goers a écrit :
...When the email gets to be long or quotes previous nested emails in
their entirety I tend to just move on and ignore the post...
FWIW, it is exactly my case: not enough time to follow these lng
emails. The mailing-list discussion mode makes it v
Daniel Fagerstrom wrote:
is resolved in the same way as an ordinary external block URI. To make
this possible the role of being a super block must be identifiable
among the connections in the wiring info. Maybe by reserving the name
"super" for this case.
WDYT?
/Daniel
A few thoughts here (tha
Daniel Fagerstrom wrote:
--- o0o ---
Just some sidenotes...
The main involved components are the BlocksManager that in turn has
access to one BlockManager for each block.
(From [1] BlockManager is the ServiceManager of the block)
Block local access
--
Daniel Fagerstrom wrote:
Pier Fumagalli wrote:
On 4 Apr 2005, at 16:26, Daniel Fagerstrom wrote:
Pier Fumagalli wrote:
On 31 Mar 2005, at 01:26, Stefano Mazzocchi wrote:
block:super://blah.xml
A very simple remark, I don't want to criticise...
I'm already slightly "upset" about the "cocoon://" pro
17 matches
Mail list logo