| Re: [stp-dev] Look and feel proposal for integration of XEF and WTP-based policy editors |
Hi David,
Thanks for the nice ideas!
1: Extension of IEditorPart and IEditorInput interfaces.
I just discussed it with my colleges in detail and we found it the most correct and standard way.
Idea:
a) IPolicyDetailEditor extends IEditorPart. It just adds closeEditor() and setProperties() methods.
b) IPolicyDetailEditorInput extends IEditorInput and adds methods to retrieve InputStream, project, callback
Then call of detail Editor will look like:
IPolicyDetailEditorInput ed = new PolicyDetailEditorInput("My Assertion", stream, project, callback);
IEditorPart part = IDE.openEditor(workbenchPage, ed, "ID");
// check instance of editor ... and cast it to IPolicyDetailEditor
IPolicyDetailEditor editor = (IPolicyDetailEditor)part;
So will use standard Eclipse mechanism to activate detail editor.
I attached sample project with interfaces and implementations.
All interfaces (IPolicyDetailCallback.java, IPolicyDetailEditor.java, IPolicyDetailEditorInput.java) will be located WTP-Editor project and exported from there.
Implementation of callback will be located in WTP-Editor project.
Implementations: PolicyDetailEditor.java, PolicyDetailEditorHelper.java will be located in XEF-Editor project.
What do you think?
2: Schema catalogue.
I agree with your suggestion - let use implementation of schema catalogue from XEF-Editor on the first step.
Anyway it make sense to create bugzilla enhancement request for WTP, as Oisin suggests.
Regarding context: I am not pretty sure, but I think that schema catalog per policy assertion is too match. Most of assertions are based on the single schema, in these cases functionality of schema catalogue will not be used on 100%.
Normally assertions in policy are more or less logically related, so it make sense to define schema catalogue for whole policy (for all assertions in policy).
I have prepared method in IPolicyDetailEditor for set schema catalogue (see attachment). Could you please take a look and update it?
Regards,
Andrei.
----- Original Message -----
From: "David Bosschaert" <davidb@xxxxxxxx>
To: "STP Dev list" <stp-dev@xxxxxxxxxxx>
Sent: Montag, 17. Dezember 2007 16.42 Uhr (GMT+0100) Europe/Berlin
Subject: 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
(http://dev.eclipse.org/svnroot/stp/trunk/org.eclipse.stp.servicecreation/org.eclipse.stp.xef/src/org/eclipse/stp/xef/ISchemaProvider.java)
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,
David
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.
> 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
>
> _______________________________________________
> stp-dev mailing list
> stp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/stp-dev
>
>
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Attachment:
WTP-XEF.zip
Description: Zip compressed data