Hi Rhett,

Thanks a lot for your contribution; I will make sure I review ASAP
(coming weeks :( ).

Thanks again for keeping Castor a living project,

Arnaud

> -----Original Message-----
> From: Rhett Sutphin [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 30, 2003 12:19 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [castor-dev] Source Generator: binding member/@java-type
and
> IDREF
> 
> Hi,
> 
> Patch done.  I opened a bug (1341) in bugzilla and attached the patch.
> 
> http://bugzilla.exolab.org/show_bug.cgi?id=1341
> 
> It is a very small change:  it adds a "reference" attribute to
> fieldType whose sole effect is to tell DescriptorSourceFactory to
> generate a FieldDescriptor that marshals by reference.
> 
> Rhett
> 
> On Wednesday, June 25, 2003, at 09:52  AM, Rhett Sutphin wrote:
> 
> > Hi,
> >
> > I'm going to go ahead and try to add this feature.  But first I'd
like
> > to run my design past you (Keith and Arnaud in particular, but I'll
> > take comments from any Source Generator user) to make sure it
doesn't
> > conflict with the overall vision for the binding file.
> >
> > To recap, I want to specify the type of an IDREF in the binding
file.
> > Doing this
> >
> >>> <attribute name="eltname/@ref-attr">
> >>>         <member java-type="RequiredType"/>
> >>> </attribute>
> >
> > doesn't work, because the resulting descriptor loses indication that
> > the attribute should be marshaled as an IDREF.
> >
> > I propose adding a "reference" attribute to the complex type
fieldType
> > in the binding file schema.  If the value of this attribute is
"true",
> > the generated descriptor will be configured to marshal the field by
> > reference (i.e., as though it were an IDREF).  The above example
would
> > become this:
> >
> > <attribute name="eltname/@ref-attr">
> >   <member java-type="RequiredType" reference="true"/>
> > </attribute>
> >
> > And the generated descriptor would gain a `desc.setReference(true)`
> > line in the block of code initializing the FieldDescriptor for
> > _refAttr.
> >
> > I don't know what the semantics should be if "reference" is combined
> > with "wrapper" or "handler".  Advice would be appreciated.
> >
> > Thanks,
> > Rhett
> >
> > On Monday, June 16, 2003, at 05:25  PM, Keith Visco wrote:
> >> Hi Rhett,
> >>
> >> What you want to do should be possible when Castor supports
> >> key/keyref/unique. However, I see no reason why the binding file
> >> cannot
> >> have support for specifying the type for an IDREF if the type is
> >> known.
> >> I don't want to change the XSIdRef class, because these changes
should
> >> be limited to the binding file, but it should still be doable.
Arnaud?
> >>
> >> --Keith
> >>
> >> Rhett Sutphin wrote:
> >>>
> >>> Hi,
> >>>
> >>> I would like to change the java [parameter type/return type] for
an
> >>> attribute that is declared as IDREF in my schema.  That is, the
> >>> reference must be to an element of a certain complexType and I'd
like
> >>> the generated source to enforce that restriction.
> >>>
> >>> (The base problem is that I want to unmarshal a bidirectional
> >>> relationship in generated source without a StackOverflowError;
> >>> ID/IDREF
> >>> seems to be the way to do this.  Is there another way?)
> >>>
> >>> Using a binding file with an attributeBinding like this
> >>>
> >>> <attribute name="eltname/@ref-attr">
> >>>         <member java-type="RequiredType"/>
> >>> </attribute>
> >>>
> >>> will successfully change the type of the field/accessors in the
> >>> generated code, but the descriptor loses the
> >>> `desc.setReference(true)`
> >>> line.  I glanced through the Source Generator code, and this seems
to
> >>> be intractable because the XSIdRef type class doesn't allow you to
> >>> set
> >>> the JClass.  So I was considering adding some way to declare that
an
> >>> element/attribute should be marshalled by-reference to the binding
> >>> file.  Perhaps with a "reference='true'" attribute on fieldType.
> >>>
> >>> Does this seem like the appropriate way to handle this?  Is there
an
> >>> existing way so that I don't need to modify the binding
> >>> infrastructure?
> >>>
> >>> Thanks,
> >>> Rhett
> >>> --
> >>> Rhett Sutphin
> >>> Research Assistant (Software)
> >>> Coordinated Laboratory for Computational Genomics
> >>>     and the Center for Macular Degeneration
> >>> University of Iowa - Iowa City - Iowa - 52246
> >>> mailto:[EMAIL PROTECTED]
> >>>
> >>> -----------------------------------------------------------
> >>> If you wish to unsubscribe from this mailing, send mail to
> >>> [EMAIL PROTECTED] with a subject of:
> >>>         unsubscribe castor-dev
> >>
> >> -----------------------------------------------------------
> >> If you wish to unsubscribe from this mailing, send mail to
> >> [EMAIL PROTECTED] with a subject of:
> >>         unsubscribe castor-dev
> >>
> >
> > ----------------------------------------------------------- If you
> > wish to unsubscribe from this mailing, send mail to
> > [EMAIL PROTECTED] with a subject of:
> >        unsubscribe castor-dev
> >
> 
> -----------------------------------------------------------
> If you wish to unsubscribe from this mailing, send mail to
> [EMAIL PROTECTED] with a subject of:
>         unsubscribe castor-dev

----------------------------------------------------------- 
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
        unsubscribe castor-dev

Reply via email to