[
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,
Sure, we will improve design and interfaces iteratively.
I have 2,5 weeks vacation - will continue on 7.01.2008.
Happy New Year and Merry Christmas!
Andrei
----- Original Message -----
From: "David Bosschaert" <davidb@xxxxxxxx>
To: "STP Dev list" <stp-dev@xxxxxxxxxxx>
Sent: Dienstag, 18. Dezember 2007 16.37 Uhr (GMT+0100) Europe/Berlin
Subject: Re: [stp-dev] Look and feel proposal for integration of XEF and WTP-based policy editors
Hi Andrei,
That all looks good to me. Thanks!
Over the coming few days I will start working on actual implementations
of PolicyDetailEditor and PolicyDetailEditorInput and will add them to
the XEF editor.
I guess we should leave the option open to refine things if we find any
improvements along the way.
Cheers,
David
Andrei Shakirin wrote:
> Hi David,
>
> Small correction to previous mail:
>
> lines:
> Implementation of callback will be located in WTP-Editor project.
> Implementations: PolicyDetailEditor.java, PolicyDetailEditorHelper.java will be located in XEF-Editor project.
>
> should be:
> Implementation of callback and PolicyDetailEditorHelper.java will be located in WTP-Editor project.
> Implementations: PolicyDetailEditor.java, PolicyDetailEditorInput.java will be located in XEF-Editor project.
>
> Regards,
> Andrei.
>
> ----- Original Message -----
> From: "Andrei Shakirin" <andrei.shakirin@xxxxxxxxx>
> To: "STP Dev list" <stp-dev@xxxxxxxxxxx>
> Sent: Dienstag, 18. Dezember 2007 13.13 Uhr (GMT+0100) Europe/Berlin
> Subject: 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
>
> _______________________________________________
> 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
