For applet delivery any web server. We currently use Apache to deploy the sample on our site. For the floating license server you would need a J2EE server, like Tomcat if you want to restrict the access to the licenses.
If you do not need the access restrictions that are possible with a J2EE server you can simplify the deployment of the floating license server by using the standalone version of this server. The standalone license server is a simple Java application that communicates with the Author Componentby TCP/IP connections.
Oracle (formerly Sun) Java JRE version 1.6 update 10 or newer. At least 200 MB disk space and 200MB free memory would be necessary for the Author Component applet.
The applet is signed and will request access to the user machine, in order to store customization data (frameworks). The applet needs to be signed by you with a valid certificate.
The component should work well with newer Java versions but we cannot guarantee this.
Framework files are downloaded on the first load of the applet. Subsequent loads will re-use the cached customization files and will be much faster.
See the explanation above.
A single AuthorComponentFactory instance can create multiple EditorComponentProvider editors which can then be added and managed by the developer who is customizing the component in a Swing JTabbedPane. A single license (floating or user-based) is enough for this.
If you need to run multiple Java Applets or distinct Java processes using the Author Component, the current floating license model allows for now only two concurrent components from the same computer when using the license servlet. An additional started component will take an extra license seat.
No.
What you can see on our web site is just an example of the Author Component (which is a Java Swing component) used in an Applet.
This applet is just for demonstration purposes. It's source can be at most a starting point for a customization. You should implement, sign and deploy your custom applet implementation.
The save operation could be implemented either in JavaScript by requesting the XML content from the Applet or in Java directly working with the Author Component. You would be responsible to send the content back to the CMS.
The applet has a total amount of used memory specified in the JNLP JavaWebstart configuration file which can be increased if necessary. By default it is 156 Mb. It should work comfortably with documents of 1-3 megabytes.
GIF, JPEG, PNG, BMP and SVG.
You could add listeners to intercept clicks and open the clicked links. This would require a good knowledge of the oXygen SDK. The Author Component can only render static images (no GIF animations).
No.
By default no but you could customize the applet that contains the Author Component to save its content periodically to a file on disk.
Yes.
If no customizations are available the content is pasted as simple text. We provide customizations for the major frameworks (DITA, DocBook, TEI, etc.) which use a conversion XSLT stylesheet to convert HTML content from clipboard to the target XML.
Any UTF-8 character can be inserted and rendered provided that the font used for editing supports rendering the characters. The font can be changed by the developers but not by the users. When using a logical font (which by default is Serif for the Author Component) the JVM will know how to map all characters to glyphs. There is no character map available but you could implement one
You can mount on your custom toolbar all actions available in the standalone Oxygen XML Editor application for editing in the Author mode. This includes custom actions defined in the framework customized for each XML type.
The Author Component also can provide the Outline, Model, Elements, and Attributes views which can be added to your own panels (see sample applet).
The Author mode internal engine uses CSS to render XML.
For a special type of XML you can create a custom framework (which also works in an Oxygen XML Editor standalone version) which would also contain default schemas and custom actions. A simple framework would probably need 2-3 weeks development time. For a complex framework with many custom actions it could take a couple of months. Oxygen XML Editor already has frameworks for editing (DocBook, DITA, TEI, etc.) Sources for them are available in the Oxygen SDK.
More than one framework can coexist in the same Oxygen XML Editor instance (the desktop standalone version or the applet version) and can be used at the same time for editing XML documents.
All the UI parts from the Author Component are assembled by you. You could provide two applet implementations: one for advanced/power users and one for technical authors.
You could avoid placing the change tracking toolbar actions in the custom applet. You could also use API to turn change tracking ON when the content has been loaded.
You can remove the change tracking actions completely in a custom applet implementation. Including the ones from the contextual menu.
Using our API you can customize what the Outline or Breadcrumb presents for each XML tag. You can also customize the in-place content completion list.
The API allows for a content completion filter which also affects the Elements view.
Yes, using the Author Component API.
Yes.
A framework developed for the desktop version of the Oxygen XML Editor application can then be bundled with the Author Component in a custom applet. For example, the demo applet from our web site is DITA-aware using the same framework as the Oxygen XML Editor standalone distribution.
A custom version of the applet that includes one or more customized frameworks and user options can be built and deployed for non-technical authors by a technical savvy user using a built-in tool of Oxygen XML Editor. All the authors that load the deployed applet from the same server location will share the same frameworks and options.
A custom editing solution can deploy one or more frameworks that can be used at the same time.