Hi Markus,
2014-06-19 17:06 GMT+02:00 Markus Schneider <[email protected]>: > 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. > Yes, I think also having it configurable from the backend is better. I already plan to had a default configuration so by default user have nothing to do. They only change it if they want some customisation. > > 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?) > Yes having rule can be a posibility. But I prefer to have a real need before adding this kind of feature because it will be not so easy to support and also I have no idea of what exactly a customer will really need (which rule, where we store..). I prefer to have a simple solution for now and them we can refactor/extend the existing code if a customer have the need and the budget ;) By the way your idea is interesting ;) For now I just want to implement a storage per model/field so we can easily serve image with nginx (apache or want you want) without using OpenERP. (I want to have it by model/field in order to share only public data ;) ) > Don't ask me who needs this, just share my mind, what can be possible ;) > > Thanks for your feedback. I think I am going to implement the "storage.configuration" ;) > 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 <[email protected] > > <mailto:[email protected]>>: > > > > 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 > > <[email protected] <mailto:[email protected]>> > > 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: [email protected] > > <mailto:[email protected]> > > 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 : [email protected] > > <mailto:[email protected]> > > 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: [email protected] > 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 : [email protected] Unsubscribe : https://launchpad.net/~openerp-connector-community More help : https://help.launchpad.net/ListHelp
