View Single Post
Old 07-09-2011, 09:36 AM   #4
chaley
Grand Sorcerer
chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.
 
Posts: 12,452
Karma: 8012886
Join Date: Jan 2010
Location: Notts, England
Device: Kobo Libra 2
Quote:
Originally Posted by Silek View Post
The rendering problem you mention may be why I am not seeing the GUI entries. I am using the "multiple text, show in tag browser" column type.
Look at the metadata.opf file in the books folder in the library. They do not exhibit the problem.
Quote:
Now the order of the JSON fields is different, but I thought that would not matter.
It won't.
Quote:

The template entry for a custom field is:

My entry is:

<meta>
<name>calibre:user_metadata:#characters</name>
<content>
I have no idea if calibre's xml engine will consider this alternate structure as equivalent to its own.
Quote:
Due to the rendering problem, I do not have a good idea of what the entry is supposed to look like.
As mentioned above, you can see calibre's version in the metadata.opf file.
Quote:
I figure the #value# entry is wrong, but I am not getting an error from calibredb set_metadata. Since I did not get an error, I did not know to dig in to the format (or even, where in the format to look).
The question is whether or not the JSON decode will work. The decoder might not throw an error, but could come up with different values. For example, I note that your string constants in #value# are not quoted. JSON will probably ignore them.
Quote:
I am using this data type because I wanted these entries to show in the tag browser. I suppose I could use dc:subject tags and add then specifically as tags, and leave them as one long comma delimited string in a text field, but that feels kludgy.
There are a lot of types that show up in the tag browser, such as text, enumeration, text/multiple, composite w/show in tag browser checked. You should use the one that makes sense for your data.

I also note that your template declares that the multiple text entry contains names (the is_names in the display attribute). Why did you check that box for tags-like items?
chaley is offline   Reply With Quote