cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <gkossakow...@apache.org>
Subject Re: [PROPOSAL] Block conventions
Date Wed, 14 Mar 2007 19:27:42 GMT
Peter Hunsberger napisaƂ(a):
>
> Small changes have a way of becoming institutionalized; the next thing
> you know two years from know someone will be saying this is the
> proper/only way to do things, or someone will build some kind of
> complex functionality that would be generally useful if only it didn't
> have hard coded built in assumptions...
>

Ok, so let's focus on addressing all doubts.

>> Really nothing...
>> If blockA has external/foo.js and blockB has external/foo.js there is no
>> trouble in such a case. From the blockC perspective, first resource is
>> available under servlet:blockA:/external/foo.js and the second under
>> servlet:blockB:/external/foo.js. This are two absolutely different
>> paths. No option for name clashes...
>
> What's the relative path for each?   What happens if I started out
> with only blockA and had coded dependencies on the relative path for
> it and then later I add blockB (perhaps not even realizing it contains
> a foo.js)?

I'm not sure about what relative path you ask. Could you clarify?

Our discussion on blocks connection and sharing their resources is
little bit out of scope of this particular, small proposal but it's
seems that it's crucial for you so I'm going to address your all doubts
on this matter. :-)
Also, I kindly ask you to take a look at servlet-service-fw samples,
because I suspect that your doubts come from lack of knowledge how this
fw works.
Now, blocks are _completely_ seperated from each other from their
architecture foundation. It means that resources in one block do not
interfere with resources in other block in any way. What's more, it's
virtually not possible to access resources from block A in block B (or
at least we should not assume that because it's not part of contract
between blocks) directly. I mean that even if blockA is mounted on
/root/BlockA and blockB is mounted /root/BlockB we are not allowed to
access resources from blockA in blockB in this way: map:read
src="../blockA/foo.js".
Relative paths are only relative to the block's context. From every
block's perspective block's context is root path and there is no
superior location/path whatever.

Then, how can we access resources from blockA in blockB? We have to make
*connection*. blockB makes connection to the blockA and from this point
blockB is allowed to write something like this:
servlet:blockA:/foo.js. Which means, calculate relative path of foo.js
getting as base path block's context of A. Yes, by writing
servlet:blockA we just change context in which paths are calculated.
When you write just "foo.js" omitting context, current block's context
is used as base path.

This means that you can add files whatever you like to the blockB and
even not thinking of using blockA at the time. Then connect to the
blockA and be sure that nothing wrong happens with filenames because
they are accessible from two different contexts.

I hope that this helps you understand this. If not, I'm giving up and
maybe Daniel can explain it better...

>
>> (I'm really running out of ideas how to explain this)
>
> Maybe I'm missing something about how these both would be made
> available in the site map?

Yes, I think that's the case. And you have explanation above.

>
> That's actually an open question from what I can tell; some people are
> undoubtedly attracted to Cocoon because they think it won't take much
> work to configure or customized but it seems to me that it rarely
> works out that this is true...

Yes, Cocoon now (in 2.1.x) demands lots of configuring, reading the
sources (because documentation is poor), playing with samples etc before
you become productive.
I remember myself struggling badly on the beginning so I decided that my
main aim here (as Cocoon committer) will be making it easier to start
with Cocoon for newcomers. I was going to propose many small
improvements (at least I see them as improvements) but now I have some
doubts if I will have enough energy to struggle like with this one.

Don't get me wrong with my last sentence.

-- 
Grzegorz Kossakowski

Mime
View raw message