CIValue.getValue() vs CIValue.getInsertString()
Oxygen general issues.
-
- Posts: 1
- Joined: Wed Aug 15, 2012 10:25 pm
CIValue.getValue() vs CIValue.getInsertString()
Post by IsRunnable »
Here's what I want. I have an attribute called "resourceUuid" that is a reference to another element's "uuid" attribute. In the attribute editing window or in the ctrl-space drop down list in text editing mode, I want to present the user with a list of valid values, but since the value are UUIDs, they aren't very human readable.
Instead of something like:
0524c6b8-8d73-491d-9794-3a02bbe5433c
2ccccf94-871f-4580-8fa6-4db78c54687c
342db3fe-bfe7-4103-a29f-d19bf6b1d1f1
43a68c36-079c-4c73-8c9d-e66221327112
I want to present then with something like:
Student Edition, Unit page 1.1 (Unit-1.1.pdf) 0524c6b8-8d73-491d-9794-3a02bbe5433c
Student Edition, Unit page 1.2 (Unit-1.2.pdf) 2ccccf94-871f-4580-8fa6-4db78c54687c
Student Edition, Unit page 1.3 (Unit-1.3.pdf) 342db3fe-bfe7-4103-a29f-d19bf6b1d1f1
Student Edition, Unit page 1.4 (Unit-1.4.pdf) 43a68c36-079c-4c73-8c9d-e66221327112
I've implemented a SchemaManagerFilter. In the filterAttributeValues method, I return a list of CIValues, which return a different value for getValue() and getInsertString(). According to the documentation, getInsertString() should return "the String to be inserted in the document", and getValue() should return "the actual value." Well, that's as clear as mud. I return CIValues that have the UUID for the insertString value, and the friendly text for the value.
It works as I would expect in text edit mode when I press ctrl-space to get a list of possible values. The list contains the human-friendly values, and when one of those friendly values is selected, just the UUID is inserted into the document. Perfect. That's exactly what I wanted. However, it does NOT work when editing the attribute value in the Author Mode. The dropdown list presents a the same human-friendly list of items, but when I select one, the human-friendly text (the same text in the dropdown) is inserted into the document instead of just the UUID.
Okay, since the documentation sucks (to put in mildly), I decided to just see happens in the debugger. I implement a class called MyCIValue, which extends CIValue, but just logs some debugging output and calls super. I then set a breakpoint in getInsertString(). In text mode, when selecting an item for the list, getInsertString() is called, and the value that it returns is inserted into the document. However, when in Author Mode, getInsertString() is not called.
Got any suggestions for how I can get this to work properly? It would be a lot easier to debug your code if it wasn't obfuscated, but judging by what I've seen, I don't blame you for obfuscating it. I would be ashamed of it too.
Instead of something like:
0524c6b8-8d73-491d-9794-3a02bbe5433c
2ccccf94-871f-4580-8fa6-4db78c54687c
342db3fe-bfe7-4103-a29f-d19bf6b1d1f1
43a68c36-079c-4c73-8c9d-e66221327112
I want to present then with something like:
Student Edition, Unit page 1.1 (Unit-1.1.pdf) 0524c6b8-8d73-491d-9794-3a02bbe5433c
Student Edition, Unit page 1.2 (Unit-1.2.pdf) 2ccccf94-871f-4580-8fa6-4db78c54687c
Student Edition, Unit page 1.3 (Unit-1.3.pdf) 342db3fe-bfe7-4103-a29f-d19bf6b1d1f1
Student Edition, Unit page 1.4 (Unit-1.4.pdf) 43a68c36-079c-4c73-8c9d-e66221327112
I've implemented a SchemaManagerFilter. In the filterAttributeValues method, I return a list of CIValues, which return a different value for getValue() and getInsertString(). According to the documentation, getInsertString() should return "the String to be inserted in the document", and getValue() should return "the actual value." Well, that's as clear as mud. I return CIValues that have the UUID for the insertString value, and the friendly text for the value.
It works as I would expect in text edit mode when I press ctrl-space to get a list of possible values. The list contains the human-friendly values, and when one of those friendly values is selected, just the UUID is inserted into the document. Perfect. That's exactly what I wanted. However, it does NOT work when editing the attribute value in the Author Mode. The dropdown list presents a the same human-friendly list of items, but when I select one, the human-friendly text (the same text in the dropdown) is inserted into the document instead of just the UUID.
Okay, since the documentation sucks (to put in mildly), I decided to just see happens in the debugger. I implement a class called MyCIValue, which extends CIValue, but just logs some debugging output and calls super. I then set a breakpoint in getInsertString(). In text mode, when selecting an item for the list, getInsertString() is called, and the value that it returns is inserted into the document. However, when in Author Mode, getInsertString() is not called.
Got any suggestions for how I can get this to work properly? It would be a lot easier to debug your code if it wasn't obfuscated, but judging by what I've seen, I don't blame you for obfuscating it. I would be ashamed of it too.
-
- Posts: 9445
- Joined: Fri Jul 09, 2004 5:18 pm
Re: CIValue.getValue() vs CIValue.getInsertString()
Dear Steve,
You are right, the API class CIValue is poorly commented and we'll try to improve this.
One of the reasons for this is that CIValue was not originally intended as API and we should have combed it better before making it API.
Our code (except the API) is obfuscated because we are a commercial application, I know that because of this it is frustrating to debug it but unfortunately this cannot be helped.
Now about your problem:
The CIValue object does not (yet) have a means to set a rendered value but to have something different inserted in the document.
The "getValue" method from it should return the value as it was detected in the schema.
The default implementation of the "getInsertString" method returns the same value but having the characters which are forbidden in attribute values like ">" escaped. The Text page makes use of this method, the Author page as you noticed uses directly the "getValue" method because its internal model will escape the attribute value anyway when the Author model gets serialized to XML.
Right now you can use the "CIValue.setAnnotation(String)" method to set an annotation to the value.
The annotation should appear as an additional hint for each value (either in the attributes view or in the ctrl-space content completion window).
What we could do on our side would be to add additional API to the CIValue (like getRenderString(), setRenderString()) which would be used on the Oxygen side to show one value and actually have another one inserted in the document. If you are interested in this approach I can add an improvement request on this.
Regards,
Radu
You are right, the API class CIValue is poorly commented and we'll try to improve this.
One of the reasons for this is that CIValue was not originally intended as API and we should have combed it better before making it API.
Our code (except the API) is obfuscated because we are a commercial application, I know that because of this it is frustrating to debug it but unfortunately this cannot be helped.
Now about your problem:
The CIValue object does not (yet) have a means to set a rendered value but to have something different inserted in the document.
The "getValue" method from it should return the value as it was detected in the schema.
The default implementation of the "getInsertString" method returns the same value but having the characters which are forbidden in attribute values like ">" escaped. The Text page makes use of this method, the Author page as you noticed uses directly the "getValue" method because its internal model will escape the attribute value anyway when the Author model gets serialized to XML.
Right now you can use the "CIValue.setAnnotation(String)" method to set an annotation to the value.
The annotation should appear as an additional hint for each value (either in the attributes view or in the ctrl-space content completion window).
What we could do on our side would be to add additional API to the CIValue (like getRenderString(), setRenderString()) which would be used on the Oxygen side to show one value and actually have another one inserted in the document. If you are interested in this approach I can add an improvement request on this.
Regards,
Radu
Radu Coravu
<oXygen/> XML Editor
http://www.oxygenxml.com
<oXygen/> XML Editor
http://www.oxygenxml.com
Jump to
- Oxygen XML Editor/Author/Developer
- ↳ Feature Request
- ↳ Common Problems
- ↳ DITA (Editing and Publishing DITA Content)
- ↳ SDK-API, Frameworks - Document Types
- ↳ DocBook
- ↳ TEI
- ↳ XHTML
- ↳ Other Issues
- Oxygen XML Web Author
- ↳ Feature Request
- ↳ Common Problems
- Oxygen Content Fusion
- ↳ Feature Request
- ↳ Common Problems
- Oxygen JSON Editor
- ↳ Feature Request
- ↳ Common Problems
- Oxygen PDF Chemistry
- ↳ Feature Request
- ↳ Common Problems
- Oxygen Feedback
- ↳ Feature Request
- ↳ Common Problems
- Oxygen XML WebHelp
- ↳ Feature Request
- ↳ Common Problems
- XML
- ↳ General XML Questions
- ↳ XSLT and FOP
- ↳ XML Schemas
- ↳ XQuery
- NVDL
- ↳ General NVDL Issues
- ↳ oNVDL Related Issues
- XML Services Market
- ↳ Offer a Service