at-libitum / cops Goto Github PK

It seems that the static icon array also gets included with each entry when performing a search.
And come to think of it when looking closer, why does it get included with each entry.
This feels like overkill so this needs to be looked into.

Hmm, I would almost say, why is it included to begin with? Each entry has an item pointing to the corresponding icon already, so why add the full array? Probably a reason for it, we'll see.

see https://github.com/At-Libitum/cops/compare/submitsearch
(that is if it still points to the correct compare target.)

And this is how the result of an in-library search looks.

While debugging I noticed that this new function gets called an awful lot of times, just about every time when a function performs a database function and then often times within that one action it will get called multiple times in a row...

I'm wondering if it would not be better to use the same construction as getDb () and have the class functions refer to a private class variable instead of calling another class function each time...

While on the subject, the calibre_directory is also regularly referenced. Since we already have a static db variable, and adding a private static multi variable seeming to be the next logical step, why not also do the same for the calibre_directory setting, I think it's one of the most referenced variables, if it were to be made a private static variable then this would also make it possible to remove those global references in places where getCurrentOption cannot be used.

it won't speed things up so dramatically that it will be noticeable I suspect. At best it might feel somewhat snappier on really big libraries, but it is bad form and simply the wrong way to do things. While still in the learning process myself it's ill advised to pick up bad habits when I can still avoid it.

Fixing the 'bookdetail' page issue with the title reveals another problem. It now inserts . a spinner icon both in the header and next to the book title in-page. One is enough.

Will be fixed on next commit.

See ff4e61e

eReaders may not notice any side effect if the information to display is retrieved from metadata. On Windows however it has the effect of dropping everything in front of the reserved character.

additional information:

This seems only to happen when cops_update_epub-metadat is set to 1.

And at first I thought that the author was clipped along with everything else in front of the offending OS character ( a : btw) but I just now notice the above mentioned setting affects the outcome.

A title such as HTML5: The Next Generation? - Unknown Author.epub will get written as
HTML5_ The Next Generation_ - Unknown Author.epub if the setting is disabled (i.e. 0 ) and will get written as
The Next Generation.epub if the setting is activated (i.e. 1)

The current "By Letter" views displays entries grouped by the first letter, however, names and titles starting with an accented character, punctuation character or digit are grouped separate from names and titles starting with the same unaccented equivalent character.

Likewise when sorting these names/titles they are sorted to the bottom of the list instead of together with titles starting with the unaccentedversion.

Searching also is affected by this in that a search for i.e. 'Honore' will not find 'Honoré'

The intention is to add an option to group, sort and search that does not make any disitinction between accented characters and their unaccented counterparts in the same way as Calibre currently does.

However, as is stated in this , this can have unwanted side effects in certain languages. So it must also be possible to revert to the language specific grouping/sort/search method.

Ran into a problem after re-using a class field for the purpose it was intended. Turns out bookdetail popup and page don't get supplied with a title in the book data, but instead the page title field is used. However, due to implementing sub titles and always forcing the configured title as main title for a page (and/or popup as in this case), this means the book title now suddenly displays the catalog name.

Refactor all expressions involving configuration options to not use strict type checking so that a controllable feature keeps doing what it is intended to do, even if someone forgets to put quotes around a value. For the purpose of checking whether a setting is activated or not it does not really make all that much difference if the setting is specified as 1 or as "1" if both are considered the same in a relaxed check.

see 3445924

see https://github.com/At-Libitum/cops/compare/by_date

see 9c3a152

Here's the problem. Up to now I've only made incidental use of XDebug. Mostly because it was a pain to find a stable combination of editor and plugin in which it worked consistently.

And along came NetBeans, however, I find that it is incapable of switching file encoding on the fly. It applies the setting project wide. So when opening a file that is not UTF8 encoded, it causes a warning and if continuing, the ansi representation of accented characters gets destroyed. Since most of these occur in the author name, that is in itself not a big deal, easy to fix. It's gonna be a pain though keeping them UTF8 encoded when pulling updates from original COPS.

So why use UTF8? Well, since the wish came to be able to search, sort or group without accented characters not being found, sorted out of order or grouped separately, this means at least one file requires to be UTF8 encoded. And because of stupid NetBeans only applying this project wide all files need to use same encoding.

Since I've wasted a lot of time already trying to get Eclipse to work with XDebug, and now finding that its a breeze using it in NetBeans, I am not inclined to start hunting again so conversion to UTF8 is then the simplest alternative.

The lightbox popup shows X of Y, but it doesn't show the title of the book as caption even though it is capable of doing so. Assuming for now this data is not provided for the lightbox.

When pulling down the tool panel via the Cogwheel icon, focus is automatically placed in the search input field.

Although this may have seemed like a logical approach at first, it is terribly annoying on mobile devices as this automatically causes the device keyboard to popup.

Also, as there are multiple actions possible when opening any view resulting in a booklisting, it is not a given that the reason for pulling down the panel is to perform a search. It could very well have been the intention to use a different sort order or to exclude a specific tag from the listing.

Todo: either completely disable or turn it into a configurable option.

Maybe a weird idea, but while adapting my version of the submit search to follow the same calling pattern as in the original COPS, I glitched somewhere. Instead of the query going through the search functions, the program flow just went through the normal steps as when building the category page of a library, so basically still collecting counts per category but without applying the entered query as filter. Surprisingly however, the results still got displayed in the typeahead dropdown, even though the flow went through a completely different set of queries.

So, I gets to think that with a little adjusting, perhaps these different queries per category could be unified into a single query for different purposes. Afterall, the predefined sql skeleton statements get re-used in different situations too. In theory all it would need is to look if arguments are supplied and if so, use these to as selection criteria for whatever supplied these criteria, query function shouldn't need to care about who (or which function) asks the question. Its purpose in life is to retrieve data given a set of criteria and nothing else.

Is it only criteria that need to be dynamic, or also the columns retrieved in the query.
Well, even that part could be dynamic, but only when it concerns knowing how many results versus the details of those results. when details are wanted it doesn't make all that much difference if three or thirteen attributes are retrieved during a single query, what makes more of a difference is if this is done with or without criteria. If without then better be prepared to cache that data someplace until you're positively sure it's not needed anymore to save further querying the database(s). COPS already implements paging so the number of detail results is controllable so that is already half the battle.

Change checkconfig.php to distinguish between the different library related error conditions.

It already checks if the path is local, so why not also make it check if it ends in a forward slash.

And for that matter, if the new user simply starts with accessing COPS without having done any configuration at all? So also trigger an error for when the catalog setting is 'overlooked'.

See 184ca88, 4dce0c1, 9c7329d and 37f9760

Changed author names function to always bring back both the regular form and sort form so that sorting could be done independent from the preferred display format, and did the same for the book title.

Changed various references to author name to make sure they referenced correct variable.

Changed output processing so that both forms are always present whenever needed.

Adjusted html template and stylesheets to account for both forms being present in output and to make sure that one form stays hidden where both forms are present (on book list and on book detail pages).

Now that the typeahead and the submit search follow the same pattern when displaying results. The next logical step would be to cache the result from a typeahead search so that in the case this search is followed by an Enter key (or Submit click), we wouldn't need to repeat it. This will probably be easier than to add a timeout to the typeahead to wait and see if the Enter key gets pressed (or Submit click).