John,
>If we stick with option 1 longer term, I would prefer to keep the reader
>API (including the feature ids) contained within the WSDLReader interface,
>which means keeping ReaderFeatures as an internal implementation class, but
>I'm open to suggestions on that. In this case there's some redundancy in
>defining static finals twice for each feature id - perhaps ReaderFeatures
>should use the statics defined in WSDLReader.
Agreed.
Lawrence Mandel
| John Kaputin <[EMAIL PROTECTED]>
01/27/2006 02:31 PM
|
|
Lawrence,
I think the 'scalability' is the same for both options. The API is
represented by public methods and public static finals. To add a new
feature to the Woden API, option 1 requires a new public static final while
option 2 requires 2 new methods (set/get). API change is required in both
cases.
Even with option 2, the setFeature/getFeature methods are still required on
the API to support user-defined features, so it is always possible to add
features to the implementation that are not defined on the API (but I'm not
suggesting this is a good approach).
As for adding 'noise to the API' with option 2, I assume this refers to 2
methods per Woden feature compared to 1 public static final field for
option 1. Definitely a 2 to 1 ratio there!
If we stick with option 1 longer term, I would prefer to keep the reader
API (including the feature ids) contained within the WSDLReader interface,
which means keeping ReaderFeatures as an internal implementation class, but
I'm open to suggestions on that. In this case there's some redundancy in
defining static finals twice for each feature id - perhaps ReaderFeatures
should use the statics defined in WSDLReader.
John Kaputin
Lawrence Mandel
<[EMAIL PROTECTED]
om> To
[email protected]
27/01/2006 18:04 cc
Subject
Please respond to Re: Exposing WSDLReader features on
woden-dev the API
1) +1. I think I added the ReaderFeatures class to have one place to
contain all the specified features. These can be specified on the reader
(this may be simplest) or we can externalize the ReaderFeatures class. For
the current docs I vote to go with WSDLReader.FEATURE_VALIDATION as you
suggested.
2) -1. I don't think we should specify methods specifically for enabling
every feature. Doing this will add noise to the API and is not scalable.
(Every feature requires a new enablement method.) This also leads to two
ways to specify features. I think we should learn from Xerces and use the
feature framework we've got in place to specify all of our features.
Lawrence Mandel
Software Developer
IBM Rational Software
Phone: 905 - 413 - 3814 Fax: 905 - 413 - 4920
[EMAIL PROTECTED]
John Kaputin <[EMAIL PROTECTED]>
To
01/27/2006 08:41 AM [email protected]
cc
Please respond to Subject
woden-dev Exposing WSDLReader
features on the API
I came across this issue while writing the user guide.
The validation feature identifier
"http://ws.apache.org/woden/features/validation" is currently defined as a
static final in 2 places:
WSDLReader.FEATURE_VALIDATION
ReaderFeatures.VALIDATION_FEATURE_ID
The M3 release notes describe enabling validation by setting
ReaderFeatures.VALIDATION_FEATURE_ID to true, but this is an internal
class. We can correct this easily in various ways:
1) by specifying WSDLReader.FEATURE_VALIDATION for the programming model
(i.e. rather than exposing an interface for ReaderFeatures on the API).
2) by removing the static finals for pre-defined features like validation
from the WSDLReader interface and adding specific methods for those
pre-defined features - for example, setValidation(boolean) and
isValidationEnabled(). Other pre-defined features are CONTINUE-ON-ERROR and
VERBOSE (i.e. trace).
Option 2) would require more methods on the API but it would remove the
need to explicitly define identifiers for these pre-defined features in the
API. Then only user-defined features would need to use the setFeature(..)
and getFeature() methods on WSDLReader. Ditto for properties.
For now, to complete the user guide I'll go with Option 1) because it will
work with the existing implementation.
It's really a style thing - both approaches work. I remember proposing
option 1) originally, but I now prefer option 2) because I think it makes
the reader API more obvious and it offers better encapsulation (i.e. no
identifiers are required externally for pre-defined features).
Please comment or vote if you have a preference.
John Kaputin
Web Services Development
Hursley Laboratory
IBM UK Ltd, MP211, Hursley Park, Winchester, SO21 2JN, UK.
email: [EMAIL PROTECTED]
Tel/Fax: +44 (0)1962 817363 (internal 7-247363)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
