Re: Adding the sitemap path to Cocoon's Request object
Gianugo Rabellino wrote: SNIP/ I am very bad in naming stuff, but I would say that something like getSitemapPath() could do the trick. Hmm, did you have a look at the Request interface in 2.2: /** * p * Returns the path to the sitemap of the requested resource as interpreted * by the sitemap. * For example, if your webapp is mounted at webapp and the HTTP request * is for webapp/foo, this method returns webapp/. Consequently, if the * request is for foo, this method returns the empty string. * /p * * @return a codeString/code containing the path to the sitemap * @since 2.2 */ String getSitemapPath(); Is this what you're looking for :) Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Adding the sitemap path to Cocoon's Request object
On Mon, 14 Feb 2005 09:29:08 +0100, Carsten Ziegeler [EMAIL PROTECTED] wrote: Gianugo Rabellino wrote: SNIP/ I am very bad in naming stuff, but I would say that something like getSitemapPath() could do the trick. Hmm, did you have a look at the Request interface in 2.2: String getSitemapPath(); Is this what you're looking for :) D'OH! OK, I'm going to write 200 times every committer is supposed to check out 2.2 as well as a punishment. So, let's change the question: what's wrong in backporting this functionality to 2.1? Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: Adding the sitemap path to Cocoon's Request object
Gianugo Rabellino wrote: On Mon, 14 Feb 2005 09:29:08 +0100, Carsten Ziegeler [EMAIL PROTECTED] wrote: Gianugo Rabellino wrote: SNIP/ I am very bad in naming stuff, but I would say that something like getSitemapPath() could do the trick. Hmm, did you have a look at the Request interface in 2.2: String getSitemapPath(); Is this what you're looking for :) D'OH! OK, I'm going to write 200 times every committer is supposed to check out 2.2 as well as a punishment. So, let's change the question: what's wrong in backporting this functionality to 2.1? :) My opinion is we shouldn't change contracts in maintenance releases. As backporting would change the request interface, I think we shouldn't do it. If we change contracts inbetween, we could imho just skip the versioning schema and simply use month/year as the release version :) But that's just my opinion about it. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Adding the sitemap path to Cocoon's Request object
Carsten Ziegeler wrote:
Gianugo Rabellino wrote:
On Mon, 14 Feb 2005 09:29:08 +0100, Carsten Ziegeler
[EMAIL PROTECTED] wrote:
Gianugo Rabellino wrote:
SNIP/
I am very bad in naming
stuff, but I would say that something like getSitemapPath() could do
the
trick.
Hmm, did you have a look at the Request interface in 2.2:
String getSitemapPath();
Is this what you're looking for :)
D'OH! OK, I'm going to write 200 times every committer is supposed to
check out 2.2 as well as a punishment.
So, let's change the question: what's wrong in backporting this
functionality to 2.1?
:) My opinion is we shouldn't change contracts in maintenance releases.
+1
As backporting would change the request interface, I think we shouldn't
do it. If we change contracts inbetween, we could imho just skip the
versioning schema and simply use month/year as the release version :)
But that's just my opinion about it.
--
Reinhard Pötz Independant Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Adding the sitemap path to Cocoon's Request object
The fellow readers of my blog might have noticed that pretty much on top of my Cocoon rant list is how unnecessarily complex is to build relocatable Cocoon applications, that is applications who can work no matter how shallow or deep are nested within the Cocoon hierarchy. The problem I'm facing is that in order to build relocatable links you either have to: 1. resort to strictly relative links, something that quickly becomes unmanageable; 2. perform string manipulation by substracting request.getSitemapURI() from request.getRequestURI(). This is painful and slow in XSLT, as an example, and requires two parameters instead than the one you're actually looking for (hence being error prone at best); The solution is technically a piece of cake, and we have been using a braindead custom inputmodule exactly for that. However, I feel that this data should be available from the Cocoon environment straight away, the best place being o.a.c.environment.Request (which will provide immediate user access through the RequestInputModule). I am very bad in naming stuff, but I would say that something like getSitemapPath() could do the trick. Being this a change in the core environment API, no matter how harmless, the issue might deserve some discussion and a vote. Or a big slap in my face if I'm missing the obvious solution. :-) So, is that only me having to face this issue day in day out? Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com
Re: Adding the sitemap path to Cocoon's Request object
Gianugo Rabellino wrote: the best place being o.a.c.environment.Request (which will provide immediate user access through the RequestInputModule). I am very bad in naming stuff, but I would say that something like getSitemapPath() could do the trick. +1 for having such a method, but shouldn't it rather belong to the sitemap, which is being passed or am I misunderstand something? Michi -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: Adding the sitemap path to Cocoon's Request object
Gianugo Rabellino wrote: The fellow readers of my blog might have noticed that pretty much on top of my Cocoon rant list is how unnecessarily complex is to build relocatable Cocoon applications, that is applications who can work no matter how shallow or deep are nested within the Cocoon hierarchy. The problem I'm facing is that in order to build relocatable links you either have to: 1. resort to strictly relative links, something that quickly becomes unmanageable; 2. perform string manipulation by substracting request.getSitemapURI() from request.getRequestURI(). This is painful and slow in XSLT, as an example, and requires two parameters instead than the one you're actually looking for (hence being error prone at best); The solution is technically a piece of cake, and we have been using a braindead custom inputmodule exactly for that. However, I feel that this data should be available from the Cocoon environment straight away, the best place being o.a.c.environment.Request (which will provide immediate user access through the RequestInputModule). I am very bad in naming stuff, but I would say that something like getSitemapPath() could do the trick. Being this a change in the core environment API, no matter how harmless, the issue might deserve some discussion and a vote. Or a big slap in my face if I'm missing the obvious solution. :-) So, is that only me having to face this issue day in day out? No, clearly not. Again, damn it, this is fixed very elegantly in the real block design: link rel=stylesheet src=block:skin:/styles/default.css/ then you just have to place a map:tranform type=linkmounter/ before your serializers and voila', it becomes link ref=stylesheet src=/mypath/myapp/styles/default.css/ note how the linkmounter will need to know two things: 1) the URL of the public URL where the cocoon root is mount (might not be inferred from the servlet API because of proxying!) 2) how to ask the block manager where 'skin' is mount in the cocoon URL space Simple, elegant and polymorphic safe. -- Stefano.
