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> 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 > 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 >
-- 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
