Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [stp-dev] Look and feel proposal for integration of XEF and WTP-based policy editors

Hi Andrei,

Thanks for your detailed response. Looks like we're very much on the same page! A few more thoughts below.

One more thought in relation to opening the embedded editor. I haven't personally looked into to the way an *embedded* editor is opened yet. Do you know what API is typically used for that? In general however, in Eclipse an editor is opened by calling IDE.openEditor() and passing in an IEditorInput. Have you thought about making IPolicyDetailEditor extend IEditorInput. Then we could use it in a way that is very natural in eclipse to open the editor. You would do: IPolicyDetailEditorInput ed = new PolicyDetailEditorInput("My Policies", stream, prj, cb);
 IEditorPart part = IDE.OpenEditor(workbenchPage, ed, editorID);
This would be very similar to what the XEF editor has today. There is a class called XMLProviderEditorInput that is used in this way to open the editor. However, I don't know whether the use of an IEditorInput works with creating an embedded editor. Do you?

onError() - ok, I see how this could be useful
closeEditor() - yes, that sounds good too

On the schema catalogue, if we were to use the WTP schema catalogue, it would have to implement org.eclipse.wst.xml.core.internal.catalog.provisional.ICatalog - clearly not great as it's both internal as well as provisional ;) Currently the XEF editor has it's own ISchemaProvider interface ( which is a lot simpler than the ICatalog interface:
 public interface ISchemaProvider {
   Collection<String> listSchemaNamespaces(String filter);
   String getSchema(String namespace);

   Collection<String> listSnippets(String filter);
   String getSnippet(String name);

   void refresh();
Schemas are purely looked up by namespace, so listSchemaNamespaces() returns a list of namespaces each representing a schema. A schema can be obtained from a namespace by calling getSchema(). There are also a listSnippets/getSnippet() APIs in there. Snippets are a feature of the XEF editor that make it possible to create a template of one or more policies and give them a name. So you could have a number of policies together with some (but maybe not all) values filled in and call it 'My Company's SOA policy'. Then you could apply that in one go to your services. This is what the snippets represent. I'm not sure whether we want to expose this in the combined editor, if consensus is that we shouldn't use the snippets, then we could create a Schema Provider interface without them. I have the feeling that it would be quite easy to write a bridge between ICatalog and ISchemaProvider (but I havent tried it). I think it would be better to focus on a simple interface for the moment rather than going with ICatalog from WTP.

Just one more thing on the schema catalogs. I think it's important that these are non-static. I don't like obtaining them with a static call (like XMLCorePlugin.getDefaultXMLCatalog()). The reason is that the catalog of schema's may depend on the current context. E.g. you may have a different schema catalog if you are editing the policies of a router than when you're editing the policies of another type of service. Or if you are editing services for two different target runtimes your policies may also be different. Therefore I think its important that the schema catalogue is passed in as an argument to the openEditor() call, so that multiple policy editors could have different schemas. So I would be in favour of either adding an extra argument to the IPolicyDetailEditor.openEditor() call or an extra contructor argument to PolicyDetailEditorInput().

Best regards,


Andrei Shakirin wrote:
Hi David,

I agree with the most of your suggestions:

1. Naming suggestions (method parameters, interfaces): OK

2. IProject parameter: OK, makes sense

3. IEditorPart return type: OK, makes sense (for example to discovery dirty status of detail editor). But I recommend read only using of this interface by WTP-Editor.

4. void setProperties(final Map<String, Object> props): OK, it will be more flexible

5. void onError(): as far as openEditor call is asynchronous, I would like to have mechanism to inform WTP-Editor about problems/errors in XEF-Editor.
   a) some kind of errors can be recoverable (for example missing schema in catalogue)
   b) some other kind of errors can cause special activities of WTP-Editor (for example warn user before save/publish policy, disable part of functionality, etc.)

