Inject html-title in Freemarker

Developers Experience Manager
#1

I am using the following snippet to inject a title in the base-template:

 <#-- Title -->
<!-- get title from document-bean --->
<#if hstRequest.requestContext.contentBean.title??>
    <title>${hstRequest.requestContext.contentBean.title}</title>
<!-- get title from servlet-attribute (banner component) --->
<#elseif hstRequest.requestContext.getServletRequest().getAttribute("htmlTitle")??>
    <title>${hstRequest.requestContext.getServletRequest().getAttribute("htmlTitle")}</title>
<!--otherwise set a default title -->
<#else>
    <title>LIENAS GmbH</title>
</#if>

<!-- for the root-page, because servlet does not work here  -->
<#if hstRequest.requestContext.baseURL.pathInfo = "" || hstRequest.requestContext.baseURL.pathInfo = "/">
    <title>LIENAS GmbH</title>
</#if>

My questions are:

1.Why can I not access the Servlet-Attribute `htmlTitle on the root-page (I debugged the component- it should be there)
2. In case (1) the #else-Block is not executed (that is why I have the last #if Block

Thx

#2

HST is component based framework, so page is composed from the output of different components (composing is done in aggregation valve, see link below).

If you don’t have a controller(component) assigned to your base layout page which sets some attributes onto request, there will be no attributes you can access.
You also cannot access attributes from other (child) components: each component has its own isolated request (this is a bit simplified explanation, see links below for more info).

You can however set attributes onto HstRequestContext object, HstRequestContext is shared among components and each component can set or read attributes from it.
Just remember that execution of the child components is not orderable and also not guaranteed (changing HST config might reorder components). So, before setting an attribute onto HstRequestContext you should check if it already exists (because it can already be set by other component). You can implement your own logic there and decide what to do if attribute is already set.

related documentation:

In addition, HstRequest object provide namespaced access to information such as the parameters and attributes for the component from the request, the HstRequestContext and lifecycle phase. The access is namespaced such that every HstComponent can read and write parameters and attributes from the HstRequest without needing to take into account other Components writing for example to the same attribute name.

#3

Is that not what I tried to do here ?

This works on all pages- except my root (home)-page!!!

And what about my 2nd question ! (#else-Block)

#4

I don’t know.
Did you set that attribute onto HstRequestContext in any of your components?

#5

also, make sure you call:
<@hst.defineObjects/>
before you access attributes.

#6

Yes, in a custom component to render a banner. As I said this works on all pages - except homepage!
This is a code-snippet of the component:

 EssentialsDocumentComponentInfo paramInfo = (EssentialsDocumentComponentInfo)this.getComponentParametersInfo(request);
    String documentPath = paramInfo.getDocument();
    final Banner contentBean = this.getHippoBeanForPath(documentPath, Banner.class);
    final String title = contentBean.getTitle();
    request.getRequestContext().getServletRequest().setAttribute("htmlTitle", title);`Preformatted text`

I debugged the component. It is called from root and the title has a value!!

Yes, it is !!

#7

you should use:
RequestContextProvider.get().setAttribute(“foo”,“bar”)

and:
${hstRequest.requestContext.foo}

#8

ok - I’ll try that next year :slight_smile: and come back with the result.
Happy new year !

#9

happy new year

EqbCF5iW8AMKX7l
EqbCF5iW8AMKX7l800×670 55.3 KB

#10

Hi,

I changed my code as suggested - but I still have the issue, that the title is not working on the root-page:-(

And I still have the issue, that the else block ist not working in the frameworker template.
That is what I have currently in the Template:

<#-- Title -->
<#if hstRequest.requestContext.contentBean.title??>
    <title>${hstRequest.requestContext.contentBean.title}</title>
<#elseif hstRequest.requestContext.getAttribute("htmlTitle")??>
    <title>${hstRequest.requestContext.getAttribute("htmlTitle")}</title>
<#else>
    <title>LIENAS GmbH</title>
</#if>

an in my component (org.lienas.components.OsdeSearchBannerComponent) :
RequestContextProvider.get().setAttribute("htmlTitle", title);

I would expect, that

  • title = title of document in pages with a single document
  • title = htmlTitle injected by component OsdeSearchBannerComponent in pages with that component
  • title = LIENAS GmbH if the other options are not valid

But what I get is:

  • no title on the root-page
  • not title on pages which are not single documents or they do not have the OsdeSearchBannerComponent

I am confused !!

#11

I expect your log files are filled with errors. If you don’t have contentBean set, this will throw an exception:

`<#if hstRequest.requestContext.contentBean.title??>

That block needs additional if check hstRequest.requestContext.contentBean??
Other than that, it should work if you set things onto requestContext.
(RequestContextProvider.get().setAttribute(“contentBean”, someBean) etc…

#12

Hi,

unfortunately I do not see errors - althought there should be errors !!

I guess the reason for that is the following error I get on starting since I updated to Version 14.3.3!!!

ERROR StatusLogger Unable to access file://D/Developement/git-hippo/osde_4_1/conf/log4j2-dev.xml
...
ERROR StatusLogger Reconfiguration failed: No configuration found for 'Default' at 'null' in 'null'

Seems to be a version conflict with log4J! I think I shoulf fix that- to get the expected errors.

Do you know this error and can you tell me how I can fix that ??

Additional Info:
On my integration-server I get the following lines:

SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/opt/cms/tomcat/shared/lib/log4j-slf4j-impl-
  2.13.3.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/opt/cms/tomcat/shared/lib/log4j-slf4j-impl-2.11.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
#13

If file://D/Developement/git-hippo/osde_4_1/conf/log4j2-dev.xml exists, check if your tomcat user has enough rights to access it…(file://D) smells like a windows (or a mac?) system… I haven’t touched either one for ages, so I can’t help you with that (user rights issue, if that is the case).

Log4j libraries should only be part of the tomcat shared folder, so if any of your war files contains those jars, that should be fixed (exclude them from war files).

See:

#14

It is a Windows System and I am quite sure that this is not a rights issue.
As already mentioned, that occurs since the Update to 14.3.3.
I tested with a fresh deployment of that version - everything is fine there!

I am also fighting with the maven configuration since that update. In my IDE (IntelliJ) the modules are not always recognized correctly. Especially when I check some changes into git and merge them on annother computer.

The error-message on dev appears while site.war is deployed! So I checked in site.war, if there is a slf4j*.jar in that file. There isn’t.

Where else could the 2nd-version (2.11.1) come from ??? I think it should onlx be 2.13.3 ! Correct?

#15

After some further investigation I found the issue.
I changed the following line in root pom

<log4j.configurationFile>file://${project.basedir}/conf/log4j2-dev.xml</log4j.configurationFile>

to

<log4j.configurationFile>file:///${project.basedir}/conf/log4j2-dev.xml</log4j.configurationFile>`

Just 1 more slash after file: !!

Now I see log entries :slight_smile:

And on integration I just deleted the slf4j-jars for version 2.11.1 in the tomcat shared folder. I do not know how they got there !