Extension guidelines
Following these extension guidelines will help you maximize the chance that your extensions will continue to work in future releases of Creo Elements/Direct Model Manager.
Extend, don't modify
You are welcome to extend
Creo Elements/Direct Model Manager code. Java and XML make it relatively easy to extend
Creo Elements/Direct Model Manager without modifying
Creo Elements/Direct's code. If you are creating a customization for multiple customers,
using business objects for attributes will result in a customization that is easier to integrate with other customizations.
There are two ways you can have Creo Elements/Direct Model Manager call your extended class:
• you can register your extended class directly in the XML configuration file, or
• you can call your extended class through a class that is registered in the XML configuration file.
Creo Elements/Direct Model Manager and Creo Elements/Direct Drawing Manager use the <BusinessObjectClass> tag to define the name of the Java class that will control a database class. In this example, the custom business logic was created as "AcmeModel3D" in the com/acme/biz directory.
<Class extends="DMModel, DMReleaseProcess">
<Name catalog="awm_stda" msg_num="258">MODEL_3D</Name>
<BusinessObjectClass>com.acme.biz.AcmeModel3D</BusinessObjectClass>
</Class>
Use classes from com.osm.action.util for new windows and dialogs
Avoid extending or using methods from any *.ui.* directories. Any customizations you create by extending or using methods from classes in these directories are likely to break with a new version of Creo Elements/Direct Model Manager.
Instead, extend the classes in com.osm.action.util.* to create pop-up windows and dialogs.
Use listeners
Listeners allow you to perform many actions without extending business object classes.
PreApply listeners are executed before data is stored to the database. They are useful for checking data integrity or modifying data before it is stored.
PostApply listeners are only applied if the object was successfully stored to the database. They are useful for integrating with external systems. For example, you can use a PostApply listener to send information about a part to SAP system. This way the data won't be sent unless the data is saved successfully. PostApply listeners require the system to cache data from the PreApply code. This caching process can affect performance.
Transaction listeners were added in OneSpace Manager 2005. They are like PostApply listeners, but are executed by the Web Service, so don't result in a performance penalty for Creo Elements/Direct Model Manager users. To execute the Transaction listener, Creo Elements/Direct Model Manager contacts a Web service with information about the transaction. Creo Elements/Direct Model Manager continues working while the Web service implements the Transaction listener. The Creo Elements/Direct Model Manager subscription tools for release 18.0 and above use Transaction listeners instead of PostApply Listeners.
Four new listeners were added in CoCreate Model Manager 13.20A:
• OSMXferDataModel listener – called just before the Save dialog is displayed.
• TransactionPreApply listener – called just before the transaction is applied. This listener is called once for the transaction while the PreApply is called for each object in the transaction.
• InitAttributeValues listener – called just after initAttributeValues is called.
• StateChange listener – called just before a state transaction is applied.
See the XML Customization section for information on how to register listeners. See the Web Services section for more information on the Web Service and Transaction Listeners.
Follow class naming conventions
Java doesn't care how you name your directories, but Creo Elements/Direct engineers have found that maintaining a consistent directory structure makes it easier to find code later. The convention is to create the directory structure starting with "com" followed by the product or company name followed by the directory for the type of class. When you extend a class, use the same directory name for your extension. For example, if you extend a class in com.osm.biz, put your extension in com.yourcompany.biz.
|
action
|
actions that appear in action menu or menubar menus
|
|
actionmenu
|
action menus that pop up when users click the right mouse button on an object or select the Action menu in the menu bar
|
|
biz
|
business objects
|
|
editor
|
attribute or element editors
|
|
editormodel
|
editor models for element editors
|
|
event
|
various audit events and events generated when objects are modified
|
|
exception
|
exceptions
|
|
media
|
gif and jpg files
|
|
renderer
|
attribute renderers (how values are displayed in the user interface)
|
|
tcm
|
table column models used in the workspace, load and save user interfaces
|
|
test
|
unit tests
|
|
util
|
miscellaneous utility classes
|
Be careful with semaphores
The pdm.semaphore should only be used for keeping pdm related business logic thread-safe. Use of critical sections should be minimized. The pdm.semaphore is used to:
• Limit one thread at a time to enter the kernel.
• Make critical sections of business logic thread safe. For example, you should use the pdm.semaphore to keep Java-kernel related hashmaps and caches in sync or to group several pdm calls together into an atomic operation.
All user interface operations must remain outside of these critical sections or you could introduce deadlock (See the Creo Elements/Direct Model Manager help for more information on deadlock.). You can create and use other semaphores to control the flow of user interface operations. When creating a new semaphore, be careful of semaphore dependencies. All semaphore dependencies must go in the same direction to avoid deadlock. In particular, don't make any pdm calls dependent on your semaphore.
Extend getDisplayChildren(), not getChildren()
If you want to modify the items displayed to the user, you should extend getDisplayChildren() rather than getChildren(). Changing the list of items returned by getChildren() can break the model load code.