RE: Easier data access in Webcontent templates (and maybe ADTs)

thumbnail
Christoph Rabel, modified 5 Years ago. Liferay Legend Posts: 1555 Join Date: 9/24/09 Recent Posts
When I write a webcontent template currently, I have quite a hard time to access some of the data.
Accessing .vars['reserved-article-create-date'].data is clumsy and not intuitive, accessing categories is not trivial. Related articles? Complicated. Accessing translations (or even checking if there are indeed translations available) is not directly possible.
I would like to have a better access object or a helper that gives me:
* a List of related assets*
(a helper would be nice here to allow me to use the actual asset (JournalArticle, DLFileEntry, ..., but lets start small)
* a list of categories
* a list of tags
* a list of custom fields
* all relevant fields of the article (groupId please!)
* a view link to the item (display page, download link for files, ...)
* an edit link
...
and I am sure, more could be found.

Extra features:
* Allow me to map those fields to fragments and to specify how they should be rendered
* Allow me to add my own fields (I am not talking about structure fields but dynamic attributes to enrich the article data e.g. with a list of similar articles, articles by the same author, ...)
* Please allow me to fetch that data transfer object in ADTs too (at least for JournalArticle and DLFileEntry it would be really helpful)

I believe that a fitting DTO would be most convenient, but maybe a nice helper service would be better for some usecases or from a performance point of view.
thumbnail
Fernando Fernandez, modified 5 Years ago. Expert Posts: 401 Join Date: 8/22/07 Recent Posts
Indeed :-)
Lee Jordan, modified 5 Years ago. Expert Posts: 449 Join Date: 5/26/15 Recent Posts
Upvoted +1

I also can't request service locator be re-enabled in Freemarker and we shouldn't have to allow API access to all template creators anyway. So 95% of documented workarounds to get to data are useless to me.

The question is how do we move forward?

A standard approach to variables is needed and we have the best perspective on what's needed, perhaps we could explore this? For me the "assethelper" has been really helpful for ADT writing, but there's so much the asset helper can't do and everything leads back to service locator. So can we wrap up those ugly service locator hacks into a standard data set like ... ${entry.small-image} ${entry.related-assets} etc etc?

It should be intuitive enough that we can guess a dot notation expansion for what we need, custom fields ... ${entry.custom-field.my-custom-field}
Lee Jordan, modified 5 Years ago. Expert Posts: 449 Join Date: 5/26/15 Recent Posts
With LSV-658 also ... Remote code execution (RCE) with FreeMarker/Velocity templates ... It's becoming impossible to do much of of anything beyond basic stuff with templates. Service Locator is one of those, it was restricted for a reason, we can't just lift the restriction especially not if the service is in the cloud, or not behind a firewall.
thumbnail
Jorge Ferrer, modified 5 Years ago. Liferay Legend Posts: 2871 Join Date: 8/31/06 Recent Posts
Hey Christoph,Those all seem like reasonable requests to me. I have not spend a lot of time lately researching the situation of the Templating context, but I'd like to revisit it once we finish the ongoing work on Collection Display and related components. In fact, much of what you describe is being covered as part of this work, but for mapping through the UI. It would make a lot of sense to me to leverage the same infrastructure to make it also available in templates.Would you mind creating a feature request (or several if you think the idea can be broken up into several needs) so that we can discuss it in more detail a bit further on and come up with a solution?
thumbnail
Jorge Ferrer, modified 5 Years ago. Liferay Legend Posts: 2871 Join Date: 8/31/06 Recent Posts
Thanks Christoph!
thumbnail
Jorge Ferrer, modified 5 Years ago. Liferay Legend Posts: 2871 Join Date: 8/31/06 Recent Posts
BTW, try to always select the most appropriate component when creating a Feature Request. That will make it arrive to the appropriate team faster.