Announcement Announcement Module
Collapse
No announcement yet.
Constrained Fields? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Constrained Fields?

    I am digging into the deeper parts of RCP trying to learn how to use it and how it is designed. Very nice so far, but I have some issues/questions. One of them is a fairly simple behavior I don't see in any of the examples/samples/integrations or code. I went digging and didn't see it anywhere. I did see where a person could build the support for it and it looks promising to use the RCP design to do this, but I won't know until I try.

    Before I jump into it though, I thought I would ask so I am not reinventing the wheel, or worse, trying to do something that will so clash with RCP that it won't be practical (which I doubt).

    At a past gig I did a lot of Swing development. We had our own homebrew sub-optimum methodology for binding beans to various Swing components using reflection (not my choice), but I went with it.

    The point I am getting to is that I am a strong believer in the UI not letting the user make mistakes in data entry. For example, if the user is entering a zipcode, the user should never be allowed to enter alpha chars. The field shouldn't need to flag them, it just shouldn't allow them at all. Or better yet, the field might know what a valid zip code is and not allow an invalid zip even if the format is correct. Other feedback is great (field color, icons, etc.), but not allowing incorrect chars is very friendly and not rocket science.

    In my previous gig I wrote a number of extensions of Document/Filter and TextComponent such that these were bound to a given bean and the resulting text components would examine the bean property they were bound to for a constraint annotation. So, it was fairly easy to annotate a property in a bean with constraints such as NotNullOrEmpty, MaxLength, MinLength, MinValue, MaxValue - that kind of thing. The text components would use the Document/Filter and document listeners to constrain the user input and give the user feedback on what was expected/etc.

    So, the user could not enter an invalid value in many fields and they never had to delete invalid data. Like I said, not rocket science, and fairly common behavior in many apps.

    I looked and did not see support for this in any RCP components. I saw one that used a document filter, others used JFormattedTextField which I am not too keen on. Every example I tried allowed non-numeric entry for numeric properties.

    Anyway, here are my questions:

    1) Is there something already that does this? I didn't see it in RCP, JGoodies or JIDE.
    2) Assuming the answer to #1 is no, is there perceived value in this?
    3) Is this practical to do with RCP?

    I can replicate what I did at my previous gig in an OSS friendly way easily enough. Integrating it with RCP and implementing in the RCP way would actually take longer, although I see value in that instead of going off in my own direction without RCP.

    Thanks.

  • #2
    Hello

    Google "spring rcp validation"

    This may help

    http://java.dzone.com/news/getting-f...ng-rc?page=0,6

    BR
    Carsten

    Comment


    • #3
      Carsten, thanks.

      I have already been going through Geertjan's tutorials and I should have mentioned that I had already looked at validation/rules. It is all very nice.

      What I meant was, is there an example/implementation of the application of validation/rules/fields where the field never lets the user enter, for example, an alpha char in a numeric field?

      I did this in my previous implementation by using the document filter to intercept each char as it was entered. If the field couldn't parse the string into a number, the char was rejected, never added to the document and the field optionally beeped and IIRC I think I gave the user a textual clue as to what they were doing wrong.

      I have already looked at validation/etc. in the docs and code. All the Spring RCP/JGoodies/JIDE examples I have seen so far let the user enter invalid data, but flag it after entry - which is good practice, but not best practice. I know what I want can be done, I am thinking of doing it - I am just making sure I haven't missed someone else already doing it.

      Comment


      • #4
        Originally posted by Developer Dude View Post
        Carsten, thanks.

        I have already been going through Geertjan's tutorials and I should have mentioned that I had already looked at validation/rules. It is all very nice.

        What I meant was, is there an example/implementation of the application of validation/rules/fields where the field never lets the user enter, for example, an alpha char in a numeric field?

        I did this in my previous implementation by using the document filter to intercept each char as it was entered. If the field couldn't parse the string into a number, the char was rejected, never added to the document and the field optionally beeped and IIRC I think I gave the user a textual clue as to what they were doing wrong.

        I have already looked at validation/etc. in the docs and code. All the Spring RCP/JGoodies/JIDE examples I have seen so far let the user enter invalid data, but flag it after entry - which is good practice, but not best practice. I know what I want can be done, I am thinking of doing it - I am just making sure I haven't missed someone else already doing it.
        I think this is a good idea.
        As mentioned in your initial post, this could mean that a database connection during validation is necessary (enter only valid postcode that is also available in the db).
        I could also imagine that you will depend some fields to another.
        This will mean that the validation can be complex at certain point.

        Comment


        • #5
          Originally posted by XuOne View Post
          I think this is a good idea.
          As mentioned in your initial post, this could mean that a database connection during validation is necessary (enter only valid postcode that is also available in the db).
          I could also imagine that you will depend some fields to another.
          This will mean that the validation can be complex at certain point.
          The validation framework/rules seem to handle this well, and I would integrate with/use/interface with that framework.

          In my previous implementation I used annotations on the beans, and some general rules (number fields generally should not allow non-numeric output). I think that letting the validation framework handle all that would probably make the code cleaner and more flexible rather than do both.

          As for a DB connection - generally I would not use that, but for some things I can see how that might work. For example, in GWT, you can write auto-completion callbacks for components that can talk to the server and this could work for zip codes. But that would be up to the coder. The best way would just be to have an interface for some kind of provider and then the coder would configure the component to whatever provider they wish to use.

          I am thinking I would probably extend JGoodies components. I need to look closer at those, maybe I missed where they have implemented this. I am just asking for a sanity check here, not how to do it.

          Comment


          • #6
            Hi,

            With Binder/Binding, you can choose which swing component is used for a specific bean property or a specific property class.

            Basically, the Binder create the swing component and the binding while the binding synchronizes the view with the formModel.

            There are several Binder/Binding already implemented in RCP, you might have a look at it.

            Hope that helps!

            Comment

            Working...
            X