Content Placeholders / Replace Text on Page with Query String Parameters? | Community
Skip to main content
J
jocamp
October 16, 2015
Solved

Content Placeholders / Replace Text on Page with Query String Parameters?

  • October 16, 2015
  • 6 replies
  • 3331 views

We're looking to set up a system that replaces placeholder text on a page based on passed query string parameters. For example, the authored content would look like -

The customer, {CUSTOMER_NAME} can be sold the product for {PRODUCT_PRICE}.

And those placeholder values could be swapped out in the jsp through the url query string parameters -

/content/site/page1?customer_name=Smith&product_price=6.99

I'm sure we could develop this ourselves fairly easily but i was wondering if there was anything out of the box that supported any kind of content placeholder/text replacement?

Thanks

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by JustinEd3

Hi,

In AEM/CQ, personalization (whether by geolocation or referrer or anything else) is meant to be done on the client side. It sounds like your whole system needs to be reconsidered.

That said, to answer your specific question, the closest thing included in the product would be http://commons.apache.org/proper/commons-lang/javadocs/api-2.5/org/apache/commons/lang/text/StrSubstitutor.html

Regards,

Justin

6 replies

O
om_vineet
October 16, 2015

Before I answer this, I would like to know why you want to do something like this. I would highly discourage to use query string parameters since it breaks CQ dispatcher caching strategy completely. On the other hand, generally data is kept in JCR which you can display on JSP to bring in dynamism, I see no use case of end users passing all these parameters since you will have no limitations.

So before I answer can you let me know what is the use case you are trying to achieve?

J
Adobe Employee
JustinEd3Adobe EmployeeAccepted solution
Adobe Employee
October 16, 2015

Hi,

In AEM/CQ, personalization (whether by geolocation or referrer or anything else) is meant to be done on the client side. It sounds like your whole system needs to be reconsidered.

That said, to answer your specific question, the closest thing included in the product would be http://commons.apache.org/proper/commons-lang/javadocs/api-2.5/org/apache/commons/lang/text/StrSubstitutor.html

Regards,

Justin

J
jocampAuthor
October 16, 2015

Reposting this because it somehow got deleted:

I understand your skepticism, so i'll explain a bit more. Firstly, to your point about the dispatcher's cache -  sad to say we've disabled the cache completely. All of our pages have to be dynamically created depending on the user (eg. a page will display differing content depending on what part of the country the user is in).

The use case for the replaceable parameters goes something like this:

  1. Calling system (Not CQ) displays the customer's information (name, price offered, etc.) to the user and a link to the CQ content.
  2. User clicks the link to open the CQ content page and promptly forgets the customers name/price offered.
  3. The calling system passed the customer's name and price to be offered in the query string so CQ grabs those and integrates them into the content page where appropriate. Now the user doesn't need to go back and forth between the two pages.
J
jocampAuthor
October 16, 2015

Thanks Justin, i'll take a look at that. It's a bit more complicated than what i described, unfortunately. The personalization is based on two factors - location of the user and what role they are. The content that we filter out is information that they are not legally allowed to see. So we have to do it on the server side in the event that some user looks at the source and sees something they're not supposed to.

J
Adobe Employee
JustinEd3Adobe Employee
Adobe Employee
October 16, 2015

Hi,
Yes, I agree that security and personalization are different and that security must be handled on the server side. That said, passing the price via a query parameter is not really secure smiley so I'm sure you can understand the confusion.

Justin

J
jocampAuthor
October 16, 2015

Ha absolutely, price was probably a bad example. It's more contextual information than anything that would be a security issue.

Appreciate the help!

Terms & ConditionsAccessibility statement

Loading footer...