On Mar 28, 2010, at 12:07 PM, Ricardo Aráoz wrote:
> So, you mean to tell me that in the bizObj validateField and
> validateRecord are two independent things but in the form they are not?
Not really. Of course in the bizobj they are two separate things, as
they are designed to deal with separate situations. But we are talking about
you calling save(), which is a series of events, any one of which can abort the
process.
> Does that mean that there is no onRecordValidationFailed() method in the
> form?
There is, but it is more generically named: notifyUser(). The message,
severity and exception object are passed to it, so that your form can determine
how best to present this information to the user.
> I must be misunderstanding you, if the validateRecord() bizobj method
> flags an error there is no way the onFieldValidationFailed() form method
> can get to know which field is erroneous, and thus it cannot know the
> "ctrl" parameter, so I deduced that the onFieldValidationFailed() method
> would not be called, and if this method is not called then I am not
> choosing to suppress any behaviour (I suppose my overriding of the
> onFieldValidationFailed() is the reason you wrote "you've chosen to
> suppress that behavior").
The problem is that you are misunderstanding the order that things
happen. Before anything happens, the field validation must be dealt with. Then
the changed records are determined, and each is run through the
validateRecord() code. Only after all that happens is an attempt made to
actually save the data.
Think of it this way: the only reason for field validation is to ensure
that under no circumstance will you allow the user to enter invalid data into a
field; that no matter what the state of the rest of the record is, they should
not be allowed to leave that field until the invalid data is corrected.
Now that I understand what you're trying to do better, I think that
what you are looking for isn't field validation at all; instead, you simply
want the control to visually reflect the validity of the content. You could do
this in onKeyChar or onValueChanged, or, as I later suggested, onLostFocus.
> You mean to say I should subclass dTextBox for every control I must
> validate?
???
I honestly don't understand what makes you think that this would be
necessary.
> Or subclass dTextBox and in the onLostFocus() ask for the name of the
> control in order to call the appropriate validation function?
How many of these special cases do you have? You mentioned a single
control whose color you want to reflect the validity of the content. Are you
now saying that you have many controls that need similar behaviors?
> And I'd like to ask you if when I override the the
> onFieldValidationPassed() form method to restore the control's ForeColor
> to black I should call super() so as to keep intended behaviour.
There is no default behavior, so calling the super()'s method will do
nothing, so it won't hurt, but it won't do anything, either. It's simply a hook
that is there for you to tap into if needed.
-- Ed Leafe
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message:
http://leafe.com/archives/byMID/[email protected]
