Fórum

ADT in DXP for document metadata values

David Weitzel, modificado 6 Anos atrás.

ADT in DXP for document metadata values

Junior Member Postagens: 65 Data de Entrada: 07/10/15 Postagens Recentes
Hi guys
not sure if this is a bug or I am just not doing it right. I am converting 6.2 ADT for listing documents that needs to retrieve data from the document type dataset.
The old method (see here) of using the DLFileEntry.getFields method is not longer available.

so we have to resort to using the Storage Engine.

when I add
<#assign storageEngineUtil = utilLocator.findUtil("com.liferay.dynamic.data.mapping.kernel.StorageEngineManagerUtil") /> 

to my template I am getting a bean not found error (at least UtilLocator is being called - the allowed variables properties have to be set through the ui now)
12:08:49,551 ERROR [http-nio-8080-exec-3][UtilLocator:39] com.liferay.portal.kernel.bean.BeanLocatorException: org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'com.liferay.dynamic.data.mapping.kernel.StorageEngineManagerUtil' is defined
com.liferay.portal.kernel.bean.BeanLocatorException: org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'com.liferay.dynamic.data.mapping.kernel.StorageEngineManagerUtil' is defined
	at com.liferay.portal.bean.BeanLocatorImpl.locate(BeanLocatorImpl.java:111)
	at com.liferay.portal.kernel.bean.PortalBeanLocatorUtil.locate(PortalBeanLocatorUtil.java:90)
	at com.liferay.portal.template.UtilLocator.findUtil(UtilLocator.java:36)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at freemarker.ext.beans.BeansWrapper.invokeMethod(BeansWrapper.java:1458)
	at freemarker.ext.beans.ReflectionCallableMemberDescriptor.invokeMethod(ReflectionCallableMemberDescriptor.java:52)
	at freemarker.ext.beans.MemberAndArguments.invokeMethod(MemberAndArguments.java:48)
	at freemarker.ext.beans.OverloadedMethodsModel.exec(OverloadedMethodsModel.java:62)
	at freemarker.core.MethodCall._eval(MethodCall.java:62)
	at freemarker.core.Expression.eval(Expression.java:78)
	at freemarker.core.Assignment.accept(Assignment.java:131)
	at freemarker.core.Environment.visit(Environment.java:324)
	at freemarker.core.MixedContent.accept(MixedContent.java:54)
	at freemarker.core.Environment.visitByHiddingParent(Environment.java:345)
	at freemarker.core.ConditionalBlock.accept(ConditionalBlock.java:48)
	at freemarker.core.Environment.visit(Environment.java:324)
	at freemarker.core.MixedContent.accept(MixedContent.java:54)
	at freemarker.core.Environment.visit(Environment.java:324)
	at freemarker.core.Environment.process(Environment.java:302)
	at freemarker.template.Template.process(Template.java:325)
	at com.liferay.portal.template.freemarker.internal.FreeMarkerTemplate.processTemplate(FreeMarkerTemplate.java:135)
	at com.liferay.portal.template.AbstractSingleResourceTemplate.doProcessTemplate(AbstractSingleResourceTemplate.java:67)
	at com.liferay.portal.template.AbstractTemplate.write(AbstractTemplate.java:175)
	at com.liferay.portal.template.AbstractSingleResourceTemplate.processTemplate(AbstractSingleResourceTemplate.java:90)
	at com.liferay.portal.template.RestrictedTemplate.processTemplate(RestrictedTemplate.java:97)
	at com.liferay.portal.templateparser.Transformer.mergeTemplate(Transformer.java:243)
	at com.liferay.portal.templateparser.Transformer.transform(Transformer.java:146)
	at com.liferay.portlet.display.template.internal.PortletDisplayTemplateImpl.renderDDMTemplate(PortletDisplayTemplateImpl.java:456)
	at com.liferay.portlet.display.template.internal.PortletDisplayTemplateImpl.renderDDMTemplate(PortletDisplayTemplateImpl.java:483)
	at com.liferay.portlet.display.template.PortletDisplayTemplateUtil.renderDDMTemplate(PortletDisplayTemplateUtil.java:150)
	at org.apache.jsp.template_005frenderer.start_jsp._jspService(start_jsp:246)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
	



Doe s anyone have an example of ADT for DXP that accesses document Type fields? spent a long time searching and cannot find any - I would think this was pretty common
thumbnail
David H Nebinger, modificado 6 Anos atrás.

RE: ADT in DXP for document metadata values

Liferay Legend Postagens: 14914 Data de Entrada: 02/09/06 Postagens Recentes
Ick.

So personally I never really like doing business logic inside of a script. I have always found it to be more useful to build a custom SB instance, add my complicated logic in here, then just let the scripts find and invoke my actual code with the simple variables they have.

Plus, going this route you get to deal with certain issues at compile time and you only have to worry about runtime issues in the script, plus you can both log and debug those as they're in code and not just in scripts.







Come meet me at the 2017 LSNA!
David Weitzel, modificado 6 Anos atrás.

RE: ADT in DXP for document metadata values

Junior Member Postagens: 65 Data de Entrada: 07/10/15 Postagens Recentes
Hi David,
There is no business logic here.
All I am trying to do is list documents from the asset entries list, but access the "custom properties" that are in our document type - things like "Display Title" (Since the title in the control panel is for admin to find and has to be unique), "Author" which could be a public figure not a Liferay user and the "Actual Publish Date" which is the date when a document was signed actually published which may in future be a work follow item but isn't at the moment.

I can actually list the fields but not the values for which I need the Storage Manager from what I can tell, should I raise a ticket?

