Hi Sebastien, is was looking at your code and setting the "binary.location" hard, is the one i struggle with. A storage.configuration on each field i see the advantage, but i should be a default value, that you need not redefine on every field.
What i think about instead of choosing it on model/field side, maybe a rule system would be more flexible. So that you have the information on each ir.attachment where it stored. So one possible rule is: model=product,field=image => Filestore then you can have additional rules like filesize>1MB or something like this. (asking myself: Hmm should we use OpenERP domain syntax?) Don't ask me who needs this, just share my mind, what can be possible ;) Greetings Markus On 17.06.2014 08:55, Sebastien Beau wrote: > Hi Paul and Markus. > I did some update on my code > https://code.launchpad.net/~akretion-team/server-env-tools/server-env-tools > > And I start to refactor the product image module based on it > https://code.launchpad.net/~akretion-team/openerp-product-attributes/openerp-product-attributes-product-image > > Note, I am thinking about adding an object "storage.configuration" and a > field "storing_configuration_id" on the model "ir.model.fields". The > idea will to use a default storing configuration for every field (on > file sytem for exemple) but after we will be able to customise on every > field from the backend where where you want to store each binary/image > fields (database, S3, ftp, SFTP, Filestore....) > Do you like the idea? (not so hard to implement) > > > > > 2014-05-14 11:02 GMT+02:00 Paul Catinean <paulcatin...@gmail.com > <mailto:paulcatin...@gmail.com>>: > > Hello Sebastien, > > I was just trying to find a solution for this yet again and I > noticed there is no complete module out there for product images > that is accessible to everyone (you are right about the default_code) > > This is an interesting project and I hope to contribute to it if I > can, code, testing etc > > Thanks for you efforts and keep us posted > > > On Wed, May 14, 2014 at 11:44 AM, Markus Schneider > <markus.schnei...@initos.com <mailto:markus.schnei...@initos.com>> > wrote: > > Hi Sebastien, > > we just looking on your solution to get ideas how to implemented a > Attachment field with additional meta data. This helps us a lot, > thank > you for sharing your work. > > So i just want to share my thoughts about your implementation. > So you > solve two problems in one module. I suggest to split it. > > 1) Part: Giving us a new field typ which store more metadata for > a file, > like Imagesize. > > 2) Part: Changing the storage behaviour of ir.attachment. So for > your > case, that you can store the files in a separate path in the > file-system. (I think the reason is to provide them directly > with other > fast web server). > > As i know there are some other concepts to extend the storage > location > for ir.attachment like MongoDB or some cloud specific API. So at > the end > it would be great to combine some metadata binary field with some > storage location module total free. > > Kind Regards > > Markus > > On 01.05.2014 11:55, Sebastien Beau wrote: > > Hi all, > > > > If like me you want to store image and binary in you file > system instead > > of the database this mail can interest you. > > > > Since version 6 we make some improvement in the product image > module in > > order to be able to store image in the file system > > > > (http://bazaar.launchpad.net/~product-core-editors/openerp-product-attributes/7.0/files/head:/product_images/) > > But I am not satisfy by the work done (I did it) because this > > implementation only support the image of product. More over we > use the > > product default code in the path for storing the image and > this make > > mandatory the default code on product which do not fit with > every customer. > > > > After thinking twice, I think the best solution is to > introduce new type > > of field that will manage the storage for us. Indeed if we > implement > > this with a field, we can use it everythere (product, > category, user, > > company....) > > > > Here is my proposal: > > Adding 3 new fields: > > - BinaryField > > - ImageField > > - ImageResizeField > > > > > > An exemple of how using it will be this : > > > > > > _columns = { > > 'binary_test': fields.BinaryField('Test Binary'), > > 'image_test': fields.ImageField('Test Image'), > > 'image_test_resize': fields.ImageResizeField( > > related_field='image_test', > > string='Test Image small', > > height=64, > > width=64, > > ), > > } > > > > Adding this kind of field will also create this field (on fly): > > > > - binary_test_info_id > > - image_test_info_id > > - image_test_resize_info_id > > > > Why adding this field? > > The aim is simple, I want to read the metadata of my image > (path, size, > > extension...) > > For exemple, if you build an external application maybe you > want to get > > the path of the image. > > In this case you just have to do > > "product.image_test_info_id.store_fname" and you get the path. > > Acceding to the image with you external application using the > images > > served by nginx (or apache) is really easy. > > > > I know that "Explicit is better than implicit." but I think It > will be a > > paint to add this field manually. I don't see any other > solution that > > make easy (and compatible with the existing API) to access to > the image > > content or to the image metadata (using the context is not a > good idea > > because you may access to the content of a field and the > information of > > an other field at the same time) > > > > > > I start a POC here : > > > > https://code.launchpad.net/~akretion-team/server-env-tools/server-env-tools > > > > How this work > > > > First the object "binary.binary" > > ================================= > > > > It's just a table that store the metadata of my binary field > (image, > > pdf, video...) and store the path of the binary. > > > > I try to reuse the function to create/write/delete of the > > "ir.attachment" class, because is kind of the same feature. > > > > > > Then the new fields : > > ======================== > > > > BinaryField > > -------------- > > > > BinaryField is a function field with a "fnct" and a "fnct_inv" > already > > defined. Basically when I add a pdf in this kind of field, the > "fnc_inv" > > will create (or update) the "binary.binary" and store the id > of the > > "binary.binary" in the field "my_field_info_id" > > > > > > ImageField > > --------------- > > ImageField inherit of BinaryField. The only difference is that > > ImageField can have resized Image linked so this class will > trigger a > > refresh of resized image > > > > > > ImageResizeField > > ----------------- > > ImageResizeField inherit of ImageField. The best way to > explain it is to > > give an exemple. Let's say that we have added the fields > "image_test" > > and "image_test_resize" (like on the top of my email) > > > > First setting a image in "image_test" > > ------------------------------------- > > If you set a image into the field "image_test" then the > > "image_test_resize" will be refresh. > > The ImageResizefield like the BinaryField create a > "xxx_info_id" field. > > So in this case the resized image is stored in a > "binary.binary" and the > > id of this binary is stored in "image_test_resize_info_id" > > > > > > First setting a image in "image_test_resize" > > --------------------------------------------------- > > Giving the posibility to set the image from the resize field is > > necessary (OpenERP already do that on product image). > > So if you set an image in this king of field, the image will > be store in > > the ImageField related, this mean in the "image_test" and then > the cache > > of the ImageResizeField will be refresh. > > > > > > If you need more details, ask me. I will push some change/fix > in the > > branch so be carefull when you update the code when you test it. > > (creating a new db after pulling the code maybe the best idea) > > > > > > If you are ok with that I will propose a new version of > product_image > > based on it. > > > > If you have better naming idea, share it ! > > > > Thanks for your feedback. > > > > > > > > > > > > > > > > > > > > > > -- > Dipl.-Comp.-Math. Markus Schneider > Softwareentwickler > > initOS GmbH & Co. KG > An der Eisenbahn 1 > 21224 Rosengarten > > Mobil: +49 (0)172 2303699 <tel:%2B49%20%280%29172%202303699> > Phone: +49 (0)4105 5615613 <tel:%2B49%20%280%294105%205615613> > Fax: +49 (0)4105 5615610 <tel:%2B49%20%280%294105%205615610> > > Email: markus.schnei...@initos.com > <mailto:markus.schnei...@initos.com> > Web: http://www.initos.com > > Geschäftsführung: > Dipl. Wirt.-Inf. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke > Haftende Gesellschafterin: initOS Verwaltungs GmbH > > Sitz der Gesellschaft: Rosengarten – Klecken > Amtsgericht Tostedt, HRA 201840 > USt-IdNr: DE 275698169 > Steuer-Nr: 15/205/21402 > > -- > Mailing list: https://launchpad.net/~openerp-connector-community > Post to : openerp-connector-community@lists.launchpad.net > <mailto:openerp-connector-community@lists.launchpad.net> > Unsubscribe : https://launchpad.net/~openerp-connector-community > More help : https://help.launchpad.net/ListHelp > > > -- Dipl.-Comp.-Math. Markus Schneider Softwareentwickler initOS GmbH & Co. KG An der Eisenbahn 1 21224 Rosengarten Mobil: +49 (0)172 2303699 Phone: +49 (0)4105 5615613 Fax: +49 (0)4105 5615610 Email: markus.schnei...@initos.com Web: http://www.initos.com Geschäftsführung: Dipl. Wirt.-Inf. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke Haftende Gesellschafterin: initOS Verwaltungs GmbH Sitz der Gesellschaft: Rosengarten – Klecken Amtsgericht Tostedt, HRA 201840 USt-IdNr: DE 275698169 Steuer-Nr: 15/205/21402 -- Mailing list: https://launchpad.net/~openerp-connector-community Post to : openerp-connector-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~openerp-connector-community More help : https://help.launchpad.net/ListHelp