This is a "best practices" sort of question...

I came across this statement while going through the latest Tutorial (the tutorial is great, by the way): "The page author registers the validator on a component by nesting the validator's tag within the component's tag."

It strikes me that field validation should be the responsibility of the model developers rather then the page authors. Intermixing validation logic with presentation logic seems like a violation of the spirit of the desire to separate the model from the view.

Validation of a form's fields should be associated with the model rather then with the presentation. There may different presentations for the same model, and the validation rules should (more then likely) be consistent regardless of the presentation.

Am I missing something?

 

 

You are right. It never occurred to me till I read your post. Good job.

 

 

I think it depends on what validation you are doing inside the validator being attached to the ui component. I feel it is acceptable to do what I call 1st level edits within the presentation layer. A first level edit might be something based around form. Example, if a input_text is expected to receive a date from the user, having the presentation layer verify that the input is in fact a date (02/03/2003) and not XX-3KJD8-1, would be acceptable. However, requiring the date be greater than todays (or some other date) should not be controlled in the presentation layer (this would be a 2nd level edit).
This, potentially, alleviates the model layer from doing trivial validation. The model layer would then expect its' interface (ui or other) to abide by these 1st level edits. It could optionally reproduce these validations also, just for defensive coding sake.

 

 

I don't disagree with your point at all... some validation (edits to you database folks) should be performed in the presentation layer, but experience leads me to believe that the validation rules should be specified by the model. This insures that the same validation will be performed regardless of the presentation.

Perhaps we need a convention for specifying validation rules within the form bean definition... We now have the Java Bean getXXX and setXXX for dealing with the value of property XXX, perhaps we need "getContraintsXXX".

We could then develop standard validation tags that can extract rules from the model, rather then having to communicate the rules to the presentation designer, and running the risk of introducing errors.

 

 

I like that.

Along the lines of your bean example:
setXXX()
getXXX()
isValidXXX()

I really like that.

 

 

It's an interesting question ... and there is more than one perspective from which it might be answered.

Let's consider an application architecture that has three tiers in it ... UI (represented as forms on an HTML page), business logic (represented as JavaBeans or perhaps EJBs) and a persitence tier (for simplicity, let's assume that you're using a relational database accessed via JDBC. Now, put yourself in the shoes of the developer creating each of the three tiers. Are there validation requirements in all three? You bet there are:

In the presentation tier, only certain actions
are valid at certain times. Thus, you'll often
see conditional logic to enable and disable
menu options, or dynamic changes to the set of
valid answers in a combo box. Indeed, using a
combo box instead of a text field is implicitly
performing a "validation check" of sorts, by
limiting the user to only valid options (at least
if they are using the browser and not sending in
an HTTP request directly :-)

In the business logic tier, only certain methods
can be called at certain times, and only certain
combinations of input data are acceptable when
you call them. So, you implement validation
checks on input values, and perhaps throw things
like IllegalArgumentException when the specified
requirements are not met.

* In the persistence tier, you must ensure that the
information stored in the database is always
consistent, so you implement things like NOT NULL
and FOREIGN KEY constraints to ensure that invalid
combinations of things cannot be stored at all.

All this makes architectural sense ... each tier is responsible for protecting itself from bad input coming from tiers closer to the user (of from the user itself). So, each tier erects gauntlets that incoming data must flow through to ensure that it's OK. Correctly implemented, you've got a robust and reliable application.

But there's another perspective to consider ... and in many cases it's much more important than our view from inside -- what does the user experience when they actually make a mistake?

