cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: JNet integration doubts
Date Fri, 04 Apr 2008 00:48:32 GMT
On Apr 3, 2008, at 2:58 PM, Grzegorz Kossakowski wrote:
> Reinhard Poetz pisze:
>> Why do we have to replace the blockcontext: protocol at all?
> Take a look at its current source code. There is no such a thing  
> like "blockcontext:" protocol implementation at the moment.
> In my [RT] mail I explained how we could possibly to stop cheating  
> pretending there is a blockcontext protocol and


> replace it with blockcontext expression that would better reflect  
> current implementation.


> Another possibility (suggested by you) is to provide real  
> implementation of blockcontext: protocol and use blockcontext  
> protocol in base URLs for blocks. I cannot comment on this solution  
> because I haven't enough free time to check all implications.  
> Remember: you will put blockcontext into ServletContext that is  
> rather general interface. I don't say there is any problem, I'm only  
> saying I haven't checked if there is none.
> I prefer (only for now, as a quick solution) first way because there  
> is not much room for discussion, brainstorming and general research  
> which is quite opposite to URL-em-them-all approach. I really would  
> like to fix SSF ASAP and let the discussion/research on URL go in  
> parallel.

I've read your RT and I agree with conclusion that approach taken  
there - to convert String (blockcontext:) --> SourceResolver -->  
Source --> and back into String (file:) - it definitely smells bad.

But, I don't think plugging dependency to expressions block (A above)  
is the good idea. I'd rather prefer B: make blockcontext a regular  
protocol, and treat context path parameter as regular source without  
any special treatment. I'd expect any of supported source  
implementations to work there, be it http, webdav, or xmldb, or even  


View raw message