ICEfaces
  1. ICEfaces
  2. ICE-3266

Provide a client side bridge API to dispose of a view

          Details

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

            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

              Task - A task that needs to be done. ICE-2657 Using Liferay portlet close widget to dynamically remove ICEfaces portlets results in bridge JS error

              • Minor - Minor loss of function, or other problem where easy workaround is present.
              • Closed

              Improvement - An improvement or enhancement to an existing feature or task. ICE-4107 Provide simple API for dynamically disposing the views

              • Major - Major loss of function.
              • Closed
              depends on

              Bug - A problem which impairs or prevents the functions of the product. ICE-3229 Bridge cannot dispose of multiple views within a single window (portlets).

              • Major - Major loss of function.
              • Closed

                Activity

                Ascending order - Click to sort in descending order
                Deryk Sinotte created issue -
                Hide
                Permalink
                Deryk Sinotte added a comment -

                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 - 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).
                Deryk Sinotte made changes -
                Field Original Value New Value
                Assignee Mircea Toma [ mircea.toma ]
                Ken Fyten made changes -
                Link This issue blocks ICE-2657 [ ICE-2657 ]
                Ken Fyten made changes -
                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 assocated view. 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.
                Ken Fyten made changes -
                Component/s Bridge [ 10011 ]
                Fix Version/s 1.7.2 [ 10130 ]
                Assignee Priority P1
                Hide
                Permalink
                Mircea Toma added a comment -

                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 - 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 -

                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 - 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.
                Repository Revision Date User Message
                ICEsoft Public SVN Repository #17022 Fri Jul 04 04:06:06 MDT 2008 mircea.toma ICE-3266 Add public method that notifies server and then disposes the view bound bridge instance.
                Files Changed
                Commit graph MODIFY /icefaces/trunk/icefaces/bridge/lib/element.js
                Commit graph MODIFY /icefaces/trunk/icefaces/bridge/src/application.js
                Repository Revision Date User Message
                ICEsoft Public SVN Repository #17023 Fri Jul 04 04:15:13 MDT 2008 mircea.toma ICE-3266 Add public method that notifies server and then disposes the view bound bridge instance
                Files Changed
                Commit graph MODIFY /icefaces/branches/icefaces-1.7/icefaces/bridge/src/application.js
                Commit graph MODIFY /icefaces/branches/icefaces-1.7/icefaces/bridge/lib/element.js
                Hide
                Permalink
                Mircea Toma added a comment -

                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.

                Show
                Mircea Toma added a comment - 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.
                Mircea Toma made changes -
                Status Open [ 1 ] Resolved [ 5 ]
                Resolution Fixed [ 1 ]
                Ken Fyten made changes -
                Link This issue depends on ICE-3229 [ ICE-3229 ]
                Repository Revision Date User Message
                ICEsoft Public SVN Repository #17175 Wed Jul 16 08:57:34 MDT 2008 mircea.toma ICE-3266 Add public method that notifies server and then disposes the view bound bridge instance.
                Files Changed
                Commit graph MODIFY /icefaces/branches/icefaces-1.7.1/icefaces/bridge/src/application.js
                Commit graph MODIFY /icefaces/branches/icefaces-1.7.1/icefaces/bridge/lib/element.js
                Ken Fyten made changes -
                Fix Version/s 1.7.2RC1 [ 10140 ]
                Fix Version/s 1.7.2 [ 10130 ]
                Ken Fyten made changes -
                Fix Version/s 1.7.2 [ 10130 ]
                Fix Version/s 1.7.2RC1 [ 10140 ]
                Ken Fyten made changes -
                Status Resolved [ 5 ] Closed [ 6 ]
                Assignee Priority P1
                Assignee Mircea Toma [ mircea.toma ]
                Mircea Toma made changes -
                Link This issue blocks ICE-4107 [ ICE-4107 ]

                  People

                  • Assignee:
                    Unassigned
                    Reporter:
                    Deryk Sinotte
                  • Votes:
                    0 Vote for this issue
                    Watchers:
                    0 Start watching this issue

                    Dates

                    • Created:
                      Updated:
                      Resolved: