Re: svn commit: r1076507 deletes the images folder.

[rohit]

hi,

i see that in this commit the images folders are being deleted. I assume that anyone running ofbiz on its trunk would lose all the product images if they updated their code as the folder will be deleted.

please correct me if I am wrong. and if this is the case, i am really surprised how such a major change can be included without further discussions. the current commit also shows that a new folder is created for every product, thus if a store had say 100K products, there will be 100K additional folders created. I am not sure if this is at all expected or desirable and before getting such major changes incorporated in the trunk, it has not been discussed at all.

please post your feedback.

thanks

Rohit
 

[hans_bakker]

For your information this is what the log message says:

Log:
issue https://issues.apache.org/jira/browse/OFBIZ-4194: reorder of
product images and extension of the <@ofbizcontenturl macro. A
contribution of Antwebsystems employee Tukkata

Regards,
Hans

On Wed, 2011-03-09 at 04:20 -0800, rohit wrote:

> hi,
>
> i see that in this commit the images folders are being deleted. I assume
> that anyone running ofbiz on its trunk would lose all the product images if
> they updated their code as the folder will be deleted.
>
> please correct me if I am wrong. and if this is the case, i am really
> surprised how such a major change can be included without further
> discussions. the current commit also shows that a new folder is created for
> every product, thus if a store had say 100K products, there will be 100K
> additional folders created. I am not sure if this is at all expected or
> desirable and before getting such major changes incorporated in the trunk,
> it has not been discussed at all.
>
> please post your feedback.
>
> thanks
>
> Rohit
>  
>
> -----
> saanjhi.com
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/Re-svn-commit-r1076507-deletes-the-images-folder-tp3343463p3343463.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.

--
Ofbiz on twitter: http://twitter.com/apache_ofbiz
Myself on twitter: http://twitter.com/hansbak
Antwebsystems.com: Quality services for competitive rates.

[hans_bakker]

Hi Rohit,

Further to this subject a made a notice in the upgrade document at:
https://cwiki.apache.org/confluence/display/OFBTECH/Revisions+Requiring
+Data+Migration

thanks for your comment.

Regards,
Hans


On Wed, 2011-03-09 at 04:20 -0800, rohit wrote:

> hi,
>
> i see that in this commit the images folders are being deleted. I assume
> that anyone running ofbiz on its trunk would lose all the product images if
> they updated their code as the folder will be deleted.
>
> please correct me if I am wrong. and if this is the case, i am really
> surprised how such a major change can be included without further
> discussions. the current commit also shows that a new folder is created for
> every product, thus if a store had say 100K products, there will be 100K
> additional folders created. I am not sure if this is at all expected or
> desirable and before getting such major changes incorporated in the trunk,
> it has not been discussed at all.
>
> please post your feedback.
>
> thanks
>
> Rohit
>  
>
> -----
> saanjhi.com
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/Re-svn-commit-r1076507-deletes-the-images-folder-tp3343463p3343463.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.

--
Ofbiz on twitter: http://twitter.com/apache_ofbiz
Myself on twitter: http://twitter.com/hansbak
Antwebsystems.com: Quality services for competitive rates.

[Eric DE MAULDE]

Hi Hans,

In your issue, you havn't written why your new image file system
(image.filename.format propertie)
is better than the original ?

What about the multiple productId directories ?

Save image with ScaleImage.java is now conflicting with the old image
file system because create image filename like "large.jpg" ...

What is the entity to request to find images related to a product,
uploaded by the image management ?
Or How request an image from the image management ?

Thanks

Eric

On Wed, 2011-03-09 at 19:41 +0700, Hans Bakker wrote:

