Suggestion: Plugin API exposing basic metadata

[AlPe]

The plugin developer might want/need to access a couple of basic ebook metadata, like dc:identifier or dc:language.

At the moment, she must call bk.get_opf() and parse the resulting blob.

Although the above requires half a dozen lines of code (if you know lxml and xpath), I am quite sure that this a common situation to the extent that a future version of the Plugin APIs might want to include a call, say get_meta(), to get, say, a Python dict() with the metadata from the current OPF.

[rubeus]

Thats easy: write a class offering high level methods and hide the basic stuff in protected methods. Publish it here so that everyone can access the data more easily.

[eschwartz]

Perhaps a sticky containing useful code fragments, like this calibre recipes sticky here: https://www.mobileread.com/forums/showthread.php?t=70263


The builtin plugin API should be stable and not change in every version just because someone thinks of a new interesting thing you can add to it.
And this allows people to share complicated stuff as well, things that stand less chance of being built into Sigil.

Also means people don't need to wait for a new version of Sigil in order to publish a plugin...

[DiapDealer]

The bookcontainer (Edit-type plugin) object--usually represented "bk" in a plugin--has get|setmetadataxml() methods that can retrieve and set the xml portion of the opf file that deals wirh metadata. There's no need to parse the entire opf to get/set metadata.

bk.getmetadataxml()
parse metadata
meta = rebuilt metadata xml fragment
bk.setmetadataxml(meta)

[AlPe]

Alright, but you still need to parse the resulting XML string to extract the value.

Anyway, just my two cents.

I am currently using:

    def get_meta(self, meta, default=""):
        value = default
        try:
            import lxml.etree as etree
            opf = self.bk.get_opf().encode("utf-8")
            root = etree.fromstring(opf)
            query = "//dc:%s" % (meta)
            namespaces = {"dc": "http://purl.org/dc/elements/1.1/"}
            dc_elem = root.xpath(query, namespaces=namespaces)
            if len(dc_elem) > 0:
                value = dc_elem[0].text
        except:
            pass
        return value

[AlPe]

Originally Posted by rubeus

Thats easy: write a class offering high level methods and hide the basic stuff in protected methods. Publish it here so that everyone can access the data more easily.

My argument in favor of having such a new function in the Plugin API was in fact to avoid duplicating the same code in several plugins.

The builtin plugin API should be stable and not change in every version just because someone thinks of a new interesting thing you can add to it.

Agreed. In fact, I was suggesting adding a new function, not changing existing one.

Anyway, if there is consensus my proposal is unwarranted, no problem, feel free to copy the code above (or modify it with bk.getmetadataxml()), in case you need to extract the value of a metadatum.

[KevinH]

There is an example in the testme plugin that does a quick serial parse of the metadata using QuickParser. So no need to use lxml since it need not exist for Python 2.7 plugins. Calling it parses the metadata into text, tag, attribute and contents fields that are simple python data types. But yes you still need to parse it somehow.

The reason behind that is that epub3 metadata refines makes relationships among those entries and across to manifest entries as well. As any interface would need to identify and build up any refines done and map them to the primary entries. So you will need to parse all of the metadata just to get one entry and be sure of having all of its refines.

Thanks for the code snippet. I may modify it and add it to the plugin developer thread to keep it with the gui pieces and things.

[eschwartz]

I still think a sticky for sharing useful code is a good idea regardless.

And I am also concerned with keeping backwards compatibility.
Sure, people *should* always upgrade to the latest version of Sigil, but I think plugins should still endeavor to work with any version of Sigil (that supports plugins).


I am not necessarily knocking the idea of extending the plugin launcher.

[KevinH]

Originally Posted by eschwartz

I still think a sticky for sharing useful code is a good idea regardless.

Yes that is what this sticky was meant to be ...

https://www.mobileread.com/forums/sho...d.php?t=251452

It does have a few nice links at the front to useful code snippets and docs, but has become a more q&a thing. A new thread is probably needed. I will add it to my ever growing to-do list!

KevinH

[eschwartz]

Originally Posted by KevinH

https://www.mobileread.com/forums/sho...d.php?t=251452

[...] but has become a more q&a thing.

Exactly.

But at least further questions can be addressed in the q&a thread, and code snippets could be posted to some sort of new "reusable code snippets" thread.

[rubeus]

Originally Posted by AlPe

My argument in favor of having such a new function in the Plugin API was in fact to avoid duplicating the same code in several plugins.

Do you have lxml duplicated in each plugin? PIL? strings? No, you havent, you are importing them. So your argument isn't an argument.

[eschwartz]

Originally Posted by eschwartz

Exactly.

But at least further questions can be addressed in the q&a thread, and code snippets could be posted to some sort of new "reusable code snippets" thread.

Sticky Post your Useful Plugin Code Fragments Here