[oXygen-sdk] Request to enable 'form based editing' from processing instructions

[Michael Anthony Smith]

Hello,

We would like to request an enhancement to the way in which 'form based editing' aspect of the css-styliong works. 

We are working on a merge conflict resolver using processing instructions so that validity can be checked during editing.

Here is an example fragment of DITA:

        <p class="- topic/p ">allow intelligent resolution of conflicts in a
            <?dxml-merge-start text group="d2e150" mergeType="modify"  ?>
            <dxml-merge-marker:marker xmlns:dxml-merge-marker="http://www.deltaxml.com/ns/dxml-merge-marker"  />
            <?dxml-merge text group="d2e150" chosen="true" deltaV2="base"?>
           Content  Managment
           <?dxml-merge text group="d2e150" chosen="false" deltaV2="anna=ben=chris" <Content Management?>
           <?dxml-merge text group="d2e150" chosen="false" deltaV2="david" <Document Management?>
           <?dxml-merge-end text group="d2e150"?>
          System …
       </p>

We have implemented a way of choosing between the three alternative options in Java, see below.



When the user clicks on the conflict symbol the three alternatives are displayed.




At the moment we believe that we need to use an element to enable the 'form based editing' control to be displayed. We have tried using elements like <ph />, which work in the above example, but do not work in all DITA contexts.

In a StylesFilter if we are processing an element then it is possible to attach a 'form based editor' using the following code.

    props.put(InplaceEditorCSSConstants.PROPERTY_EDIT, ".");
    props.put(InplaceEditorCSSConstants.PROPERTY_RENDERER_CLASS_NAME, MergeAttributeChooserRenderer.class.getCanonicalName());
    props.put(InplaceEditorCSSConstants.PROPERTY_SWING_EDITOR_CLASS_NAME, MergeAttributeChooserEditor.class.getCanonicalName());

This works for an element, but not a processing instruction.

The AuthorInplaceContext elements allows us to get at the element that the style was attached to, as follows:

    AuthorNode authorNode= authorInplaceContext.getElem();

However, it would be nicer if we could get the nodes (specifically the processing instruction nodes). If this was possible, we would not need to introduce the dummy element in the above example, which introduces DITA validation errors. 

Best Regards,
Anthony.
-- 
-- -------------------------------------------------------------------------
Michael Anthony Smith, DeltaXML Ltd "Michael Anthony Smith, DeltaXML Ltd "Experts in Information Change""
T: +44 1684 869035   E: anthony.smith at deltaxml.com   http://www.deltaxml.com
Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.oxygenxml.com/pipermail/oxygen-sdk/attachments/20121219/24910567/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2012-12-19 at 15.32.22.png
Type: image/png
Size: 8285 bytes
Desc: not available
URL: <http://www.oxygenxml.com/pipermail/oxygen-sdk/attachments/20121219/24910567/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2012-12-19 at 15.32.58.png
Type: image/png
Size: 20900 bytes
Desc: not available
URL: <http://www.oxygenxml.com/pipermail/oxygen-sdk/attachments/20121219/24910567/attachment-0001.png>