|
I've had a bunch of little bugs assigned to me where some action in the
UI is allowing a user to add or remove something from a collection, or
change some item in a collection. to fix these bugs, we've ended up
scattering little checks for isReadOnly() all over the place in the UI,
everywhere from drag and drop to menu item enabling, to keyboard
handling. This is error prone, and could eventually lead to some
security issue with readonly collections. Perhaps we could come up with a lower level mechanism, or at the very least a system for alerting and/or asserting developers when "disallowed" changes happen to a read-only collection... at least that way the UI wouldn't be responsible for enforcing the readonlyness. The system I'm imagining is some sort of internal toggle variable on a collection that indicates if a collection is read only or not - then any add/delete/etc type operation would assert that the collection is writable. To toggle this variable, we'd probably want to have methods for opening/closing the collection - something like BeginReadonlyAccess()/EndReadonlyAccess(). Obviously we can't ultimately 'enforce' readonlyness because internally we do actually need to change readonly collections. But at least it would be obvious when the assertion fired that we're doing the wrong thing, rather than relying on developer to remember "ah, this new feature modifies a collection, so I better check for readonlyness" and then relying on QA to test that scenario. The doesn't handle the situation of modifying items themselves that exist in readonly collections, and I don't really have an idea for that other than maybe having some debug-only watching that intercepts collection changed notifications and fires assertions when they see a change to an item in a readonly collection. Thoughts? Is there a better way to handle this? I don't have a lot of experience in this area.. Alec |
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
