[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: ISSUE 130: New DataObject method: cast()
Hi Ron, Sorry I didn't provide the problem statement. This is what I had in mind: <BEGIN DESCRIPTION> An SDO Data Object is a data structure composed of named properties. The DataObject interface provides the primary standard Dynamic API for reading and manipulating the underlying data structure. However, a number of other interfaces provide alternate "views" of the same data structure: 1) Sequence.class - if the object's type isSequenced 2) a custom Java interface (e.g., Company.class) - if the type is static SDO Another possible view of a data object (currently implementation-dependent, but a possible future addition to the spec) would be a DOM view: 3) Node.class - if one wants to provide a 100% XML fidelity view of the underlying XML structure using an XML standard API The current approach for accessing alternate views is using specific APIs for each view: 1) DataObject.getSequence() to get the Sequence view 2) Java cast - e.g., (Company)myDO - for a static SDO view 3) If we want to get a Node view, then we'll need to add some new API for that - e.g., XMLHelper.getNode(myDO) This proposal suggests to instead provide a single uniform API for accessing any alternate view. This will have the advantage of simplicity (1 method for all) as well as extensibility for future supported (or even implementation dependent) views. <END DESCRIPTION> Now, to answer your questions (from below) Ron: 1) I'm not sure if we need to cast back from every possible view - if so, then we may want to add one or more APIs for that as well, but I think it's a separate issue. Note that Sequence currently doesn't provide a method to get back to the DataObject view - i.e., there is no Sequence.getDataObject() method. 2) I'm just saying this will "probably" be useful when we want to integrate with JAXB/JPA. It opens up the possibility of implementations supporting static using DataObject proxies, or similar, instead of byte-code insertion or specialized code generation to make sure that everything is done in a single instance. 3) JAXB is a static solution. If we want Dynamic SDO with 100% XML fidelity, we need something like Node. Note that I said "something like" - I'm open to other suggestions, but I think that since Node is "the standard XML API", we should consider using it. I hope this helps to clarify things. Thanks, Frank. "Barack, Ron" <ron.barack@sap.com> 06/12/2008 09:36 AM To Frank Budinsky/Toronto/IBM@IBMCA, <sdo@lists.oasis-open.org> cc Subject ISSUE 130: New DataObject method: cast() http://www.osoa.org/jira/browse/SDO-130 Hi Frank, I had a little trouble entering this into the JIRA: you make a proposal without stating what problem you would like to solve. Casting to Node isn't part of the proposal, so XMLFidelity isn't addressed, so what is the problem we are trying to solve? From your text I have extrapolated the following DESCRIPTION: Under SDO 2.1, clients obtain a reference to the static SDO by casting the DataObject, that is, the static SDO must be the same instance as the DataObject. This will be a problem when we do JPA/ JAXB integration. Is this correct? Now for some questions: 1) don't we need a symetric operation, one that allows you to go from the static SDO back to the DataObject (casting always worked in both directions)? 2) what is your justification is for the last assertion, that we need this for JPA/ JAXB integration? 3) Regarding casting to Node...Assuming we get JAXB integration to work (by the way, I think JAXB integration is much harder than JPA), doesn't that give us all the XMLFidelity we need? Which technology should we focus on integrating? Best Regards, Ron -----Ursprüngliche Nachricht----- Von: Frank Budinsky [mailto:frankb@ca.ibm.com] Gesendet: Donnerstag, 12. Juni 2008 00:06 An: sdo@lists.oasis-open.org Betreff: [sdo] [NEW ISSUE] New DataObject method: cast() 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]