Wicket
  1. Wicket
  2. WICKET-2298

Style and variant resolution is broken

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.5-M1
    • Component/s: None
    • Labels:
      None

      Description

      the resolution of style and variant is broken because there is no way to identify them if only one is used. eg panel_foo.html - is foo the style or the variant? for more details and possible solutions refer to

      http://markmail.org/thread/lj3luznjnvbun72r

      we will need to discuss, as a group, what format to use for the solution.

        Activity

        Hide
        Juergen Donnerstag added a comment -

        Has been fixed in 1.5

        Show
        Juergen Donnerstag added a comment - Has been fixed in 1.5
        Hide
        Juergen Donnerstag added a comment -

        Component.getStyle() and getVariation() are now separate. getStyle() no longer returns the variation as well. All resources have been modified as well..

        Show
        Juergen Donnerstag added a comment - Component.getStyle() and getVariation() are now separate. getStyle() no longer returns the variation as well. All resources have been modified as well..
        Hide
        Igor Vaynberg added a comment -

        MyPanel_en_us.html

        ^ is "en " the variation and "us" the style? this will take more then just making variation start with a "_" to fix

        Show
        Igor Vaynberg added a comment - MyPanel_en_us.html ^ is "en " the variation and "us" the style? this will take more then just making variation start with a "_" to fix
        Hide
        Juergen Donnerstag added a comment -

        The problem will be that we usually call Component.getStyle() to get the combination of variation and style. If we are going to change that, than we need to check every place where getStyle() is used today. Teadious, but probably not complicated. Introducing Component.getStyleAndVariation() (which is equal to todays getStyle()) would make that transition more simple. I still would suggest to make getStyleAndVariation() final and not allow users to change it, since resource name iterator needs to implement that concatenation scheme as well.

        Show
        Juergen Donnerstag added a comment - The problem will be that we usually call Component.getStyle() to get the combination of variation and style. If we are going to change that, than we need to check every place where getStyle() is used today. Teadious, but probably not complicated. Introducing Component.getStyleAndVariation() (which is equal to todays getStyle()) would make that transition more simple. I still would suggest to make getStyleAndVariation() final and not allow users to change it, since resource name iterator needs to implement that concatenation scheme as well.
        Hide
        Juergen Donnerstag added a comment -

        I agree. I think the whole mail discussion is mislead. We don't need a mechanism in Wicket to easily read filenames and identify the constituent parts. Wicket simply links them.

        This is from Component.getStyle()

        if (style != null && !"".equals(style))

        { style = variation + "_" + style; }

        else

        { style = variation; }

        If users define a rule that variations always have to start with a "_" whereas style must not, than there will be no filename clash.

        But in order for that to work StyleAndVariationResourceNameIterator must be fixed to do what Ned in his very first post requested: consider variation for the iteration as well, which we currently don't do.

        Show
        Juergen Donnerstag added a comment - I agree. I think the whole mail discussion is mislead. We don't need a mechanism in Wicket to easily read filenames and identify the constituent parts. Wicket simply links them. This is from Component.getStyle() if (style != null && !"".equals(style)) { style = variation + "_" + style; } else { style = variation; } If users define a rule that variations always have to start with a "_" whereas style must not, than there will be no filename clash. But in order for that to work StyleAndVariationResourceNameIterator must be fixed to do what Ned in his very first post requested: consider variation for the iteration as well, which we currently don't do.
        Hide
        Johan Compagner added a comment -

        i dont like prefixes or what ever, i prefer:

        /panel_local_style_variant.html

        and if 1 is missing just remote it and let it be __ so only the variant will result in this:

        /panel___variant.html

        but i think that doesnt happen to often
        We just have to look what is more often used and place those at the beginning.

        Show
        Johan Compagner added a comment - i dont like prefixes or what ever, i prefer: /panel_local_style_variant.html and if 1 is missing just remote it and let it be __ so only the variant will result in this: /panel___variant.html but i think that doesnt happen to often We just have to look what is more often used and place those at the beginning.

          People

          • Assignee:
            Juergen Donnerstag
            Reporter:
            Igor Vaynberg
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development