Re: Data validation, mapping, and error handling

Aaron Bartell wrote:

My sense is that it's a lot more work.

I think it depends on how you look at it. For instance, you are trying to
use the JSF required="true" parameter to ease your development, but after
learning how that approach works I prefer to simply add an IF statement in
my handler code to test for the same thing so I can have uniform validation
(i.e. not have some of it in the UI layer and some in the controller layer).

Yeah, but then we're down to opinion. And your opinion begins to waver just a little bit when we're talking about dozens or hundreds of screens. Since I can define this validation at the data item level, it will automatically be added whenever I add a field to the screen - no additional code. You have to add it to the code every time.

I guess you could say I am throwing the baby out with the bath water, but I
also gained an efficiency by having my validation code all in one place
without that much more work (i.e. probably take about 30 more seconds to
code the IF statement vs. the JSF required="true" approach).

If you like to type redundant code, that's fine. But those 30 seconds' add up; I think that's the big push behind the DRY principle that's so hip among the cool kids these days <grin>. And don't take this the wrong way, but I really start to wonder when the phrase "without that much more work" pops up. When we're trying to determine which tool is more productive, that's a pretty questionable sentiment. It's kind of like the all-SQL all-the-time folks saying that the performance "isn't that much worse".

If you're willing to say EGL is more productive, but you would rather hand-key, then fine. But if you're saying your method (hand-coding all validations) is more effective, then I have to disagree. Especially if we move the edits all the way down to the client, and they can be done without a round-trip back to the server.

This next statement could be completely based on how I like to code, but
this is one of those cases where the framework tries to help out by giving a
cool feature out of the box, but it instead is just muddying the waters
IMO.

Yup. I agree. Your statement is completely based on how you like to code. <grin>

I do however like how the UI control values are mapped directly to
POJO's - that has saved me TONS of time.

Agree again <smile>.

The same concept could be applied in RPG fairly easily though I would be
concerned about performance. When I say fairly easily I mean I have done
all the different pieces of technology and I don't mean it would be quickly
built (as in time). All JSF is doing under the covers is mapping HTML
<input /> tags to "setters" in the JSF controller.

Hee hee! And all SQL is doing is mapping strings to field names and values! Sure, you could re-invent this particular wheel, Aaron. My guess is you will never get the time.

But in the end RPG doesn't currently have it and JSF/EGL does...

... and that's pretty much the salient point, isn't it?

Joe