On 05/12/06, Simon Laws <[EMAIL PROTECTED]> wrote:
Hi Pete
Some comments in line...
On 12/5/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
>
> A number of SDO issues have come up over the past week regarding
sequenced
> data objects. I think the current implementation is incorrect in a
number
> of
> ways.
>
> For a sequenced data object you can use the "sequence api" to get/set
the
> values of properties in the sequence. You can also use the standard
setXXX
> methods on DataObject to set the properties. If you do this, however,
then
> the values are not added to the sequence. This is incorrect.
Agreed, sequence should just be a view on the DO so data shouldn't appear
in
one and not the other.
The sequence is a sequence of 'elements' in XML terms. Properties that are
> defined as attributes should be set using the normal setXXX methods and
> should NOT be added to the sequence. They will not be returned when
using
> the get methods from the sequence api.
I'm not sure how you define or identify a property as an attribute, other
then by reading in a schema, but it sounds a little complicated to ask the
user to make the decision.
If the user decides to define Types and Properties programmatically then he
is the only one that can make the decision as to how it should be
serialized. This control is, I believe, added in to the Java and C++ spec
APIs now. If the Types/Properties are defined using a schema then the
XSDHelper will do this work for you.
Properties that are defined to an open type when loading a schemaless xml
> document should have PropertyInformation attached to indicate whether
the
> property is an attribute or element.
Agreed. Regardless of whether the type is open it can still have elements
and attributes in XML
Properties that are not defined via DataFactory::addPropertyToType should
be
> treated as elements and added to the sequence.
I don't understand this.
This is properties defined dynamically when setting a value on an Open type.
The CopyHelper will have to copy the sequenced SDO by using the sequence API
> and then using the DataObject getter/setted methods to copy properties
> that
> were xml attributes.
Can we remove this difference between sequences and DOs
I don't understand this.
Any other thoughts?
>
> --
> Pete
>
>
IMHO sequences feel a little strange in the way that they are articulated
in
the SDO API as it stands. It seems that the primary motivation for SDO is
unordered access to data based on type or property name. Sequenced access
stands out as an add on extra. From a users perspective I'd like a simpler
approach. For example, in PHP I might access a named property as:
// using object property accessor
$value = $myDO->prop1;
or
// using an associative array accessor
$value = $myDO['prop1'];
The PHP approach also allows iteration over objects so I could do:
foreach ( $myDO as $propName => $propValue ) {
echo $propName . " = " . $propValue;
}
The order here is naturally the order in which types are defined not the
order in which data is added. So far so good. SDO fits in well.
If though there is some underlying order of the property values then in
SDO
currently I would do something like
$sequence = $myDO->getSequence();
an then go ahead and use the $sequence as though it were the DO.
This is not so bad but I think it would be cleaner if the DO knew whether
it
was sequenced or not (It does already) and managed values through it's
interface based on this knowledge. I wouldn't then be faced with having to
decide where to add a piece of data, sequence or DO, based on whether I
though it might end up as an attribute or not when the time comes to
serialize the DO. I would expect the DO to sort this out for me.
Just my 2c
Simon
The sequence api is necessary for ordering of settings. I think I AM
proposing that the SDO code does manage the values so if you do
myDO->setInt("fred", 41); the SDO code delegates this to the sequence api
if myDO is sequenced.
--
Pete
