Request interface change (was: Re: environment input module)

[Sylvain Wallez <sy...@anyware-tech.com>]

Christian Haul wrote:

>On 21.Jan.2003 -- 05:35 PM, Torsten Curdt wrote:
>  
>
>>>>sure - will do...
>>>>        
>>>>
>>>What's the need for an environment input module besides getting the 
>>>current uri prefix ?
>>>      
>>>
>>I couldn't really think of anything else yet..
>>
>>    
>>
>>>Remember that environment is an internal object used by the pipeline 
>>>system (sitemap + pipeline implementations) that isn't visible from 
>>>other classes.
>>>
>>>I also recently needed to get the uri-prefix, and was thinking of adding 
>>>a new getSitemapPath() to Request, that would complement 
>>>getContextPath() with the current uri prefix.
>>>
>>>Thoughts ?
>>>      
>>>
>>Something like that was also my first thought... just hesitated to 
>>propose a change/addition of the Request interface ...since I only need 
>>it inside the sitemap - so I came up with the idea of the environment 
>>module.
>>
>>Shall we add it to the Request?
>>    
>>
>
>Sounds even better.
>

Thinking further about this, we have to define carefully how this 
relates to the "cocoon:" protocol, because in such a case we have _two_ 
request paths :
- the protocol-level path, accessible using getRequestURI(),
- the sitemap-level path, accessible using getSitemapURI() (different 
from the above in the case of a mount or "cocoon:")

We also have to consider that, through getSitemapURI(), the 
"getSitemapXxx" names are tied to the current sitemap request (i.e. the 
"cocoon:" one).

IMO, the use case is more related to the protocol-level URI : I had the 
need for this when building links to images located at the root of the 
current sitemap from an abitrarily nested URI (see [1] and search for 
"{request:contextPath}/mount/cvssource").

But this is only my view of the problem. Any other use case ?



We also have to consider how to handle the interface change :
- on 2.1, no problem : we're not even alpha ;-)
- on 2.0, there can be some backwards compatibility for people having 
implemented their own Request without extending one of the provided 
classes. Are there many of them ? I would say no, but if there are, 
please stand up !

Sylvain

[1] 
http://cvs.cocoondev.org/cgi-bin/viewcvs.cgi/cvssource/src/samples/cvssource/sitemap.xmap?rev=1.1&cvsroot=cvssource&content-type=text/vnd.viewcvs-markup

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Request interface change (was: Re: environment input module)

[Torsten Curdt <tc...@dff.st>]

<snip/>

> Thinking further about this, we have to define carefully how this 
> relates to the "cocoon:" protocol, because in such a case we have _two_ 
> request paths :
> - the protocol-level path, accessible using getRequestURI(),
> - the sitemap-level path, accessible using getSitemapURI() (different 
> from the above in the case of a mount or "cocoon:")

Hm... you are right

> We also have to consider that, through getSitemapURI(), the 
> "getSitemapXxx" names are tied to the current sitemap request (i.e. the 
> "cocoon:" one).
> 
> IMO, the use case is more related to the protocol-level URI :

I aggree

<snip/>

> But this is only my view of the problem. Any other use case ?

I have the same use case - and same view :)

...but I am really wondering if there aren't any use cases not only 
related to the protocol level. Anyone?

> We also have to consider how to handle the interface change :
> - on 2.1, no problem : we're not even alpha ;-)
> - on 2.0, there can be some backwards compatibility for people having 
> implemented their own Request without extending one of the provided 
> classes. Are there many of them ? I would say no, but if there are, 
> please stand up !

Hm... changing an core interface in 2.0? I guess I am -0 on that...
...maybe we should ask on cocoon-users?
--
Torsten


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org