diego gabriele 8 Years Ago I will try to summarize what your advice is:- for simple customization use JSP hooks or struct action overriding- for complex customization write a new portlet and a new JSP and use interfaces like the CMS-API.So my questions is: for the purposes of the maintenance is Liferay going to change the API, let's say from one major milestone to another milestone? Because if liferay do so, also writing a custom portlet will require maintence work isn't?Regards Please sign in to reply. Reply as... Cancel Olaf Kock diego gabriele 8 Years Ago "It depends" (TM) - this is also what I'd like to state as my advice When you modify a JSP, you're actually modifying Liferay's implementation. A JSP-hook is very close to an ext-plugin in that it actually refers to the implementation of Liferay itself - it just is easier to override through copying a few JSPs. Thus, when you change the implementation of Liferay (the portal), keep in mind that it is the business of Liferay (the company) to change its implementation too. And nobody minds if someone else did the same in a plugin.The API however is designed to be as stable as possible. It changes far less often (and if it happens it's easier to identify and potentially better documented) than any change to the implementation, including a JSP. So yes, you still have to maintain your portlets, but at least they're shielded from the implementation by the API. That should be a lot easier than a three-way-merge every time you get a minor fix for something in Liferay. From that point of view my advice is: Don't immediately choose the obvious (a JSP hook) but note that there are more options. Choose one of them because you've evaluated the different expected maintenance effort. And don't underestimate the problems of maintaining a JSP hook to a complex JSP page.All other things being equal (which they never are), I'd always opt for easier maintainability. Which side will be easier to maintain depends a lot on the complexity of the changed UI. It's just that I have the feeling that nobody ever thinks of writing their own plugin, everybody just tries to modify Liferay's UI and I'd like to turn this default around or at least provide another option. Please sign in to reply. Reply as... Cancel
Olaf Kock diego gabriele 8 Years Ago "It depends" (TM) - this is also what I'd like to state as my advice When you modify a JSP, you're actually modifying Liferay's implementation. A JSP-hook is very close to an ext-plugin in that it actually refers to the implementation of Liferay itself - it just is easier to override through copying a few JSPs. Thus, when you change the implementation of Liferay (the portal), keep in mind that it is the business of Liferay (the company) to change its implementation too. And nobody minds if someone else did the same in a plugin.The API however is designed to be as stable as possible. It changes far less often (and if it happens it's easier to identify and potentially better documented) than any change to the implementation, including a JSP. So yes, you still have to maintain your portlets, but at least they're shielded from the implementation by the API. That should be a lot easier than a three-way-merge every time you get a minor fix for something in Liferay. From that point of view my advice is: Don't immediately choose the obvious (a JSP hook) but note that there are more options. Choose one of them because you've evaluated the different expected maintenance effort. And don't underestimate the problems of maintaining a JSP hook to a complex JSP page.All other things being equal (which they never are), I'd always opt for easier maintainability. Which side will be easier to maintain depends a lot on the complexity of the changed UI. It's just that I have the feeling that nobody ever thinks of writing their own plugin, everybody just tries to modify Liferay's UI and I'd like to turn this default around or at least provide another option. Please sign in to reply. Reply as... Cancel