Currently in my project we are caching methods using ehcache and Spring cache system, however I don't know which mechanism we should use to cache components like header, footer, banners etc...
Does Hybris provides a mechanism via XML to cache these components?
By default Hybris already caches CMS components using an EhCache region called cmsCacheRegion. You can find configuration for this bean in acceleratorcms-cache-spring.xml
This can be enabled/disabled with the property cms.cache.enabled. If using Cloud Commerce, this property will be enabled by default on storefront nodes.
If you would like to extend the CMS component types being cached, see bean defaultCacheKeyProviders in acceleratorcms-spring.xml. You should mostly be covered though as there's an entry for AbstractCMSComponent
Some more information here: https://help.sap.com/viewer/4c33bf189ab9409e84e589295c36d96e/2105/en-US/8abd87cc866910149aa5e52e716d568e.html?q=acceleratorcms
Related
I'm new to developing for Liferay DXP and for OSGi.
When we were using Liferay 6.2, we used Spring to configure com.liferay.portal.security.ldap.PortalLDAPExporterUtil to use our class that implemented com.liferay.portal.security.ldap.PortalLDAPExporter, com.liferay.portal.security.ldap.PortalLDAPImporterUtil to use our class that implemented com.liferay.portal.security.ldap.PortalLDAPExporter, and implement our own com.liferay.portal.security.auth.Authenticator.
Now that we're using Liferay DXP, I've been able to change one of the services a module's component uses, but what do I do if I want to change the service a component provides? I notice that com.liferay.portal.security.ldap.internal.authenticator.LDAPAuth, com.liferay.portal.security.ldap.internal.exportimport.LDAPUserExporterImpl, and com.liferay.portal.security.ldap.internal.exportimport.LDAPUserImporterImpl are all components of the LDAP application's "Liferay Portal Security LDAP" module. I want to make sure my version of these things are used, instead of the LDAP's version. Is it possible to replace a module's component or the implementation of the service that component provides? Or do I need to replace the entire LDAP application with my own version?
I'm currently trying to use PrimeFaces (not mobile) for my WebSphere 8.0 application. The basic stuff like p:dataTable seems to work. But if I want to use the fancy stuff of PrimeFaces, like filter columns or pagination, there is either a NullPointerException or the additional function is not rendered at all.
The Nullpointer occurred when entering something in the generated filtering field in the table. The setter method that is called is given null as parameter.
The pagination on the other hand is not even being rendered. (I used the templates of the PrimeFace showcase)
Weird thing is, the sorting by column function is working fine.
I haven't done any big adjustments, just put the .jar file to my classpath and disabled all themes of PrimeFaces in my web.xml. That's it.
When I inspect the network and stuff in chrome there is no exception thrown in the console when loading the page.
Now I'm thinking that this version of PrimeFaces is not compatible with MyFaces2.0 that is used by WAS8.0.
Is that the case? If so, what version of PF would be compatible? Or would it be possible to load a newer Version of MyFaces and dependencies and put it in WAS to use this version instead of the current used version?
Or maybe I have to make some adjustments to my application?
If everything is not possible, do you know an alternative to PF to easily create tables?
Using a third-party JSF provider with WebSphere is documented here (the doc is for 8.5.5, but it's the same procedure in 8.0): https://www.ibm.com/support/knowledgecenter/en/SSAW57_8.5.5/com.ibm.websphere.nd.doc/ae/tweb_jsf.html
Basically, the answer is to put your provider (along with the corresponding API) into a shared library, set that library to use an isolated class loader, and associate that shared library with your web app. That will tell the web module's class loader to search your shared library before it delegates to server class loaders, and it'll find your JSF provider first when your app attempts to use JSF.
I want create simple cache in my JSF project. I view a few method of cache in web app (Guava, Redis etc.) and I choose Omnifaces cache. I found example here, but in this example Omnifaces is used for chart with tag in XHTML. In my project I created charts dynamically in Java code so maybe someone know how use it in my case. I dont't have <p:chart>tag in my project. Maybe is something better for JSF cache than Omnifaces.
Quoting from http://showcase.omnifaces.org/components/cache
The component allows to cache a fragment of rendered markup.
So this is usefull if you want to cache already rendered code which is expensive to rerender.
In your case you need a Java cache. One of the easiest solutions is to use the life cycle model of CDI beans to cache the results. Using #Inject inject a reference to your cached results. You may want to choose different strategies depending on your use-case.
I'm developing a web application and using JSF 2.2 and Primefaces.
It contains a lot of output texts, user warning messages etc. I want to support many different languages. What is the most usable way to do this? Is there any standard or efficient procedure to achieve this?
JSF supports internationalized messaging through locale specific .properties resource files. Once a locale is set, either implicitly via the browser or explicitly by the user, the appropriate bundle will be loaded. For browser settings:
<f:view locale="#{facesContext.externalContext.requestLocale}">
You will also need to define the <resource-bundle> in you faces-config.xml where base-name defines the base file name and var defines the scoped result map.
I would start with this doc from #BalusC: http://jdevelopment.nl/internationalization-jsf-utf8-encoded-properties-files/
Also from #Mkyong: http://www.mkyong.com/jsf2/jsf-2-message-and-messages-example/
Both files seem very similar, subsequently I'm struggling to understand their purposes.
I have seen faces-config referred to as a plain JSF controller, while adfc-config is an extended ADF controller.
Some clarification would be good, as right now I can't see why you would have both in an ADF application if that is the case, so I must be missing something.
adfc-config is different from faces-config
Faces Config is the controller of your application, it's what make JSF based frameworks work effectively, and it's where you will need to define your own customization like view handlers, converters, validators, etc...
adfc-config is just the main application unbounded Task Flow, which make it a little easier for developers to define their pages and main navigation root inside of it instead of doing it the JSF way and define them in faces config, it also provide additional functionality like defining managed beans which will have much more scopes than the original JSF given the ADF Framework additions, but still at the end it's just an Unbounded Task Flow. Here is the documentation reference about adfc-config.xml
adfc-config is used by the ADF Faces framework, when task flows are in the picture.
More information at: http://docs.oracle.com/cd/E23943_01/web.1111/b31974/taskflows.htm
Yes, you are right when you say that the functionality looks similar. Things like pageFlowScope / backingBeanScope / task flows / etc. are extensions to the standard JSF framework and require a custom configuration file.
So, if you create a project based on the Fusion WebApplication template, then you will see a default adfc-config.xml file entry.
Hope that helps.