Common Struts action for multiple Liferay Ext portlets

[11年前 に Martin Egunjobi によって更新されました。]

Hello all,

This is my first post so please forgive me if the question is not clear enough - I'll do my best to explain it well.
I have some custom portlets created through an ext plugin and I want each of these portlets to be able to call a struts action which will do some processing like retrieve some text from a db, etc. and eventually render a JSP. E.g. login portlet and registration portlet would need to be able to call that custom action when a certain link is clicked on the corresponding pages (I understand the link can be created through the use of the <portlet:actionURL> tag). Now the question - what options do I have when it comes to creating that custom, but also common to all ext portlets,action? The immediate problem I can see is the fact that the ext portlets have different struts actions (e.g. /ext/login and /ext/register). If I define the new custom action along with the ext actions then I'd need a mapping per struts action for each portlet's struts path which doesn't seem very flexible, i.e. if I wanted to map the new action called showdetails to an action class I'd need /ext/login/showdetails and /ext/register/showdetails.Is there a more flexible way to achieve this?I'd appreciate suggestions, code samples, etc.

Thank you in advance,

Martin

[11年前 に David H Nebinger によって更新されました。]

First you should not be using an EXT plugin this way. Deploying plugins in an EXT is a feature that is marked for deprecation (translation: not supported) in the future.

As far as the portlets themselves go, if you bundle them in a single deployable war file, they can all use the same struts action.

But honestly I'd say what you're doing is totally wrong. Your DB access stuff should be done using Service Builder, that way all of the DB access is done in one spot and is shared. Your portlets may or may not be separated depending upon requirements, but I would decouple the shared code from the portlet implementations and deploy that separately (possibly within the SB code, since it handles that pretty well). Finally, for login/registration I would examine the requirements and decide whether it was easier to extend the Liferay implementations or roll my own. Extending has value in that login itself is a core portlet that Liferay uses in many places, but if you're changes end up having you pound a square peg into a round hole, the roll your own option may prove to be easier.

All that said, what you may have now might be working, but the advice that I'm offering is based upon years of experience with Liferay. From that experience I know there is a significant cost involved when you go against the Liferay grain, a cost that you might not incur right now but one that you'll pay when it comes time to do an upgrade to a newer version.