openerp-connector-community team mailing list archive
-
openerp-connector-community team
-
Mailing list archive
-
Message #00464
Re: Storing Images
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 <paulcatinean@xxxxxxxxx
> <mailto:paulcatinean@xxxxxxxxx>>:
>
> 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.schneider@xxxxxxxxxx <mailto:markus.schneider@xxxxxxxxxx>>
> 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.schneider@xxxxxxxxxx
> <mailto:markus.schneider@xxxxxxxxxx>
> 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@xxxxxxxxxxxxxxxxxxx
> <mailto:openerp-connector-community@xxxxxxxxxxxxxxxxxxx>
> 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.schneider@xxxxxxxxxx
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
Follow ups
References
