GUI Proposal: XEF and WTP Editor Integration
This proposal provides GUI look and feel for integration of XEF and WTP-based editors.
As it was agreed, integration provides a way to combine the strengths of both editors: use the WTP-based editor to view and edit the policy document as a whole and the XEF editor as a detail editor when fragments in the policy document that contain individual assertions need to be edited.
1. Editing policy document as whole
On the first step user will open(create) policy file (or policy attachment in wsdl) with WTP-based editor. Here it is possible to add/delete new alternatives and assertions, combine and build the hierarchy of them. Additionally, WTP-based policy editor could provide following functionality:
- merge policies;
- intersect polices;
- normalize policy;
- validate policy.
Validation could be used in two modes:
- validate whole policy document;
- propose list with only allowed policy assertions (in GUI).
Draft look&feel of policy document editing is represented bellow:
2. Editing individual assertions
As soon as user chooses editing of individual assertion in WTP-based policy editor (via click on arrow), XEF editor will be activated. XEF editor represents GUI elements accordingly assertion schema. User can change assertion properties, save them and return to editing of whole policy document (via icon in left corner). It is possible to edit more than one assertion in parallel (idea is the same as in editing of WSDL inline schemas).
David Bosschaert: I'm curious how you can edit multiple assertions in parallel, since editing an assertion should go into that particular assertion, which would replace the canvas of the high-level editor with the more detailed one (just like what happens with the WTP XML editor). I don't quite understand how you can edit multiple assertions in parallel that way. Sure you could jump into one assertion, make changes, jump back out to the high-level editor and go into a second assertion, that should work fine. It's just the 'parallel' piece that I don't get yet.
Draft look&feel of individual assertion editing is represented bellow:
David Bosschaert: In many cases the policy assertions within a single alternative are related, so I think it would be good to at least give the details editor access to the other assertions within the same alternative, so you can edit them together. Below you can see a suggestion on how this could look.
Jerry Preissler: Good idea, what about the following changes:
* when switching to the detail editor, display all assertions contained in the compositor (all|exactlyOne) that contains the selected assertion * directly edit the primitive assertions in the detail editor * switch back to the overview editor if a contained compositor is selected
If you don't want to see the other alternatives, you can click them away with a special layout button in the editor toolbar. See below: