Entity renaming: avoid dangling references?

[gklyne]

Think about handling of identifier renaming (re-write data, record equivalence, or ...). (See also "data storage".)

• [ ] when renaming through edit form, update URI if it corresponds to previous ID??
• [ ] need to think about maintaining a list of corresponding URIs?
• [ ] Use server-internal revectoring? What about delete multiple?

Currently there's some inconsistency about view handling which may affect this: confirm views are rendered directly (as this allows form parameters to be provided directly), but other form action links are handled by redirection. Try to be more consistent about this? Create a more general pattern for handling continuation forms? Note: redirect means that different view GET function signatures, with values provided in the request URI, are handled in generic fashion. POST views are more easily handled directly with form parameters as supplied dictionary

[gklyne]

See also issue #34, which deals with type renaming