swingx
  1. swingx
  2. SWINGX-972

FormatStringValue should return EMPTY for unhandled values

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.9.4
    • Fix Version/s: 0.9.6
    • Component/s: Renderer
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      972

      Description

      FormatStringValue.getString returns TO_STRING.getString for any unrecognized
      value (IllegalArgument). I think it should return EMPTY.getString. EMPTY
      suggests being unclaim, whereas TO_STRING suggests that might be something I
      intended.

      The other possible option is to alter how getString works and a null return be
      an unclaimed translation allowing the user to install a default TO_STRING or
      EMPTY in the ComponentProvider. Or add default choice somewhere else.

      Karl

        Activity

        Hide
        rah003 added a comment -

        Moving all open issues to the next version.

        Show
        rah003 added a comment - Moving all open issues to the next version.
        Hide
        kleopatra added a comment -

        and I think it's a judgement call Arguably not to decide in the general
        case, old style renderers do the one or other just as the developer thinks is
        okay for the specific case.

        Just checked your FileXX: looks like we tend to different defaults, usually I
        return a string representation from a value which doesn't fit the expected type
        while you return an empty string. My reasoning being, better to show anything
        than an empty cell if there is something contained.

        Whatever we do in our defaults, we probably should be consistent (which
        currently we aren't). On the other hand: it's not a big deal, the xxValues are
        meant as the "small coin" to implement in any way developers want to.

        Would like to change this to a task type with lower priority, the task being to
        consistently decide what to do for default StringValue implementations if the
        type is unhandled. We could explicitly add a configurable hook for a fallback
        StringValue. Anyway, should move the discussion out to the forum

        Cheers
        Jeanette

        Show
        kleopatra added a comment - and I think it's a judgement call Arguably not to decide in the general case, old style renderers do the one or other just as the developer thinks is okay for the specific case. Just checked your FileXX: looks like we tend to different defaults, usually I return a string representation from a value which doesn't fit the expected type while you return an empty string. My reasoning being, better to show anything than an empty cell if there is something contained. Whatever we do in our defaults, we probably should be consistent (which currently we aren't). On the other hand: it's not a big deal, the xxValues are meant as the "small coin" to implement in any way developers want to. Would like to change this to a task type with lower priority, the task being to consistently decide what to do for default StringValue implementations if the type is unhandled. We could explicitly add a configurable hook for a fallback StringValue. Anyway, should move the discussion out to the forum Cheers Jeanette
        Hide
        Karl Schaefer added a comment -

        Yeah, I tend to believe that the flyweights should only "claim" what they are
        designed to claim and leave the rest up to the developer. One of the reasons,
        I suggested allowing null returns from the contract. null could be the
        unclaimed value, allowing us to implement a simple compound StringValue that
        walks until non-null is returned.

        Anyway, agree that we need to take this to the forum. Added that to my list
        and will do so later (today, I hope).

        Karl

        Show
        Karl Schaefer added a comment - Yeah, I tend to believe that the flyweights should only "claim" what they are designed to claim and leave the rest up to the developer. One of the reasons, I suggested allowing null returns from the contract. null could be the unclaimed value, allowing us to implement a simple compound StringValue that walks until non-null is returned. Anyway, agree that we need to take this to the forum. Added that to my list and will do so later (today, I hope). Karl
        Show
        kleopatra added a comment - ref to thread: http://forums.java.net/jive/thread.jspa?threadID=55896&tstart=0
        Hide
        kleopatra added a comment -

        Karl,

        and the winner iiiiissss ... no idea - with that little interest (that is, the
        page hits aren't so bad, but just one interested enough to come up with an
        opinion) it's hard to tell.

        Currently, I'm thinking about

        • adding a not-handled marker to the stringValue interface, something like
          NOT_HANDLED = "- could not handle the string conversion -"
        • implement a StringValue which returns it
        • enhance the formatStringValue to allow the config of a fallback

        Then,

        • our defaults can be doc'ed to implement a fallback to TO_STRING (yeah, my pref
        • that one external opinion in my favour
        • custom formats are easily configurable
        • experiments with compound StringValues are possible

        Alternatively, we can just leave everything as is and postpone the whole issue -
        with that little feedback it doesn't seem to be a big point right now. And it's
        not really a code-breaking issue, we can always simply add more default
        implementations

        CU
        Jeanette

        Show
        kleopatra added a comment - Karl, and the winner iiiiissss ... no idea - with that little interest (that is, the page hits aren't so bad, but just one interested enough to come up with an opinion) it's hard to tell. Currently, I'm thinking about adding a not-handled marker to the stringValue interface, something like NOT_HANDLED = "- could not handle the string conversion -" implement a StringValue which returns it enhance the formatStringValue to allow the config of a fallback Then, our defaults can be doc'ed to implement a fallback to TO_STRING (yeah, my pref that one external opinion in my favour custom formats are easily configurable experiments with compound StringValues are possible Alternatively, we can just leave everything as is and postpone the whole issue - with that little feedback it doesn't seem to be a big point right now. And it's not really a code-breaking issue, we can always simply add more default implementations CU Jeanette
        Hide
        Karl Schaefer added a comment -

        Jeanette,

        I'd avoid the NOT_HANDLED marker at this time for two reasons:
        1. we should just return the same thing from all values: and I'll go with
        TO_STRING (for now) that one extra vote you got from that dummy account you
        made was enough.
        2. I really feel that null should be that marker, but that requires some
        significant rework of the API (changing the docs to allow null and handling
        null later in the process where currently non-null is expected).

        Let's move the current implementations to consistancy, close this bug, and open
        a new bug for "StringValue flyweights don't support nesting" or somesuch that
        discusses the issues of not having a NOT_HANDLED marker and the lack of ability
        to use a CompoundStringValue because of it.

        Karl

        Show
        Karl Schaefer added a comment - Jeanette, I'd avoid the NOT_HANDLED marker at this time for two reasons: 1. we should just return the same thing from all values: and I'll go with TO_STRING (for now) that one extra vote you got from that dummy account you made was enough. 2. I really feel that null should be that marker, but that requires some significant rework of the API (changing the docs to allow null and handling null later in the process where currently non-null is expected). Let's move the current implementations to consistancy, close this bug, and open a new bug for "StringValue flyweights don't support nesting" or somesuch that discusses the issues of not having a NOT_HANDLED marker and the lack of ability to use a CompoundStringValue because of it. Karl
        Hide
        kleopatra added a comment -

        okay, let's do as you suggested right now (haha, so the beer I invested into
        Walter's vote payed off <g>)

        Will change the file related defaults, you open a new issue for post-final.

        Thanks
        Jeanette

        Show
        kleopatra added a comment - okay, let's do as you suggested right now (haha, so the beer I invested into Walter's vote payed off <g>) Will change the file related defaults, you open a new issue for post-final. Thanks Jeanette
        Hide
        kleopatra added a comment -


        done: file-related now fall back to TO_STRING

        Show
        kleopatra added a comment - done: file-related now fall back to TO_STRING

          People

          • Assignee:
            kleopatra
            Reporter:
            Karl Schaefer
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: