Mailing-List: contact users-help@sling.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@sling.apache.org
Received-SPF: pass (athena.apache.org: domain of davidjgonzalez@gmail.com
 designates 74.125.82.52 as permitted sender)
References: <AE27E3CFE0E2486FA29C9D75BAE8DF8E@gmail.com>
 <CAHNhh3prNZGHhSN=BsCPruRL-1e=RStJ26aYgN9+gfCQc=ZEew@mail.gmail.com>
 <-6817350045038920643@unknownmsgid>
 <CAHNhh3rrcLGBA7Ug1ryyQVfwH0=usELFMUQ+UrXLLRZ6qkkBZg@mail.gmail.com>
 <32DEFFD0F835407FA7637D6EE4DBA3FD@gmail.com>
 <CACrt3pyL1qG6q0LMpR-HUjtgAcpQBPBVmMTYTNHo8GSL=RMeXA@mail.gmail.com>
From: David Gonzalez <davidjgonzalez@gmail.com>
In-Reply-To: 
 <CACrt3pyL1qG6q0LMpR-HUjtgAcpQBPBVmMTYTNHo8GSL=RMeXA@mail.gmail.com>
Mime-Version: 1.0 (1.0)
Date: Tue, 7 Feb 2012 07:38:22 -0500
Message-ID: <-6888712074089617927@unknownmsgid>
Subject: Re: Sling URL Mapping Questions
To: "users@sling.apache.org" <users@sling.apache.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Sam, doesn't etc/map require a root mapping which can't be a regex
(can't be regex for outgoing mapping atleast)? How would I structure
the etc/map nodes to only match on the resource path? Would I just put
the resource mapping directly under scheme (http) node I lieu of the
root mapping?

Thanks


On Feb 7, 2012, at 7:18 AM, "sam =94" <skynare@gmail.com> wrote:

> You can rewrite from http server.
>
> For the urls appearing in html, you can use rewriter:
> http://sling.apache.org/site/output-rewriting-pipelines-orgapacheslingrew=
riter.html
>
> Or, since your mappings are simple, you can roll out your own utility tha=
t
> walks /etc/map for sling:internalRedirect. And, find the longest matching
> internalRedirect against resourcePath.
> Once found, you can construct url from there.
>
>
> On Mon, Feb 6, 2012 at 10:42 PM, David G. <davidjgonzalez@gmail.com> wrot=
e:
>
>> Hey,
>>
>> I'm using dispatcher running under httpd as cache.
>>
>> One of the things I am trying to get around is serving pages from the
>> usual /content/<site>/<lang>/page.html structure.
>>
>> I need to validate, but I think I could
>>
>> 1) handle incoming rewrites: mysite.com/page.html >
>> /content/mysite/en/page.html
>> 2) use the JCR Resource Resolver mappings to rewrite all my in-page link=
s
>> to point at /page.html
>>
>> I haven't looked at the source code to see why sling can't handle
>> bi-directional mapping when using regex (it seems like it should be able
>> to, but I must be missing something).
>>
>> Thanks
>>
>> --
>> David Gonzalez
>> Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
>>
>>
>> On Monday, February 6, 2012 at 12:29 PM, James Stansell wrote:
>>
>>> On Mon, Feb 6, 2012 at 5:26 AM, David Gonzalez <davidjgonzalez@gmail.co=
m(mailto:
>> davidjgonzalez@gmail.com)>wrote:
>>>
>>>> Does mod-rewrite support rewriting all the links in the documents
>>>> returned in the response?
>>>>
>>>
>>>
>>> Probably not. In fact right now a lot of our links are
>>> /content/<site>/en/page.html and we have rewrite rule which gives a
>>> redirect to /page.html.
>>>
>>> It should be possible to use a sling filter to modify the links when
>>> serving the page but we haven't looked into that yet.
>>>
>>>
>>>> Have you seen perf hits doing this? (I'm assuming every html response
>>>> must be parsed and rewritten.)
>>>>
>>>
>>>
>>> As far as I know our performance concerns are in other areas. Our sling
>> is
>>> actually part of CQ5 so we already were using httpd in order to host th=
e
>>> dispatcher plugin for caching the pages. Plus we are using mod_rewrite
>> for
>>> rewriting 1000s of legacy URLs so I don't think we ever considered
>> another
>>> option.
>>>
>>>
>>>> Are there any gotchas w mod_rewrite that you've run into rewriting
>>>> incoming and outgoing urls?
>>>>
>>>
>>>
>>> Our biggest problems have been with the legacy URLs. I guess a general
>>> gotcha could be the regexes for the rewrite; not thinking of anything
>> else.
>>>
>>> If we were using plain sling we would probably be caching with varnish.=
 I
>>> wonder if that has any rewrite support? Are you using a web cache?
>>>
>>>
>>
>>
>>