APEX managing XML data

Question

Hi
Has anyone build an APEX app the reads and writes XML data held in Oracle, either as CLOB or XML DB data ? If so can you tell me how you did it ?
Jules

Answer 1

Hi Jules,
We are managing XML documents through APEX, but treat them as complete documents for editing purposes.
Basically:
1) We have a single XMLTYPE table hold all documents of a given XML schema.
2) When registering the schema, have a defaulttable annotation to create a link with the XDB repository.
3) Load the table via the repository using ftp (recommended for better error-reporting from database) or a webdav client such as Windows Explorer (however, we use Cadaver since the content comes from a linux server). Ensure the instance documents reference the registered schema.
4) Create a relational view atop the xml table.
5) Build a report on this view in APEX. This is for the user to search for the document they are interested in and to choose it for editing. The new 3.1 interactive reports are great for this.
6) Set a link column in the report that takes you to an editing page.
7) On the editing page we use a WYSIWYG XML editor ActiveX control. A small bit of javascript in the page header directs the control to the document via it's location in the repository.
8) When the document is saved by the control, the corresponding table row is automatically updated.
Some things to note with this technique:
1) The current set of embedded XML editors all have a problem with very large documents (blame the browser). Our way around this was to create a subreport that lists a bunch of fragments from the full XML document (aka subdocuments). When the user chooses 1, we extract that fragment to a temp file in the repository and point the editor at it. We then intercept the save and post an UpdateXML() call against the master document. For REALLY large documents/subdocuments, we use a WebDAV-aware client XML editor to work with the content directly from the repository.
2) You don't need to actually store the documents in a table. XML documents can sit in the repository and this technique still works just fine. Good for quick and dirty projects and the editing is very fast since the documents don't need to be stored into other tables, but you lose a lot of the XDB capabilities.
3) The repository will likely request a username and password. This can be hidden from the user with some javascript.
4) ActiveX controls typically need MSIE to run. However, other editors use javascript, or even java, so they can work with other browsers.
5) An ActiveX control wants a "click to activate", but that can also be overcome by referencing the object from a static file containing javascript.
6) Try to use a schema-validating editor so that it is less likely the user will try to store invalid xml.
7) Highly recommend a schema validation routine be inserted into the table's INSERT OR UPDATE trigger to prevent invalid XML from being stored.
If you want to work with the XML as if the elements were columns in forms, or don't want to use the XDB repository, then Earl's post of writing your own row processing seems like the way to go. You might also want to investigate INSTEAD OF triggers for your relational views. And watch out for large XML element nodes which exceed APEX size limits and which will require special processing.
Hope this helps.
Keith