Hi,
in our development environment we had several properties defined in the
properties includefiles in the adm2/custom directory (i.e.
src/adm2/custom/datapropcustom.i). Now we switched from Dynamics 1.1 to
Dynamics 2 and I am facing the issue, that these custom properties are not
yet defined for the object type and in dynamics 2 the function
prepareInstance in the repository manager is responsible for defining the
adm-props temp-table rather than the code in the ...props.i files.
I could add these properties to the default object type but that would cause
a modification of the original object type definition. Something the
Dynamics Configuration Utility DCU tried to prevend by adding the
..._SITE_ classes to the repository where changes where made to
default object types.
I could create an sdo_SITE_1511 (our sitecode) object type myself as an
object extending the sdo object type and add my custom attributes to that
type. I guess that might work, but then these properties would only be
available for sdos of that object type.
This would cause issues with the code in my datacustom.p running for ALL
sdos. I could try to make the code depend on the object type or invent a
separate super procedure for my sdo objects which would require the change
of the include file referenced in all my sdos.
What is the proposed way of dealing with custom object properties (of static
objcet) when migrating an application from plain adm2 or Dynamics 1.1 to
Dynamics 2.
Any help appreciated,
Mike
mike fechner it consulting
Breite Str. 116
50667 Köln
Germany
Tel.: +49 (0) 221 / 27 609-40
Fax.: +49 (0) 221 / 27 609-41
Mobil: +49 (0) 160 / 700 82 29
mike.fechner@fechner.de
www.fechner.de
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
Hi Mike,
Have you tried extending the Data class rather than the SDO class? The "data_SITE_1511" would be functionally equivalent to the static datacustom class.
Regards,
Peter
|-Original Message-
|Sent: Monday, January 27, 2003 10:27 AM
|To: dev@icf.possenet.org
|Subject: How to deal with properties from adm2 custom classes
|
|
|Hi,
|
|in our development environment we had several properties
|defined in the properties includefiles in the adm2/custom
|directory (i.e. src/adm2/custom/datapropcustom.i). Now we
|switched from Dynamics 1.1 to Dynamics 2 and I am facing the
|issue, that these custom properties are not yet defined for
|the object type and in dynamics 2 the function prepareInstance
|in the repository manager is responsible for defining the
|adm-props temp-table rather than the code in the ...props.i files.
|
|I could add these properties to the default object type but
|that would cause a modification of the original object type
|definition. Something the Dynamics Configuration Utility DCU
|tried to prevend by adding the ..._SITE_classes to
|the repository where changes where made to default object types.
|
|I could create an sdo_SITE_1511 (our sitecode) object type
|myself as an object extending the sdo object type and add my
|custom attributes to that type. I guess that might work, but
|then these properties would only be available for sdos of that
|object type.
|
|This would cause issues with the code in my datacustom.p
|running for ALL sdos. I could try to make the code depend on
|the object type or invent a separate super procedure for my
|sdo objects which would require the change of the include file
|referenced in all my sdos.
|
|What is the proposed way of dealing with custom object
|properties (of static
|objcet) when migrating an application from plain adm2 or
|Dynamics 1.1 to Dynamics 2.
|
|Any help appreciated,
|Mike
|
|
|
|mike fechner it consulting
|Breite Str. 116
|50667 Köln
|Germany
|
|Tel.: +49 (0) 221 / 27 609-40
|Fax.: +49 (0) 221 / 27 609-41
|Mobil: +49 (0) 160 / 700 82 29
|
|mike.fechner@fechner.de
|www.fechner.de
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
Hi Peter,
I haven't yet tried to extend the data or sdo class. From my understanding
it would not make any difference for my propblem if I extend the data or the
sdo class as the sdo class is derived from data and sdo does not add any
property at all.
The difference to the plain adm2 datapropcustom.i file is that in adm2 all
sdos (those delivered with dynamics and my own sdos) hold these properties
in the adm-props temptable record. The code in datacustom.p is also running
for all these objects. In progress adm2 changes made in custom files were
available for all objects and now we strongly depend on the object type (for
properties at least and super-procedures might strongly depend on those
properties).
Now I feel like I have to either change the code in datacustom.p to check
for the object type (and object types derived from my custom object type) or
change the super-procedure of all my sdos.
As I guess we are not the only developers triing to migrate an application
with custom properties to dynamics 2 there should be a standard procedure
with steps to follow delivered from progress as a white paper or something
in the release notes or anything else.
Regards,
Mike
-Ursprüngliche Nachricht-
Gesendet: Montag, 27. Januar 2003 10:30
An: dev@icf.possenet.org
Betreff: RE: How to deal with properties from adm2 custom
classes
Hi Mike,
Have you tried extending the Data class rather than the SDO class? The
"data_SITE_1511" would be functionally equivalent to the static datacustom
class.
Regards,
Peter
|-Original Message-
|Sent: Monday, January 27, 2003 10:27 AM
|To: dev@icf.possenet.org
|Subject: How to deal with properties from adm2 custom classes
|
|
|Hi,
|
|in our development environment we had several properties
|defined in the properties includefiles in the adm2/custom
|directory (i.e. src/adm2/custom/datapropcustom.i). Now we
|switched from Dynamics 1.1 to Dynamics 2 and I am facing the
|issue, that these custom properties are not yet defined for
|the object type and in dynamics 2 the function prepareInstance
|in the repository manager is responsible for defining the
|adm-props temp-table rather than the code in the ...props.i files.
|
|I could add these properties to the default object type but
|that would cause a modification of the original object type
|definition. Something the Dynamics Configuration Utility DCU
|tried to prevend by adding the ..._SITE_classes to
|the repository where changes where made to default object types.
|
|I could create an sdo_SITE_1511 (our sitecode) object type
|myself as an object extending the sdo object type and add my
|custom attributes to that type. I guess that might work, but
|then these properties would only be available for sdos of that
|object type.
|
|This would cause issues with the code in my datacustom.p
|running for ALL sdos. I could try to make the code depend on
|the object type or invent a separate super procedure for my
|sdo objects which would require the change of the include file
|referenced in all my sdos.
|
|What is the proposed way of dealing with custom object
|properties (of static
|objcet) when migrating an application from plain adm2 or
|Dynamics 1.1 to Dynamics 2.
|
|Any help appreciated,
|Mike
|
|
|
|mike fechner it consulting
|Breite Str. 116
|50667 Köln
|Germany
|
|Tel.: +49 (0) 221 / 27 609-40
|Fax.: +49 (0) 221 / 27 609-41
|Mobil: +49 (0) 160 / 700 82 29
|
|mike.fechner@fechner.de
|www.fechner.de
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
Hi Mike,
We converted to V2 without any problem. We added the properties of
datapropcustum.i to the data class. I think adding them to the sdo will work
as well.
What I remember is that I had to restart my session after adding the
properties to the classes.
Frank
-Original Message-
Sent: Monday, January 27, 2003 10:49
To: dev@icf.possenet.org
Subject: AW: How to deal with properties from adm2 custom classes
Hi Peter,
I haven't yet tried to extend the data or sdo class. From my understanding
it would not make any difference for my propblem if I extend the data or the
sdo class as the sdo class is derived from data and sdo does not add any
property at all.
The difference to the plain adm2 datapropcustom.i file is that in adm2 all
sdos (those delivered with dynamics and my own sdos) hold these properties
in the adm-props temptable record. The code in datacustom.p is also running
for all these objects. In progress adm2 changes made in custom files were
available for all objects and now we strongly depend on the object type (for
properties at least and super-procedures might strongly depend on those
properties).
Now I feel like I have to either change the code in datacustom.p to check
for the object type (and object types derived from my custom object type) or
change the super-procedure of all my sdos.
As I guess we are not the only developers triing to migrate an application
with custom properties to dynamics 2 there should be a standard procedure
with steps to follow delivered from progress as a white paper or something
in the release notes or anything else.
Regards,
Mike
-Ursprüngliche Nachricht-
Gesendet: Montag, 27. Januar 2003 10:30
An: dev@icf.possenet.org
Betreff: RE: How to deal with properties from adm2 custom classes
Hi Mike,
Have you tried extending the Data class rather than the SDO class? The
"data_SITE_1511" would be functionally equivalent to the static datacustom
class.
Regards,
Peter
|-Original Message-
|Sent: Monday, January 27, 2003 10:27 AM
|To: dev@icf.possenet.org
|Subject: How to deal with properties from adm2 custom classes
|
|
|Hi,
|
|in our development environment we had several properties defined in the
|properties includefiles in the adm2/custom directory (i.e.
|src/adm2/custom/datapropcustom.i). Now we switched from Dynamics 1.1 to
|Dynamics 2 and I am facing the issue, that these custom properties are
|not yet defined for the object type and in dynamics 2 the function
|prepareInstance in the repository manager is responsible for defining
|the adm-props temp-table rather than the code in the ...props.i files.
|
|I could add these properties to the default object type but that would
|cause a modification of the original object type definition. Something
|the Dynamics Configuration Utility DCU tried to prevend by adding the
|..._SITE_classes to the repository where changes where made
|to default object types.
|
|I could create an sdo_SITE_1511 (our sitecode) object type myself as an
|object extending the sdo object type and add my custom attributes to
|that type. I guess that might work, but then these properties would
|only be available for sdos of that object type.
|
|This would cause issues with the code in my datacustom.p running for
|ALL sdos. I could try to make the code depend on the object type or
|invent a separate super procedure for my sdo objects which would
|require the change of the include file referenced in all my sdos.
|
|What is the proposed way of dealing with custom object properties (of
|static
|objcet) when migrating an application from plain adm2 or Dynamics 1.1
|to Dynamics 2.
|
|Any help appreciated,
|Mike
|
|
|
|mike fechner it consulting
|Breite Str. 116
|50667 Köln
|Germany
|
|Tel.: +49 (0) 221 / 27 609-40
|Fax.: +49 (0) 221 / 27 609-41
|Mobil: +49 (0) 160 / 700 82 29
|
|mike.fechner@fechner.de
|www.fechner.de
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
Hi Frank,
I guess that would work, but then you have a modified object type definition
in your repository.
We had several changes to the default object types in our dynamics 1.1
environment. The update routines to Dynamics 2 (Dynamics configuration
utility) created _SITE_1511 (our sitecode) object types and moved all
our modified objects to these types as Progress (i.e. Anthony Swindells)
does not recommend changes to the default object types.
Following this approach from progress I am looking for a standard way of
dealing with the custom properties.
Regards,
Mike
-Ursprüngliche Nachricht-
Gesendet: Montag, 27. Januar 2003 10:55
An: 'dev@icf.possenet.org'
Betreff: RE: How to deal with properties from adm2 custom
classes
Hi Mike,
We converted to V2 without any problem. We added the properties of
datapropcustum.i to the data class. I think adding them to the sdo will work
as well.
What I remember is that I had to restart my session after adding the
properties to the classes.
Frank
-Original Message-
Sent: Monday, January 27, 2003 10:49
To: dev@icf.possenet.org
Subject: AW: How to deal with properties from adm2 custom classes
Hi Peter,
I haven't yet tried to extend the data or sdo class. From my understanding
it would not make any difference for my propblem if I extend the data or the
sdo class as the sdo class is derived from data and sdo does not add any
property at all.
The difference to the plain adm2 datapropcustom.i file is that in adm2 all
sdos (those delivered with dynamics and my own sdos) hold these properties
in the adm-props temptable record. The code in datacustom.p is also running
for all these objects. In progress adm2 changes made in custom files were
available for all objects and now we strongly depend on the object type (for
properties at least and super-procedures might strongly depend on those
properties).
Now I feel like I have to either change the code in datacustom.p to check
for the object type (and object types derived from my custom object type) or
change the super-procedure of all my sdos.
As I guess we are not the only developers triing to migrate an application
with custom properties to dynamics 2 there should be a standard procedure
with steps to follow delivered from progress as a white paper or something
in the release notes or anything else.
Regards,
Mike
-Ursprüngliche Nachricht-
Gesendet: Montag, 27. Januar 2003 10:30
An: dev@icf.possenet.org
Betreff: RE: How to deal with properties from adm2 custom classes
Hi Mike,
Have you tried extending the Data class rather than the SDO class? The
"data_SITE_1511" would be functionally equivalent to the static datacustom
class.
Regards,
Peter
|-Original Message-
|Sent: Monday, January 27, 2003 10:27 AM
|To: dev@icf.possenet.org
|Subject: How to deal with properties from adm2 custom classes
|
|
|Hi,
|
|in our development environment we had several properties defined in the
|properties includefiles in the adm2/custom directory (i.e.
|src/adm2/custom/datapropcustom.i). Now we switched from Dynamics 1.1 to
|Dynamics 2 and I am facing the issue, that these custom properties are
|not yet defined for the object type and in dynamics 2 the function
|prepareInstance in the repository manager is responsible for defining
|the adm-props temp-table rather than the code in the ...props.i files.
|
|I could add these properties to the default object type but that would
|cause a modification of the original object type definition. Something
|the Dynamics Configuration Utility DCU tried to prevend by adding the
|..._SITE_classes to the repository where changes where made
|to default object types.
|
|I could create an sdo_SITE_1511 (our sitecode) object type myself as an
|object extending the sdo object type and add my custom attributes to
|that type. I guess that might work, but then these properties would
|only be available for sdos of that object type.
|
|This would cause issues with the code in my datacustom.p running for
|ALL sdos. I could try to make the code depend on the object type or
|invent a separate super procedure for my sdo objects which would
|require the change of the include file referenced in all my sdos.
|
|What is the proposed way of dealing with custom object properties (of
|static
|objcet) when migrating an application from plain adm2 or Dynamics 1.1
|to Dynamics 2.
|
|Any help appreciated,
|Mike
|
|
|
|mike fechner it consulting
|Breite Str. 116
|50667 Köln
|Germany
|
|Tel.: +49 (0) 221 / 27 609-40
|Fax.: +49 (0) 221 / 27 609-41
|Mobil: +49 (0) 160 / 700 82 29
|
|mike.fechner@fechner.de
|www.fechner.de
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
Hi Mike,
In theory the _SITE_is the way to go - and it should be in practice, too. I am playing around with this a bit. I have manually created a custom class that extends the Data class and have added an attribute to is. It looks like the attribute is in the class TT in the Repository (correct). However, for some reason it looks like this is not in the ADM Props TT - which it should be.
I need to look a bit further into it, and I will log an issue if necessary.
Regards,
Peter
|-Original Message-
|Sent: Monday, January 27, 2003 11:07 AM
|To: dev@icf.possenet.org
|Subject: AW: How to deal with properties from adm2
|custom classes
|
|
|Hi Frank,
|
|I guess that would work, but then you have a modified object
|type definition
|in your repository.
|
|We had several changes to the default object types in our dynamics 1.1
|environment. The update routines to Dynamics 2 (Dynamics configuration
|utility) created _SITE_1511 (our sitecode) object types
|and moved all
|our modified objects to these types as Progress (i.e. Anthony
|Swindells)
|does not recommend changes to the default object types.
|
|Following this approach from progress I am looking for a
|standard way of
|dealing with the custom properties.
|
|Regards,
|Mike
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
Hi Mike,
After some more investigation I have found that the property is in both the Repository class TT and the ADMProps TT. I realised that the Procedure Object Viewer ProTool doesn't necessarily show all of the fields in the ADMProps TT.
If the attributes are correctly defined in the Repository, the ADMProps TT that is constructed by prepareInstance() will be identical to the ADMProps TT constructed statically by the compilation of the *prop.i files into the various objects. Once the TT is constructed, it makes no difference to the ADM how it was constructed.
The structure of the classes in the Repository and in particular the Base class and those classes that inherit from it, should match as closely as possible the ADM2 class structure. This is why I suggested that your custom class extend the Data class and not the SDO class.
Incidentally, in another email Frank Arnold has a good point, although you can run the destroyClassCache() API in the Repository Manager to achieve the same thing without the need to shut the whole sesison down. This API clears the Repository cache and then destroys the dynamic TTs that make up the class cache. These TTs are rebuild as and when the class is requested.
| In progress adm2 changes made in custom files were
|available for all objects and now we strongly depend on the
|object type (for properties at least and super-procedures
|might strongly depend on those properties).
How do these dependencies on the object types work?
|Now I feel like I have to either change the code in
|datacustom.p to check for the object type (and object types
|derived from my custom object type) or change the
|super-procedure of all my sdos.
If there are dependencies on the object type, you can check whether an object belongs to a particular class using instanceOf() API. This is an ADM2 function in smart.p that determines whether an ADM object belongs to a particular class or not. This API allows you to check whether a class inherits from, say, the 'SDO' class even though it actually belongs to the 'sdo_SITE_1511' class.
HTH,
Peter
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
Hi Peter,
thanks for your remarks. Actually what you we're writing is one of my
suggestions. What I'd like to know now is, if that is the way Progress
proposes or if it just one way to go. If this is the way progress proposes I
expect progress (or all possenet developers) to take care of this in future
versions.
I'd like to know that before I change all my sdos to a data_SITE_1511 oder
sdo_SITE_1511 class.
Regareds,
Mike
-Ursprüngliche Nachricht-
Gesendet: Montag, 27. Januar 2003 12:30
An: dev@icf.possenet.org
Betreff: RE: How to deal with properties from adm2 custom
classes
Hi Mike,
After some more investigation I have found that the property is in both the
Repository class TT and the ADMProps TT. I realised that the Procedure
Object Viewer ProTool doesn't necessarily show all of the fields in the
ADMProps TT.
If the attributes are correctly defined in the Repository, the ADMProps TT
that is constructed by prepareInstance() will be identical to the ADMProps
TT constructed statically by the compilation of the *prop.i files into the
various objects. Once the TT is constructed, it makes no difference to the
ADM how it was constructed.
The structure of the classes in the Repository and in particular the Base
class and those classes that inherit from it, should match as closely as
possible the ADM2 class structure. This is why I suggested that your custom
class extend the Data class and not the SDO class.
Incidentally, in another email Frank Arnold has a good point, although you
can run the destroyClassCache() API in the Repository Manager to achieve the
same thing without the need to shut the whole sesison down. This API clears
the Repository cache and then destroys the dynamic TTs that make up the
class cache. These TTs are rebuild as and when the class is requested.
| In progress adm2 changes made in custom files were
|available for all objects and now we strongly depend on the
|object type (for properties at least and super-procedures
|might strongly depend on those properties).
How do these dependencies on the object types work?
|Now I feel like I have to either change the code in
|datacustom.p to check for the object type (and object types
|derived from my custom object type) or change the
|super-procedure of all my sdos.
If there are dependencies on the object type, you can check whether an
object belongs to a particular class using instanceOf() API. This is an
ADM2 function in smart.p that determines whether an ADM object belongs to a
particular class or not. This API allows you to check whether a class
inherits from, say, the 'SDO' class even though it actually belongs to the
'sdo_SITE_1511' class.
HTH,
Peter
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
Hi Peter,
one thing I have to add: Unfortunately I have to migrate all of my sdos to
sdo_SITE_1511 objects. I can't migrate to data_SITE_1511 as that would cause
a change of the objects code subtype in roundtable which is not possible. So
the theory of deriving the class from the base class is stopped by the
practical roundtable integration and the problem that roundtable does not
support a change of objects code subtypes.
Regards,
Mike
-Ursprüngliche Nachricht-
Gesendet: Montag, 27. Januar 2003 13:05
An: dev@icf.possenet.org
Betreff: AW: How to deal with properties from adm2 custom
classes
Hi Peter,
thanks for your remarks. Actually what you we're writing is one of my
suggestions. What I'd like to know now is, if that is the way Progress
proposes or if it just one way to go. If this is the way progress proposes I
expect progress (or all possenet developers) to take care of this in future
versions.
I'd like to know that before I change all my sdos to a data_SITE_1511 oder
sdo_SITE_1511 class.
Regareds,
Mike
-Ursprüngliche Nachricht-
Gesendet: Montag, 27. Januar 2003 12:30
An: dev@icf.possenet.org
Betreff: RE: How to deal with properties from adm2 custom
classes
Hi Mike,
After some more investigation I have found that the property is in both the
Repository class TT and the ADMProps TT. I realised that the Procedure
Object Viewer ProTool doesn't necessarily show all of the fields in the
ADMProps TT.
If the attributes are correctly defined in the Repository, the ADMProps TT
that is constructed by prepareInstance() will be identical to the ADMProps
TT constructed statically by the compilation of the *prop.i files into the
various objects. Once the TT is constructed, it makes no difference to the
ADM how it was constructed.
The structure of the classes in the Repository and in particular the Base
class and those classes that inherit from it, should match as closely as
possible the ADM2 class structure. This is why I suggested that your custom
class extend the Data class and not the SDO class.
Incidentally, in another email Frank Arnold has a good point, although you
can run the destroyClassCache() API in the Repository Manager to achieve the
same thing without the need to shut the whole sesison down. This API clears
the Repository cache and then destroys the dynamic TTs that make up the
class cache. These TTs are rebuild as and when the class is requested.
| In progress adm2 changes made in custom files were
|available for all objects and now we strongly depend on the
|object type (for properties at least and super-procedures
|might strongly depend on those properties).
How do these dependencies on the object types work?
|Now I feel like I have to either change the code in
|datacustom.p to check for the object type (and object types
|derived from my custom object type) or change the
|super-procedure of all my sdos.
If there are dependencies on the object type, you can check whether an
object belongs to a particular class using instanceOf() API. This is an
ADM2 function in smart.p that determines whether an ADM object belongs to a
particular class or not. This API allows you to check whether a class
inherits from, say, the 'SDO' class even though it actually belongs to the
'sdo_SITE_1511' class.
HTH,
Peter
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
Hi Mike,
I would recommend that your custom attributes are kept in a separate class from the default attributes. This is valid for both new attributes AND attribute values which are specific to your site. For example, you may decide to change RowsToBatch to 50 (instead of the std 200). This attribute value should be set against your custom class.
The reason why a separate, custom class is recommended is because of issues with data deployment. It becomes extremely difficult (if not impossible) to determine which attributes are custom attributes and which are the default values. This problem is compounded when the default attribute values are being changed at the same time (I think I have the broad outlines of this right).
I also think that it is a good idea to keep your custom stuff (code or data) separate from the std Dynamics stuff.
This is the way I would do it, personally. The fact that the DCU creates new classes seems to indicate that this is the Dynamics recommended way.
HTH,
Peter
|-Original Message-
|Sent: Monday, January 27, 2003 1:05 PM
|To: dev@icf.possenet.org
|Subject: AW: How to deal with properties from adm2
|custom classes
|
|
|Hi Peter,
|
|thanks for your remarks. Actually what you we're writing is
|one of my suggestions. What I'd like to know now is, if that
|is the way Progress proposes or if it just one way to go. If
|this is the way progress proposes I expect progress (or all
|possenet developers) to take care of this in future versions.
|
|I'd like to know that before I change all my sdos to a
|data_SITE_1511 oder sdo_SITE_1511 class.
|
|Regareds,
|Mike
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
Hi Mike,
To the best of my understanding, the Dynamics Roundtable implementation caters for the _SITE_classes and ensures that you don't have to change code subtypes for these classes. This is why these extended classes are named in this way.
However, I am not the best qualified to answer Roundtable questions and so there is a (very slight ) chance that I am wrong.
HTH,
Peter
|-Original Message-
|Sent: Monday, January 27, 2003 1:26 PM
|To: dev@icf.possenet.org
|Subject: AW: How to deal with properties from adm2
|custom classes
|
|
|Hi Peter,
|
|one thing I have to add: Unfortunately I have to migrate all
|of my sdos to sdo_SITE_1511 objects. I can't migrate to
|data_SITE_1511 as that would cause a change of the objects
|code subtype in roundtable which is not possible. So the
|theory of deriving the class from the base class is stopped by
|the practical roundtable integration and the problem that
|roundtable does not support a change of objects code subtypes.
|
|Regards,
|Mike
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
Mike/Peter
Having read this thread briefly - I think you guys are missing each
other slightly.
Peter is correct that you should make your customizations in a custom
object type below data, so data_SITE_1511. Because SDO inherits from
data, subclassing data should do the trick I think - Peter, can you
confirm how I subclass within the middle of the class Hierarchy.
If you subclass at this level, you will not need to change any object
types - you can leave them all as SDO.
Regarding Roundtable, you are correct you could not change from sdo to
data, but you should not have to. It is ok however to change to a
different type with siten because this is stripped off to fix the
Roundtable issues, but the first part of the object type must be the
same.
Finally, a utility does exist to move objects from one object type to
another, so if the DCU moved your SDO's to your new subclass, you could
easily move them back with this utility as a batch lot - I believe it is
mentioned in the release notes.
It is quite different how you go about customizing things in V2 than V1.
John Sadd is giving a talk on this very subject at Exchange, and I
expect a whitepaper will also be delivered further clarifying the
Progress prescribed approach.
HTH
Anthony
Anthony D Swindells
Engineering Fellow and Lead Architect for Progress Dynamics
Progress Software Corporation http://www.progress.com
aswindel@progress.com
-Original Message-
Sent: January 27, 2003 7:30 AM
To: dev@icf.possenet.org
Subject: RE: How to deal with properties from adm2 custom
classes
Hi Mike,
To the best of my understanding, the Dynamics Roundtable implementation
caters for the _SITE_classes and ensures that you don't
have to change code subtypes for these classes. This is why these
extended classes are named in this way.
However, I am not the best qualified to answer Roundtable questions and
so there is a (very slight ) chance that I am wrong.
HTH,
Peter
|-Original Message-
|Sent: Monday, January 27, 2003 1:26 PM
|To: dev@icf.possenet.org
|Subject: AW: How to deal with properties from adm2
|custom classes
|
|
|Hi Peter,
|
|one thing I have to add: Unfortunately I have to migrate all
|of my sdos to sdo_SITE_1511 objects. I can't migrate to
|data_SITE_1511 as that would cause a change of the objects
|code subtype in roundtable which is not possible. So the
|theory of deriving the class from the base class is stopped by
|the practical roundtable integration and the problem that
|roundtable does not support a change of objects code subtypes.
|
|Regards,
|Mike
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
Hi Anthony,
I do not have the issue you described at the end. The DCU did not move my
sdos to a new class as the differences in classes were defined in source
code and not in repository object types. I am talking mainly about static
sdos.
So before deciding to what class to move my sdos to is more important than
how to move them there. Maybe to subclassing in the middle of the class
hierarchy might be a chance as well.
Just told of the exchange presentation and white paper. Are there drafts
available of those today?
Thanks,
Mike
-Ursprungliche Nachricht-
Gesendet: Montag, 27. Januar 2003 13:46
An: dev@icf.possenet.org
Cc: 'Peter Judge'; 'Bruce Gruenbaum'; 'Haavard Danielsen'
Betreff: RE: How to deal with properties from adm2 custom
classes
Mike/Peter
Having read this thread briefly - I think you guys are missing each
other slightly.
Peter is correct that you should make your customizations in a custom
object type below data, so data_SITE_1511. Because SDO inherits from
data, subclassing data should do the trick I think - Peter, can you
confirm how I subclass within the middle of the class Hierarchy.
If you subclass at this level, you will not need to change any object
types - you can leave them all as SDO.
Regarding Roundtable, you are correct you could not change from sdo to
data, but you should not have to. It is ok however to change to a
different type with siten because this is stripped off to fix the
Roundtable issues, but the first part of the object type must be the
same.
Finally, a utility does exist to move objects from one object type to
another, so if the DCU moved your SDO's to your new subclass, you could
easily move them back with this utility as a batch lot - I believe it is
mentioned in the release notes.
It is quite different how you go about customizing things in V2 than V1.
John Sadd is giving a talk on this very subject at Exchange, and I
expect a whitepaper will also be delivered further clarifying the
Progress prescribed approach.
HTH
Anthony
Anthony D Swindells
Engineering Fellow and Lead Architect for Progress Dynamics
Progress Software Corporation http://www.progress.com
aswindel@progress.com
-Original Message-
Sent: January 27, 2003 7:30 AM
To: dev@icf.possenet.org
Subject: RE: How to deal with properties from adm2 custom
classes
Hi Mike,
To the best of my understanding, the Dynamics Roundtable implementation
caters for the _SITE_classes and ensures that you don't
have to change code subtypes for these classes. This is why these
extended classes are named in this way.
However, I am not the best qualified to answer Roundtable questions and
so there is a (very slight ) chance that I am wrong.
HTH,
Peter
|-Original Message-
|Sent: Monday, January 27, 2003 1:26 PM
|To: dev@icf.possenet.org
|Subject: AW: How to deal with properties from adm2
|custom classes
|
|
|Hi Peter,
|
|one thing I have to add: Unfortunately I have to migrate all
|of my sdos to sdo_SITE_1511 objects. I can't migrate to
|data_SITE_1511 as that would cause a change of the objects
|code subtype in roundtable which is not possible. So the
|theory of deriving the class from the base class is stopped by
|the practical roundtable integration and the problem that
|roundtable does not support a change of objects code subtypes.
|
|Regards,
|Mike
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
Hi Mike,
| Maybe to subclassing in the middle of the class hierarchy might be a chance as well.
There is nothing to stop you sub-classing anywhere in the class heirarchy. This is what I am doing when I say:
|I have manually created a custom class that extends the
|Data class and have added an attribute to is.
I landed up with a heirarchy that looks like:
...
- Data
- data_SITE_84
- attributes
- myCustomDataAttribute
- SDO
- DynSDO
If you then add the properties that appear in your datacustprop.i file as attributes under the data_SITE_* then you should be OK, and not need to migrate you SDO objects, since the SDO and dynSDO classes inherit from data_SITE_*.
I had to manually update the "Extends Object Type" field of the dynSDO and SDO classes so that they extended the new data_SITE_* class (rather than the Data class), but that was all I needed to so. Just run destroyClassCache() or restart your session and everything should work fine.
Regards,
Peter
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
Hi Anthony, Hi Peter,
I guess this will work and it seems like a very practical approach so I
think I will goes this way.
In theory I am not so lucky with that solution as it ends up in custom
attributes in objects of the standard object types. Speaking of deployment I
guess that this way I will be able to deliver sdos with custom attributes to
other repositories that do not know the attributes.
I am really interested in any documentation/instructions from progress about
how to deal with this!
Regards,
Mike
-Ursprüngliche Nachricht-
Gesendet: Montag, 27. Januar 2003 14:00
An: dev@icf.possenet.org
Betreff: RE: How to deal with properties from adm2 custom
classes
Hi Mike,
| Maybe to subclassing in the middle of the class hierarchy might be a
chance as well.
There is nothing to stop you sub-classing anywhere in the class heirarchy.
This is what I am doing when I say:
|I have manually created a custom class that extends the
|Data class and have added an attribute to is.
I landed up with a heirarchy that looks like:
...
- Data
- data_SITE_84
- attributes
- myCustomDataAttribute
- SDO
- DynSDO
If you then add the properties that appear in your datacustprop.i file as
attributes under the data_SITE_* then you should be OK, and not need to
migrate you SDO objects, since the SDO and dynSDO classes inherit from
data_SITE_*.
I had to manually update the "Extends Object Type" field of the dynSDO and
SDO classes so that they extended the new data_SITE_* class (rather than the
Data class), but that was all I needed to so. Just run destroyClassCache()
or restart your session and everything should work fine.
Regards,
Peter
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org