In PTTracker, a screen is pop-up to let you select the record and then goes to the screen to load the details of the selected record to edit. I'm developing a application. I want to integrate 2 screens. I want each record can be edit independently. Now the question comes, which method should I use?
Method 1: Same as PTTracker, load record list as read-only. When user click one of the loaded record, pass the record id to load an editable record details.
Method 2: Load record list as Editable. When user click one of the record, just locate the record in the list and edit, save.
I believe that consistency in the user interface is pretty important and in most of my apps I've got situations in which the edit screens sometimes involve large collections and sometimes small ones. Sometimes the objects have lots of properties and sometimes they have a few. So I feel that it is necessary to make a choice independent of those criteria so that the user's experience in editing objects is consistent. Everyone is entitled to their own opinion on these matters of course.
But, going further with mine, I like to offer the user a screen on which they have a combo box at the top of the form whose list is populated by either an NVL or ROC object that lists all the items from which they may choose to edit with this form. In my apps, the combo box behaves in this manner: if the user types or selects a value matching an existing item in the list and they leave the combo box, I load that object (the screen is actually bound to ERO object they have chosen). They can simply view or edit as necessary.
If they type a value that doesn't match an item in the list, then we offer an empty object with which they can begin editing.
Actually, this choice really wasn't even mine. My programs just happen to interface with an accounting package that the user already operates and, in an attempt to make their life as simple as possible, my app mimics the behavior of that other system.
This method may not be for everybody, but my own opinion is that it is a bit more intuitive for the user. I think Rocky's choice for the technique used in PTracker was probably motiviated as much (or more) by the ease with which the UI can be developed with his framework as it was to meet any particular U.I. standard(s) for the types of applications he usually develops.
After all, the book is a learning tool to demonstrate that framework. I don't think we need subscribe to exactly what he choose to do with that framework in his demonstrations (though we might choose to do so, of course). That's the beauty of that framework isn't it? We can use it to meet whatever design requirements we have!
If I understand your statement of the choices you perceive, I think my method most closely resembles your second choice.
Good luck with CSLA!
Copyright (c) Marimer LLC