[oXygen-sdk] CMS integration: Resolving images
Pascal Beutels
pbeutels at sdl.com
Fri Feb 8 07:06:29 CST 2013
Hi,
In our custom protocol handler, how can we know that oXygen is requesting for
a referenced resource and not the DITA document (topic, ...) itself?
Kind regards,
-Pascal
------------------------------
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
****************************************
More information about the oXygen-sdk
mailing list