Uploaded image for project: 'Click'
  1. Click
  2. CLK-592 Refactor Menu control
  3. CLK-407

Menu improvements - more properties: enable/disable, show/hide

    Details

    • Type: Sub-task
    • Status: Resolved
    • Priority: Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: 2.3.0
    • Component/s: extras
    • Labels:
      None

      Description

      Please improve the Menu Control, by allowing the user to show/hide menu items, and also to enable/disable them.
      Right now, this is not possible at all with the Menu Control .
      This is very limiting, making the existing Menu Control useless for most user applications, thus forcing the users
      to make their own menu controls (or the hack the original one).

      There's no need for these properties to be present in menu.xml, since their role is mostly at runtime:

      • enable/disable would allow to enable or disable a menu item (so to show it but make it unclickable).
      • show/hide would allow to to show and hide menu items (of course if the user doesn't have a specific role, the menu will be hidden).
        Regarding the API, it would be important to have practical methods for hiding and disabling menu items:
        something like Menu#hide(Menu item) would not be very practical since in most cases the "item" reference is not present
        so it should be Menu#hide(String path), and when applied, to seach this in the children items too.

      Another improvement would be if the Menu Click control would use Link Controls for the items (since that's what they are).

      Thank you,

      Demetrios.

        Activity

        Hide
        medgar Malcolm Edgar added a comment -

        The menu control allows you to do pretty well whatever you want. How you render it is up to you. This is why rendering is done via a Velocity macro. Its not possible to anticipate all the ways people may wish to provide the page navigation.

        For example I have created an Outlook style accordion menu by with a custom Velocity macro, JS and CSS.

        http://www.switchonthecode.com/tutorials/javascript-and-css-tutorial-accordion-menus

        regards Malcolm Edgar

        Show
        medgar Malcolm Edgar added a comment - The menu control allows you to do pretty well whatever you want. How you render it is up to you. This is why rendering is done via a Velocity macro. Its not possible to anticipate all the ways people may wish to provide the page navigation. For example I have created an Outlook style accordion menu by with a custom Velocity macro, JS and CSS. http://www.switchonthecode.com/tutorials/javascript-and-css-tutorial-accordion-menus regards Malcolm Edgar
        Hide
        jschmidt71 Joseph Schmidt added a comment -

        > How you render it is up to you. This is why rendering is done via a Velocity macro.
        Exactly this is my biggest problem with the behavior of the Menu control
        I don't have to do this with most Click controls, and that's why I like Click.
        I just use $form and $table - nothing more. Only Java code.

        (well the Panels are an exception - they look complicated too, so I don't use them either - despite the fact that I would like to )

        > Its not possible to anticipate all the ways people may wish to provide the page navigation.
        Of course not, but what about good/intelligent defaults?
        What about a good set of "decorators"(styles, or how would one call it) like I described in the links in the following issues ?:
        https://issues.apache.org/jira/browse/CLK-511
        https://issues.apache.org/jira/browse/CLK-512

        They would cover what most people want - just like the Table control does.

        thanks,
        Joseph.

        Show
        jschmidt71 Joseph Schmidt added a comment - > How you render it is up to you. This is why rendering is done via a Velocity macro. Exactly this is my biggest problem with the behavior of the Menu control I don't have to do this with most Click controls, and that's why I like Click. I just use $form and $table - nothing more. Only Java code. (well the Panels are an exception - they look complicated too, so I don't use them either - despite the fact that I would like to ) > Its not possible to anticipate all the ways people may wish to provide the page navigation. Of course not, but what about good/intelligent defaults? What about a good set of "decorators"(styles, or how would one call it) like I described in the links in the following issues ?: https://issues.apache.org/jira/browse/CLK-511 https://issues.apache.org/jira/browse/CLK-512 They would cover what most people want - just like the Table control does. thanks, Joseph.
        Hide
        a_adrian Adrian A. added a comment -

        I also need enable/disable, show/hide methods in most applications for the menus.
        (I think the simplest would be to add the according properties to the xml file and the Menu class)

        In most applications, it's a requirement:

        • to be able to hide items not just based on roles but also based on application logic, and not just at the beginning but at various moments in time.
        • to disable (i.e. to show but make non-click-able some items) e.g.
        • user needs to upgrade his account to a better scheme or it is in demo/trial mode.
        • another user performs that action at the same time (e.g. backup or some other batch process), so the menu item needs to be disabled too.

        For this to work properly however, I think https://issues.apache.org/jira/browse/CLK-405 should also work correctly - only so it makes (if different users can see different menu item states)

        Thank you,
        A.

        Show
        a_adrian Adrian A. added a comment - I also need enable/disable, show/hide methods in most applications for the menus. (I think the simplest would be to add the according properties to the xml file and the Menu class) In most applications, it's a requirement: to be able to hide items not just based on roles but also based on application logic, and not just at the beginning but at various moments in time. to disable (i.e. to show but make non-click-able some items) e.g. user needs to upgrade his account to a better scheme or it is in demo/trial mode. another user performs that action at the same time (e.g. backup or some other batch process), so the menu item needs to be disabled too. For this to work properly however, I think https://issues.apache.org/jira/browse/CLK-405 should also work correctly - only so it makes (if different users can see different menu item states) Thank you, A.
        Hide
        jschmidt71 Joseph Schmidt added a comment -

        > Have committed implementation of this to SF project. Would appreciate a review or comments before committing to Apache.
        If I see right, it is for 406, not for this issue (being 407).
        Adrian's solution was working for me pretty well.

        Since you made a general interface however, I think it would be better to combine it with the "onSecurityCheck" too (I like it much more than the container solution since it's portable).

        Show
        jschmidt71 Joseph Schmidt added a comment - > Have committed implementation of this to SF project. Would appreciate a review or comments before committing to Apache. If I see right, it is for 406, not for this issue (being 407). Adrian's solution was working for me pretty well. Since you made a general interface however, I think it would be better to combine it with the "onSecurityCheck" too (I like it much more than the container solution since it's portable).
        Hide
        a_adrian Adrian A. added a comment -

        How to handle child Menu items? E.g. when a menu has several levels?
        1. Ignore them both for the visibility and enabling flags? and let the rendering (specific for each menu type) take care of this?
        2. Propagate the properties in all children?

        Thanks in advance,
        Adrian.

        Show
        a_adrian Adrian A. added a comment - How to handle child Menu items? E.g. when a menu has several levels? 1. Ignore them both for the visibility and enabling flags? and let the rendering (specific for each menu type) take care of this? 2. Propagate the properties in all children? Thanks in advance, Adrian.
        Hide
        a_adrian Adrian A. added a comment -

        Issue is obsolete: the Menu control was already refactored a long time ago.

        Show
        a_adrian Adrian A. added a comment - Issue is obsolete: the Menu control was already refactored a long time ago.

          People

          • Assignee:
            a_adrian Adrian A.
            Reporter:
            dkyriakis Demetrios Kyriakis
          • Votes:
            3 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development