[oXygen-sdk] CMS integration: Resolving images
Oxygen XML Editor Support
support at oxygenxml.com
Fri Feb 8 07:25:52 CST 2013
Hi Pascal,
So the user opens a topic in Oxygen using a custom protocol like:
sdl://path/to/topic.dita
Then the user calls the "Insert Image" toolbar action.
I will assume that you have already added an URL chooser customizer
(there is an example in the CustomWorkspaceAccess sample Java class):
ReferencesCustomizer.addInputURLChooserCustomizer(InputURLChooserCustomizer)
Then the user uses your custom "Browser CMS" action to browse the CMS
and choose an image. Your action must return an absolute URL so you can
return something like:
sdl://GUID-1BA7EFB7-FE54-4643-8AEA-6A2E6A92BD85
Oxygen will try to make this URL relative to the URL of the opened
topic, and will fail in this case because the image @href is actually an
ID and not a path to a resource.
Then indeed you could set a relative references resolver (like the
example in the CustomWorkspaceAccess).
which when receives a base URL like:
sdl://path/to/topic.dita
and a child URL like:
sdl://GUID-1BA7EFB7-FE54-4643-8AEA-6A2E6A92BD85
actually returns GUID-1BA7EFB7-FE54-4643-8AEA-6A2E6A92BD85.
This should probably work.
Regards,
Radu
Radu Coravu
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com
On 2/8/2013 2:57 PM, Pascal Beutels wrote:
> 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 at sdl.com>
> Subject: [oXygen-sdk] CMS integration: Resolving images
> To: <oxygen-sdk at oxygenxml.com>
> Message-ID:
>
> <D7B7EA2108156F42BEC04DEF9C75D66301303CDC at 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
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://www.oxygenxml.com/pipermail/oxygen-sdk/attachments/20130204/8cee91de/a
> ttachment-0001.html
>
> ------------------------------
>
> Message: 3
> Date: Mon, 04 Feb 2013 11:11:10 +0200
> From: Oxygen XML Editor Support <support at oxygenxml.com>
> Subject: Re: [oXygen-sdk] CMS integration: Resolving images
> To: oxygen-sdk at oxygenxml.com
> Message-ID: <510F7B2E.7000306 at oxygenxml.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> Hi Pascal,
>
> Right now how exactly are you opening the XML files from the CMS? Did you
> create a custom protocol or are you relying on WebDav?
>
> Oxygen works inside using Java URLs.
> Usually references (to images, to links, conrefs) are converted to URLs by
> using the URL of the current opened resource (topic). Then Oxygen requests
> the content for these URLs to the URL protocol handler.
>
> Most (probably all known) CMS vendors who integrated with Oxygen took this
> approach:
>
>> http://www.oxygenxml.com/doc/ug-oxygen/index.html#tasks/howto-cms-plug
>> in.html
>
> Basically you use a plugin extension to define a custom URL protocol like:
>
> "sdl://...."
>
> Then you a Browse or "Check out" button on the application's toolbar using a
> Workspace Access plugin extension.
> The browse button will show the user your custom CMS browser and the user
> will choose a resource. Then you call our API
> (ro.sync.exml.workspace.api.Workspace.open(URL)) to open the resource using
> your custom protocol, something like:
>
> "sdl://path/to/resource.dita"
>
> Oxygen will request content for that resource from your custom protocol
> handler and your code will contact the CMS to obtain it. When Oxygen will
> find relative resources (like the image
> "GUID-1BA7EFB7-FE54-4643-8AEA-6A2E6A92BD85") it will consider them relative
> to the opened XML file, will create for them an URL like:
>
> "sdl://path/to/GUID-1BA7EFB7-FE54-4643-8AEA-6A2E6A92BD85"
>
> and will call again your protocol handler to obtain the content for it.
>
> Your custom protocol handler also gets called to produce an output stream if
> Oxygen wants to save the content of the edited resource.
>
> In dialogs in which the user needs to browse again the CMS to look for a
> certain resource (like Insert Image, Insert Conref, Insert Cross
> Reference) we have API which allows you to add a custom action for browsing
> the CMS:
>
>> ro.sync.exml.workspace.api.standalone.ReferencesCustomizer.addInputURL
>> ChooserCustomizer(InputURLChooserCustomizer)
>
> This API is used in the sample Java class
> "CustomWorkspaceAccessPluginExtension" present in our Plugins SDK as a sample
> of Workspace Access plugin.
>
> Regards,
> Radu
>
> Radu Coravu
> <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
> http://www.oxygenxml.com
>
> On 2/4/2013 10:25 AM, Pascal Beutels wrote:
>> 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
>>
>>
>>
>> _______________________________________________
>> oXygen-sdk mailing list
>> oXygen-sdk at oxygenxml.com
>> http://www.oxygenxml.com/mailman/listinfo/oxygen-sdk
>>
>
>
> ------------------------------
>
> _______________________________________________
> oXygen-sdk mailing list
> oXygen-sdk at oxygenxml.com
> http://www.oxygenxml.com/mailman/listinfo/oxygen-sdk
>
>
> End of oXygen-sdk Digest, Vol 4, Issue 2
> ****************************************
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 07 Feb 2013 13:48:01 +0200
> From: Oxygen XML Editor Support <support at oxygenxml.com>
> Subject: Re: [oXygen-sdk] Overwriting or Extending the DITA framework
> To: oxygen-sdk at oxygenxml.com
> Message-ID: <51139471.2000809 at oxygenxml.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi Pascal,
>
> I understand, then that MSI will probably install Oxygen standalone (XML
> Editor, Author or Developer) + your plugins + maybe a modified version of the
> DITA framework which will work with your modified DTDs.
>
> So when the user checks out a resource, it will actually be brought down from
> the server to the local disk, right?
> Even so, a resource has references to images or links to other resources
> which are still on the CMS.
>
> So having a custom protocol (which either resolves the resource on disk or
> downloads it from the CMS if not present on the local disk) makes sense. The
> initial opened XML (which was already checked out) is loaded using the custom
> protocol (but from the local disk). When additional calls are made to your
> custom protocol handler to load relative referenced resources which are not
> yet on disk (maybe a referenced image or the user clicked a link in the topic
> to open the target topic) you download from the CMS the topic and bring it
> locally.
>
> Regards,
> Radu
>
> Radu Coravu
> <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
> http://www.oxygenxml.com
>
> On 2/7/2013 10:37 AM, Pascal Beutels wrote:
>> 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 at oxygenxml.com
>> [mailto:oxygen-sdk-bounces at oxygenxml.com] On Behalf Of
>> oxygen-sdk-request at oxygenxml.com
>> Sent: maandag 4 februari 2013 19:00
>> To: oxygen-sdk at oxygenxml.com
>> Subject: oXygen-sdk Digest, Vol 4, Issue 2
>>
>> Send oXygen-sdk mailing list submissions to
>> oxygen-sdk at 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 at oxygenxml.com
>>
>> You can reach the person managing the list at
>> oxygen-sdk-owner at 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 at oxygenxml.com>
>> Subject: Re: [oXygen-sdk] Overwriting or Extending the DITA framework
>> To: oxygen-sdk at oxygenxml.com
>> Message-ID: <510F6341.2040003 at 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.addPriorityEntityResolv
>>> e
>>> 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 at 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 at sdl.com>
>> Subject: [oXygen-sdk] CMS integration: Resolving images
>> To: <oxygen-sdk at oxygenxml.com>
>> Message-ID:
>>
>> <D7B7EA2108156F42BEC04DEF9C75D66301303CDC at 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
>>
>>
>>
>> -------------- next part -------------- An HTML attachment was
>> scrubbed...
>> URL:
>> http://www.oxygenxml.com/pipermail/oxygen-sdk/attachments/20130204/8ce
>> e91de/a
>> ttachment-0001.html
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Mon, 04 Feb 2013 11:11:10 +0200
>> From: Oxygen XML Editor Support <support at oxygenxml.com>
>> Subject: Re: [oXygen-sdk] CMS integration: Resolving images
>> To: oxygen-sdk at oxygenxml.com
>> Message-ID: <510F7B2E.7000306 at oxygenxml.com>
>> Content-Type: text/plain; charset=windows-1252; format=flowed
>>
>> Hi Pascal,
>>
>> Right now how exactly are you opening the XML files from the CMS? Did
>> you create a custom protocol or are you relying on WebDav?
>>
>> Oxygen works inside using Java URLs.
>> Usually references (to images, to links, conrefs) are converted to
>> URLs by using the URL of the current opened resource (topic). Then
>> Oxygen requests the content for these URLs to the URL protocol handler.
>>
>> Most (probably all known) CMS vendors who integrated with Oxygen took
>> this
>> approach:
>>
>>> http://www.oxygenxml.com/doc/ug-oxygen/index.html#tasks/howto-cms-plu
>>> g
>>> in.html
>>
>> Basically you use a plugin extension to define a custom URL protocol like:
>>
>> "sdl://...."
>>
>> Then you a Browse or "Check out" button on the application's toolbar
>> using a Workspace Access plugin extension.
>> The browse button will show the user your custom CMS browser and the
>> user will choose a resource. Then you call our API
>> (ro.sync.exml.workspace.api.Workspace.open(URL)) to open the resource
>> using your custom protocol, something like:
>>
>> "sdl://path/to/resource.dita"
>>
>> Oxygen will request content for that resource from your custom
>> protocol handler and your code will contact the CMS to obtain it. When
>> Oxygen will find relative resources (like the image
>> "GUID-1BA7EFB7-FE54-4643-8AEA-6A2E6A92BD85") it will consider them
>> relative to the opened XML file, will create for them an URL like:
>>
>> "sdl://path/to/GUID-1BA7EFB7-FE54-4643-8AEA-6A2E6A92BD85"
>>
>> and will call again your protocol handler to obtain the content for it.
>>
>> Your custom protocol handler also gets called to produce an output
>> stream if Oxygen wants to save the content of the edited resource.
>>
>> In dialogs in which the user needs to browse again the CMS to look for
>> a certain resource (like Insert Image, Insert Conref, Insert Cross
>> Reference) we have API which allows you to add a custom action for
>> browsing the CMS:
>>
>>> ro.sync.exml.workspace.api.standalone.ReferencesCustomizer.addInputUR
>>> L
>>> ChooserCustomizer(InputURLChooserCustomizer)
>>
>> This API is used in the sample Java class
>> "CustomWorkspaceAccessPluginExtension" present in our Plugins SDK as a
>> sample of Workspace Access plugin.
>>
>> Regards,
>> Radu
>>
>> Radu Coravu
>> <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
>> http://www.oxygenxml.com
>>
>> On 2/4/2013 10:25 AM, Pascal Beutels wrote:
>>> 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
>>>
>>>
>>>
>>> _______________________________________________
>>> oXygen-sdk mailing list
>>> oXygen-sdk at oxygenxml.com
>>> http://www.oxygenxml.com/mailman/listinfo/oxygen-sdk
>>>
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> oXygen-sdk mailing list
>> oXygen-sdk at oxygenxml.com
>> http://www.oxygenxml.com/mailman/listinfo/oxygen-sdk
>>
>>
>> End of oXygen-sdk Digest, Vol 4, Issue 2
>> ****************************************
>> _______________________________________________
>> oXygen-sdk mailing list
>> oXygen-sdk at oxygenxml.com
>> http://www.oxygenxml.com/mailman/listinfo/oxygen-sdk
>>
>
>
> ------------------------------
>
> _______________________________________________
> oXygen-sdk mailing list
> oXygen-sdk at oxygenxml.com
> http://www.oxygenxml.com/mailman/listinfo/oxygen-sdk
>
>
> End of oXygen-sdk Digest, Vol 4, Issue 3
> ****************************************
> _______________________________________________
> oXygen-sdk mailing list
> oXygen-sdk at oxygenxml.com
> http://www.oxygenxml.com/mailman/listinfo/oxygen-sdk
>
More information about the oXygen-sdk
mailing list