Quote:
Originally Posted by capink
Running over non selected books is something I always pondered, not just for Single Field Edit, but for all builtin actions with the exception of calibre actions, which have to be always selection based, since the actions are not under the plugin control.
|
That is a good idea.
Quote:
The way I imagined it was a template based solution, where the template returns list of ids. For example, to run over all ids the template below can be used:
Code:
program:
from_search('id', '')
|
I thought of this. My concern was that the template functions explode string lists, which is *very slow* for large lists such as thousands of books. If you (we) go down this road then we might want to introduce a specific type and associated functions for book lists that uses a python set underneath. I think this would be OK in the specific case of lists (sets) of numbers. I need to look at this if we want to try it.
Quote:
The book_vars ids will need a new template function, since book_vars always act on one selected row (the row containing the current index). Or maybe modify both book_vars and set_book_vars and make them accept id values.
|
My idea was to use the key to the book_vars dict, which as far as I can tell is always the book id (I think book_vars is {book_id: {var_name: value}}). Setting any var would add the book to the list to be processed. The template would need to know what it is doing.
That said, a chain_vars-like action that returns a list of books is probably the best solution. That gets us back to the above questions...
Quote:
The stumbling block was whether to implement this for each action separately, or can there be a better way to implement a general mechanism used by all actions. Any suggestions would be welcome. This might take some time until I reach a solution I am comfortable with.
|
I agree. I sometimes don't think enough about solutions and end up making something that doesn't work very well but must be maintained for compatibility.
You (we) also need to ensure that the complexity doesn't rise beyond the "usable point". That is a problem I have had with the template language for the last 10 years.
Quote:
Edit: One concern with this approach will be how handle invalid template output as they will be difficult to validate ahead of time.
|
I think that functional validation is hopeless. Who knows what the "template program" is supposed to do, and who knows if it is doing it correctly? Only the user. Verifying syntax is about the best one can do, unless some test mechanism is introduced where the action is run but nothing is permanent. How to do that in a chain of actions escapes me.