Struts 2
  1. Struts 2
  2. WW-808

ParamTag does not convert to string

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: WW 2.1.7
    • Fix Version/s: WW 2.2.2
    • Component/s: Plugin - Tags
    • Labels:
      None

      Description

      The ParamTag does this

      Object value = findValue(valueAttr);

      instead of this

      Object value = findValue(valueAttr, String.class);

      which means that it bypasses your custom type converters.

        Activity

        Hide
        tm_jee added a comment -

        Oppss... sorry late reply....

        Thx for handling this issue Claus.

        I prefered it to be the way it is now, document this behaviour as Claus already did.

        I think there might be both behaviour have its particular usage, if we want to have a param that is a string, it makes sense to use <param>...</param>, anything in between that's enclosed with %{} will be evaluated and its toString() called. On the other hand, if we want an object, we could used the value attribute. I guess what i'm trying to say is that both way of using param have their own usage.

        Of course this is just my 2 cents

        Show
        tm_jee added a comment - Oppss... sorry late reply.... Thx for handling this issue Claus. I prefered it to be the way it is now, document this behaviour as Claus already did. I think there might be both behaviour have its particular usage, if we want to have a param that is a string, it makes sense to use <param>...</param>, anything in between that's enclosed with %{} will be evaluated and its toString() called. On the other hand, if we want an object, we could used the value attribute. I guess what i'm trying to say is that both way of using param have their own usage. Of course this is just my 2 cents
        Hide
        Claus Ibsen added a comment -

        Updatede tag documentation.

        If we need to align the tag as a consistent behaviour for both situations we should reopen this and schedule it for a 2.3 or future version where we need to give 3rd party tag developers the change to validate their tags if we change it in WW.

        Show
        Claus Ibsen added a comment - Updatede tag documentation. If we need to align the tag as a consistent behaviour for both situations we should reopen this and schedule it for a 2.3 or future version where we need to give 3rd party tag developers the change to validate their tags if we change it in WW.
        Hide
        Claus Ibsen added a comment -

        Okay I have updated Param.java with a note section about the two situations outlined by Toby (1) and (2).

        Show
        Claus Ibsen added a comment - Okay I have updated Param.java with a note section about the two situations outlined by Toby (1) and (2).
        Hide
        Claus Ibsen added a comment -

        Rainer

        As I have little real life WW experience I can only voice as an outsider.
        I would expect the tags to work excatly the same way using both usages. It's just a preference how you write XML.

        If we have a migration guide we could write that this behavior is changed.

        As the 2.2.2 release is out of the door soon, we could keep as it is and write comments in the javadoc, wiki about this odd behavior.
        And for 2.3 we could fix it.

        Show
        Claus Ibsen added a comment - Rainer As I have little real life WW experience I can only voice as an outsider. I would expect the tags to work excatly the same way using both usages. It's just a preference how you write XML. If we have a migration guide we could write that this behavior is changed. As the 2.2.2 release is out of the door soon, we could keep as it is and write comments in the javadoc, wiki about this odd behavior. And for 2.3 we could fix it.
        Hide
        Rainer Hermanns added a comment -

        Toby, Claus,

        what are your suggestions on this?
        My expectation would be, that both usages behave similar or it should be clearly outlined in the docs (wiki AND javadocs) pointing out the difference...

        What do you think?

        Show
        Rainer Hermanns added a comment - Toby, Claus, what are your suggestions on this? My expectation would be, that both usages behave similar or it should be clearly outlined in the docs (wiki AND javadocs) pointing out the difference... What do you think?
        Hide
        Claus Ibsen added a comment -

        Hi Toby

        Yeah I agree that breaking old components is dangerous. And does the unit test really cover all these situations? WW code coverage is < 40%.

        Yes I would be nice the hear others opinions and if anyone had a real use-case with this situation.

        And I really think the two different situations should be documented in the javadoc for the .class and at wiki docs.

        For a user this could be a hard defect to track down.

        Show
        Claus Ibsen added a comment - Hi Toby Yeah I agree that breaking old components is dangerous. And does the unit test really cover all these situations? WW code coverage is < 40%. Yes I would be nice the hear others opinions and if anyone had a real use-case with this situation. And I really think the two different situations should be documented in the javadoc for the .class and at wiki docs. For a user this could be a hard defect to track down.
        Hide
        tm_jee added a comment -

        Hi Claus,

        Currently they are not working in the same way actually. If we change them it might break some components.... but then we have our little test case to check against....

        > And I guess %

        { ... }

        expression should always be evaluated.

        I think it is evaluated in both case, just that in once case it is evaluated to a String while the other to object.

        I am not sure if we should change the current behaviour... maybe we could post this in the forum and see what others think about it. What do you think?

        Show
        tm_jee added a comment - Hi Claus, Currently they are not working in the same way actually. If we change them it might break some components.... but then we have our little test case to check against.... > And I guess % { ... } expression should always be evaluated. I think it is evaluated in both case, just that in once case it is evaluated to a String while the other to object. I am not sure if we should change the current behaviour... maybe we could post this in the forum and see what others think about it. What do you think?
        Hide
        Claus Ibsen added a comment -

        @tm

        Should both situations 1+2 not work excatly the same way? Otherwise users will get confued, I for sure would.
        And I guess %

        { ... }

        expression should always be evaluated.

        Show
        Claus Ibsen added a comment - @tm Should both situations 1+2 not work excatly the same way? Otherwise users will get confued, I for sure would. And I guess % { ... } expression should always be evaluated.
        Hide
        tm_jee added a comment -

        If not mistaken

        <param>someThing</param> ----- (1)

        <param value="anotherThing"/> ---- (2)

        In (1), it would be evaluated to the stack as String while in (2) it will be evaluated to the stack as object.

        I guess, if one needs it as string then (1) could be used, it is possible to have eg.

        <param>hello %

        {user.name}

        </param>

        where user.name will be evaluated to the stack and its string value appended.

        If it works this way, i don't think it is a bug.

        Show
        tm_jee added a comment - If not mistaken <param>someThing</param> ----- (1) <param value="anotherThing"/> ---- (2) In (1), it would be evaluated to the stack as String while in (2) it will be evaluated to the stack as object. I guess, if one needs it as string then (1) could be used, it is possible to have eg. <param>hello % {user.name} </param> where user.name will be evaluated to the stack and its string value appended. If it works this way, i don't think it is a bug.
        Hide
        Alexandru Popescu added a comment -

        Is this still an issue? I cannot find that code in ParamTag. I see something in that type into Param, but it looks oke to me.

        ./alex

        .w( the_mindstorm )p.

        Show
        Alexandru Popescu added a comment - Is this still an issue? I cannot find that code in ParamTag. I see something in that type into Param, but it looks oke to me. ./alex – .w( the_mindstorm )p.

          People

          • Assignee:
            Claus Ibsen
            Reporter:
            John Patterson
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development