You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
we have a huge issue and we need to fix it now: changes made to implement #158 have result on a cascade of errors and hurries to fix those errors have resulted on more errors and coding that hide the errors.
The problem
first, let's think a little bit on the original problem: why we need to change the text of title or description fields on a tile? because they don't fit well in the area available; on an image fields the problem is different: we use features included in packages like plone.app.imagecropping to create a miniature that shows a detail of the original image, not only in the front page, but also in other places like listings and so on.
The use cases
I'll try to explain use cases that we imagine here to see if we understand them and we can find a better solution; I'll use the image tile because it's easier:
1. user drops an existing image into the image tile
in this case we must refer to the original image and scales; if the user change the image or their scales, the image and scales in the tile will reflect these changes; I think this is pretty intuitive and ease to explain.
2. user uploads an image into the image tile
in this case the image is stored as an annotation in the cover and we rely, for now, on standard Plone mechanisms to create the scales for now; in next iteration we can implement support for in place editing of the scales.
now let's image similar situations on a different tile, the basic one:
3. user drops an object with an image into the basic tile
if the object has an field named 'image' or a method named getImage, we are in the first use case and we must keep a relation with the original image; if the image is stored on a different field name, we simply ignore it, and we are in next use case, which is...
4. user uploads an image into the basic tile
this is the same as the second use case.
The solution?
we have to accomplish the above:
documenting
covering everything with tests
without messing on the tile's templates
without hiding unnecessarily exceptions
so please let's think a little bit about it and write down how are we going to implement it before changing anything on code.
we have a huge issue and we need to fix it now: changes made to implement #158 have result on a cascade of errors and hurries to fix those errors have resulted on more errors and coding that hide the errors.
The problem
first, let's think a little bit on the original problem: why we need to change the text of title or description fields on a tile? because they don't fit well in the area available; on an image fields the problem is different: we use features included in packages like plone.app.imagecropping to create a miniature that shows a detail of the original image, not only in the front page, but also in other places like listings and so on.
The use cases
I'll try to explain use cases that we imagine here to see if we understand them and we can find a better solution; I'll use the image tile because it's easier:
1. user drops an existing image into the image tile
in this case we must refer to the original image and scales; if the user change the image or their scales, the image and scales in the tile will reflect these changes; I think this is pretty intuitive and ease to explain.
2. user uploads an image into the image tile
in this case the image is stored as an annotation in the cover and we rely, for now, on standard Plone mechanisms to create the scales for now; in next iteration we can implement support for in place editing of the scales.
now let's image similar situations on a different tile, the basic one:
3. user drops an object with an image into the basic tile
if the object has an field named 'image' or a method named getImage, we are in the first use case and we must keep a relation with the original image; if the image is stored on a different field name, we simply ignore it, and we are in next use case, which is...
4. user uploads an image into the basic tile
this is the same as the second use case.
The solution?
we have to accomplish the above:
so please let's think a little bit about it and write down how are we going to implement it before changing anything on code.
feedback, please, @agnogueira @ericof @jpgimenez @Quimera
The text was updated successfully, but these errors were encountered: