Ask Questions and Find Answers

Thanks for your reply.

Maybe I didn't express myself correctly, I didn't talk about adding my own tags into a own JSP file but adding the '<liferay-util:dynamic-include>' tag in other places within a .jsp file of a Liferay portlet, other that the top and bottom places where they are already placed.

Just for setting out a concrete example, what I'm facing is the customization of the jsp(s) files in charge of displaying the documents in the Liferay's Documents & Media portlet. Let's suppose (on the basis that the documents are displayed on a table-displaying setting), I want to remove the 'status' column and I want to add an additional column showing a value from an expando (for instance).

I concluded (I might be wrong) it's not possible to accomplish the intended task on the basis of a 'Dynamic include' approach, mainly because I need to remove elements of a .jsp file.

Do you think the Liferay's'Portlet Filter' approach is valid for the intended task?

I would not use a portlet filter for this. The portlet filter needs to basically buffer the rendered response from the portlet, then it needs to manipulate it without breaking it...

It's a recipe for disaster.

Using the D&M as your example, you can see where the entries are being handled by the view_entries.jsp file. So if you added or removed columns, a JSP fragment bundle gets the job done.

It doesn't need to be overly complicated and have all kinds of "dynamic includes" to support changing the columns. Adding that in for your own implementation just makes things more complicated and is typically not something that users of your portlet will take advantage of.

You know how many "dynamic includes" I have written for my many years of Liferay development? Zero. They're typically at the wrong place, don't allow me to remove things that shouldn't be there and basically they have zero benefit to me as a customizer.

You know how many fragment bundles I have written? Too many to keep track of. If I need to manipulate a JSP, the fragment bundle is the right way to do it and the only way to have total control over what is changed.

You can promote this by decomposing a single page w/ all columns into individual JSP files that are included by a main one, or you can just have the table managed by a single JSP that's easy to override. Either way, it is better taking this route than trying to figure out what someone might want to do with a dynamic include.

As for the Portlet Filter based solution, I was thinking about trasforming the text-based response to an XML-based response, so that it can be easily manipulable; then, and once removed/added the intended/needed xml elements, converting the modified XML-based response to a text-based response to be sent to the client. But it might still be being a recipe for a disaster...

Regarding the Fragment Bundle based solution you propose, I see your point! And the idea of decomposing a single page into individual pages is more than an elegant solution. Thanks a lot.

Thank you very much for your reply.

Maybe my initial question was very general, and I think I should narrow it, because when I talk about customization of .jsp files, I mean customization of .jsp files of Liferay portlets. Setting out a concrete example, what I'm facing is the customization of the jsp(s) files in charge of displaying the documents in the Liferay's Documents & Media portlet.

Let's suppose (on the basis that the documents are displayed on a table-displaying setting), I want to remove the 'status' column and I want to add an additional column showing a value from an expando (for instance).

From your reply, I know I won't be allowed to change the content of the corresponding JSP, so the Liferay's 'Dynamic include' approach is not a valid approach for the intended task. Moreover, the '<liferay-util:dynamic-include>' tags are placed at the top and bottom of the JSP page, which is useless for the intended task.

In your opinion, what is the rigth approach I should embrace to accomplish the intended task? Maybe 'Fragment bundles'? BTW, when you say 'fragment bundle' you mean 'OSGi fragments', don't you? But this approach is discouraged by Liferay, isn't it?.

So the "liferay way" (if we could call it that) is to use a separate jsp(f) file for the column guys.

That way, if you needed to change the columns, a simple fragment bundle will get you there.

But again, I wouldn't do this for code that you own. I mean, you have the code for the original, just fix the original code and mark it as done.

This kind of thing is only useful when someone else, who doesn't have the code for the original, wants to affect their own changes. But separating it out to its own JSP means it can be easily changed (from the column perspective) to include/exclude what you want via a fragment bundle.

Personally, though, I'd forget all of this. I'd have portlet configuration set up so you could show/hide some columns and then leverage that configuration for the rendering of the portlet. If end users need some control over which columns are displayed, you can give them that ability without having them code up some sort of JSP solution to get the job done.

Hi David, thanks for your reply.

I'm really sorry but I don't see your point. You suggest I fix the original code, but the original code is the code of the Liferay's out-of-the-box Document and Media Portlet; it sounds kind a intimidating doing such a thing like that.

Since I'm a newcomer to world of the customization of Liferay's Portlets, I think I'm going to embrace the Fragment Bundle based solution. When I become a more experienced developer I'll come back to the portlet configuration based solution you propose. Thanks.