justanr / flask-transfer Goto Github PK

Right now Flask-Transfer has a single custom exception -- UploadError -- which is just a catch all for when something goes wrong. I'd rather not define more exceptions than needed, especially because the last thing the Python community needs is yet another ValidationError.

How much error handling should we be concerned with? Should we take a wtforms approach and collect all the errors before reporting them (potentially causing other errors to be triggered, say we get a JPG but we were expecting a PDF) or just abort on the first issue?

Or should error handling be left to the caller?

Right now, the saving mechanism receives a completely different set of arguments than the rest of Flask-Transfer's calls. On one hand, this is great, one can pass arguments directly down to it. However, I think it makes it potentially awkward: validators and processors receive one set of data to work with and the saving mechanism gets a different one.

If data needs to be shared between these -- say a directory to throw thumbnails into -- it needs to be duplicated.

ImageTransfer = Transfer(preprocessors=[thumbnailify])
meta = {'save_path': get_save_path()}
ImageTransfer.save(filehandle, metadata=meta, save_path=meta['save_path'])

But if the saving mechanism gets the metadata object as well, it can be located in a single place and makes the calling conventions for everything consistent. Everything gets filehandle, metadata, rather than the current everything gets filehandle, metadata except the destination.

Thoughts?

Haven't been any changes to Flask-Transfer for a few months now, and there are a bunch of commits that aren't included in 0.0.1.

Would be great if a 0.0.2 release of Flask-Transfer could be made, so that these commits are included in a stable version.

I had originally designed a Flask-WTForms compatibility layer for the validators. There's still traces of this, such as optionally turning off validation when calling Transfer.save. However, once I added the concept of passing metadata to the validators and didn't see a good of passing metadata to Flask-Transfer validators that end up living on a wtforms field.

Flask-Transfer could provide a custom Form class with a modified Form.validate_on_submit that receives a metadata attribute. But I feel this may be overstepping Flask-Transfer's scope. This also involves injecting a class in between a validator and BaseValidator that intercepts the __call__ and passes the correct attributes instead of field, form.

This could be out of scope for this project and I'm open to creating a Flask-WTF-Transfer (or similar) project that mediates this. Just import the form and validators from there so they can live peacefully together rather than hacking something together that'll distract from Flask-Transfer's goal.

As I'm actually writing documentation (instead of just playing Kingdom Rush....), what if it were possible to nest Transfer objects. Seeing as they are already callable, it'd be possible to pass one into the pre/post processor list and have it run there.

What are the thoughts on formalizing this use?