|
AdobeBridgeCS5SDK | ||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||
SUMMARY: FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
Object | +--CustomSortExtensionHandler
Demonstrates how to implement a custom sorting and filters with a node-handling extension.
Shows how to implement an ExtensionHandler and ExtensionModel with customized sorting of nodes in a content hierarchy. This sample uses SortCriterion, FilterDescription and XMPMeta objects from the Bridge scripting DOM to implement the custom sorts. An additional property is also added to the ExtensionModel that is used to set and get manually sort settings.
To enable customized sorting, a method ExensionModel.getSortCriteria() has been defined. The method adds several new sorting options to Bridge for handled nodes by adding SortCriterion objects the to the default list ( app.defaultSortCriteria ). This extension has added three additional sort criterion. These demonstrate the two variations of SortCriterion objects that can be used, SortCriterion that relies on Infoset data and SortCriterion that relies on XMP data.
For the handled nodes to support being sorted by XMP data, Bridge must be made aware of the nodes capabilities. This is achieved by setting some of the capabilites of the node in the core infosets. Setting the 'canGetXMP' and 'canSetXMP' properties of the itemContent infoset to 'true' will cause Bridge to look for the appropriate methods on the handler.
To set metadata on a node then its handler must implement the long running operaton ExtensionHandler.setXMP(). In this sample, the methods create a ProgressOperator, which carries out the operation of adding or updating the XMP data for the selected node. The ProgressOperator can display a modal progress bar to give feedback of the ongoing operation. To ensure the progress bar is visible, the operator should be passed to app.enqueueOperation().
This sample also supports manual sorting of nodes. A manual sort does not have to rely on any particular data set or metadata; it can simply be nodes sorted by the user and placed in a configuration within the content pane. Nodes can be dragged and dropped to arrange them in the desired manner. To keep the sort persistent then three additional methods must be defined on the model to support manual sorting:
This method will be called on a handled container node to determine wether nodes can be sorted manually.
If the manual sorting is supported, then this method is used to store the sort details. A XML string is passed to this method which contains the sort details. How these details are stored is implementation-dependent. This sample uses a custom property on the model, ExtensionModel.sortXML, but any number of ways could be implemented, such as using the ExtensionModel.privateData property or even storing the details in a file on disk.
This method is called whenever Bridge needs to display the handled nodes in a manual sort. An XML string is returned containing the details of sort. The XML string is in the following format:
<dirinfo> <files> <item key='XXX' /> </files> </dirinfo>
The item element has an attribute named 'key'. This attribute holds a string which is the name of the thumbnail and the date of creation. The date will take the format:
For example, if we have a thumbnail named myFile which was created on Monday, September 25th at 10:28 and 34 seconds the date string would be 20060925102834. This is concatenated with the file name to give the attribute value of:
The date is retrieved from the immediate infoset - core.immediate.creationDate - and the order of the item elements denotes the display order of the thumbnails. For example, the thumbnail denoted as the first 'item' element is displayed first in the browser pane, the thumnail denoted as second 'item' element is displayed second in the browser pane and etc, etc. If the creation date will not be supported for the handled nodes (core.immediate.creationDate) then a string of 0 (zero) is used to create the key. For example:
The XML string is always in this format, even if the sort has been reversed. You do not need to consider the reverse order of the sort when building the XML string, if the sort is reversed then Bridge can determine this.
To add additional filters for custom nodes, the model must return an array of FilterDescription objects when the ExtensionModel.getFilterCriteria() is called. The array can add to the default list or create an entirely new list. This sample adds a custom filter to the default list, allowing the handled nodes to be filtered on a string value stored in a custom Infoset.
See the Bridge JavaScript Guide for more details of node-handling mechanisms
you can implement.
See:
Field Summary | |
String |
requiredContext
The context in which this sample can run. |
Constructor Summary | |
CustomSortExtensionHandler()
|
Method Summary | |
Boolean
|
canRun()
Determines whether sample can be run given current context. |
Object
|
initModel(sortModel, sys)
Initialize the model and define the methods that this model supports |
Boolean
|
run()
Functional part of this sample, creates several nodes of the new type, and one manager object, which stores the node-identifying prefix and root node. |
Field Detail |
String requiredContext
Constructor Detail |
CustomSortExtensionHandler()
Method Detail |
Boolean canRun()
Object initModel(sortModel, sys)
sortModel
- The model for the handled nodes
sys
- The manager object for the handled nodes
Boolean run()
Creates the ExtensionHandler object, whose definition includes the 'makeModel()' method, which Bridge uses to create the ExtensionModel object at node-display time. Registers the ExtensionHandler, associating it with the node-identifying prefix.
|
AdobeBridgeCS5SDK | ||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||
SUMMARY: FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |