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
