Arnaud,
I'm ok with using the <nameRule> for other things besides 'implements'.
Below, I took your example and incorporated Rhett's <except> idea.
To get it to look right, I had to move the <all>
down a level. I also added an optional <pattern>, which
could be implemented after all the other stuff is done.
When it comes to conflicting rules, I also like the idea of
allowing "the rules that are defined later to trump the earlier ones".
<xs:complexType name="nameRule">
<xs:sequence>
<xs:choice>
<xs:element name="equals" type="xs:string"/>
<xs:element name="all" type="xs:string"/>
<xs:sequence>
<xs:element name="startsWith" type="xs:string" minOccurs="0"/>
<xs:element name="endsWith" type="xs:string" minOccurs="0"/>
<xs:element name="pattern" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:choice>
<xs:element name="except" minOccurs="0">
<xs:complexType>
<xs:choice maxOccurs="unbounded">
<xs:element name="endsWith" type="xs:string"/>
<xs:element name="startsWith" type="xs:string"/>
<xs:element name="equals" type="xs:string"/>
<xs:element name="pattern" type="xs:string"/>
<!-- note that <all> is intentionally omitted -->
</xs:choice>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
This structure for <except> allows you to have multiple exceptions to a single
rule. The developers I support use this a lot in my in-house version.
Comments?
--eto
> -----Original Message-----
> From: Arnaud Blandin [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 16, 2003 5:41 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [castor-dev] expanding the 'implements'
> functionality in
> the binding file (2)
>
>
> Hi guys,
>
> Sorry for jumping so late on the thread, roughly
> speaking I like the
> idea a lot.
> I think it should be implemented as a generic feature
> of componentType
> to define generic rules:
>
> For all the elements/groups/complexTypes whose names
> end with Foo,
> etc...
> If we want to enforce rules defined in a XML Schema, I
> think you are
> right in using a name element:
>
> <choice>
> <element name="all" type="boolean"/>
> <element name="nameRule">
> <choice>
> <element name="equals" type="string"/>
> <sequence>
> <element name="startsWith" type="string"
> minOccurs='0'/>
> <element name="endsWith" type="string"
> minOccurs='0'/>
> </sequence>
> </choice>
> </element>
> </choice>
> The <except> element is a good way of expressing negation.
>
> I am still not sure we wouldn't want to use it with
> extends since it
> will allow us to define a common super-class like we do in the
> castorbuilder.properties.
> If we go that road we need precise rules to resolve conflicts.
> The rule should be:
> Given a component, first look at a binding whose name
> is equal to the
> component name. Then look for a startsWith or endsWith
> and finally look
> for the all.
>
> What do you think?
>
> Arnaud
>
> >
> > -----Original Message-----
> > From: Ostermueller, Erik [mailto:[EMAIL PROTECTED]
> > Sent: Monday, June 16, 2003 11:45 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [castor-dev] expanding the 'implements'
> functionality in
> the
> > binding file (2)
> >
> >
> > Rhett wrote:
> > > One more thing: how do you plan to resolve conflicts?
> > > That is, if
> > > more than one complexTypeBinding applies to a
> > > particular complexType,
> > > how will you pick the one to use?
> > Having multiple hits is OK.
> > One complexTypeBinding might say: All complexTypes
> must implement
> > java.io.Serializable
> > (I think I forgot that one in my example).
> > Another might say, "All complexTypes ending in 'Rq' implement
> 'GenericRq'"
> > This would generate: public class MyRq implements
> java.io.Serializable,
> > GenericRq
> >
> > This, of course, won't work with 'extends'(no
> mutliple inheritance in
> java)
> > and 'member' and a number of
> > the other constructs in the binding file. One
> similar problem would
> be if
> > multiple rules contradict each other, such as
> >
> > "a must implement A" and
> > "everything implements A <except> a"
> >
> > All that said, I really like the rest of your layout
> -- everything
> from <name>
> > downward.
> > Perhaps we should only use this <name> construct beneath the
> <implements>
> > node.
> >
> > Arnaud?
> >
> > Rhett's whole reply:
> > > I've got a suggestion for how you could
> handle the more
> > > complex rules.
> > > Instead of defining a bunch of new attributes for
> > > complexTypeBinding,
> > > consider making the name the first child element. You
> > > could have
> > > something like this:
> > >
> > > <complexTypeBinding>
> > > <name><equals>CustomerType</equals></name>
> > > ...
> > > </complexTypeBinding>
> > >
> > > to get the current functionality. For your other
> > > examples, it might be
> > > something like:
> > >
> > > <name><startsWith>Foo</startsWith></name>
> > > <name><endsWith>Foo</endsWith></name>
> > > <name><all/></name>
> > >
> > > To do negation you might do something like:
> > >
> > > <name>
> > > <startsWith>Foo</startsWith>
> > > <except>
> > > <endsWith>Bar</endsWidth>
> > > </except>
> > > </name>
> > >
> > > You might also want to consider allowing more than one
> > > to be specified
> > > with some sort of simple implicit rule
> (probably AND). So
> > >
> > > <name>
> > > <startsWith>Foo</startsWith>
> > > <endsWith>Bar</endsWidth>
> > > <except>
> > > <equals>FooBazBar</equals>
> > > </except>
> > > </name>
> > >
> > > Since castor's already dependent on
> jakarta-regexp, you
> > > might consider
> > > having a <pattern> selector, too.
> > >
> > > One more thing: how do you plan to resolve conflicts?
> > > That is, if
> > > more than one complexTypeBinding applies to a
> > > particular complexType,
> > > how will you pick the one to use?
> > >
> > > 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]
> > >
> > > On Monday, June 16, 2003, at 11:08 AM, 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
> > >
> > >
> > > DISCLAIMER:
> > > This email message is for the sole use of the intended
> > > recipient(s) and may contain confidential and
> > > privileged information. Any unauthorized review, use,
> > > disclosure or distribution is prohibited. If you are
> > > not the intended recipient, please contact the sender
> > > by reply email and destroy all copies of the original
> > > message and attachments.
> > >
> >
> > -----------------------------------------------------------
> > 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
>
>
> DISCLAIMER:
> This email message is for the sole use of the intended
> recipient(s) and may contain confidential and
> privileged information. Any unauthorized review, use,
> disclosure or distribution is prohibited. If you are
> not the intended recipient, please contact the sender
> by reply email and destroy all copies of the original
> message and attachments.
>
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
