cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Knodt <>
Subject Re: cocoon:// design bug?
Date Sun, 18 May 2003 14:46:50 GMT
Hash: SHA1

> b) if you really need such a different behaviour, you can implement your
>    own protocol version - remember, protocols are components in cocoon
>    and can be adopted for your own needs. It's possible, but I personally
>    wouldn't do so for this case.
> In most applications I did over the last years with cocoon, I never
> needed the absolute version of cocoon:, the relative one was suffucient
> As Stefano explained, cocoon:// was not the best idea and the "real-blocks"
> (can we find a better name for it? Perhaps Flux Compensator?) will solve
> this. Ok, it's a little bit odd, to always hear "real-blocks" will solve
> this and this and that as well, but simply see it as a motivation to
> support the development of the next cocoon version beyound 2.1 ;)
Absolute URI's are the best solution I thought of, not nercessary the only. 
The real problem is, that XML content is fetched from a Source and the links 
therein should be maintained, to be valid in the included document. It's 
unimportant if they are absolute or relative, as long as they are valid and 
give the right result. But using cocoon:../blablub/blubbla also doesn't work. 
The only way I found to access parent sitemaps was the absolute variant 
cocoon://, which can't be computed by standard methods/ classes. I can't use 
a simple ../ because then I don't know if this relative to context:, cocoon: 
or whatever the content is accessible. For my personal use, I could always 
use cocoon:, but I think this isn't something which is useable by all and 
will be commited.
Whatever I do, I would gladly see this in 2.1 or 2.2. I try to keep my "cvs 
diff" as small as possible. I haven't read about development in this area so 

- -- 
Domain in provider transition, hope for smoothness. Planed date is 24.7.2003
pub 1024D/4CD29A2C 2001-01-12 Torsten Knodt <>
 Schl.-Fingerabdruck = A2B1 C626 F819 7C58 B2F9 4F4C BF16 64B6 4CD2 9A2C
Version: GnuPG v1.2.2 (GNU/Linux)


View raw message