Projects:Image Reference/Technical Specifications
Contents |
Image Reference - Technical Specifications
Implementation
Model
The model implementation for images will follow a similar approach as currently, a single table (AD_Image) will contain information about all the images in the application and when a table requires images a column will link to this table.
This approach allows to not have to store the image information in the main table (the one that is using the image).
Additionally, if image galleries are implemented a new table would be necessary (AD_Image_Gallery), this table would be a header and its lines would be rows in AD_Image. In this case a SeqNo and a isDefault fields should be added to AD_Image in order to know the sequence of an image inside the gallery and if it's the default image for the gallery being this the only one viewed in the tab user interface.
Application dictionary
Current image reference would be maintained as deprecated for backwards compatibility and a new gallery reference would be created.
This gallery reference would be able to store one or more images and one of them would be set as default being this one displayed in the tab user interface.
WAD
In the tab user interface the field display size must be taken into account, currently it is not taken and the image is always displayed at full size. It must be decided how this size is managed, it could be done only with the display size in the field, this would be translated in the number of columns the image element has and the image's height would be free (the width would be always 100% to adjust to the table), in case also the height is going to be controlled a new column for field would be required to decide it, in this case some Javascript treatment would be needed in order to adjust the width or height maintaining the correct image scale.
Gallery wrapper
In order to make easier the gallery management a wrapper java class to manage it could be created, this class would have methods for:
- Getting the default image.
- Getting an image in a fixed size: it would be nice to be able to obtain the image directly in this way because it would reduce the load for thumbnails.
- Getting all the images within the gallery.
Selector
A new interface for gallery selector must be created, this selector is callable from the tab user interface and would consist on:
- A fixed size image displaying the currently selected image.
- An icon to delete it from gallery.
- An icon to edit it. When it is clicked a new pop-up will be displayed.
- In this pop-up the image will be shown as full-size, it's possible to change:
- Name
- Sequence
- Default for gallery
- In this pop-up the image will be shown as full-size, it's possible to change:
- A thumbnails list of all images within the current gallery, clicking on one of this images it is selected appearing it as the selected one making possible its edition.
- A new button that opens another pop-up:
- This pop-up allows to upload new image files, it would look similar to the add pop-up for attachments.
Backwards compatibility
This project will maintain the current image reference to have backwards compatibility though it is recommended to use the new one.
In the core product the only used image reference is M_Product table, this column will be deprecated and a new one will be added. In current installations using images for products there are two possibilities:
- Maintain old reference: To do this it will be necessary to reactivate the old image filed and deactivate the new one.
- Use the new one: To do this having the old images it will be necessary to run a script to do the migration.
In case custom columns that holds images the old reference will be maintained and if the new one is wanted to be used a new column will be required and it will be needed to run the migration script.
Open discussion items
How to store images
web/images directory
Currently images are manually saved in this directory. Tomcat can serve them directly.
The main problem with this approach is that images are accessible to anybody just typing the URL.
Database
Another approach is to save images within database as a raw type. This approach solves the security problem in the first one. The problem it has is depending on database raw type management is different.
Attachments
The third approach is to manage images in the same way that attachments. They are stored in a directory where tomcat has write permissions but it can be outside of the tomcat context so it is not directly accessible via URL, so the security management can be done within the java class that looks for images. Additionally this approach is consistent with the current way of saving attached files.