6. [new] I think it makes sense also to introduce asynchronous method to close XEF-editor (for example in case if user closes parent WTP-editor)
   void closeEditor(final String name, final boolean force) throws Exception;
   XEF-Editor will release all resources and close editor window by this method. If force mode is true, XEF-Editor should not ask user about saving (for example in case if user deletes the policy file).

7. Regarding schema catalogue: I see some possible solutions here:
a) reuse WTP XML catalog

   WTP has implementation for default, system and user catalog
   Entry point is XMLCorePlugin.getDefaultXMLCatalog, it also provides some extension points for catalog resolver and catalog contributions.
   If we can publish our schemas in WTP XML catalog, we don't need any additional API and parameters.
   Disadvantage is that the most of API is WTP internal. So we need to discuss with WTP the possibility to externalize it.

b) Use own catalog implementation
   In this case we need additional parameter in openEditor call or additional method in interface.

What do you think? How do you use schema catalogue at the moment?

I have updated interface in wiki (


----- Original Message -----
From: "David Bosschaert" <davidb@xxxxxxxx>
To: "STP Dev list" <stp-dev@xxxxxxxxxxx>
Sent: Montag, 10. Dezember 2007 11.46 Uhr (GMT+0100) Europe/Berlin
Subject: Re: [stp-dev] Look and feel proposal for integration of XEF	and	WTP-based policy editors

Two more thoughts after hitting send.

1. Maybe we should conform to the interface naming as done in many other Eclipse interfaces by putting a capital I in front of the name, so e.g. IPolicyDetailEditor and IPolicyDetailCallback.
2. We haven't figured out how to pass the Schema Catalogue to the XEF editor yet. The current XEF editor takes a SchemaProvider as part of the Editor Input constructor.
In the concall a few weeks ago we discussed integration with other policy catalogues. Do we need an argument on the IPolicyDetailEditor.openEditor() API to pass on the current catalogue?



David Bosschaert wrote:

    Hi Jerry, Andrei,

    I read your comments and agree in general. I do have some additional thoughts which I'm putting in this mail.

    On how the details editor should behave in the following case:
        <!-- assertion 1 -->
        <!-- assertion 2 -->
        <wsp:All> <!-- assertion 3 --> </wsp:All>
        <wsp:ExactlyOne> <!-- assertion 4 --> </wsp:ExactlyOne>
    I think I would prefer option 3 as outlined but I agree that we should do the simplest thing first and mainly focus on the integration.

    On the editor interface, I know I'm a little bit pedantic here, but I would suggest the following:

    public interface PolicyDetailEditor {
        IEditorPart openEditor(final String name, final InputStream source, final IProject ctxProject, final PolicyDetailCallback callback) throws Exception;
        void setProperties(final Map<String, Object> props);

    The policy editor needs a project where it can store temporary files, so that's why I added it. The source does not have to be a file in that project.
    For the properties I would suggest a Map<String, Object> or a Map<String, String> instead of a Properties object.
    And why not rename it to PolicyDetailEditor...

    On the callback interface, I would suggest:

    public interface PolicyDetailCallback {
        Object getData(String ctxID);
        void onSave(final InputStream source) throws Exception;
        void onClose();

    I'm curious what the onError() that was in your proposal would be used for. In the current XEF editor, when an error occurs, it is simply logged to the PDE Error log and the system continues. I wonder what the high-level editor would do with any error over and above that.
    I added a getData() method. The XEF Policy editor supports a mechanism where context-specific information can be obtained, which can be used to populate the editor with suggested data. As an example consider a policy that needs the name of an operation as its value. The XEF editor can be annotated to make a callback into the application to find out what the possible operations are. This callback would be made with a context ID, e.g. "wsdl.operations" which could be understood by the installed callback handler. A loosely typed getData() as above would facilitate such callbacks...

    Anyway, just a few thoughts.

    Best regards,

stp-dev mailing list

stp-dev mailing list

IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Back to the top