将iframe放在Liferay portlet中

Question

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!

Answer 1

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?

Answer 2

It doesn't really sound like you're using Liferay or portlets as they are typical are used. Which asks the question, why are you even using Liferay and portlets to begin with? If you're just writing a JS application, what's the point of this thing in the middle adding an extra layer that you don't know how to work with? I dont mean that to be an insult, it just seems like it isn't the right tool for the job, or you need to spend more time learning about Liferay, portlets and how they work.

More to your specific questions though: In general, I tend to think of iframe usage as a hack around trying to find a better solution. There are some use cases for iframes. See this question Why do people still use iframes? for more on use cases for iframes.

Edit: Gave it some more thought on why I feel this solution isn't as good as it could be. By serving your application from an iframe that Liferay provides, your changing the architecture of the solution. I've used an iframe in a portlet before, so it can offer a solution. But we only did so because there was NO other way to get the functionality we needed into our solution. And this was because it was a limitation of the services we had to connect to. By getting Liferay to serve the application, you can maintain the general architecture of the existing solution.