- oXygen-sdk - www.oxygenxml.com

Re: [oXygen-sdk] CMS integration: Resolving images
by Pascal Beutels 08 Feb '13

08 Feb '13

Then we probably need a RelativeReferenceResolver for our protocol when inserting e.g. images? ------------------------------ Message: 2 Date: Mon, 4 Feb 2013 08:25:33 -0000 From: "Pascal Beutels" <pbeutels(a)sdl.com> Subject: [oXygen-sdk] CMS integration: Resolving images To: <oxygen-sdk(a)oxygenxml.com> Message-ID: <D7B7EA2108156F42BEC04DEF9C75D66301303CDC(a)emeamail0304.global.sdl.corp> Content-Type: text/plain; charset="us-ascii" Hi, We are creating a plugin for oXygen (14.1) for our DITA based repository. All the content is stored in our repository, also the images, .... When e.g. a topic contains an image element, it only contains the unique identifier: <image href="GUID-1BA7EFB7-FE54-4643-8AEA-6A2E6A92BD85" placement="break"> What would be the best way to resolve this. Are there hooks foreseen in oXygen we can use? Does oXygen require that this image is on the file system (in other words does it expect a file path)? The same for internal links and conrefs. Kind regards, Pascal Beutels

2 3

Re: [oXygen-sdk] Overwriting or Extending the DITA framework
by Pascal Beutels 07 Feb '13

07 Feb '13

Hi, Our final intent is to deliver an MSI that customers of our DITA repository can install so they can use oXygen xml editor to check ou/check in/View/... documents from our repository. The documents are always downloaded to a (configurable) location on the local hard disk, so no WebDAV support. -Pascal -----Original Message----- From: oxygen-sdk-bounces(a)oxygenxml.com [mailto:oxygen-sdk-bounces@oxygenxml.com] On Behalf Of oxygen-sdk-request(a)oxygenxml.com Sent: maandag 4 februari 2013 19:00 To: oxygen-sdk(a)oxygenxml.com Subject: oXygen-sdk Digest, Vol 4, Issue 2 Send oXygen-sdk mailing list submissions to oxygen-sdk(a)oxygenxml.com To subscribe or unsubscribe via the World Wide Web, visit http://www.oxygenxml.com/mailman/listinfo/oxygen-sdk or, via email, send a message with subject or body 'help' to oxygen-sdk-request(a)oxygenxml.com You can reach the person managing the list at oxygen-sdk-owner(a)oxygenxml.com When replying, please edit your Subject line so it is more specific than "Re: Contents of oXygen-sdk digest..." Today's Topics: 1. Re: Overwriting or Extending the DITA framework (Oxygen XML Editor Support) 2. CMS integration: Resolving images (Pascal Beutels) 3. Re: CMS integration: Resolving images (Oxygen XML Editor Support) ---------------------------------------------------------------------- Message: 1 Date: Mon, 04 Feb 2013 09:29:05 +0200 From: Oxygen XML Editor Support <support(a)oxygenxml.com> Subject: Re: [oXygen-sdk] Overwriting or Extending the DITA framework To: oxygen-sdk(a)oxygenxml.com Message-ID: <510F6341.2040003(a)oxygenxml.com> Content-Type: text/plain; charset=windows-1252; format=flowed Hi Pascal, What is your final intent? Do you want to distribute a plugin which can be installed into any Oxygen installation to allow validation and editing support for your slightly modified DITA content? We have some API like: > ro.sync.exml.workspace.api.util.XMLUtilAccess.addPriorityEntityResolve > r(EntityResolver) which would allow you to return your own DTD content when certain DITA public IDs are resolved. This would work for validating and providing content completion for your type of documents. But the API does not allow you to see for which XML content the entity resolver was called because the catalog resolver is called from many parts of the editor. Usually this kind of customization is done by distributing a custom framework (which can be a copy of our DITA framework with some things changed). A custom framework can also be distributed like an addon together with the plugin. > These customizations also require special rendering in the Author view, so we also need to extend the standard DITA css files. We do not (yet) have Java API which would allow you to add an additional CSS content for rendering a certain opened XML document. In Oxygen 14.2 (in a couple of weeks) we will add a special type of plugin extension which will allow you to add a StylesFilter (ro.sync.ecss.extensions.api.StylesFilter) > We can make the distinction between standard DITA and DITA files > coming from our repository, so we would like to do this without > changing the default behavior of DITA files not coming from our > repository You could create your own framework (document type) starting by copying our DITA document type. In the Preferences->"Document Type Association" page your document type would be placed before the usual DITA one (a document type has a priority field which can be increased). And your document type would have an association rule which would match only your type of XML documents (you can implement an interface "ro.sync.ecss.extensions.api.DocumentTypeCustomRuleMatcher" to create a custom rule matcher). If you have a custom DITA document type, you can change the CSS and catalogs in it to suit your situation. Regards, Radu Radu Coravu <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com On 2/1/2013 5:16 PM, Pascal Beutels wrote: > Hi, > > We are creating a plugin for oXygen (14.1) for our DITA based repository. > > We have some customizations (not specializations) on the DITA DTD?s, > but our DITA files contain the standard DITA public id?s. > > Is there a way to extend the oXygen DITA framework, so we can ?inject? > our catalog instead of the default DITA catalog? > > These customizations also require special rendering in the Author > view, so we also need to extend the standard DITA css files. > > We can make the distinction between standard DITA and DITA files > coming from our repository, so we would like to do this without > changing the default behavior of DITA files not coming from our > repository > > Kind regards, > > Pascal > > > > _______________________________________________ > oXygen-sdk mailing list > oXygen-sdk(a)oxygenxml.com > http://www.oxygenxml.com/mailman/listinfo/oxygen-sdk > ------------------------------ Message: 2 Date: Mon, 4 Feb 2013 08:25:33 -0000 From: "Pascal Beutels" <pbeutels(a)sdl.com> Subject: [oXygen-sdk] CMS integration: Resolving images To: <oxygen-sdk(a)oxygenxml.com> Message-ID: <D7B7EA2108156F42BEC04DEF9C75D66301303CDC(a)emeamail0304.global.sdl.corp> Content-Type: text/plain; charset="us-ascii" Hi, We are creating a plugin for oXygen (14.1) for our DITA based repository. All the content is stored in our repository, also the images, .... When e.g. a topic contains an image element, it only contains the unique identifier: <image href="GUID-1BA7EFB7-FE54-4643-8AEA-6A2E6A92BD85" placement="break"> What would be the best way to resolve this. Are there hooks foreseen in oXygen we can use? Does oXygen require that this image is on the file system (in other words does it expect a file path)? The same for internal links and conrefs. Kind regards, Pascal Beutels