> For your information this is what the log message says:
>
> Log:
> issue https://issues.apache.org/jira/browse/OFBIZ-4194: reorder of
> product images and extension of the <@ofbizcontenturl macro. A
> contribution of Antwebsystems employee Tukkata
>
> Regards,
> Hans
>
> On Wed, 2011-03-09 at 04:20 -0800, rohit wrote:
> > hi,
> >
> > i see that in this commit the images folders are being deleted. I assume
> > that anyone running ofbiz on its trunk would lose all the product images if
> > they updated their code as the folder will be deleted.
> >
> > please correct me if I am wrong. and if this is the case, i am really
> > surprised how such a major change can be included without further
> > discussions. the current commit also shows that a new folder is created for
> > every product, thus if a store had say 100K products, there will be 100K
> > additional folders created. I am not sure if this is at all expected or
> > desirable and before getting such major changes incorporated in the trunk,
> > it has not been discussed at all.
> >
> > please post your feedback.
> >
> > thanks
> >
> > Rohit
> >  
> >
> > -----
> > saanjhi.com
> > --
> > View this message in context: http://ofbiz.135035.n4.nabble.com/Re-svn-commit-r1076507-deletes-the-images-folder-tp3343463p3343463.html
> > Sent from the OFBiz - User mailing list archive at Nabble.com.
>

[rohit]

hi,

i am also not sure of a few other practical issues. for eg. bulk uploading of new products and images. currently i assume most use the the xml file to import products data and then upload product images into 1 directory after re-sizing. though it appears that the existing image file system can be maintained, but does it make sense to have 2 different image file system, it can obviously be an issue when doing back-up maintenance etc.

The new image management contribution, does not seem complete as its not working fully on the demo server, when i checked last 03/09/11.

Also there are many store which run ofbiz on the trunk. though the trunk may not be ideal for it, i still believe that the current structure should not have been removed so fast as many using ofbiz risk accidently deleting all their images. And instead of replacing the current directory structure a new directly may have used until the code matured and acquired more acceptance.

Should it not be researched more, before it replaces the current structure.

thanks

Rohit

[hans_bakker]

Hi Eric

see my answers inline

On Fri, 2011-03-11 at 00:14 +0100, eric wrote:
> Hi Hans,
>
> In your issue, you havn't written why your new image file system
> (image.filename.format propertie)
> is better than the original ?
>

Images are now grouped together by productid so can be managed more
easily.

> What about the multiple productId directories ?
>

Now an layer of directories is introduced which is used more often than
the 5 directories it replaces which makes the retrieval a little faster,
not slower.

> Save image with ScaleImage.java is now conflicting with the old image
> file system because create image filename like "large.jpg" ...

No it does not because this 'large.jpg' is now stored in the productid
directory, not in the 'large' directory.

> What is the entity to request to find images related to a product,
> uploaded by the image management ?

There is no entity involved, they are stored in the filesystem and be
retrieved just as before, just the directory structue is differently
organized.

> Or How request an image from the image management ?
>

see previous point.

> Thanks
>
> Eric
>
> On Wed, 2011-03-09 at 19:41 +0700, Hans Bakker wrote:
>
> > For your information this is what the log message says:
> >
> > Log:
> > issue https://issues.apache.org/jira/browse/OFBIZ-4194: reorder of
> > product images and extension of the <@ofbizcontenturl macro. A
> > contribution of Antwebsystems employee Tukkata
> >
> > Regards,
> > Hans
> >
> > On Wed, 2011-03-09 at 04:20 -0800, rohit wrote:
> > > hi,
> > >
> > > i see that in this commit the images folders are being deleted. I assume
> > > that anyone running ofbiz on its trunk would lose all the product images if
> > > they updated their code as the folder will be deleted.
> > >
> > > please correct me if I am wrong. and if this is the case, i am really
> > > surprised how such a major change can be included without further
> > > discussions. the current commit also shows that a new folder is created for
> > > every product, thus if a store had say 100K products, there will be 100K
> > > additional folders created. I am not sure if this is at all expected or
> > > desirable and before getting such major changes incorporated in the trunk,
> > > it has not been discussed at all.
> > >
> > > please post your feedback.
> > >
> > > thanks
> > >
> > > Rohit
> > >  
> > >
> > > -----
> > > saanjhi.com
> > > --
> > > View this message in context: http://ofbiz.135035.n4.nabble.com/Re-svn-commit-r1076507-deletes-the-images-folder-tp3343463p3343463.html
> > > Sent from the OFBiz - User mailing list archive at Nabble.com.
> >
>
>

--
Ofbiz on twitter: http://twitter.com/apache_ofbiz
Myself on twitter: http://twitter.com/hansbak
Antwebsystems.com: Quality services for competitive rates.

[hans_bakker]