were you confusing with my post about Calendar entries? What I did was pretty basic and again what users really want to do.

In 6.2 there was a way of avoiding the StorageManager using the DLFileEntryGetFields() method but that is no more. No documented replacement example that I can see. I'm sure it will all work in java code but not Freemarker templates from what I see.

What did you mean by "custom SB instance," surely not a Service builder interface?
thumbnail
David H Nebinger, modificado 6 Anos atrás.

RE: ADT in DXP for document metadata values

Liferay Legend Postagens: 14914 Data de Entrada: 02/09/06 Postagens Recentes
David Weitzel:
What did you mean by "custom SB instance," surely not a Service builder interface?


Yep, certainly do. I separate business logic from display logic. To me the display logic is good for the ADT, but business logic (even a matter of finding all documents for a given article) I prefer to wrap in a entityless service layer (since both velocity and freemarker have support for accessing custom service instances).

And like I said, there are a lot of benefits from going this route. As code, it is under revision control so changes can be tracked. You can easily log statements out of the custom code, plus you can set a debug breakpoint in code to resolve issues that you just can't do inside of the ADT.








Come meet me at the 2017 LSNA!
thumbnail
Christoph Rabel, modificado 6 Anos atrás.

RE: ADT in DXP for document metadata values

Liferay Legend Postagens: 1554 Data de Entrada: 24/09/09 Postagens Recentes
I'm with David Nebinger here, I think this will get messy and you shouldn't implement it in Freemarker.
But skip SB. Too much overhead. Just register the service yourself.

Create an Activator module and create a DLFileEntryHelper class and Impl
build.gradle:
compileOnly group: "com.liferay", name: "com.liferay.registry.api", version: "1.0.0"

import com.liferay.registry.ServiceRegistration;

public void start(BundleContext bundleContext) throws Exception {
            Registry registry = RegistryUtil.getRegistry();
            _serviceRegistration = registry.registerService(DLFileEntryHelper.class, new DLFileEntryHelperImpl());
}

public void stop(BundleContext bundleContext) throws Exception {
   if (_serviceRegistration != null) _serviceRegistration.unregister();
    _serviceRegistration = null; // Not sure if necessary
}


Then you can use serviceLocator to fetch your DLFileEntryHelper as usual.
thumbnail
David H Nebinger, modificado 6 Anos atrás.

RE: ADT in DXP for document metadata values

Liferay Legend Postagens: 14914 Data de Entrada: 02/09/06 Postagens Recentes
+1 Christoph, but only if you're on DXP. The OP started saying 6.2, so self registration isn't going to be a recommended path for him yet.








Come meet me at the 2017 LSNA!
David Weitzel, modificado 6 Anos atrás.

RE: ADT in DXP for document metadata values

Junior Member Postagens: 65 Data de Entrada: 07/10/15 Postagens Recentes
I am converting from 6.2 to DXP.
What is frustrating is that this template has been working for years in 6.2 using the getFieldValues method and here we are talking about every single customer having to write their own SB or other code in order to access the StorageManager Util from which we should be able to get the Fieldvalues.

It will not happen, this has to be available as standard using similar templating as before

or is this just a bug that I can create on LESA?

Is there a reference location of example and liferay provided ADT's and other templates for DXP ? (eg the new default Journal Article structure and template?
thumbnail
Andrew Jardine, modificado 6 Anos atrás.

RE: ADT in DXP for document metadata values

Liferay Legend Postagens: 2416 Data de Entrada: 22/12/10 Postagens Recentes
Personally, I think ADTs are one of, if not the best, feature that was introduced in 6.2. I also think that it is one of the most abused and incorrectly used. I you go cruise through message boards where people are asking question about scriptlets in JSPs you'll find peopel going crazy yelling about bad code and code smell and incorrect usage, etc. Putting your business logic in an ADT is the same story.

My understanding of ADT was that it was meant to be a way to provide multiple representations of the data. But the idea is that the final data, in the form you need it, is passed to the template. The template is just supposed to pick out the fields it needs and lay them out into the template. I don't think the intention of an ADT was to allow users to create a microapp using the service locator.

So with that said, I am with David on this one -- there should be a wrapping service. Any time i write a solution where i find myself relying on a portion of the Liferay API, I will likely decide to wrap my own service around it. It's a simple technique that mitigates the risk (and the future work) that is require to update the code when the API changes.

Personally, I would not consider this a bug but rather you have an opportunity now to use ADT in the proper manner, and to refactor your code to provide a better (and more future proof) solution.
thumbnail
Christoph Rabel, modificado 6 Anos atrás.

RE: ADT in DXP for document metadata values

Liferay Legend Postagens: 1554 Data de Entrada: 24/09/09 Postagens Recentes
While I think that code in ADTs should be minimized, I also think that you are right, this is either a bug or weird behaviour. If there is a Util Locator and a set of Util classes, the UtilLocator should be able to find them.

So, I think you should open a LESA ticket and ask support about the exception.
Lee Jordan, modificado 3 Anos atrás.

RE: ADT in DXP for document metadata values

Expert Postagens: 449 Data de Entrada: 26/05/15 Postagens Recentes
Same issue here, I am trying to display a document title because there is currently no such field for a document title (flame me, roast me, but there isn't a document title currently in DM and we all need to look at it closer). Localhost, turned on service locator, I can't get my (now wonderful translatable) document title field to display in my template.

Is there an easier way to access these fields, like there is in Web Content ... you just go myFieldName.getData() boooooom job done.  Move on and there is none of this service locator funny business??