Cloning functionality is used to support versioning and copy-reuse in (e.g.) the ROLE client. The CORK ReplicatedObjectClient interface provides a basic mechanism for uploading an arbitrary object into the database such that it is assigned an ObjectID, is protected by a Permissions object, and becomes sharable as if it were constructed by the server. This provides the basic support needed to clone objects, but cannot completely handle cloning of aggregated sets of objects, e.g.:
- Lists of objects from a node in a containment hierarchy in BRIDGE, such as a WebSite
- Page format objects, which reference other objects for standard "pluggable" parts of the format such as header, footer, and sidebar
- MapConfig objects, which may also include editable layers of spots and structures
Other objects are even trickier, since cloning requires action that essentially occurs outside of CORK, e.g.:
- Copying a SharedFile should result not only in copying the file's metadata, but also it's contents
A general mechanism for providing pluggable support for copying could be introduced as part of CORK or BRIDGE, though the application-specific nature of these operations suggest that building them into (e.g.) the CORK ReplicatedObjectClient is not appropriate:
- Permissions setup on copied objects will almost certainly be application-specific
- Error handling may require user intervention
- The details of cloning may require other application-specific information, e.g., handling of "link-only" objects in BRIDGE
- For security reasons, the copying operations should be driven by a client entity (even if it is a client running in a servlet container).
It does not, however, seem that either the BRIDGE ComponentView or WebView classes are the appropriate place for this funcationality, since implementations of these (appropriately) make assumptions about running within a UI or servlet container. Implementations of the copy functionality would also tend to be no-op'd for most kinds of (non-aggregate) objects.
The interface to a general cloning mechanism would need at least the following:
- A CORK
ReplicatedObjectClient instance
- The original object, which the cloning mechanism would presumably deep-copy (if replicated) before adding to the database. Further object-specific cloning operations would presumably need to know the object id for this object (e.g., to set up
DelegatedPermissions objects that refer to the original object).
- The permissions to be assigned to the cloned object.
The initial implementation of this functionality will be contained in ...cork.util:
-
ReplicatedObjectCopyUtility will provide static methods for copying objects (given the parameters described above). It will also include methods for registering ReplicatedObjectCopier instances for specific object types.
- The
ReplicatedObjectCopier interface will provide a way to register specific cloning logic for types of replicated objects
NOTE: Eventually we'll want roughly the same functionality for deleting objects
|