You are viewing a plain text version of this content. The canonical link for it is here.
Posted to woden-dev@ws.apache.org by Arthur Ryman <ar...@gmail.com> on 2005/12/01 03:00:27 UTC
Re: Using typesafe enums instead of Strings
John,
The "correct" solution is to make MessageLabel an NCName, not a String.
-- Arthur
On 11/29/05, John Kaputin <KA...@uk.ibm.com> wrote:
> Arthur,
> I'll have a think about making MessageLabel extensible this week, while
> working on MEPs and binding extensibility. If it isn't doable or if it
> becomes too cumbersome in the framework (i.e. pgm model or configuration)
> then we can revert to Strings.
>
> thanks,
> John Kaputin
>
>
>
>
> Arthur Ryman
> <arthur.ryman@gma
> il.com> To
> woden-dev@ws.apache.org
> 28/11/2005 20:14 cc
>
> Subject
> Please respond to Re: Using typesafe enums instead of
> woden-dev Strings
>
>
>
>
>
>
>
>
>
>
> John,
>
> That makes sense for Direction, but not {message label} since the
> allowed values are an open set. Each MEP defines a set of message
> labels, but anyone can define a new MEP that has new message labels.
>
> On 11/25/05, Jeremy Hughes <jp...@gmail.com> wrote:
> > Trouble is enum is a reserved work in Java 5. Howabout using
> > enumeration instead?
> >
> > Jeremy
> >
> > On 11/25/05, John Kaputin <KA...@uk.ibm.com> wrote:
> > > I have changed the representation of the {message label} property and
> the
> > > {direction} property from Strings to typesafe enumeration classes -
> > > MessageLabel and Direction in a new package
> org.apache.woden.wsdl20.enum.
> > > The attached zip file contains the javadoc for these two
> > > classes, containing a description and examples.
> > >
> > > (See attached file: TypesafeEnumJavadoc.zip)
> > >
> > > There are some other WSDL properties that could be represented this way
> too
> > > (e.g. NMTokens #element, #value, #none, etc).
> > >
> > > There are some Woden configuration constants currently represented as
> > > strings and captured in the Constants file or in API interfaces which
> could
> > > perhaps be better represented as typesafe enums, but these should
> probably
> > > go in a new package org.apach.woden.enum. For example, a Feature enum
> for
> > > validation, tracing, etc and a Property enum for the type system,
> parser
> > > api, etc.
> > >
> > > These enums can be implemented as fixed or extensible, as needed.
> > >
> > > John Kaputin
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: woden-dev-help@ws.apache.org
> > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: woden-dev-help@ws.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: woden-dev-help@ws.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: woden-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: Using typesafe enums instead of Strings
Posted by John Kaputin <KA...@uk.ibm.com>.
Arthur,
Good point. I've just looked at org.apache.axis.types.NCName which takes a
String in its ctor and has an isValid() method to indicate if it's a
correctly formed NCName.
John Kaputin
Arthur Ryman
<arthur.ryman@gma
il.com> To
woden-dev@ws.apache.org
01/12/2005 02:00 cc
Subject
Please respond to Re: Using typesafe enums instead of
woden-dev Strings
John,
The "correct" solution is to make MessageLabel an NCName, not a String.
-- Arthur
On 11/29/05, John Kaputin <KA...@uk.ibm.com> wrote:
> Arthur,
> I'll have a think about making MessageLabel extensible this week, while
> working on MEPs and binding extensibility. If it isn't doable or if it
> becomes too cumbersome in the framework (i.e. pgm model or configuration)
> then we can revert to Strings.
>
> thanks,
> John Kaputin
>
>
>
>
> Arthur Ryman
> <arthur.ryman@gma
> il.com> To
> woden-dev@ws.apache.org
> 28/11/2005 20:14 cc
>
> Subject
> Please respond to Re: Using typesafe enums instead of
> woden-dev Strings
>
>
>
>
>
>
>
>
>
>
> John,
>
> That makes sense for Direction, but not {message label} since the
> allowed values are an open set. Each MEP defines a set of message
> labels, but anyone can define a new MEP that has new message labels.
>
> On 11/25/05, Jeremy Hughes <jp...@gmail.com> wrote:
> > Trouble is enum is a reserved work in Java 5. Howabout using
> > enumeration instead?
> >
> > Jeremy
> >
> > On 11/25/05, John Kaputin <KA...@uk.ibm.com> wrote:
> > > I have changed the representation of the {message label} property and
> the
> > > {direction} property from Strings to typesafe enumeration classes -
> > > MessageLabel and Direction in a new package
> org.apache.woden.wsdl20.enum.
> > > The attached zip file contains the javadoc for these two
> > > classes, containing a description and examples.
> > >
> > > (See attached file: TypesafeEnumJavadoc.zip)
> > >
> > > There are some other WSDL properties that could be represented this
way
> too
> > > (e.g. NMTokens #element, #value, #none, etc).
> > >
> > > There are some Woden configuration constants currently represented as
> > > strings and captured in the Constants file or in API interfaces which
> could
> > > perhaps be better represented as typesafe enums, but these should
> probably
> > > go in a new package org.apach.woden.enum. For example, a Feature enum
> for
> > > validation, tracing, etc and a Property enum for the type system,
> parser
> > > api, etc.
> > >
> > > These enums can be implemented as fixed or extensible, as needed.
> > >
> > > John Kaputin
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: woden-dev-help@ws.apache.org
> > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: woden-dev-help@ws.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: woden-dev-help@ws.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: woden-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org