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
