Hello,
The architecture of the web-client is the organic end result of our first attempt to build a JSF portlet web-application. The nature of building a large JSF application has proved both challenging at times and very interesting (especially since several of our developers were responsible for the design and implementation of the Documentum WebDevelopmentKit which is so similar in its architecture). It has also proved that JSF applications are quite tightly "coupled" within themselves due to the nature of the required XML based configuration and setup for the framework and its components.
Our original intentions were to build a set of "portlets" as different mini applications against the Alfresco repository. The list would have been pretty much what you suggest, a Browse portlet, a Search portlet, an admin portlet and so on. However one of our other goals was to build a portal based web-application that did not require different versions for different platforms, and to support standards whenever possible. The most portable and standards based route to achieve this goal is JSR-168. However at the moment JSR-168 is a pretty basic standard for portlets, it does not have any spec for inter-portlet communication. This meant that multiple portlets would be standalone apps without custom portal IPC code. We felt that we did not have the resource to code this for each possible portal implementation.
We wanted the web-application to be rich in functionality and to achieve that end would have required the IPC if we wrote it as a set of independant portlets. So instead it has been written a single JSR-168 portlet using JSF as the web-framework. One of the good features of JSF is that it's very easy to swap in different component implemenations at a later date - so configuration and customization features of a component can be improved later without signficant impact on the rest of the application.
There is no good reason why the community cannot code individual portlets based on our code if required. It would probably be a great learning exercise to build a simple folder/content browser etc.
It is also worth remembering that this is just version 1.0 of the application! Much more configuration, and a customization framework will be added in later versions I'm sure. It's not perfect yet by any means, but we think it's a good start!
Thanks,
Kevin
The architecture of the web-client is the organic end result of our first attempt to build a JSF portlet web-application. The nature of building a large JSF application has proved both challenging at times and very interesting (especially since several of our developers were responsible for the design and implementation of the Documentum WebDevelopmentKit which is so similar in its architecture). It has also proved that JSF applications are quite tightly "coupled" within themselves due to the nature of the required XML based configuration and setup for the framework and its components.
Our original intentions were to build a set of "portlets" as different mini applications against the Alfresco repository. The list would have been pretty much what you suggest, a Browse portlet, a Search portlet, an admin portlet and so on. However one of our other goals was to build a portal based web-application that did not require different versions for different platforms, and to support standards whenever possible. The most portable and standards based route to achieve this goal is JSR-168. However at the moment JSR-168 is a pretty basic standard for portlets, it does not have any spec for inter-portlet communication. This meant that multiple portlets would be standalone apps without custom portal IPC code. We felt that we did not have the resource to code this for each possible portal implementation.
We wanted the web-application to be rich in functionality and to achieve that end would have required the IPC if we wrote it as a set of independant portlets. So instead it has been written a single JSR-168 portlet using JSF as the web-framework. One of the good features of JSF is that it's very easy to swap in different component implemenations at a later date - so configuration and customization features of a component can be improved later without signficant impact on the rest of the application.
There is no good reason why the community cannot code individual portlets based on our code if required. It would probably be a great learning exercise to build a simple folder/content browser etc.
It is also worth remembering that this is just version 1.0 of the application! Much more configuration, and a customization framework will be added in later versions I'm sure. It's not perfect yet by any means, but we think it's a good start!
Thanks,
Kevin