On Thu, 2011-03-10 at 19:39 -0800, rohit wrote:
> hi,
>
> i am also not sure of a few other practical issues. for eg. bulk uploading
> of new products and images. currently i assume most use the the xml file to
> import products data and then upload product images into 1 directory after
> re-sizing. though it appears that the existing image file system can be
> maintained, but does it make sense to have 2 different image file system, it
> can obviously be an issue when doing back-up maintenance etc.

resizing can now be done by the image management system.

>
> The new image management contribution, does not seem complete as its not
> working fully on the demo server, when i checked last 03/09/11.
>

Let me know what is not working by raising a jira issue. We plan to
provide more information on the image management system in the next few
weeks.

> Also there are many store which run ofbiz on the trunk. though the trunk may
> not be ideal for it, i still believe that the current structure should not
> have been removed so fast as many using ofbiz risk accidently deleting all
> their images. And instead of replacing the current directory structure a new
> directly may have used until the code matured and acquired more acceptance.
>

There was an jira issue on this which was open for 10 days before
committing.

> Should it not be researched more, before it replaces t
> he current structure.
>
> thanks
>
> Rohit
>
>
> -----
> saanjhi.com
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/Re-svn-commit-r1076507-deletes-the-images-folder-tp3343463p3347403.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.

You might consider following the OFBiz mailing list directly, so you are
better informed.

--
Ofbiz on twitter: http://twitter.com/apache_ofbiz
Myself on twitter: http://twitter.com/hansbak
Antwebsystems.com: Quality services for competitive rates.

[Eric DE MAULDE]

Hi Hans,

To manage my images, I need to attach an attribute to each image
Ex : image has a "Background", image is a "Collection" of product ... ,
what features my image is composed ...

(Fabiance web site works with OFBiz)
See the first image of the slide show, "Canapé HOME SPIRIT ... Chicago"
http://www.fabiance.fr/
And now the "Chicago" product detail :
http://www.fabiance.fr/canape-tissu-home-spirit-silver/chicago
The presentation image with "Background" is in fifth position.

Another example with a category "POUF" : http://www.fabiance.fr/pouf
For the product "MACAO", "Pouf" image is the last image :
http://www.fabiance.fr/canape-tissu-home-spirit-silver/macao

How can I select images without attribute ?

Eric


On Fri, 2011-03-11 at 12:54 +0700, Hans Bakker wrote:

> On Thu, 2011-03-10 at 19:39 -0800, rohit wrote:
> > hi,
> >
> > i am also not sure of a few other practical issues. for eg. bulk uploading
> > of new products and images. currently i assume most use the the xml file to
> > import products data and then upload product images into 1 directory after
> > re-sizing. though it appears that the existing image file system can be
> > maintained, but does it make sense to have 2 different image file system, it
> > can obviously be an issue when doing back-up maintenance etc.
>
> resizing can now be done by the image management system.
>
> >
> > The new image management contribution, does not seem complete as its not
> > working fully on the demo server, when i checked last 03/09/11.
> >
>
> Let me know what is not working by raising a jira issue. We plan to
> provide more information on the image management system in the next few
> weeks.
>
> > Also there are many store which run ofbiz on the trunk. though the trunk may
> > not be ideal for it, i still believe that the current structure should not
> > have been removed so fast as many using ofbiz risk accidently deleting all
> > their images. And instead of replacing the current directory structure a new
> > directly may have used until the code matured and acquired more acceptance.
> >
>
> There was an jira issue on this which was open for 10 days before
> committing.
>
> > Should it not be researched more, before it replaces t
> > he current structure.
> >
> > thanks
> >
> > Rohit
> >
> >
> > -----
> > saanjhi.com
> > --
> > View this message in context: http://ofbiz.135035.n4.nabble.com/Re-svn-commit-r1076507-deletes-the-images-folder-tp3343463p3347403.html
> > Sent from the OFBiz - User mailing list archive at Nabble.com.
>
> You might consider following the OFBiz mailing list directly, so you are
> better informed.
>

[hans_bakker]

Hi Eric,

every image is defined by a contentId/dataresource/image to which
attributes: 'ContentAttribrutes' can be added....

Regards,
Hans


