Re: [sdo] [NEW ISSUE] New DataObject method: cast()

[Frank Budinsky <frankb@ca.ibm.com>]

Hi Blaise,

For Issue 1, I think the SDO metadata would be annotated with the 
appropriate mapping information and I agree that we need to figure out the 
behavior for the case of more than one binding.

For issue 2, I think all views need to be kept in sync. That said, I don't 
think that all implementations need to support all possible views, and 
especially not concurrently.

I'm OK with discussing the technology alignment first, as long as we can 
make progress on it soon. This is pretty high priority issue for us. How 
soon do you think you can share your HelperContext ideas?

Thanks,
Frank




Blaise Doughan <blaise.doughan@oracle.com> 
06/12/2008 10:04 AM

To
sdo@lists.oasis-open.org
cc

Subject
Re: [sdo] [NEW ISSUE] New DataObject method: cast()






Hi Frank,

I can see the value in aligning DataObjects with other standards such as 
DOM, JAXB, and JPA.  I can also see several issues with the proposed cast 
operation, including:

Issue 1 - Casting to Java Objects
If model.Employee is annotated using both JAXB and JPA annotations, which 
metadata takes precedence.
JPA entities can have their metadata specified in XML files, this metadata 
cannot be determined from the Java class and would be unavailable during a 
cast operation.
JAXB objects are not required to be annotated (unlike JPA entities which 
are), would unannotated classes by default be treated by the JAXB rules or 
plain POJO rules.
Issue 2 - Multiple Casts
If you casted to a DOM Node class then obviously this DOM node would be 
involved in the XML marshalling process provided by XMLHelper.  The same 
would be true if a cast was made to JAXB objects, since currently both DOM 
and JAXB provide better XML representations than SDO.  Now if the user 
casted to both a DOM Node and a JAXB object how do you reconcile this 
during the marshal operation, or are the DOM nodes and JAXB objects kept 
in continuous sync with the DataObjects and each other?
My preference would be to work out a technology alignment story first, and 
then figure out how to expose the correct API (I have some ideas at how 
this can be done at the HelperContext rather than the DataObject level).

-Blaise

Frank Budinsky wrote: 
Hi Guys,

I would like to propose adding the following method to the DataObject 
interface:

    <T> T cast(Class<T> targetClass)

I'm not sure if the name should really be "cast" or "project" or something 

else, but I'm thinking "cast" may be best, since the intent is to get some 

other interface to work with and view the DataObject.

An implementation of this method will look something like this:

    public <T> T cast(Class<T> targetClass)
    { 
        if (targetClass.isInstance(this)) return (T)this;
        if (targetClass == Sequence.class && getType().isSequenced() 
return getSequence();
        // TBD other required or optional casts (e.g., maybe Node.class)
        // TBD implementation specific casts
        return null; //TBD maybe instead we should throw 
ClassCastException
    }

The idea behind this method is that it provides a single API for 
converting a DataObject to any other possible interface "view".

To get the Sequence view of a DataObject, a user would call:

    Sequence sequence = myDO.cast(Sequence.class);

To get the interface of a static SDO, you would call:

    Company company = myDO.cast(Company.class);

Using this API instead of simply using Java cast - (Company)myDO - has the 

advantage that we've opened up the door for different implementations of 
static SDO (e.g., a corresponding POJO) in the future where the static 
object and the DataObject are not required to be the same instance. This 
will be important when we get to the JAXB/JPA integration discussions.

Once this API is in place, we can think about other (required or optional) 

uses for it, such as using it to cast to Node.class (or something else) as 

a catch all for the XML Fidelity corner cases that we don't want to handle 

in SDO directly.

If we agree to add this new method, I think we should also deprecate 
getSequence(), which will have the added benefit of this issue not 
actually increasing the number of methods in the DataObject interface.

Thanks,
Frank.

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in 
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php