[ICE-3266] Provide a client side bridge API to dispose of a view - ICEsoft JIRA Issue Tracker

Details

Type: Improvement
Status: Closed
Priority: Major
Resolution: Fixed
Affects Version/s: None
Fix Version/s: 1.7.2
Component/s: Bridge
Labels:
None
Environment:
portal portlet Liferay

Support Case References:
https://www.icesoft.ca:4443/supportilla/show_bug.cgi?id=4892
Affects:

Documentation (User Guide, Ref. Guide, etc.), Sample App./Tutorial

Description

It's possible in certain portal environments like Liferay to dynamically remove a portlet from a portal page. When this occurs, there is currently no way for the ICEfaces framework to properly dispose of the resources associated with that view. Liferay (an possibly other portal containers) does provide a mechanism to listen for when a portlet is closed which would allow a developer to call an ICEfaces API to dispose of the associated view.

Note that this must be a client-side JS API.

Issue Links

blocks

ICE-2657 Using Liferay portlet close widget to dynamically remove ICEfaces portlets results in bridge JS error

Closed

ICE-4107 Provide simple API for dynamically disposing the views

Closed

depends on

ICE-3229 Bridge cannot dispose of multiple views within a single window (portlets).

Closed

Activity

Ascending order - Click to sort in descending order

Hide

Permalink

Deryk Sinotte added a comment - 02/Jul/08 3:40 PM

The listener code for portlets closing in Liferay is outlined in this case:

http://jira.icefaces.org/browse/ICE-2657

Work on this issue should also be coordinated with the work on this case:

http://jira.icefaces.org/browse/ICE-3229

for disposing of multiple views (when a portal page is closed).

Show

Deryk Sinotte added a comment - 02/Jul/08 3:40 PM The listener code for portlets closing in Liferay is outlined in this case: http://jira.icefaces.org/browse/ICE-2657 Work on this issue should also be coordinated with the work on this case: http://jira.icefaces.org/browse/ICE-3229 for disposing of multiple views (when a portal page is closed).

Hide

Permalink

Mircea Toma added a comment - 03/Jul/08 2:31 PM

I think the opposite, ICEFaces using Liferay's client API, is a much simpler proposition. Even if we have a client API of our own, the exact way it should be used could make it very difficult to use properly by a developer.

Show

Mircea Toma added a comment - 03/Jul/08 2:31 PM I think the opposite, ICEFaces using Liferay's client API, is a much simpler proposition. Even if we have a client API of our own, the exact way it should be used could make it very difficult to use properly by a developer.

Hide

Permalink

Deryk Sinotte added a comment - 03/Jul/08 5:23 PM

It's true that it might be simpler, but it has the drawback of ICEfaces needing to include proprietary Liferay code in our client bridge - code that would only be exercised in a certain percentage of deployments. It's small but unnecessary for many other (ie non-Liferay) environments. Adding stuff like this to the client-side code goes against our "server-centric", "highly mobile" characteristics too. Having an API there that can be used to dispose 1 or more views can solve more than one issue and could prove valuable going forward. At this point, I'd be happy to have the API available but undocumented (i.e use at your own risk). We can even stamp it with a skull and crossbones Since it's JavaScript, many of the functions fall into that category. As we look towards future versions of ICEfaces, we might start to build a more "open" client API anyway.

Show

Deryk Sinotte added a comment - 03/Jul/08 5:23 PM It's true that it might be simpler, but it has the drawback of ICEfaces needing to include proprietary Liferay code in our client bridge - code that would only be exercised in a certain percentage of deployments. It's small but unnecessary for many other (ie non-Liferay) environments. Adding stuff like this to the client-side code goes against our "server-centric", "highly mobile" characteristics too. Having an API there that can be used to dispose 1 or more views can solve more than one issue and could prove valuable going forward. At this point, I'd be happy to have the API available but undocumented (i.e use at your own risk). We can even stamp it with a skull and crossbones Since it's JavaScript, many of the functions fall into that category. As we look towards future versions of ICEfaces, we might start to build a more "open" client API anyway.

Hide

Permalink

Mircea Toma added a comment - 04/Jul/08 5:23 AM

Add public method that notifies server and then disposes the view bound bridge instance.
Here's an example how the public method can be used:

{ 'id1234'.asExtendedElement().findBridge().disposeAndNotify(); }

);
</script>

The 'script' element needs to be inserted somewhere in the portlet content so that it can find the bridge instance.

Show

Mircea Toma added a comment - 04/Jul/08 5:23 AM Add public method that notifies server and then disposes the view bound bridge instance. Here's an example how the public method can be used: <script id="id1234"> Liferay.bind('closePortlet', function() { 'id1234'.asExtendedElement().findBridge().disposeAndNotify(); } ); </script> The 'script' element needs to be inserted somewhere in the portlet content so that it can find the bridge instance.

Provide a client side bridge API to dispose of a view

Details

Description

Issue Links

Activity

People

Dates