Announcement Announcement Module
Collapse
No announcement yet.
Using Validators and Error objects outside of Controllers Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Using Validators and Error objects outside of Controllers

    Hi All,

    I need to introduce some object validation to a Spring 2.5 MVC application. Rather than occurring within a Controller this validation needs to happen quite deep within the application.

    I am keen to use Spring's 'Validator' interface to implement my validation and then inspect the 'Errors' object in my code to determine the validation result. Since my validation is not occurring within a controller I don't believe I can make use of Spring's normal instantiation of an Errors object, hence I am unsure how I would go about instantiating the 'Errors' object that needs to be passed to the validate method? I am also unsure about which Errors implementation I should choose?

    I have searched the Spring code for uses of Errors implementors constructors but can't find anything useful, I presume this is because Spring uses reflection to instantiate these objects hence obscuring the code I am searching for.

    As a disclaimer I am also aware that what I am proposing is probably a slightly unusual practice, however I am currently constrained in what I change by the maturity and complexity of the system. This is stopping me from doing a more significant redesign which is why I am forced to do the validation in this unusual place.

    Most grateful for any insight here.

    Edd

  • #2
    There is no Errors constructor simply because Errors is an interface, I suggest you take a look at the implementations of the Errors interface...

    Comment


    • #3
      Hi Marten,

      Thanks for your reply - I am indeed aware that Errors is an interface. Perhaps I phrased my question badly when I spoke of 'Errors Implementors', what I meant was 'classes which implement the Errors interface'.

      Perhaps a better example of my problem would be to look at the 'EscapedErrors' class which implements the Errors interface. This has a single, non-default constructor which takes an 'Errors' instance (to spell it out to avoid any further confusion: an instance of a class which implements the Errors interface).

      So in order to instantiate an EscapedErrors instance I need to already have a reference to an instance of a class which implements the Errors interface. This somewhat resembles the chicken and egg problem and herein lies my problem (or more likely my misunderstanding of how Spring intends that I should use these objects).

      Again, most grateful for any assistance here.

      Comment


      • #4
        I suggest you take another look because you are missing some classes/implementations...

        Comment


        • #5
          Hi Marten,

          Thanks for the reference to the Spring 3 Errors API, I'm actually using 2.5 as I stated in my original post, but that's ok - I already have the API documentation for that version.

          To refer to your last comment - I am well aware that I'm missing some implementations - that's why I posed the question in my original post:

          'I am also unsure about which Errors implementation I should choose?'

          The point of the question was really to ask for advice my proposed implementation. I was keen to get a feel from Spring experts for whether it fitted well/ badly with the 'spring way' and to get any advice on possible better solutions from people who know this part of the API better than me.

          Whilst I thank you for taking the time to answer my post I can't help but think that you haven't really read and understood what I am asking. You keep referring me to the API, however before posting I read the API and having done so had not understood how it was intended to be used. I thought I explained all this reasonably clearly in my first post but perhaps not.

          Regardless, do you think you now understand what I am trying to acheive? If so would you be able to provide any thoughts on:

          1: The validity of my approach.
          2: Under what circumstances I would want to utilise each of the classes which implement the Errors interface?

          Note: Since my initial posting I have discovered that the 'BindException' class can be instantiated and bound to an object without the cyclic need for an Errors implementation that I described above. This looks like it would work in practice since BindException implements Errors (through BindingResult), however I still have no idea if instantiating it myself seems like a reasonable thing to do in terms of the 'spring way'? I certainly don't see any examples of it throughout the documentation...

          Many thanks,

          Edd
          Last edited by eddgrant; Mar 15th, 2010, 09:40 AM.

          Comment


          • #6
            Have you looked at the JSR 303 Bean validation?
            Hibernate Validator is an implementation of that and is targetted specifically towards validation of beans with a single standard configuration, which can be made use of in any layer.

            With Spring mvc 3 and JPA/Hibernate persistence it works out of the box since the validator factory is created automatically and is appropriately intercepted with built in validation interceptors. (MVC validation & Persistence callbacks.)

            What I haven't tried is using it programmatically which I guess you might have to do if the framework can't handle it transparently for you.
            http://docs.jboss.org/hibernate/stab...rence/en/html/

            Comment

            Working...
            X