Em 11/01/11 23:41, Tim Cook escreveu:
> On Wed, 2011-01-12 at 00:40 +0000, Launchpad Bug Tracker wrote:
>> Title:
>> The PartyRef accepts refer any kind of object
>>
>> Status in Open Source Health Information Platform (OSHIP):
>> New
>>
>> Bug description:
>> The PartyRef must accept only refer objects which are considered
>> parties in a demographic or identity service. Into the range of
>> possibilities there are : PARTY, PERSON,ORGANISATION, ACTOR,
>> GROUP,ROLE and AGENT objects.
>> Abstract supertypes are also allowed if the referenced object is of
>> a type not known by the current implementation of this class (in other
>> words, if the demographic model is changed by the addition of a new
>> PARTY or ACTOR subtypes, valid PARTY_REFs can still be constructed to
>> them). Peharps object Introspection is the only way no fix it.
>
> No.
>
>
> Just be sure that all subtypes "provides" the IParty interface.
If we follow this approach, a circular import problem will be created:
The demographic module depends on identification module. That's why I
said the only way that I could imagine fix it is using object introspection.
In my opinion, the only expected design by the openEHR specs is pass all
PartyRef composite objects on the constructor method. I just include a
alternate construction mechansim because makes more sense to me pass the
referred object itself and retrieve the data from it, especially if you
want validate the object.
>
> --Tim
>
>
>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Em 11/01/11 23:41, Tim Cook escreveu: ORGANISATION, ACTOR,
> On Wed, 2011-01-12 at 00:40 +0000, Launchpad Bug Tracker wrote:
>> Title:
>> The PartyRef accepts refer any kind of object
>>
>> Status in Open Source Health Information Platform (OSHIP):
>> New
>>
>> Bug description:
>> The PartyRef must accept only refer objects which are considered
>> parties in a demographic or identity service. Into the range of
>> possibilities there are : PARTY, PERSON,
>> GROUP,ROLE and AGENT objects.
>> Abstract supertypes are also allowed if the referenced object is of
>> a type not known by the current implementation of this class (in other
>> words, if the demographic model is changed by the addition of a new
>> PARTY or ACTOR subtypes, valid PARTY_REFs can still be constructed to
>> them). Peharps object Introspection is the only way no fix it.
>
> No.
>
>
> Just be sure that all subtypes "provides" the IParty interface.
If we follow this approach, a circular import problem will be created:
The demographic module depends on identification module. That's why I
said the only way that I could imagine fix it is using object introspection.
In my opinion, the only expected design by the openEHR specs is pass all
PartyRef composite objects on the constructor method. I just include a
alternate construction mechansim because makes more sense to me pass the
referred object itself and retrieve the data from it, especially if you
want validate the object.
>
> --Tim
>
>
>
-----BEGIN PGP SIGNATURE-----
NLaOeAAoJEEfarW n4YOc8EUUH/ 1/S0kGyX2nMM+ g/YlcqY2Ih xqrnqXhynyVwDYP g4OQGGM3T6igIH7 OBFqr1tEgl7eZXi s+BRz2Sh umWasBP0LJhK6G5 mgO81DNXTFmHHwx rLYvAQDRVvIc381 T63n QaDfzIguGPvatsP GZyZRbALAfSWmWH tqs4Q4U+ p5ukIVAcrsnF068 5nVh 9KNVNTnq0+ WftReok43JTEZiH 22J8yNH5tGw5idK KsOjNpmdE dqWraTWwXL1/ i469A3SBxyw8dSn nfQ99uyoUNtmtky iiTzCs=
Version: GnuPG v1.4.11 (Darwin)
iQEcBAEBAgAGBQJ
rnYJ/Ti4zt/
HGR5Dfzel8Ftseh
gpGWG9/
FG+5uy25xMCowXx
oeL7wYcpFCvoUI6
=ROjp
-----END PGP SIGNATURE-----