How do the CSLA veterans handle this particular use case?
I'm editing a user profile (in an ERLB), and there is a edit field for the password. If I change the password, I need to be prompted to confirm the password change before the object is saved. (Moreover, the actual stored password might need to be encrypted, etc., but that's a side issue).
The more general form of this scenario (and we have 5-10 of these in our application) is that a user has made a data change that requires additional data not displayed in the grid or original screen to be supplied via a secondary prompt screen before the data is saved.
The obvious possibility is to actually not allow direct entry of any such field and provide a specific function for making the change that presents a screen with all the needed data, but I hoping to find a good pattern for handling this scenario in general that would not require this restriction.
Another thought would be to (1) have some sort of event that the UI could hook to catch the property change, coupled with (2) some sort of validation rule that renders the object invalid until the additional data is supplied. For the user scenario above, a user object with a changed password value is invalid unless a password change confirmation has also been provided to the same user object, or something similar. In our case, we actually have a "Password Changer" BO that validates the password hasn't been reused, meets complexity requirements, sets the expiration date in the user, logs the password change operation, etc., so it occurred to me to just attach such an object as a child to the user object, and the user object will save it as part of it's own processing.
Other ideas welcome...
ajj3085:
Well, my view is that prompting is a purely UI thing, so if you need a prompt, the UI should be built to do it.
I completely agree -- the problem is I don't know what the best way to build such a UI thingy is.
For the sake of discussion, say you have the password in a grid in the ERLB.
The user types in new password, then immediately clicks on the next row. ApplyEdit gets called on the user object and ERLB will try to save it.
How do you get the opportunity (or what is the best way) to prompt the user after the password change is detected but before an attempt is made to save the object?
OK, I have a running prototype, but I'm not so sure about it as a general model.
(1) My "user" BO has a static event that it fires when a new password value has been supplied. This is just a helper for a UI, and avoids serialization issues.
(2) I haven't done a the grid yet, but my user form subscribes to the password changed event
(3) When password change occurs, the event handler in the user form inspects the sender to see if it is a reference to the same object being edited, if so, it constructs a PasswordChanger and displays a "Confirm Password Change" screen bound to the PasswordChanger.
(4) If the change is successfully confirmed, then the PasswordChanger is provided to the user object (otherwise, the original value of the password is put back).
(5) When the user object is Saved(), it applies the data from the PasswordChanger as part of its database update (encrypts user-supplied value, sets password expiration date, logs password change in separate table, etc.)
The user BO logic doesn't require this particular UI model, it just requires that a PasswordChanger accompany any password change.
Again, I'm new at this, so I'm not sure what perils are hidden in this approach.
Copyright (c) Marimer LLC