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 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.
   Reasons:
   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
   org.eclipse.wst.xml.core.internal.catalog.*
   org.eclipse.wst.xml.core.internal.XMLCorePlugin

   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 (http://wiki.eclipse.org/STP/GUILookAndFeelIntegrationProposal).

Regards,
Andrei

----- 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?

Cheers,

David

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:
      <wsp:All>
        <!-- assertion 1 -->
        <!-- assertion 2 -->
        <wsp:All> <!-- assertion 3 --> </wsp:All>
        <wsp:ExactlyOne> <!-- assertion 4 --> </wsp:ExactlyOne>
      </wsp:All>
    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,

    David
_______________________________________________
stp-dev mailing list
stp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/stp-dev

Back to the top