Consider an input form with three fields on it ... one that is simply required, one that is a text field into which the user must type one of a small set of legal values (yes, this probably should have been a combo box, but the page author was too busy to create it that way this time). The third value has to be looked up in the database to be validated (say, it's the bank account number of the account you are transferring money to). Now, assume your user makes a mistake on all three fields.

If each tier simply protects itself from bad input but doesn't percolate up its validation checking, then the user has to make THREE tries to get it right. Client side JavaScript can catch the required field, so that gets caught before the form is even submitted. Now the required field is OK, but the legal value test fails, so the user gets the form back with that error message -- but the account number wasn't checked yet, because the business logic tier rejected the input. Finally, on the third attempt to submit the form, the user finds out that they transposed a digit on the account number, so they have to go back and fix it, then submit yet again.

Is that a high quality user experience?

I would suggest it is not -- human factors engineering says that what you want to do is catch ALL the mistakes that you can the first time. In terms of web application design, then, that means you need to percolate up the validation checks from lower tiers so that they all execute together.

For JavaServer Faces 1.0, the explicit way to percolate things is to nest validators inside the component tags. However, that's not the only possible approach -- one can easily envision tools that do this automatically for you. For example, if you use the Struts+Faces integration library, you get to continue using the Validator Framework for this kind of thing.

But it always needs to be possible to explicitly declare additional validations, and it's good user experience engineering to percolate up the correctness checks from lower tiers to the UI tier, so that you can catch all possible mistakes in one round trip to the server.

Craig McClanahan

 

 

Craig,

When I originally posed this question, I was prompted by thinking about the development process. The person developing the form beans defines the fields, and should know what the contraints for each field should be with respect to the business logic. How are these contraints made visible to the person respnsible for developing the presentation logic?
Unless the constraints can be programmtically extracted from the form definition, either by methods on the form bean or by extracting information from a configuration file, you have an error prone process.

I've used Struts for years (and am very grateful), but I've always been bothered by the manual synchronization necessary between the XML, the Java, and the JSP. In the horrible bad old days of generating HTML from a servlet the compiler would catch dumb mistakes. Now we have to wait for run time errors. This worries me.

 

 

It worries me, too. One of the arguments for using systems languages (like Java) to do web development, instead of scripting approaches (like ASP), is the compile-time error detection available in Java due to language features like strong type checking, etc. In ASP, you had to wait until runtime to find out you had typed a function name incorrectly, etc.

Well, Microsoft has finally delivered ASP.NET, with strong type-checking in languages like C# and VB.NET. I've experimented with it quite a bit, and they really have worked hard on giving good diagnostic messages, and on catching things like naming discrepancies between components defined in the HTML (.aspx) and the corresponding C# source code (.aspx.cs) at page compile time.

Meanwhile, the Java community seems to be moving in the opposite direction, introducing features like the JSTL (with its runtime Java introspection). Frameworks such as Struts and the new JavaServer Faces rely heavily on JSTL to avoid having to put Java expression scriptlets in the page, but you give up the compile-time type checking. Also, errors caused by naming differences between beans referenced both in .jsp files and in .java files are often hard to track down, because all you may get is a null pointer diagnostic or an empty value.

I do think tools support will help with some of the XML - Java - JSP synchronization issues, when the vendors catch up, but the whole idea of splitting up an application into declarative (XML / JSP) and procedural (Java) sections tends to make for higher learning curves, and complicates debugging.

I earnestly hope that, as we approach the final stages of the JSF reviews, much thought will be given to "making easy things easy". If this initiative is Sun's answer to Microsoft's ASP.NET, which it appears to be, the goal has to be to make Java web application programming accessible to the average developer, as well as making good developers more productive. Early error detection certainly belongs in there somewhere.

Stephen

 

 

I imagine that in theory, you could have a JSP engine or a preprocessing tool that parses the JSTL / JSP 2.0 Expression Language and reports errors at compile time.


The learning curve may be higher (but only slightly) if you already know Java, but I think you are missing the point: one of the idea behind JSP, JSTL, and JSF is that of separation of concerns. A "page author" (the person building or modifying a page) does not necessarily know Java, and probably does not want to even hear about it. For such a person, learning JSP / JSTL / JSF, or simply using a graphical tool to put components together, will be much, much easier than learning Java. In addition, the declarative approach is more adequate for tools.

 

 

I agree with your observations, but to me it is precisely the separation of concerns that exacerbates the validation issue. How do you insure that information is reliably and accurately transmitted between the various stake holders?
When the model desinger makes a change, how do you insure that the presentation logic is correctly updated prior to run time?

Tools definitely have a place in this equation, and I am suggesting that coding conventions be adopted to make the contruction of such tools easier (See the preceding posting relating to form bean methods to retrieve validation contraints).

 

 

Absolutely, my comment did not try to address the validation issue in particular. I think it would be a good thing (TM) to be able to centralize the validation code.

-Erik

 

 

Agreed -- but what about the significant number of small projects that are done by one developer? Large projects benefit from separation of responsibilities, but on smaller projects, the complexity introduced by that separation begins to outweigh its benefits. Thus, my plea for "making easy things easy."

Stephen

 

 

I can buy into the value of centralizing management of validation code, but the reality (as pointed out by this very interesting thread) is that the actual validation rules to be validated need to come from multiple tiers of the overall application -- and to guarantee a high quality user experience, you really do need to combine them so that the round trips to the server are minimized.

It is also interesting to note that centralized validation does not necessarily have to be provided by the front-most UI component framework that you are using. For example, my Struts+Faces integration library lets you use (or continue to use, if you've got existing Struts based apps) the Validator Framework, complete with its support for generating client side JavaScript. Just because this might or might not be part of JavaServer Faces itself does not mean that you can or can't use it.

Craig McClanahan

 

 

Just out of interest, how many of you have actually worked on projects where Java programmers have not done the JSPs? I personally have never worked on a project where this has been the case.

 

 

Philosophically speaking, yes. But my problem with struts-type validation (where the validation is passed through the bean) is that, very often different validation is required for different pages. Using javafaces, we can be more specific about the validation on a per-page basis.

R.