ICEfaces
  1. ICEfaces
  2. ICE-9103

Upgrade Wijmo library to 2.3.9 or newer

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:
      Any

      Description

      As part of ICE-8920, several third-party libraries were updated. However, the newer versions of Wijmo have substantial changes that a major effort will be required to upgrade this library and integrate it into our codebase. The new internal API is significantly different than that of the version that we currently use, and some internal objects are missing some properties that were previously expected, and vice versa, which produces errors in the client. There are also new, more complex mechanisms for handling submenus. Besides making multi-column submenus more difficult to re-implement, there are also issues with regular submenus. We will also have to make changes to our own Javascript code and markup rendering to adjust to these changes.

      Moreover, some of the issues for which we made custom fixes seem to have been fixed already in newer Wijmo versions, so it will also be necessary to go through all our custom fixes and see if they're really needed or not any more, in order to keep the code easier to maintain.

        Issue Links

          Activity

          Hide
          Ken Fyten added a comment -

          Given the extensive changes and effort required to move to the newer Wijmo version we should also review to see if refactoring the menu components to remove Wijmo altogether might be feasible.

          Show
          Ken Fyten added a comment - Given the extensive changes and effort required to move to the newer Wijmo version we should also review to see if refactoring the menu components to remove Wijmo altogether might be feasible.
          Hide
          Arturo Zambrano added a comment -

          Aside from the major change in the internal API of the menu widget, the number of fixe to the menu widget is quite small: just 10 fixes since the version we currently use (2.0.5). The current version is 2013v1.6.

          Looking at the version history (http://wijmo.com/wiki/index.php/Version_Histories) shows that the last modification to the menu widget was made for version 2.3.4. The changes to the menu widget are listed below.

          VERSION 2.3.4

          • Changed the default value "[]" to "null" of "items" option.

          VERSION 2.3.3

          • Changed the default value "[]" to "null" for the "items" option.

          VERSION 2.3.2

          • Fixed an issue that 'navigateUrl' is not working properly in sub menu after navigating through keyboard when 'mode' property is set to 'sliding'

          VERSION 2.2.2

          • Fix an issue when setting "direction" option to 'rtl', the 'header' and 'separator' items don't float to right.
            Update the 'showing' event, when it return false, it will be cancled.
          • Add the 'shown', 'hidding' and 'hidden' event to the menu.
          • And when the 'hidding' event return false, it will be cancled.

          VERSION 2.2.0

          • Fixed a UI issue in sliding mode when set width.

          VERSION 2.1.7

          • Fixed an issue where submenuitem's text is not shown correctly when templating.
          • Fixed an issue where the variable self.domObject is not set to null when killing element.

          VERSION 2.1.6

          • Fixed an issue that submenuitem's text is not shown correctly when templating.

          VERSION 2.1.4

          • Stop event propagation when menu is shown as a context menu.

          VERSION 2.1.3

          • Added a new option "direction", its value is "ltr" or "rtl" to support right-to-left rendering.
          • Fixed an issue in the deactivate method.

          VERSION 2.0.8

          • Removed “wijmo-wijmenu-link” class when templating.
          • Fixed a bug where the menu could not be displayed above other elements depending on the triggerElement.

          Most of the changes are bug fixes, some of which we have already fixed on our own. There's not much more in terms of new features. The menu widget doesn't seem to be getting much attention lately, there's nothing much more to add to a menu after all.

          Instead of just replacing the source code we have with the newest version and then try to re-apply all of our custom fixes, I could just go through all the different versions of the menu source code on the github repository, diff with the previous version, and apply those changes to our code. That would be easier and less regression-prone. This is the way we could go about for future updates to the menu widget.

          Instead of building our own menu widget from scratch, we might as well just keep the current version of the wijmo menu widget that we have, and just apply any fixes that would be beneficial for us, in the way described in the last paragraph, and we can also add any other custom features and bug fixes of our own. Creating a menu widget from scratch would take a substantial amount of effort, and woould give us little benefit: just a menu widget that would be as functional as the one we have and which would do the same things.

          Show
          Arturo Zambrano added a comment - Aside from the major change in the internal API of the menu widget, the number of fixe to the menu widget is quite small: just 10 fixes since the version we currently use (2.0.5). The current version is 2013v1.6. Looking at the version history ( http://wijmo.com/wiki/index.php/Version_Histories ) shows that the last modification to the menu widget was made for version 2.3.4. The changes to the menu widget are listed below. VERSION 2.3.4 Changed the default value "[]" to "null" of "items" option. VERSION 2.3.3 Changed the default value "[]" to "null" for the "items" option. VERSION 2.3.2 Fixed an issue that 'navigateUrl' is not working properly in sub menu after navigating through keyboard when 'mode' property is set to 'sliding' VERSION 2.2.2 Fix an issue when setting "direction" option to 'rtl', the 'header' and 'separator' items don't float to right. Update the 'showing' event, when it return false, it will be cancled. Add the 'shown', 'hidding' and 'hidden' event to the menu. And when the 'hidding' event return false, it will be cancled. VERSION 2.2.0 Fixed a UI issue in sliding mode when set width. VERSION 2.1.7 Fixed an issue where submenuitem's text is not shown correctly when templating. Fixed an issue where the variable self.domObject is not set to null when killing element. VERSION 2.1.6 Fixed an issue that submenuitem's text is not shown correctly when templating. VERSION 2.1.4 Stop event propagation when menu is shown as a context menu. VERSION 2.1.3 Added a new option "direction", its value is "ltr" or "rtl" to support right-to-left rendering. Fixed an issue in the deactivate method. VERSION 2.0.8 Removed “wijmo-wijmenu-link” class when templating. Fixed a bug where the menu could not be displayed above other elements depending on the triggerElement. Most of the changes are bug fixes, some of which we have already fixed on our own. There's not much more in terms of new features. The menu widget doesn't seem to be getting much attention lately, there's nothing much more to add to a menu after all. Instead of just replacing the source code we have with the newest version and then try to re-apply all of our custom fixes, I could just go through all the different versions of the menu source code on the github repository, diff with the previous version, and apply those changes to our code. That would be easier and less regression-prone. This is the way we could go about for future updates to the menu widget. Instead of building our own menu widget from scratch, we might as well just keep the current version of the wijmo menu widget that we have, and just apply any fixes that would be beneficial for us, in the way described in the last paragraph, and we can also add any other custom features and bug fixes of our own. Creating a menu widget from scratch would take a substantial amount of effort, and woould give us little benefit: just a menu widget that would be as functional as the one we have and which would do the same things.

            People

            • Assignee:
              Unassigned
              Reporter:
              Arturo Zambrano
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated: