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
