and that should read: Also, you could use Sling Rewriter Pipelines/Processors [1] to write all your links to include the mobile selector (page.mobile.html) -- not .com :)
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
