Re: Which is a better approach to avoid polymorphism and inherita nce

[Anne Thomas Manes <at...@gmail.com>]

Sorry -- I mistyped...

Does the ContentRealization indicate the content type?

Anne

On Apr 8, 2005 5:56 PM, Soti, Dheeraj <ds...@harris.com> wrote:
> Anne,
> 
> The ContentRealization do have an Id. Each "Content" contains an array of
> ContentRealization and each ContentRealization refers to its parent Content with
> an Id (Please note this Id can be for a Content which is different from the one
> that contains it). So my problem is that if the client is going to generate
> client side classes using the WSDL then the findByXXX() methods have to know
> what type of class to return ProgramContent or CommercialContent. I have to
> specify the return type as output message of my operations in WSDL.
> 
> Even there are multiple implementations of ContentRealization so while defining
> the "Content" I have to somehow specify the type of the array to tell which type
> of ContentRealization it is.
> 
>                         0..n
> Content ---------------->ContentRealization
> 
>                            ContentRealization
>                                   ^
>                                   |
>                                   |
>               -------------------------------------------
>               ^                                          ^
>               |                                          |
>               |                             0..n         |
>           ContentRealizationType1---------------ContentRealizationType2
> 
> Basically I have to flatten out the whole object model into an XML schema. That
> includes handling inheritance, polymorphism, cyclic loops.
> 
> Thanks
> 
> Dheeraj
> 
> 
> -----Original Message-----
> From: Anne Thomas Manes [mailto:atmanes@gmail.com]
> 
> Sent: Friday, April 08, 2005 4:05 PM
> To: Hittesdorf,Michael
> Subject: Re: Which is a better approach to avoid polymorphism and inheritance
> 
> Nice idea, but you should avoid <xsd:choice> groups.
> 
> Could you put an Id attribute into the ContentRealization type? That way the
> client knows ahead of time what type to request.
> 
> Anne
> 
> On Apr 8, 2005 4:14 PM, Dheeraj,Soti <ds...@harris.com>
> wrote:
> Anne,
> 
> Thanks for getting back to me.
> 
> I also like the first approach (because of clarity) but it is going to make the
> life of the clients pretty difficult. E.g. I have another complex type
> "ContentRealization" that keeps a reference to the parent "Content
> (Program/Commercial)" with an Id. Now the client gets hold of this
> "ContentRealization" and wants to fetch the details of the "Content" associated
> with it. At this point it might not even know that whether this Id is for a
> ProgramContent or a CommercialContent so which find method he'll use.
> findProgramContentById() or findCommercialContentById()
> 
> I feel that I didn't explained the second approach well.
> 
> ProgramContent has fields F1, F2, F3
> CommercialContent has fields F1, F2 and F4
> 
> So I'll create a new APIContent with fields F1, F2, F3, F4, Type. I'll define
> the type as an enumeration of Program and Commercial in the WSDL. So the client
> will populate the appropriate fields in the model based on the "type" and create
> the content using a createContent(APIContent). Based on the "type" the service
> layer can construct the appropriate internal model. The client can just issue
> findXXX() commands and the service layer will return the APIContent with the
> proper type set.
> 
> I thought of using xsd:anyType also but I read at some places that the
> implementation of this is optional as per the specification and I have to make
> sure that the service is interoperable.
> 
> Thanks
> 
> Dheeraj
> 
> > -----Original Message-----
> > From: Anne Thomas Manes [mailto:atmanes@gmail.com]
> > Sent: Friday, April 08, 2005 2:49 PM
> > To: axis-user@ws.apache.org
> > Subject: Re: Which is a better approach to avoid polymorphism and
> > inheritance
> >
> 
> > Definitely go with the first approach. JAX-RPC does not require
> > support for <xsd:union>, and very few products support it.
> >
> 
> > Anne
> >
> 
> > On Apr 6, 2005 4:36 PM, Soti, Dheeraj <ds...@harris.com> wrote:
> > >
> > >
> > > Hi,
> > >
> > > I have class structure like as shown below. I am using doc/literal
> > wrapped
> > > style and I don't want to expose concepts like polymorphism,
> > inheritance and
> > > overloading in my service methods. There are two ways to handle
> this:
> > > Define two different complex elements for each type of content. The
> > > advantage is its very clear and simple. The disadvantage is that
> there
> > are
> > > many calls like findById, findByHouseId, findByName etc. So I'll end
> > up
> > > writing duplicate set of calls for each type of content Define a
> > > single complex element with union of the fields from both
> and
> > > introduce a field to store type. The advantage is that I only need
> > single
> > > set of calls. The disadvantage is the additional type. There is a
> > saying
> > > that "Adding type means killing your object".
> > >
> > >
> > > I understand that this is not really axis related question but I
> will
> > highly
> > > appreciate if some would like to share his experience with me.
> > >
> > > Thanks
> > >
> > > Dheeraj Soti
> > >
> > >
> > >                           Content
> > >                              |
> > >            -----------------------------------------
> > >            |                                       |
> > >          CommercialContent              ProgramContent
> >
> 
> > E-MAIL CONFIDENTIALITY NOTICE:  The contents of this e-mail message
> and any attachments are intended solely for the
> > addressee(s) and may contain confidential and/or legally privileged
> information. If you are not the
> > intended recipient of this message or if this message has been
> addressed to you in error, please
> > immediately alert the sender by reply e-mail and then delete this
> message and any attachments. If you
> > are not the intended recipient, you are notified that any use,
> dissemination, distribution, copying, or
> > storage of this message or any attachment is strictly prohibited.
> >
> 
> E-MAIL CONFIDENTIALITY NOTICE:  The contents of this e-mail message and any
> attachments are intended solely for the
> 
> addressee(s) and may contain confidential and/or legally privileged information.
> If you are not the
> 
> intended recipient of this message or if this message has been addressed to you
> in error, please
> 
> immediately alert the sender by reply e-mail and then delete this message and
> any attachments. If you
> 
> are not the intended recipient, you are notified that any use, dissemination,
> distribution, copying, or
> 
> storage of this message or any attachment is strictly prohibited.
>