Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
The current behaviour is flawed as we already know from e.g. the case
with the I18N transformer where dynamic resolution is used when static
is what would have been expected. With lazy loading things get even
worse as resolution during the
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
The current behaviour is flawed as we already know from e.g. the
case with the I18N transformer where dynamic resolution is used when
static is what would have been expected. With lazy loading things
get even worse as
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
While working on the block architecture yesterday, I saw that most of
the test cases
(org.apache.cocoon.test.components.blocks.BlocksManagerTestCase)
failed. The problem was that block local files where resolved in
wrong context. After having
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
...
Currently, both the resolvers (in setup() and in the manager) use the
same base URL. I'm afraid that changing this would break a lot of
things...
Yes, you are right, the risk is to high. Also it seem to be a lot
Daniel Fagerstrom wrote:
Ok, I guess that we have to go for your solution of having several
variants of the source resolver:
SourceResolver.ROLE + /static - resolve relative to the defining
manager, and is implemented as I indicated above. We could modify
CoreComponentManager so that it
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
Ok, I guess that we have to go for your solution of having several
variants of the source resolver:
SourceResolver.ROLE + /static - resolve relative to the defining
manager, and is implemented as I indicated above. We could modify
Daniel Fagerstrom wrote:
The current behaviour is flawed as we already know from e.g. the case
with the I18N transformer where dynamic resolution is used when static
is what would have been expected. With lazy loading things get even
worse as resolution during the setup phase also can
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
The current behaviour is flawed as we already know from e.g. the case
with the I18N transformer where dynamic resolution is used when static
is what would have been expected. With lazy loading things get even
worse as resolution during the
Sylvain Wallez wrote:
And actually 3 resolvers, as we also have the one in setup() of
sitemap components :-)
Here's another suggestion that doesn't need a new component.
First of all, when a component is setup (i.e. Avalon lifecycle
interfaces), the relative path must *always* be the one
While working on the block architecture yesterday, I saw that most of
the test cases
(org.apache.cocoon.test.components.blocks.BlocksManagerTestCase) failed.
The problem was that block local files where resolved in wrong context.
After having controlled that nothing in the source resolution
Daniel Fagerstrom wrote:
While working on the block architecture yesterday, I saw that most of
the test cases
(org.apache.cocoon.test.components.blocks.BlocksManagerTestCase) failed.
The problem was that block local files where resolved in wrong context.
After having controlled that
Daniel Fagerstrom wrote:
While working on the block architecture yesterday, I saw that most of
the test cases
(org.apache.cocoon.test.components.blocks.BlocksManagerTestCase)
failed. The problem was that block local files where resolved in wrong
context. After having controlled that nothing
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
While working on the block architecture yesterday, I saw that most of
the test cases
(org.apache.cocoon.test.components.blocks.BlocksManagerTestCase) failed.
The problem was that block local files where resolved in wrong context.
After
Carsten Ziegeler wrote:
I'm actually not sure what lazy loading really gives us? Ok, Cocoon
starts faster, but if you have just configured the blocks you need I
think there is not really a difference. And if you need the components
anyway, you have to wait for them to be setup - being it lazy or
Leszek Gawron wrote:
...
I'm not following block development very precisely (mostly because of
it's complexity that I do not full understand). I have one question
though: could whole cocoon blocks be also lazily loaded - just as
eclipse plugins are (or maybe we have this feature OOTB when
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
...
I think the main problem is that we have a global source resolver and
try to get the context right during resolution in a smart and subtle
(and fragile) way. If we instead create one source reolver within
each service manager all source
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
...
I think the main problem is that we have a global source resolver
and try to get the context right during resolution in a smart and
subtle (and fragile) way. If we instead create one source reolver
within each
Daniel Fagerstrom wrote:
While working on the block architecture yesterday, I saw that most of
the test cases
(org.apache.cocoon.test.components.blocks.BlocksManagerTestCase)
failed. The problem was that block local files where resolved in wrong
context. After having controlled that nothing
18 matches
Mail list logo
