Request to enable 'form based editing' from processing instructions
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@deltaxml.com http://www.deltaxml.com Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK
Hello, We will analyze the implications of extending the form control support to generic nodes. We'll let you know as soon as we reach a conclusion. Best regards, Alex -- Alex Jitianu <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com On 19-Dec-12 6:09 PM, Michael Anthony Smith wrote:
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@deltaxml.com <mailto:anthony.smith@deltaxml.com> http://www.deltaxml.com <http://www.deltaxml.com/> Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK
_______________________________________________ oXygen-sdk mailing list oXygen-sdk@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-sdk
participants (2)
-
Michael Anthony Smith -
oXygen XML Editor Support