Currently it is not possible to create content folders which contain other content folders. An enhancement for this should be quite simple on the API side. The GUI must of course reflect this which is a bigger task and also the reason for not having it implemented at the moment.
Displaying EXIF-Data information would be a really meaningful feature in the future. Digital cameras normally provide EXIF-Data information which includes the date when the picture was taken, aperture size and different other data. Implementing it can cost performance if the whole image has to be loaded into RAM for reading and also if this information has to be read from many images at once. Either way it can be costly and that is why the whole EXIF information will normally be displayed on the detail page of an image and not within overviews with plenty images on it. For this the content provider needs a method for retrieving the EXIF data for a specific image.
This functionality was not implemented because in the case of Alfresco it would have been necessary to retrieve the image from an URL and get the information afterwards which would have been quite an effort.
Of course it is also possible to cache this information when uploading images. For this to work image uploading must be implemented for the image gallery itself (see Image upload
below). Also resynchronizing when changes are made to the images must be taken into account and different other problems which make this change a time consuming one which is the reason why it does not exist yet.
Some image galleries also make it possible to submit additional information be it user comments, submission dates or other data to each image. This is in my eyes barely useful in comparison to the effort needed. This additional information must be saved somewhere. Normally it would be saved in the database. The images normally will not be saved within a database which means that some sort of synchronization between these two storage formats must be done when content in format changes. This implies a bigger effort and therefore it is currently not a part of this implementation.
Image uploading is nice feature and can be easily implemented when completing and implementing the ContentSubmitterFace. For the time being this was not done because the sample Alfresco Content Provider offers uploading itself and so do other content management systems. Content submission gets more important when implementing a content provider which bases on file system.
In the current project there is also a ContentManipulationInterface. If content manipulation on the server side would be needed enhancing and implementing it is the way to go. Normally this should be rarely useful because of the bandwidth bottleneck. Normally it is not reasonable to transfer images with sizes larger than one megabyte to a server where they will be resized because ADSL line often support very slow upload bandwidth. Instead it would be better to resize the images on client side prior to uploading which shortens upload times significantly. For this feature many tools exist and that is why server side image manipulation is nearly superfluous.
The authentication for the content administration is done in two ways. Administration of content folders is done via the edit page of the portlet. Uploading of content is done via the content provider, in this case Alfresco. Portals and alfresco provide their own authentication mechanisms and so there is no authentication needed on the gallery side.
Images can contain sensible data and so it can be useful to restrict certain galleries or images to a limited group of users. There are two possibilities to get this working:
The first possibility should work with minor changes. Just restrict images to a group of users within the content provider GUI. When trying to display images afterwards it should be impossible for users with no current session with the appropriate access rights to retrieve the images. Because this was not tested yet it is only a suggestion and needs further examination before using it in production environments.
The second solution would use the current Portal's authentication methods. As the JSR-168 portal standard does not provide a standardized authentication suggestion every Portal provider implements its own authentication system mostly incompatible to other portals. That is why fine grained page inline security and authentication, when not providing an own abstraction layer, almost always fix to a certain Portal which was not desired for this project. A security abstraction layer was not manageable in the given time.
As you can see in the UML Diagram (see the menu on the left) content providers return content of the type ContentFace which is not limited to the use of images. Nearly every content which is accessible via an URL can be browsed this way. The only change which will be necessary is the differentiation between a content icon and its content.
At the current state the GUI is only considered as a proof of concept although there are only (if at all) a few steps needed to make it completely production ready. Present style information is attached to each html/JSF element whenever it is needed. In a corporate or organizational environment it would be better to use CSS classes defined in a central CSS file.
Furthermore their might be some passages within the backing bean code which could have been resolved more elegantly. For details on this refer to the corresponding Java Doc on the spcp7 main site or look at the source code directly.\