Search code examples
javascriptiframeextjsliferayportlet

Placing an iframe inside of a Liferay portlet


This is not a technical question whatsoever. What I have done is created an Ext JS application that I wanted to utilize inside of a Liferay portlet. After experimenting and failing miserably trying to import the entire Ext JS project into Liferay, I decided to place the entire application inside of an iframe, and place that iframe easily into my portlet (since portlets can render html).

This is probably the simplest method, it makes my project much less bulky (not importing the entire Ext JS framework which is about 204MB as well as my application).

Also, it allows for extensibility. Whenever I modify my Ext JS application, changes will immediately show in my portlet because an iframe is independent from the main html document.

The question(s): Are there any issues I'm overlooking by doing this? Any kind of problems that may arise?

To me it seems like the easy way out but when I think about it, it's a much smarter approach.

Cheers mates!


Solution

  • You're providing some information about decisions that you have made, but not about their reasons. I'm infering some possible reasons to highlight what might be the caveats of this approach:

    Let's say you'll have to integrate with Liferay, because that's the existing portal, and you're choosing Ext JS because that's what you're most familiar with.

    This optimizes the development time for the application by making best use of your time. If you're the one Ext JS guru in your office, this might be a burden for maintainers. If Ext JS is only one example of a "personal" choice, your portal might end up as a huge pile of "legacy" implementations (which is what I call this kind of solutions). So you bought quick development time by drawing from future maintenance effort.

    Let's say you've chosen to use Ext JS (external to portlet) because nobody in your team could give you a hint on how to do proper portal/portlet development. This should raise a red flag for the team, being unable to support the environment of choice. But it can be mitigated, either by choosing a different platform or by proper training

    Let's say you're chosen Ext JS because nobody cared and it's a truly "throwaway" application, write-once-run-forever (or run-for-a-limited-time) where nobody expects any maintainance effort and you just want it out-of-the-way. In this case: Don't worry.

    What are you missing? You basically don't get anything from the portal environment: Infrastructure, theming, identity management, permissioning, clustering, failover, caching, monitoring etc. It's up to you to judge if this acceptable or not. Some examples: Will the admins now be required to monitor your independently running application because it can be down independent of the portal? Who understands what to do in case it's down? How do you handle log in to your application?