Re: [castor-dev] expanding the 'implements' functionality in the binding file (2)

[Rhett Sutphin]

Hi Arnaud,

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.
I prefer Keith's suggestion:  allow the rules that are defined later to 
trump the earlier ones.  (But only where they conflict.)  This gives 
the end developer more flexibility, plus it (as Keith pointed out) is 
similar to the way XSLT (another XML-defined transformation language) 
work.

Rhett

On Monday, June 16, 2003, at 05:41  PM, Arnaud Blandin wrote:
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
----------------------------------------------------------- 
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
       unsubscribe castor-dev