• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

inputRichText with Hexadecimal formatted data

 
Ranch Hand
Posts: 132
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi there,

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?
Carlos.
 
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Carlos Conti
Ranch Hand
Posts: 132
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

Thanks again for your help!
Carlos.
 
Tim Holloway
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic