I have an inputRichText component which displays data stored in a BLOB field in a MySQL database. The data after being read from the database is stored in the backingbean in hex format. So I guessed using a custom hexadecimal converter would solve the problem. To my surprise, when the page is being loaded, the converter is called and the data is converted correctly (checking while debugging, and see data becomes readable). However, the data at the end of the day displayed inside the editor, keeps being hex formatted, hence the same before conversion. Is this a known bug in the component. Am I missing anything?
Let me post both the editor tag and the converter:
The inputRichText apparently ommits the converted value. Any ideas?
Doesn't MySQL have a "CLOB" datatype? That's the one you really should use to back an inputRichText control.
Offhand, I think you may be getting some confusion here since the converter services of the various utilities can be "helpful" when they think you're looking at binary data, and so what you see isn't necessarily exactly what you got.
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Apr 21, 2010
well, I followed your advise and changed the datatype for the affected columns from BLOB to TEXT (CLOB doesn't exist in MySQL, or atleast in my datatypes combo), and worked!
Thank you very much. I had never used TEXT before, always BLOB, even for texts, on other plattforms. So the solution is fine.
However, shouldn't the converter convert the value as well? It does work for other simpler input controls.
Another solution I was considering was to set up a converter in the JPA ORM file. But your solution came first! However I will give it a try and post the results.
CLOBS came after BLOBs when people started realizing that text deserves special consideration. Not all databases support CLOB primitives, but many ORM systems can at least handle the differences well. Which is good, since Java likes 16-bit Unicode, but a lot of character storage mechanisms are oriented more towards 8-bit ASCII.