This large-ish pull request provides a rewrite of the addepub command and replaces the add_book view, which in turn spawned a series of many related changes, in particular some tweaks to models. The details can be found on each commit, but the highlights are that, after merging:
The addepub command now accepts single files and folders, and should tolerate problems with the epubs more gracefully (cleaning up, etc).
The add_book view has been replaced with a two-step process: first, upload the file, which is parsed and validated. If successful, the info from the epub is used as a basis for the second step, where the user can customize the fields as previously.
models.Book now holds both the uploaded file (a copy of the original file in case of importing via command line) and a string with the original file path, and download_book returns the Django-stored file (ie. the original file path is not really used other than for presentational purposes).
Duplicate Book detection relies solely on file_sha256sum - if a file with the same sha256 hash exists, the DB won't allow to add another one.
The models.Book fields' blank and null have been revised, keeping the user-editable "required" fields to a minimum (author, title).
It also spawned quite a bunch of _TODO_s and issues that should be discussed and polished, in particular:
The user cannot upload a cover during add_book, as it is gathered automatically during the epub parsing, which is a bit inconvenient. It is currently possible to change the cover on edit_book, the admin, etc. though
The add view template is rather raw and ugly.
Futher work is needed for isolating the epub parsing and better handling of errors.
There is a higher than desired amount of repetition for the addepub and add_view flow that should probably be merged and moved somewhere else (possible the model or a manager).
Lots of internal stuff.
Testing has not been that extensive - it is quite possible that these changes break some other functionality. In particular, non-conformant epubs have not been tested properly.
The main idea is that this pull request provides a sane and safe starting point for future modifications and discussion: it should not be considered complete or fully tested, and the decisions in regards to the "design" issues (handling duplication, model fields, etc) are basically an effort for keeping things simple and flexible, and further refined.
This large-ish pull request provides a rewrite of the
addepubcommand and replaces theadd_bookview, which in turn spawned a series of many related changes, in particular some tweaks tomodels. The details can be found on each commit, but the highlights are that, after merging:addepubcommand now accepts single files and folders, and should tolerate problems with the epubs more gracefully (cleaning up, etc).add_bookview has been replaced with a two-step process: first, upload the file, which is parsed and validated. If successful, the info from the epub is used as a basis for the second step, where the user can customize the fields as previously.models.Booknow holds both the uploaded file (a copy of the original file in case of importing via command line) and a string with the original file path, anddownload_bookreturns the Django-stored file (ie. the original file path is not really used other than for presentational purposes).Bookdetection relies solely onfile_sha256sum- if a file with the same sha256 hash exists, the DB won't allow to add another one.models.Bookfields'blankandnullhave been revised, keeping the user-editable "required" fields to a minimum (author, title).It also spawned quite a bunch of _TODO_s and issues that should be discussed and polished, in particular:
add_book, as it is gathered automatically during the epub parsing, which is a bit inconvenient. It is currently possible to change the cover onedit_book, the admin, etc. thoughadd viewtemplate is rather raw and ugly.addepubandadd_viewflow that should probably be merged and moved somewhere else (possible the model or a manager).The main idea is that this pull request provides a sane and safe starting point for future modifications and discussion: it should not be considered complete or fully tested, and the decisions in regards to the "design" issues (handling duplication, model fields, etc) are basically an effort for keeping things simple and flexible, and further refined.