Apache Sling JCR Resource Resolver doesn't work for the anchor tags which is been rendered through j

Question

Certainly I realized that Apache Sling JCR Resource Resolver doesn't work for the anchor tags which is been rendered through jquery or javascript.
e.g.
In Felix Console , in Apache Sling JCR Resource Resolver configuration I have added following mapping.
/content/myproject/-/
So If any anchor tag is there like <a href="/content/myproject/en.html"> click me </a> then it will be mapped to "/en.html" automatically.
But the problem is there in following scenario.
I have an anchor tag as follows.
<a href="#" id="test"> click here </a>
And I am assigning the href to anchor through JQUERY.
<script>
$("#test").attr("href","/content/myproject/en.html");
</script>
Ideally this should have been mapped to "/en.html".
But it is not mapping to "/en.html". It still shows "/content/myproject/en.html".
How to resolve this.
Thanks,
Sai

Answer 1

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).