2 1

CMS integration: Resolving images
by Pascal Beutels 04 Feb '13

04 Feb '13

Hi, We are creating a plugin for oXygen (14.1) for our DITA based repository. All the content is stored in our repository, also the images, .... When e.g. a topic contains an image element, it only contains the unique identifier: <image href="GUID-1BA7EFB7-FE54-4643-8AEA-6A2E6A92BD85" placement="break"> What would be the best way to resolve this. Are there hooks foreseen in oXygen we can use? Does oXygen require that this image is on the file system (in other words does it expect a file path)? The same for internal links and conrefs. Kind regards, Pascal Beutels

2 1

Overwriting or Extending the DITA framework
by Pascal Beutels 04 Feb '13

04 Feb '13

Hi, We are creating a plugin for oXygen (14.1) for our DITA based repository. We have some customizations (not specializations) on the DITA DTD's, but our DITA files contain the standard DITA public id's. Is there a way to extend the oXygen DITA framework, so we can 'inject' our catalog instead of the default DITA catalog? These customizations also require special rendering in the Author view, so we also need to extend the standard DITA css files. We can make the distinction between standard DITA and DITA files coming from our repository, so we would like to do this without changing the default behavior of DITA files not coming from our repository Kind regards, Pascal

2 1

Installation location of oXygen on Windows.
by Pascal Beutels 30 Jan '13

30 Jan '13

Hi, We are creating a plugin for oXygen (14.1, 32-bit, windows only for the moment) and want to install that plugin (and all the related files) in the plugins folder. In order to find the installation location of oXygen we found the following key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\8531-1 278-6363-8538\InstallLocation Can we rely on this particular key? Does it change with a new version (minor, major) of oXygen? Kind regards, Pascal

2 1

User-configurable options for a plugin extension
by Koeser, Rebecca Sutton 18 Jan '13

18 Jan '13

