HDK
|
#include <namespaceEdit.h>
Public Types | |
typedef std::function< bool(const SdfPath &)> | HasObjectAtPath |
Functor that returns true iff an object exists at the given path. More... | |
typedef std::function< bool(const SdfNamespaceEdit &, std::string *)> | CanEdit |
Public Member Functions | |
SDF_API | SdfBatchNamespaceEdit () |
Create an empty sequence of edits. More... | |
SDF_API | SdfBatchNamespaceEdit (const SdfBatchNamespaceEdit &) |
SDF_API | SdfBatchNamespaceEdit (const SdfNamespaceEditVector &) |
SDF_API | ~SdfBatchNamespaceEdit () |
SDF_API SdfBatchNamespaceEdit & | operator= (const SdfBatchNamespaceEdit &) |
void | Add (const SdfNamespaceEdit &edit) |
Add a namespace edit. More... | |
void | Add (const SdfNamespaceEdit::Path ¤tPath, const SdfNamespaceEdit::Path &newPath, SdfNamespaceEdit::Index index=SdfNamespaceEdit::AtEnd) |
Add a namespace edit. More... | |
const SdfNamespaceEditVector & | GetEdits () const |
Returns the edits. More... | |
SDF_API bool | Process (SdfNamespaceEditVector *processedEdits, const HasObjectAtPath &hasObjectAtPath, const CanEdit &canEdit, SdfNamespaceEditDetailVector *details=NULL, bool fixBackpointers=true) const |
A description of an arbitrarily complex namespace edit.
A SdfBatchNamespaceEdit
object describes zero or more namespace edits. Various types providing a namespace will allow the edits to be applied in a single operation and also allow testing if this will work.
Clients are encouraged to group several edits into one object because that may allow more efficient processing of the edits. If, for example, you need to reparent several prims it may be faster to add all of the reparents to a single SdfBatchNamespaceEdit
and apply them at once than to apply each separately.
Objects that allow applying edits are free to apply the edits in any way and any order they see fit but they should guarantee that the resulting namespace will be as if each edit was applied one at a time in the order they were added.
Note that the above rule permits skipping edits that have no effect or generate a non-final state. For example, if renaming A to B then to C we could just rename A to C. This means notices may be elided. However, implementations must not elide notices that contain information about any edit that clients must be able to know but otherwise cannot determine.
Definition at line 211 of file namespaceEdit.h.
typedef std::function<bool(const SdfNamespaceEdit&,std::string*)> SdfBatchNamespaceEdit::CanEdit |
Functor that returns true
iff the namespace edit will succeed. If not it returns false
and sets the string argument.
Definition at line 246 of file namespaceEdit.h.
typedef std::function<bool(const SdfPath&)> SdfBatchNamespaceEdit::HasObjectAtPath |
Functor that returns true
iff an object exists at the given path.
Definition at line 242 of file namespaceEdit.h.
SDF_API SdfBatchNamespaceEdit::SdfBatchNamespaceEdit | ( | ) |
Create an empty sequence of edits.
SDF_API SdfBatchNamespaceEdit::SdfBatchNamespaceEdit | ( | const SdfBatchNamespaceEdit & | ) |
SDF_API SdfBatchNamespaceEdit::SdfBatchNamespaceEdit | ( | const SdfNamespaceEditVector & | ) |
SDF_API SdfBatchNamespaceEdit::~SdfBatchNamespaceEdit | ( | ) |
|
inline |
Add a namespace edit.
Definition at line 222 of file namespaceEdit.h.
|
inline |
Add a namespace edit.
Definition at line 228 of file namespaceEdit.h.
|
inline |
Returns the edits.
Definition at line 236 of file namespaceEdit.h.
SDF_API SdfBatchNamespaceEdit& SdfBatchNamespaceEdit::operator= | ( | const SdfBatchNamespaceEdit & | ) |
SDF_API bool SdfBatchNamespaceEdit::Process | ( | SdfNamespaceEditVector * | processedEdits, |
const HasObjectAtPath & | hasObjectAtPath, | ||
const CanEdit & | canEdit, | ||
SdfNamespaceEditDetailVector * | details = NULL , |
||
bool | fixBackpointers = true |
||
) | const |
Validate the edits and generate a possibly more efficient edit sequence. Edits are treated as if they were performed one at time in sequence, therefore each edit occurs in the namespace resulting from all previous edits.
Editing the descendants of the object in each edit is implied. If an object is removed then the new path will be empty. If an object is removed after being otherwise edited, the other edits will be processed and included in processedEdits
followed by the removal. This allows clients to fixup references to point to the object's final location prior to removal.
This function needs help to determine if edits are allowed. The callbacks provide that help. hasObjectAtPath
returns true
iff there's an object at the given path. This path will be in the original namespace not any intermediate or final namespace. canEdit
returns true
iff the object at the current path can be namespace edited to the new path, ignoring whether an object already exists at the new path. Both paths are in the original namespace. If it returns false
it should set the string to the reason why the edit isn't allowed. It should not write either path to the string.
If hasObjectAtPath
is invalid then this assumes objects exist where they should and don't exist where they shouldn't. Use this with care. If canEdit
in invalid then it's assumed all edits are valid.
If fixBackpointers
is true
then target/connection paths are expected to be in the intermediate namespace resulting from all previous edits. If false
and any current or new path contains a target or connection path that has been edited then this will generate an error.
This method returns true
if the edits are allowed and sets processedEdits
to a new edit sequence at least as efficient as the input sequence. If not allowed it returns false
and appends reasons why not to details
.