iScreen 1.1.0 released: POJO Validation Framework


News: iScreen 1.1.0 released: POJO Validation Framework

  1. iScreen 1.1.0 released: POJO Validation Framework (9 messages)

    Typically, form validation is handled by the presentation layer. Though this close integration with the presentation layer can help make web development easier, the validation frameworks provided by these presentation frameworks are typically weak. There aren't many fully-featured non-presentation-layer-specific frameworks out there. In fact, it's pretty much been relegated to commons-validator. Hence, iScreen was developed to fill this hole. It validates Java objects (whether JavaBeans or not), and even supports entire object graphs. It's approach is via XML configuration, choosing to keep as simple an API as possible, but as flexible a configuration as appropriate. Some of the features is has: --Failure message independence from the Validator --Dynamic message generation using OGNL or MVEL (new to version 1.1.0) --Internationalization support --Configuration inheritance --Full object-graph validation --Conditional validation --Validation of collections (iterates over the collection, validating each item) --Configuration documentation --Stateless Validators --Checked and unchecked exception for failures in main interface --Fail fast validations (stop on first validation) --Failures versus warnings Take a look at it at

    Threaded Messages (9)

  2. What makes this project fundamentally different or better that commons-validator? And, more important, I've always wondered what the advantage might be to implement validation using XML rather than plain simple Java? XML is more verbose, not compiled and thus much more error-prone, and impossible to refactor. I've always had the impression that what happened was along these lines: - validation code is boring to write: very simple Java code, always looking the same. - Yes, you're right, we should write a framework to avoid typing this boring code. - Let's do it. And here come Struts validator, and then commons-validator, and now iScreen. - Look how cool it is now: I've been able to replace 3 lines of simple type-safe Java code with 10 lines of unreadable and unsafe XML. Isn't it beautiful? JB.
  3. In comparison to commons-validator: --The XML configuration is much more powerful. With the use of OGNL/MVEL, as well as being able to document the configuration, as well as conditionals, full-object-graph validation, etc. --The Java API is simpler. --I suggest actually taking a look at it and comparing for yourself. I think you'll find it much easier to use and more powerful to boot. The question of whether to do validation in code or in configuration is an excellent one. I think it's more a matter of taste, though I think the debate would be an interesting one. Take a look at this article: Fundamentally, it's about doing it either heavily in one or the other, as somewhere in the middle (which is what commons-validator does) just makes it harder to use. Doing it heavily in code make it less flexible for change, but it is at least a native language, so may be "easier" in that regard. I don't have an answer, other than my preference would be to put it into configuration (and as for length of code...that's another interesting debate...for any complex validation, I expect iScreen will be shorter and easier to maintain than if it was done in code). As for your "motivational" steps: it didn't happen that way. Many web apps don't really have complex validation, and hence, probably wouldn't gain much from using iScreen. However, if you've worked on a web app (or web services, etc.) that required some fairly complex validation, then you know that the story changes. It is to that that motivated the creation of iScreen. I looked at commons-validator, and it wasn't sufficient (or pleasant), so something new was needed (since I looked around and couldn't find a decent one). It's the ability to do in a few hundred lines of configuration what would potentially take many, many hundreds or even thousands of lines of Java code. My suggestion would be to actually take a closer look. I think you'll be pleasantly surprised at what you can do with it.
  4. Well, in fact i think that validation of the fundamentale correctness of a business object should reside inside the object class itself (so be written in java). Some simple frameworks/patterns will help to make this code non-boring (see exemple below). Externalizing such logic leads in a weak object design as "business object" does not carry state consistancy knowledge anymore. IMHO, External validator (as XML validators) may help in validating a web user input, but not business consistency. Engine rules may help too in context where versatile rules evolve independently from software releases. But we must take care of using such tools only for versatile rules as it's best to avoid mixing two paradigms. This is an exemple of a business entity using a Notification like pattern to embedd state consistency logic. public class Person { private String id; private String name; private int age; private String email; private Person father; private Personl lover; // $? stands for an unknown value at comple time which will be valued at runtime public static final Mistake FATHER_TOO_YOUNG = new Mistake("Father age ($?) is younger than this age ($?)."); public static final Mistake NEGATIVE_AGE = new Mistake("Age can't be negative."); public static final Mistake NOT_ADULT = new Mistake("$? is not an adult."); public Validation validate() { return new Validation() .checkNotNull(email, name) .check(FATHER_TOO_YOUNG, father != null && father.age > age, father.age, this.age) .check(NEGATIVE_AGE, age >= 0); } public Validation validateForDriving() { return this.validate() .check(NOT_ADULT, this.age >= 18,; } ...
  5. Just a little offtopic, but...[ Go to top ]

    Ahoy there ! At this point I have the following doubt: Why not use the Exception mechanism to implement the validation direct on the POJO(JavaBean or whateaver). Can't we check in the "set" method if the condition is met, if not then throw an exception (possible an specialized exception for this type of validation) ? Can it be simple like this ? Thanx, Sandro.
  6. Re: Just a little offtopic, but...[ Go to top ]

    This raises an interesting question: why wouldn't validation belong in the Object, itself? Why externalize it? There's a difference between validating a domain-level business object that has full understanding of itself, its capabilities, etc. and with an object (or object graph) that represents user or system inputs. It is the same difference between business rules and simple validation (i.e. expected format, type, value, etc. of a piece of data). Validation is not designed to handle/support real business logic. Validation is a means to ensure that the data an object (or object graph) contains meets certain standards. It makes no judgment upon how that data fits within the overall business model. Business logic (and rules engines) represent decision-making capabilities. Validation engines don't. Given that type of difference, I think validation (and good validation frameworks) is effective outside the code. It provides reuse (in a simpler way than in code); it separates the user/system messages from the code; it allows multiple types of validations against the same object/object graph in a simple way, etc. Of course, having said that, iScreen is not best suited to all validation concerns. For fairly simple validation in web apps, the validation capabilities the presentation framework provides is usually sufficient. It's when you get into more complex validations, or when handling web services or other system-inputs.
  7. Internationalization[ Go to top ]

    This raises an interesting question: why wouldn't validation belong in the Object, itself?
    Well, internationalization for one. You don't want hard coded error messages that are language specific. Additionally, it's pretty nice to be able to use one code base to validate country specific zip-code structures, phone number structures etc and flexibly add new countries by adding a configuration file. Kind regards, Marc
  8. Re: Just a little offtopic, but...[ Go to top ]

    Can't we check in the "set" method if the condition is met, if not then throw an exception (possible an specialized exception for this type of validation) ? Can it be simple like this ?
    In the Person class exemple, how can you enforce that the person age is smaller than it's father age ? Business rules often involve several properties at a time.
  9. XML to leak business logic.[ Go to top ]

    For security concern, business logic should not be placed in XML descriptors. People accessing to the XML files can easily change the business logic without being notified. Why not just use static methods in seperate classes? Developers come and go. They may use different frameworks. static methods are simple and easily for different developers to edit. Right? Besides, business logics are the most valuable information. Using static methods in seperated classes can keep the business logics from being accessed by unauthorized people.
  10. XML for validation[ Go to top ]

    Writing lines of unsafe xml code for not writing a few lines of java code is not suitable for me. I prefer annotation based validation framework. XML shall be used just for extreme cases where annotations does not help. This is what JSR 303 targeted. Java community shall focus its efforts for a standard validation framework, we do not need tens of non standard validation frameworks.