"Ostermueller, Erik" wrote:
>
> Is any one else interested in this, or am I going to have to go it alone?
>
Hi Erik,
I like the ideas you have outlined below. Since Arnaud is the primary
developer working on the binding file, hopefully you two can discuss
this one in more detail.
Thanks,
--Keith
"Ostermueller, Erik" wrote:
>
> Is any one else interested in this, or am I going to have to go it alone?
>
>
> I wrote:
> > Currently this binding file:
> >
> > <binding defaultBindingType='type'>
> > <complexTypeBinding name="CustomerType">
> > <java-class>
> > <implements>mypackage.Customer</implements>
> > </java-class>
> > </complexTypeBinding>
> > </binding>
> >
> > will help you generate source like this:
> > public class CustomerType implements mypackage.Customer {...}
> >
> > This is a good thing. The SourceGenerator generates the above
> > implements statement when the name of the complexType is
> > **precisely equal** to the 'name' attribute in the
> > above binding file.
> > However, I'd like to go beyond this **precisely equal**
> > operation and add
> > support for the following:
> >
> > 1.) starts with
> > 2.) ends with
> > 3.) always
> > 4.) negation of 1, 2 and 'precisely equal'.
> >
> > I've custom coded this functionality on an older version
> > of castor and would like to implement (and contribute)
> > this on the lastest
> > version. How should we structure the binding file to
> > support this?
> >
> > <complexTypeBinding name="CustomerType"> <!--
> > currently supported -->
> > <complexTypeBinding nameStartsWith="CustomerType">
> > <!-- proposed-->
> > <complexTypeBinding nameEndsWith="CustomerType">
> > <!-- proposed-->
> > <complexTypeBinding all="true"> <!-- proposed-->
> >
> > When these new attrbutes are used, they would only work if
> > the child elements of complexTypeBinding look like this:
> >
> > <complexTypeBinding>
> > <java-class>
> > <implements>
> >
> > As for the negation, we use it to make exceptions to the rule.
> > For instance, "Dear sourcegenerator, please implement
> > interface x
> > when the name=y, except when the name=z".
> > Our SOAP incoming message names end in 'Rq', outgoing
> > msgs end in 'Rs'.
> > So, Rq's implement some interfaces, Rs's implement
> > others, with some
> > administrative Rq's manating the negation.
> >
> > So, without radically changing the binding file
> > structure, I don't yet have any
> > bright ideas on where in the binding file to place the
> > negation stuff.
> >
> > I'm completely open to how we structure this -- I just
> > need the functionality.
> >
> > --Erik O.
> >
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
