Ah - I see.
If its not a "blanket" rule like adding a ".mobile" selector to every
<a href="[relative-link]"> youll most likely have to do just update
your JSPs to use the appropriate selectors/suffixes, and split your
JSPs apart (or rename the include JSPs). Without knowing all the
variations/patterns/etc. of what youre trying do its hard to come up
with suggestions other than altering the links themselves in your
content -- i doubt there will be a "silver bullet" solution for you
though.
If you want to do handle the path mapping, for example serving:
example.com/content/site/en/home.html
from
example.com/en/home.html
I would suggest setting a one-way mapping on your jcr resource resolver for:
/content/site/en < /en
and then using your webserver to re-write requests coming on in
example.com to rewrite
/en/(.*) -> /content/site/en/$1
On Wed, Apr 18, 2012 at 4:55 PM, Jakob Külzer <[email protected]> wrote:
> Hey David,
>
> No problem. ;) Yeah, we're about to move to Day 5 and/or have projects
> that only run on Day 5 which I'm moved onto now, so I'm trying to
> learn as much as I can.
>
> Day CQ 4 is not based on Sling. In general Day CQ 4 is a very...
> inflexible platform that here and there shows ideas similar to Sling,
> but nowhere as refined. In order to get our stuff working on CQ 4 I
> ended up decompiling a lot of it's core jar files... ;)
>
> By "externalizing" (in lieu of a better word) i mean translating an
> internal reference like /content/site/lang/some/page to an external
> usable path like /lang/some/page.<selectors>.<extension></suffix>. For
> our use cases (consumer sites) rewriting the URLs to a "user friendly"
> URL is important.
>
> Hope that makes sense.
>
> Cheers,
> Jakob
>
> On Wed, Apr 18, 2012 at 4:37 PM, David G. <[email protected]> wrote:
>> Jakob,
>>
>> Ah - sorry, i missed that you are on CQ. That's a very good reason to
>> be using Sling (whether you want to or not :)).
>> Did CQ4 not use Sling (CQ4 was before my time)?
>>
>> The CQ Link Rewriter uses pipelines to do thinks like remove invalid
>> links and and rewrite outgoing urls (if you're using URI mapping via
>> etc/map or in the jcrresourceresolver).
>>
>> Check out the package Justin E. put together for an example of
>> Pipelines -its a bit more instructive than the Sling docs. [1]
>>
>> Can you expound on what you mean by "externalizing" links? Do you just
>> mean adding specific selectors to links based on some criteria?
>>
>> [1] http://www.wemblog.com/2011/08/how-to-remove-html-extension-from-url.html
>>
>>
>>
>>
>>
>> On Wed, Apr 18, 2012 at 3:44 PM, Jakob Külzer <[email protected]>
>> wrote:
>>> Hello David,
>>> no, you're not rude at all, in fact I am grateful for suggestions. As
>>> i've acknowledged earlier, i might be doing the completely wrong
>>> thing. As for now, I'm trying to understand how Sling works and if I
>>> can port the successful patterns that we implemented on Day CQ 4
>>> (ancient!) on the much newer Day CQ 5. With that said, the reason why
>>> I'm looking at Sling is obviously that CQ 5 is built on Sling.
>>>
>>> The rewriter pipeline is a very interesting piece, I'll check it out.
>>> Thank you for the pointer. How do other people solve the issue of
>>> correctly externalizing internal links? Does anybody have experience
>>> with this?
>>>
>>> Cheers,
>>> Jakob
>>>
>>> On Wed, Apr 18, 2012 at 3:34 PM, David G. <[email protected]> wrote:
>>>> Jakob,
>>>>
>>>> Im dont mean to be snide, but if you dont want to/can't meet your
>>>> requirements using a restful architecture, why are you using Sling as
>>>> your framework? It seems like you'd be much better served using some
>>>> other framework. I do sympathize as I came from a more lax MVC-based
>>>> web-app background and its easy to slip back into a behavior-based
>>>> mindset (rather than a content-based mindset).
>>>>
>>>> Also, you could use Sling Rewriter Pipelines/Processors [1] to write
>>>> all your links to include the mobile selector (page.mobile.com) if to
>>>> make links on your mobile site point to "mobile" resource
>>>> representations.
>>>>
>>>> [1]
>>>> http://sling.apache.org/site/rewriting-the-output-through-pipelines.html
>>>>
>>>>
>>>> On Wed, Apr 18, 2012 at 2:55 PM, Jakob Külzer <[email protected]>
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> I'll have a look at these links, thank you.
>>>>>
>>>>> I agree that what I'm toying with is breaking the RESTfulness of
>>>>> Sling, but at the end of the day we're not building RESTful webapps,
>>>>> we're building consumer websites. Therefore REST is not that much of
>>>>> an issue.
>>>>>
>>>>> However, the more I read about Sling, the more i realize I might be
>>>>> approaching this the in the wrong way. But let's assume i'd be
>>>>> building a mobile version using selectors, i'd have to ensure that all
>>>>> rendered internal links have the appropriate selector attached,
>>>>> otherwise a client would "break out" of the specific version of the
>>>>> website. Does Sling support me with link externalization?
>>>>>
>>>>> Cheers,
>>>>> Jakob
>>>>>
>>>>> On Wed, Apr 18, 2012 at 12:33 AM, maikhorma <[email protected]> wrote:
>>>>>> I'd suggest you take a look around in [1] and more specifically [2].
>>>>>> Even
>>>>>> so, I think you're not getting a direct answer because you "url is the
>>>>>> same"
>>>>>> requirement is not exactly in line with the fundamentals of sling.
>>>>>> Specifically Sling is like a "RESTful" web service, and by definition if
>>>>>> you
>>>>>> want something different, then you use a different url. The focus is on
>>>>>> content, so you have /content/stuff/myEntry, and if you want to view it
>>>>>> on a
>>>>>> normal browser you go to .../myEntry.html, if you want it for mobile,
>>>>>> you go
>>>>>> to myEntry.mobile, and if you want a summary, you go to myEntry.summary
>>>>>> (plus using whatever url constructs). Saying that "the url can't change"
>>>>>> pretty much breaks a lot of the power of sling and forces you to put
>>>>>> "if...else if..." somewhere to process other inputs like get parmeters.
>>>>>> Also check out [3] since I think it does a decent job of utilizing sling
>>>>>> to
>>>>>> do the job rather than writing custom code.
>>>>>>
>>>>>>
>>>>>> [1] http://sling.apache.org/site/the-sling-engine.html
>>>>>> [2] http://sling.apache.org/site/dispatching-requests.html
>>>>>> [3] http://sling.apache.org/site/46-line-blog.html
>>>>>>
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://apache-sling.73963.n3.nabble.com/Using-Filter-and-RequestDispatcher-to-substitute-responses-tp3918391p3919064.html
>>>>>> Sent from the Sling - Users mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cheers,
>>>>> Jakob
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Jakob
>
>
>
> --
> Cheers,
> Jakob
