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
Andrei Shakirin wrote:
Hi David,
Ok, great. I will be the whole next week on JavaPolis conference in Antwerpen, so let discuss it in detail 17, 18 December, if you will not be on vacation.
Regards,
Andrei.
----- Original Message -----
From: "David Bosschaert" <davidb@xxxxxxxx>
To: "STP Dev list" <stp-dev@xxxxxxxxxxx>
Sent: Freitag, 7. Dezember 2007 11.44 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 response. I will look into the interfaces and will get
back about them early next week.
I just noticed that my alternative mockup images were not properly
showing up on the page, so I have re-uploaded the images.
Cheers,
David
Andrei Shakirin wrote:
Hi David,
I find your proposal very useful, but I am not quite sure what is the best solution for use case, when policy has some assertions and alternatives on the same level.
I have updated wiki page (http://wiki.eclipse.org/STP/GUILookAndFeelIntegrationProposal
) and described possible solutions. I also have published draft variant of interfaces between editors.
My suggestion - keep the first iteration as simple as possible: just implement solution to edit single alternative on the first step. Our interfaces are flexible enough and we can extend this functionality on next iterations.
What is your opinion?
How you find the interfaces suggestion?
Regards,
Andrei.
----- Original Message -----
From: "David Bosschaert" <davidb@xxxxxxxx>
To: "STP Dev list" <stp-dev@xxxxxxxxxxx>
Sent: Donnerstag, 6. Dezember 2007 13.00 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 kicking this design off. The overall proposal looks fine to me.
I did put in a questions and took the liberty to provide an slight
alternative to your second screen shot. I hope this will work for you.
I've clearly marked my comments with my name.
Cheers,
David
http://wiki.eclipse.org/STP/GUILookAndFeelIntegrationProposal
Andrei Shakirin wrote:
Hi all,
Look and feel proposal for integration of XEF and WTP-based policy editors is available from:
http://wiki.eclipse.org/GUILookAndFeelIntegrationProposal
@David: could you please look and comment it? If it is OK from your point of view, we can start the next steps: design interfaces and extension points and finally define functionality and requirements.
Regards,
Andrei.
----------------------------
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
|