--
Ofbiz on twitter: http://twitter.com/apache_ofbiz
Myself on twitter: http://twitter.com/hansbak
Antwebsystems.com: Quality services for competitive rates.


On Fri, 2011-03-11 at 11:38 +0100, eric wrote:

> Hi Hans,
>
> To manage my images, I need to attach an attribute to each image
> Ex : image has a "Background", image is a "Collection" of product ... ,
> what features my image is composed ...
>
> (Fabiance web site works with OFBiz)
> See the first image of the slide show, "Canapé HOME SPIRIT ... Chicago"
> http://www.fabiance.fr/
> And now the "Chicago" product detail :
> http://www.fabiance.fr/canape-tissu-home-spirit-silver/chicago
> The presentation image with "Background" is in fifth position.
>
> Another example with a category "POUF" : http://www.fabiance.fr/pouf
> For the product "MACAO", "Pouf" image is the last image :
> http://www.fabiance.fr/canape-tissu-home-spirit-silver/macao
>
> How can I select images without attribute ?
>
> Eric
>
>
> On Fri, 2011-03-11 at 12:54 +0700, Hans Bakker wrote:
>
> > On Thu, 2011-03-10 at 19:39 -0800, rohit wrote:
> > > hi,
> > >
> > > i am also not sure of a few other practical issues. for eg. bulk uploading
> > > of new products and images. currently i assume most use the the xml file to
> > > import products data and then upload product images into 1 directory after
> > > re-sizing. though it appears that the existing image file system can be
> > > maintained, but does it make sense to have 2 different image file system, it
> > > can obviously be an issue when doing back-up maintenance etc.
> >
> > resizing can now be done by the image management system.
> >
> > >
> > > The new image management contribution, does not seem complete as its not
> > > working fully on the demo server, when i checked last 03/09/11.
> > >
> >
> > Let me know what is not working by raising a jira issue. We plan to
> > provide more information on the image management system in the next few
> > weeks.
> >
> > > Also there are many store which run ofbiz on the trunk. though the trunk may
> > > not be ideal for it, i still believe that the current structure should not
> > > have been removed so fast as many using ofbiz risk accidently deleting all
> > > their images. And instead of replacing the current directory structure a new
> > > directly may have used until the code matured and acquired more acceptance.
> > >
> >
> > There was an jira issue on this which was open for 10 days before
> > committing.
> >
> > > Should it not be researched more, before it replaces t
> > > he current structure.
> > >
> > > thanks
> > >
> > > Rohit
> > >
> > >
> > > -----
> > > saanjhi.com
> > > --
> > > View this message in context: http://ofbiz.135035.n4.nabble.com/Re-svn-commit-r1076507-deletes-the-images-folder-tp3343463p3347403.html
> > > Sent from the OFBiz - User mailing list archive at Nabble.com.
> >
> > You might consider following the OFBiz mailing list directly, so you are
> > better informed.
> >
>
>

--
Ofbiz on twitter: http://twitter.com/apache_ofbiz
Myself on twitter: http://twitter.com/hansbak
Antwebsystems.com: Quality services for competitive rates.

[rohit]

Hi Hans,

Firstly, even if re-sizing can be done using the new system...how do you suggest the issues of bulk upload can be tackled, without maintaining 2 separate directory structures for images?

Secondly, the JIRA issue may be open for 10 days...that does not mean, its necessarily approved of. I am no expert of the code...but i do not find if any of the other more experienced committers and contributors have made any comment of this functionality. i am not sure if any opinion was sought either. For eg. when the code was migrated to jQuery their was a conscious effort from the contributors to solicit feedback and opinion.

Thirdly, the fact that i have been following the mailing list directly is what made me identify this issue and still believe their is no reason you should replace the existing structure...when your code could have been made optional for those who wanted to use it rather than being forced to use it.

Please do not mis-construe that i am suggesting on the quality of code, all that i am saying is that it could have been made optional without removing the existing functionality.

and as Eric mentioned "Rule #1 for a committer is the same as for a doctor: first do no harm. Nothing should be committed that breaks existing functionality without replacing it either before or in the same commit. Whatever you are working with someone developed it and chances are someone is using it, and possibly MANY people."

thanks

Rohit