System Generation Properties
Basic properties
wt.generation.bin.dir, Specifies where .ClassInfo.ser files (serialized info objects) will be generated, following the package structure
wt.generation.source.dir, Specifies where mData files are expected to be found and where Java source files will be generated, following the package structure
wt.generation.sql.dir, Specifies where SQL scripts will be generated
wt.classRegistry.search.path, Specifies the path to search for files representing classes to be registered
wt.classRegistry.search.pattern ,Specifies the file pattern to consider as representing classes to be registered
Advanced properties:
• wt.generation.enforceExtendable true
• wt.generation.genJavaSource
• wt.generation.genIntrospect true
• wt.generation.genDatabase true
• wt.generation.genDisplayNames true
• wt.generation.reportDisplayNames true
• wt.tools.modelCheck true
• wt.generation.custom ${gen.custom}
• wt.home D:\ptc\Windchill
• wt.installroot D:\ptc\Windchill
• wt.buildroot D:\ptc\Windchill
• wt.sourceroot D:\ptc\Windchill
• wt.generation.sql.useDatastore false
---------------
Exercise 6-4: Add Initialization Methods
Objectives
● Add initialization methods to generated Java source..
Scenario
In this exercise, you will edit the Java source to implement appropriate initialization for modeled classes.
Step 1. Add initialization methods to modeled classes.
a. Open CustomerOrder.java.
b. Find all initialization methods. Here is one example:
c. For each initialization method, add a call to the super class initialization method. Use the same arguments passed in. Here is an example:
d. Save the file.
e. Compile.
Step 2. Check other generated code for initialization methods.
Step 3. Restart Tomcat and the Method Server.
----
Modeling Attributes
For Persistable classes, such as custom extensions extending a Persistable class, modeled attributes are columns in a database table. The column type depends on the attribute type.
• Therefore, changes such as adding or modifying attributes will affect the tables in the database.
• If a previous customization involved creating database tables, these tables need to be dropped.
Generally speaking, these tables should never contain critical data — dropping the tables should be done in a development environment. In production, the model should be set before being implemented in production.
If there were important data in the tables, the data can’t be dropped — it would need to be migrated to the new table structure.
Windchill has many tables, and there are relationships between rows in a table. If a table contains data, dropping it will not also drop related data in other tables.
It’s often possible in a development environment to just drop one custom table, leaving the extra rows in other tables, and not easily seeing a side effect in the development system. The best practice would be to delete the custom data, using the UI so that all related data is removed correctly, prior to implementing any other modeled changes.
---
Accessor Methods
When an attribute is modeled in Rational Rose, “accessor” methods will be automatically added by default to the resulting Java code for the containing class. An example of an attribute named “cost”:
1. private void costValidate( String a_Cost ) throws WTPropertyVetoException
2. public void setCost( String a_Cost ) throws WTPropertyVetoException
• Calls the validate method before setting the attribute
3. public String getCost()
The setCost() and getCost() methods are also known as setters and getters.
In Rational Rose, attributes are summarized in the Attributes tab of the Class Specification window:
Required Attribute
An attribute can be made a required attribute in the Windchill tab of the Attribute Specification window:
--
LowerLimit, UpperLimit
Figure 6-13: Windchill Attribute Specification Property LowerLimit
Attribute Specification
Attributes also have an Attributes Specification window to set detailed properties
Attributes need:
• name
• type
– The type could be a Windchill class or a Java class, it depends on the purpose of the attribute.
– For a cost attribute, java.lang.Float is a logical choice.
Note: Understanding Export Control will be an element of the exercise.
Basic properties
wt.generation.bin.dir, Specifies where .ClassInfo.ser files (serialized info objects) will be generated, following the package structure
wt.generation.source.dir, Specifies where mData files are expected to be found and where Java source files will be generated, following the package structure
wt.generation.sql.dir, Specifies where SQL scripts will be generated
wt.classRegistry.search.path, Specifies the path to search for files representing classes to be registered
wt.classRegistry.search.pattern ,Specifies the file pattern to consider as representing classes to be registered
Advanced properties:
• wt.generation.enforceExtendable true
• wt.generation.genJavaSource
• wt.generation.genIntrospect true
• wt.generation.genDatabase true
• wt.generation.genDisplayNames true
• wt.generation.reportDisplayNames true
• wt.tools.modelCheck true
• wt.generation.custom ${gen.custom}
• wt.home D:\ptc\Windchill
• wt.installroot D:\ptc\Windchill
• wt.buildroot D:\ptc\Windchill
• wt.sourceroot D:\ptc\Windchill
• wt.generation.sql.useDatastore false
---------------
Exercise 6-4: Add Initialization Methods
Objectives
● Add initialization methods to generated Java source..
Scenario
In this exercise, you will edit the Java source to implement appropriate initialization for modeled classes.
Step 1. Add initialization methods to modeled classes.
a. Open CustomerOrder.java.
b. Find all initialization methods. Here is one example:
c. For each initialization method, add a call to the super class initialization method. Use the same arguments passed in. Here is an example:
d. Save the file.
e. Compile.
Step 2. Check other generated code for initialization methods.
Step 3. Restart Tomcat and the Method Server.
----
Modeling Attributes
For Persistable classes, such as custom extensions extending a Persistable class, modeled attributes are columns in a database table. The column type depends on the attribute type.
• Therefore, changes such as adding or modifying attributes will affect the tables in the database.
• If a previous customization involved creating database tables, these tables need to be dropped.
Generally speaking, these tables should never contain critical data — dropping the tables should be done in a development environment. In production, the model should be set before being implemented in production.
If there were important data in the tables, the data can’t be dropped — it would need to be migrated to the new table structure.
Windchill has many tables, and there are relationships between rows in a table. If a table contains data, dropping it will not also drop related data in other tables.
It’s often possible in a development environment to just drop one custom table, leaving the extra rows in other tables, and not easily seeing a side effect in the development system. The best practice would be to delete the custom data, using the UI so that all related data is removed correctly, prior to implementing any other modeled changes.
---
Accessor Methods
When an attribute is modeled in Rational Rose, “accessor” methods will be automatically added by default to the resulting Java code for the containing class. An example of an attribute named “cost”:
1. private void costValidate( String a_Cost ) throws WTPropertyVetoException
2. public void setCost( String a_Cost ) throws WTPropertyVetoException
• Calls the validate method before setting the attribute
3. public String getCost()
The setCost() and getCost() methods are also known as setters and getters.
In Rational Rose, attributes are summarized in the Attributes tab of the Class Specification window:
Required Attribute
An attribute can be made a required attribute in the Windchill tab of the Attribute Specification window:
--
LowerLimit, UpperLimit
Figure 6-13: Windchill Attribute Specification Property LowerLimit
Attribute Specification
Attributes also have an Attributes Specification window to set detailed properties
Attributes need:
• name
• type
– The type could be a Windchill class or a Java class, it depends on the purpose of the attribute.
– For a cost attribute, java.lang.Float is a logical choice.
Note: Understanding Export Control will be an element of the exercise.