Default value for "native" property attributes?

Anthony Shortland

unread,

Dec 23, 2009, 11:15:43 AM12/23/09

to ControlTier Accounting

Type level default attribute values are an extremely useful feature for keeping the object model size to a minimum by eliminating the need or settings.

Is there any reason why these values only apply to "imported" attributes? What about attributes assigned to the "native" properties of a type?

For example: its common practice to assign "entity.attribute.targetdir" to the "entity.deployment-install-root" deployment property.

How come one cannot assign a default value to this attribute?:

Being able to assign default values like this would greatly reduce repetition in the project/object XML.

Thanks,

Anthony.

Anthony Shortland

unread,

Jan 5, 2010, 7:37:26 PM1/5/10

to ControlTier Accounting

Hi Guys,

After discussion with Greg, I posted a feature request for this: https://sourceforge.net/tracker/?func=detail&aid=2926584&group_id=151079&atid=779850

Since there is already provision for a default-value associated with each type property it'll (hopefully) be simple enough to use it to setup the entity attribute value.

Anthony.

Anthony Shortland

unread,

Jan 9, 2010, 12:19:50 PM1/9/10

to ControlTier Accounting

I guess there are "more things in heaven and earth, Greg,than are dreamt of in our philosophy" since it seems what I was after for native property default values is already there (3.4.10 build 9605)! Alex?

Since we decided to defer the "Add "dynamic" settings as a new Managed-Entity sub-type" feature I went ahead to sketch out an implement that meets the the requirements using a Deployment sub-type.

The rationale for this approach is that, in order to create the required "Dynamically settable configuration placeholder" type, the combination of commands (provided by all Managed-Entity sub-types) and at least two string type properties (one to hold the placeholder's substitution token, and one for its value) is all that's required.

Fortunately, the Deployment type has four type properties to choose from:

deployment-basedir
deployment-install-root
deployment-runlevel
deployment-startup-rank

I first created the Placeholder "base" type that eliminates all of Deployment's allowed resources and establishes the two type property attribute names:

[anthony@services modules]$ cat Placeholder/type.xml
<?xml version="1.0" encoding="UTF-8"?>


<types
   xmlns:module="http://open.controltier.com/base/Modules#"
   xmlns:type="http://open.controltier.com/base/Types#"
   xmlns:cmd="http://open.controltier.com/base/Modules/Commands#">

   
   <type
   name="Placeholder"
   role="concrete"
   uniqueInstances="true">

   
   <description>Dynamically settable configuration placeholder</description>

   <supertype>
   
   <typereference name="Deployment"/>
   </supertype>

   <command-settings>
   
   
   
   <notification notify="false"/>
   <template-directory></template-directory>
   <dependency-view parents="false" children="true" proximity="1"/>
   <logger name="Placeholder"/>
   </command-settings>

   <attributes>
   
   
   

   <attribute name="placeholderValue" type-property="deployment-basedir"/>
   <attribute name="placeholderToken" type-property="deployment-install-root"/>
   </attributes>

   <constraints>
   
   
   

   <dependency-constraint enforced="false" kind="child">
   <allowedtypes>
   </allowedtypes>
   <singletontypes>
   </singletontypes>
   </dependency-constraint>
   <dependency-constraint enforced="false" kind="parent">
   <allowedtypes>
   <typereference name="Deployment"/>
   <typereference name="Node"/>
   </allowedtypes>
   </dependency-constraint>
   </constraints>

   <commands>
   
   
   

   </commands>

   </type>

   
</types>

I then created a Placeholder sub-type that uses the allowed-value constraint to setup default values for both type properties and hence their attributes.

[anthony@services modules]$ cat MyPlaceholder/type.xml
<?xml version="1.0" encoding="UTF-8"?>


<types
   xmlns:module="http://open.controltier.com/base/Modules#"
   xmlns:type="http://open.controltier.com/base/Types#"
   xmlns:cmd="http://open.controltier.com/base/Modules/Commands#">

   
   <type
   name="MyPlaceholder"
   role="concrete"
   uniqueInstances="true">

   
   <description>A specific type of placeholder</description>

   <supertype>
   
   <typereference name="Placeholder"/>
   </supertype>

   <command-settings>
   
   
   
   <notification notify="false"/>
   <template-directory></template-directory>
   <dependency-view parents="false" children="true" proximity="1"/>
   <logger name="MyPlaceholder"/>
   </command-settings>

   <attributes>
   
   
   

   </attributes>

   <constraints>
   
   
   

   <allowedvalue-constraint enforced="false" type-property="deployment-basedir">
   <allowedvalue value="myplaceholdervalue" default="true"/>
   </allowedvalue-constraint>

   <allowedvalue-constraint enforced="false" type-property="deployment-install-root">
   <allowedvalue value="myplaceholdertoken" default="true"/>
   </allowedvalue-constraint>
   </constraints>

   <commands>
   
   
   

   </commands>

   </type>

   
</types>

Note that by not enforcing the allowed value constraint, the door is still open to assign any value to the properties (although, in some cases, such enforcement will be very useful).

Finally, I created an instance of MyPlaceholder and examined the set of properties. Low and behold:

[anthony@services modules]$ ctl -p anthony -t MyPlaceholder -o myMyPlaceholder -c Properties -- -format plain | fgrep deployment-
entity.deployment-basedir=myplaceholdervalue
entity.deployment-install-root=myplaceholdertoken
entity.deployment-manages=false
entity.deployment-startup-rank=

[anthony@services modules]$ ctl -p anthony -t MyPlaceholder -o myMyPlaceholder -c Properties -- -format plain | fgrep entity.attribute.placeholder
entity.attribute.placeholderToken=myplaceholdertoken
entity.attribute.placeholderValue=myplaceholdervalue

Bloody hell is all I can say! Bingo! Perhaps Alex knows something we don't about this neck of the woods ...

Looking forward; the way is open to implementing commands (e.g. getPlaceholder, setPlaceholder, validatePlaceholder, etc) that manage the value and token attribute values for a given instance. I envisage managing sets of placeholders as resources of deployments in a similar manner to how we work with packages.

Sweet.

Anthony.

Anthony Shortland

unread,

Jan 22, 2010, 1:50:27 PM1/22/10

to ControlTier Accounting

Here's the thing ... seems I jumped to a conclusion on investigating the automatic use of default property values.

What I didn't notice is that the mechanism of automatically setting a type property's value to its default is specific to Workbench: when you create an instance of a type, Workbench automatically populates any type property field with its default value (if one exists) ... these value are then saved to the model with the object. Simple as that.

Thing is, of course, this mechanism doesn't work when you use the ProjectBuilder load-objects command ... though this would be a great feature to add!

Note that this limitation doesn't undermine the overall value of the "dynamic setting/placeholder" pattern I'm working, it just eliminates the particular convenience of not having to specify values for all the required attributes in project/object XML.

I've opened up an enhancement request and will consider adding it to 3.4.10: https://sourceforge.net/tracker/?func=detail&aid=2937400&group_id=151079&atid=779850

Anthony.

Reply all

Reply to author

Forward