I think there are more possibilities than you are considering.
- Hidden/Visible - is the field visible or not
- Blanked/System/Unchanged - does the system initially set the value to blank, or to some business-rule-provided value, or is it left as-is
- ReadOnly/Editable - can the user change the value
- Required/LeaveBlank/Optional - is the field required to not be blank, or can it be left blank assuming it was blank to begin with, or is it optional and can be blank in any case
Also you need to consider a lot of factors that go into making the decision
- Role - usually the user has 1 or more roles, and those roles can allow or disallow different possibilities
- Status - the status of the object in question often controls which fields are editable, regardless of role
- Object - often the values of the object itself determine what is allowed when, beyond just's it's status
- Task - you might break down editing things into more than just read and edit
- Section - I often want to control the settings for an entire section of the object or screen, and all the controls inherit those settings, but can override them on an individual basis if needed
Implementation?
First, make sure you have a clear vision of how the page lifecycle is handled. Mine usually goes something like this.
- Get the object they are editing, usually from session state, sometimes if they are doing a "new" operation you may need to create a stub data structure for them to work on
- If this is the first time the page is loading up, populate choices into dropdowns, this is usually a generic process, done only once
- If this is a postback, update the object being edited by reading in values off the controls
- Process events such as button clicks
- Run through all your business edits, these should alter the data structure they are editing
- Update the visibility and editability of the controls based on all the data you have on hand
- Populate the controls with the data from the object being edited, including validation messages, or error messages