Hi Chuck, On 26 Feb 2015, at 3:01 am, Chuck Hill <[email protected]> wrote:
> > What I'd like is for it all to be part of the validation system, such that > when saveChanges() is called, validateForSave() throws appropriate exceptions > and messages could be sent to the view layer. But it's a bit hairy. > Consider just setPlaintextPassword(). Say the supplied string is too short > and it fails the password length test. My naive solution was to create the > ValidationException, but hang onto it until saveChanges() is called > > If the value is not valid, the validatePlaintextPassword method MUST throw at > that point. What usually happens (e.g. When takeValues is processed on an > HTML page, is that validatePlaintextPassword() is called and then > setPlaintextPassword() if it does not throw. If the value is not valid, the > validatePlaintextPassword method MUST throw at that point. If you want the > validations to work you must change the value, valid or not. Ah OK, I wasn't even implementing validatePlaintextPassword()—it didn't occur to me because 'plaintextPassword' is not a model attribute, and I'm also not keeping the plaintext password (obviously). In fact, to implement that I _would_ have to hold the plaintext password, at least in memory, and now this is all starting to sound like a security risk, albeit fairly theoretical. > —but, and you can see where this is leading, validateForSave() doesn't get > called unless the password is actually changed (assuming nothing else on the > User is changed), so I don't get to throw that exception I stashed earlier. > In that case I might be able to make the change to the too-short string, and > do what I was planning, but the changePassword() method is another story. > > Say changePassword() is called, but oldPassword doesn't hash correctly. Now > what? Do I call setPlaintextPassword(newPassword) anyway to ensure > validateForSave() is called? But then in that method, I throw the exception > I stashed, sure, but the password has now _changed_ even though the app > reports it _hasn't_. So a subsequent call to changePassword() with the > previous oldPassword value is going to fail. Again, naively, I considered > maybe changing it _back_ to the snapshot value for that attribute in > validateForSave() before throwing the exception, but then BAM! EOF > Commandment #4: > > Don't modify any EO properties in validateFor...(...) methods > > So I'm stumped. Does this sound possible, or should I give up and continue > to handle this kind of thing outside the regular validation system? > That is probably your best bet, or have changePassword throw validation > exceptions, and accumulate them and any from takeValues in the GUI layer. > That way you don’t even call saveChanges() if things have not validated to > that point. My presentation from WOWODC 2009 might give you some ideas. No, > of course I never finished it! > http://sourceforge.net/projects/wovng/ > There are no files, you have to clone the repository. Thanks Chuck. I think if the question I was asking in my original post was "Is this kind of thing a reasonable candidate for handling entirely within the model?" then the answer is "No." -- Paul Hoadley http://logicsquad.net/
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
