[
https://issues.apache.org/jira/browse/WODEN-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12865606#action_12865606
]
Sagara Gunathunga commented on WODEN-20:
-----------------------------------------
"Arthur Ryman added a comment - 07/May/10 03:30 PM
Dilshan, If programmers need to use both the read-only and the read-write
interfaces together, then it would be awkward. I assume programmers will only
use one or the other. Leaving "Editable" in the names is OK. "
Arthur ,
Above suggestion is much more clear with your assumption ,but practically this
is not always possible. As an example if I take the use case mentioned in your
2nd point modifying existing WSDL file ; first WSDLReader returns object of
Description type and then in order to modify the content user should cast into
editable.Description, here we can see both read-only and read-write APIs
together. In such scenarios user needs to use both APIs together.
Also it is not possible to pre-determine the exact place where the user move
in to one API to a another , as an example to add new child component to a
Binding component of a existing WSDL file user has following two ( or more)
options.
1.) First read the file, cast Description into editable.Description and
retrieve child components to reach to the particular editable.Binding component
and add new child component.
2.)First read the file and use Description component to reach to the particular
Binding and once he want to add new child component cast Binding into
edtable.Binding.
I have two suggestion for this
1.) Simply use "Ed" or "E" like prefix instead "Editable" to short the new
interface names.
2.) Use Arthur's suggestion with a convention /policy.
We can introduce a policy something like if a user plan for a modification in
future he should move into the read-write API at the top level by casting
Description into editable.Description this will reduce mixing components from
both APIs together. Also it is possible to encourage user to follow this policy
by introducing a method like makeEditable() on Description interface ( public
editable.Description makeEditable() {...} ). WDYT ?
" Arthur Ryman added a comment - 07/May/10 03:30 PM
2. The file serialization strategy relies and naming conventions to generate
the file names. This means you can't handle the important use case of editing
an existing set of WSDL 2.0 files. Suppose you start with a set of WSDL 2.0
files and want to modify them. You should serialize them back into the same
files. This works unless the user creates new top-level components. In this
case the user should be able to specify the name of the file. So I think the
interface for creating a new top-level component should let to specify the name
the file, or maybe an output stream. "
I'm little confusing with this , Component level API does not contains any
knowledge about physical constructs of a WSDL doc , there is no Imports or
Includes. Once the user read a WSDL file and serialize back to the file using
WSDLWriter it is necessary to preserve the physical constructs but when he
serialize using Component level API is it necessary to preserve same physical
structure ?
IMO when he serialize using Component level API he can select one of the
defined strategy and this behavior is same for both newly created docs and
existing docs .
> Component model API needs modifiers
> -----------------------------------
>
> Key: WODEN-20
> URL: https://issues.apache.org/jira/browse/WODEN-20
> Project: Woden
> Issue Type: New Feature
> Components: Parser
> Reporter: Jeremy Hughes
> Assignee: Sagara Gunathunga
> Attachments: WodenProposal_Dilshan.pdf
>
>
> A Woden 'client' - eg a tool such as java2wsdl - might want to:
> 1 introspect a tree of java classes / interfaces
> 2 create an org.apache.woden.wsdl20.Interface for each - adding to the
> Description object along the way
> 3 serialize to disk.
> Today it is only possible to modify the object form of the WSDL through the
> Element model API. This requires the client app to understand WSDL at the
> file level.
> For step 2 addInterface() is required on Description. Of course
> Interface.addInterfaceOperation() is then required and so on...
> For step 3 a 'strategy' is needed to map from the Component model to the
> Element model's representation of the WSDL in file form. e.g. do all the
> <interface> elements go in the same WSDL file or do all the <interface>
> elements in the same namespace go in one file etc. Also, do the <service>
> elements go in separately included/imported WSDL files as is typically the
> best practice with WSDL 1.1. All these options could be represented using a
> strategy pattern.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
