Yes Yogesh you are right. We can very well use following two methods in jsp level.
But the thing is that, the links are getting populated through a .js file.
As this is CQ’s native problem, I was looking for some fix in the configuration level.
Just curious when does this link getting created ? On document ready or on event ? If it is later case link won't be rewritten.
In my case I have both the scenarios. Most of the case it is document ready.
Try adding only "/myproject/en.html" using jquery and use the mapping as
sling:match - localhost.4503/
sling:internalRedirect - /content/
Working fine for me on document load and event both.
<a href="#" id="test"> click here </a>
Redirecting to /content/myProject/test2.html . Remove click function block keeping the attr line code . It will work for document ready fucntion as well.
Reply if it is something different.
It will also map /content/myProject/test2.html to http://localhost:4503/myProject/test2.html
Check at url http://localhost:4503/system/console/jcrresolver
If you want to use /content/myProject/en.html in jquery then use the following syntax :
Anyhow I have put the URL mapping for "/content/myproject/" to "/".
So if I assign the anchor tag like
It maps to "/content/myproject/test2.html" irrespective of whether it is a doucment ready or on event. Its just that I need to remove "/content/myproject" from the URL.Which is the expected behaviour.
This solution I had already in mind. And I kept this as my last approach.
I hope my question is clear.
1 person found this helpful
$("#test").attr("href","<%= resourceResolver.map(request, "/content/myproject/test2") + ".html" %>");
1 person found this helpful
When you say automatic rewriting is done by the link-checker/rewriter on all html output before it is sent out, my question here is, when we make ajax request, we are making a backend call which is returning say some HTML snippet (say <a href="/content/myproject/en">..</a>..), ideally link-checker/rewriter should run the same job over this HTML which is returned by servlet response.
The difference with normal page load and ajax load is, the way it is displayed on the browser, and ideally, this rewritter should take care of this irrespective of the way we are making request.
Is it bug at CQ side?
The link rewriter runs against only HTML - so as long as your AJAX request includes an HTML extension and your server side JSP is setting the right content type the rewriter will execute against it, no matter how the request is made from the browser. However if your AJAX request is a JSON request, or a JS file request then it won't be subject to rewriting.
Is there any better approach of doing it for JSON responses? Doing this resourceResolver.map way at JS level looks ugly design for me.. And I have this kind of scenarios in many pages.
I generally have a tag library that incluces either a tag or a function that does the map for me.
If you are generating the JSON via a servlet or a JSP then you can easily call the map method via a tag in a JSP or in the servlet Java.
The other alternative that has all sorts of possible negative impacts is to look at writing your own servlet filter to handle parsing and rewriting other request types. The challenge here is how to identify values that should be mapped. HTML has some semantic meaning so it is possible to identify the attributes that should be rewritten. In a JSON response if you are paring it how can you be sure that the value needs to be mapped - you spend a lot of time checking text looking for patterns to alter. This raise the specter of performance issues and hard to diagnose bottlenecks. While its certianly possible to do that I'd tend stay away from it unless you are really doing a lot of JSON generation where it matters.
What is the tag library that does the mapping?
If possible please give an example how that works for JSON responses.
That will be helpful.
You have to create a custom tag libray. Use that tag on the page with parameters . Suppose you define a tag library customlinks then define a tag in it rewriter . in this tag you will have to define tag class and tag extra information class . You can define parameters like link which will take the link to modify . Then in tag class you can do modifications with resourceResolver.
By doing this you tag sytax will be like <customlinks:rewriter link="link you want to modify"> Link Title</customlinks> . In place of <a></a> you can give this syntax which will return the modified <a href="mapped url"> .
Basically, with the above approach, its same as using normal HTML <a></a> tag in JSP. In my case, I have a servlet which is returning JSON for which I want to apply this logic. In my servlet I am converting VO to Json using Json mapper, it is difficult to map each attribute of VO. Any better way of doing it?
1 person found this helpful
In a servlet you have access to the resourceResolver so if you know which attributes contain links then it's relatively easy to apply resourceResolver.map to those links.
Your challenge is clearly how do you know which attributes are links and which aren't. Its is the same challenge that makes parsing the response and rewriting it on the way out difficult - the JSON doesn't have any semantic meaning so how do identify which attributes require rewriting. There really is no good answer ot that question in my experience - all the options have down sides.
- Create some convention - all attributes matching this pattern X get mapped before being converted to JSON (could be attributes whose name ends in link, or it could a convention applied to the value of the attribute - if the attribute is a string that starts with /content apply the resource resolver mapping. In this case you have train your developers to follow this convention which is the down side.
- Create some configurable list of attribute names that require mapping. This is brittle, requires training and is easy to break.
- Implement a client side version of the resource resolver mapping. It wouldn't be as full proof as server side mapping (because that takes into account but you could make it work for simple logic like stripping of /content/site/en. If ou are just trying to solve the simple version of this issue - stripping off the top of the repository path this might be your best option.
- Not worry about it and set up Apache 301 redirects that catch any long URLs and redirect them to short URLs (so configure apache to look for any URL matching /content/site/en and strip off /content/site/en and do a 301 redirect to the shortened URL. You end up with a lot of extra HTTP request because of all the 301s but it would work (I wouldn't recommend this option - but it is possible).
save mapped url in JSON from VO using ResourceResolver.