I'm working on a plugin extension for standalone Oxygen that will have some user-configurable settings, and I was wondering if there is any standard way to handle that type of thing. In particular, it would be neat if there was a way for a plugin to define options to be listed in the global Preferences. My current plan is to build a simple dialog box that with the needed input fields and store the user's input in the workspace option storage, but I wanted to check before I implement it in case there is a better option available. I'd appreciate any suggestions or input. Thanks. ________________________________ This e-mail message (including any attachments) is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message (including any attachments) is strictly prohibited. If you have received this message in error, please contact the sender by reply e-mail message and destroy all copies of the original message (including attachments).

3 3

oXygen Users Meetup @ XML Prague
by George Cristian Bina 11 Jan '13

11 Jan '13

Hi all, I want to invite you to attend XML Prague and the oXygen Users Meetup that takes place in the pre-conference day of XML Prague. The oXygen Users Meetup is a free event but registration is required. You can register online at: http://www.oxygenxml.com/oXygen-user-meetup-Prague2013.html The oXygen meetup is planned for Friday afternoon, February 8, with the following agenda: http://www.oxygenxml.com/oXygen-user-meetup-Prague2013.html#agenda-Prague20… The registration for XML Prague costs 40 EUR (or 100 EURO if you include lunches and the reception) and you can register online at http://www.xmlprague.cz/conference-registration/ The XML Prague conference agenda is available at http://www.xmlprague.cz/2012/12/21/preliminary-list-of-sessions/ I look forward to meeting you in Prague next month! Best Regards, George -- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com

1 0

Author Component 14.2 API will allow multiple editing modes (Text/Author)
by Oxygen XML Editor Support 07 Jan '13

07 Jan '13

Hi everybody, When an XML document is opened in a standalone version of Oxygen, it can be edited in three different modes (Text/Grid/Author). Starting with version 14.2 (in a couple of months) the Author Component Project (which allows embedding an Author component as a Java applet in a web page) will also have API to create multiple editing modes for an opened XML document (for example Text/Author or even Text/Grid/Author). Some of the old Java API (the AuthorComponentProvider) was deprecated but will continue to work. The ro.sync.ecss.samples.AuthorComponentSample was updated to use the new API in order to allow editing the XML in two modes (Text and Author). If anybody is willing to try out and discuss the new API, I uploaded an Author Component Sample 14.2 beta project (which has Javadoc and API sources) here: > http://www.oxygenxml.com/userFiles/author-component-sample.zip Regards, Radu Radu Coravu <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com

1 0

Setting a StylesFilter through the API
by Michael Anthony Smith 02 Jan '13

02 Jan '13

Hello, Is there a way of adding StylesFilter object to an arbitrary framework via the API, rather than having to manually configure it for each framework independently? If there is not a mechanism for adding StylesFilter object's already, possibly it could be added to the 'ExtensionBundle API class'; here the idea is that a third-party plugin/extension could add a StylesFilter to a 'styles filter chain' that is maintained by an extension bundle API. Alternatively, it might be appropriate to add this 'styles filter chain' idea to to one of the Editor[Page] API classes. The context for this query/request is included as a postscript to this email; this discusses how we have currently managed to get our StylesFilter to be used. If it were possible to add a StylesFilter to an arbitrary document through the 'WorkspacePlugin' API, I believe our 'merge conflict resolver' extension could be provided as an oXygen plugin (without the need for any user configuration of the oXygen preferences). Best regards, Anthony. PS: I am involved in a development of an oXygen extension/plugin that enables 'conflict resolving of merged documents'. Thanks to your previous help we are now able to highlight the 'merge updates/conflicts' between two processing instructions, enable them the available options to be selected, and the currently selected option to be edited. We still have to add some functionality such as 'the ability to accept currently selected content', but this should be straightforward (given what we have already got working). Currently we are using a mixture of oXygen's Author and Plugin SDK APIs, and a manual configuration of the 'document type association' in order to add our 'merge conflict' styling. The following screenshot shows how we are manually updating the DITA 'document type' to add this styling. -- -- ------------------------------------------------------------------------- Michael Anthony Smith, DeltaXML Ltd "Michael Anthony Smith, DeltaXML Ltd "Experts in Information Change"" T: +44 1684 869035 E: anthony.smith(a)deltaxml.com http://www.deltaxml.com Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK

2 1

Request to enable 'form based editing' from processing instructions
by Michael Anthony Smith 20 Dec '12

20 Dec '12

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(a)deltaxml.com http://www.deltaxml.com Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK

2 1