Motivation for implementing yet another image gallery

Plenty of image galleries exist and therefore the question why another one is needed of course is justified. Portals implementing JSR-168 like Liferay, Jboss Portal, Jetspeed and Exo - to only list a few - get more and more popular within enterprise and community context. Reasons might be versatility, standard compliance and the possibility to easily integrate new or legacy applications. Portals are programmed in java (at least the ones listed above) and so the portlet (see JSR-168 Portlet Standard ) programming language of choice considering performance and integration is of course also java, although portlets written in other programming languages are possible via portlet bridges.

Back to our main question: "Why another image gallery?". With the digression above one reason is obvious: At the moment there simply is no java image gallery portlet which can be integrated easily into a JSR-168 portlet container and thus use its unique features.

Another reason for a new image gallery implementation is the fact that contemporary image galleries do often support integration into other web applications but do not support different ways of content storage. Different possible storage formats for the images of one gallery are not necessary by themselves but when a web site already uses a content management system. In case of an existing content management system which already has its own storage format it is useful to save images within this format. In this way content redundancy can be avoided and consistency kept. These arguments even get more weight if a content management is not only used for a web site but for all contents within the enterprise or organization. Furthermore, by this method, existing functionality like versioning or workflow management of the often feature rich content management systems can be reused.