My favorites | Sign in
Project Home Wiki Source
READ-ONLY: This project has been archived. For more information see this post.
Search
for
Overview  
Updated Sep 18, 2010 by denis.ha...@gmail.com

Vision

It is our believe that web applications developed with some of client side JavaScript frameworks offer a superior user experience when compared to applications developed using the server side frameworks like JSF. After all, probably this is the reason why there are so many clients for Alfresco written in ExtJs and why Alfresco itself opted for YUI when designing Share application.

However, applications development using client side framework does not come without the risk imposed. Sometimes, it is not easy to maintain clear separation of concerns. Putting bits and pieces of business logic on the client could save you some time and few server round trips but will eventually lead to unstructured code base which is hard to maintain.

Jibe framework is built with vision to handle the above mentioned problem on a specific task of building ExtJs based applications on Alfresco platform. This is done by introducing a number of conventions on how to structure the code on the client side and a number of configuration options and extension hooks on the server side which allows you too keep the complexity of business RIA development under control.

Features

Before we start with more concrete features list, let's define the term execution context since it is used extensively in the rest of the text. Some of examples of execution context are role or group of a current user, type of a currently selected node, presence of a certain aspect, some value retrieved from remote system. Definition of execution context is easily customized according to your specific requirements.

Presentation tier

  • User interface is built as assembly of either custom built or default ExtJs components. These assemblies are defined in XML configuration files which are stored on the server. Each assembly can be marked to be valid for certain execution context. Upon request, a JSON required to instantiate and render assembly is built dynamically. The fact that UI is not defined statically allows you to have completely different user interfaces depending on the current execution context which is a common requirement in business applications
  • Existing ExtJs knowledge can be reused since XML configuration elements are the same as ExtJs configuration properties
  • All important UI building blocks like forms, grids or trees are configurable in XML using very rich configuration model. This configuration can also be marked as valid for certain execution context. This fact allows us, not only to have different layout depending on the context, but also to have variations of the same components. All this can be achieved without any coupling between components involved.
  • Each ExtJs container in Jibe has been decorated with capability to reload its children as a response to a certain event. For example, feature to reload the form definition and present different property fields depending on the type of the document selected is built into the framework and is done in a very clean manner.
  • Tab and accordion container has the capability to reload themselves and present different children depending on the execution context. Moreover, current children definition is stored on the server and reloading will not be triggered if definition does not change.
  • Communication between components in UI is handled by Jibe event handling mechanism which is a combination of server side XML configuration and conventions on the client. This allows components to be fully reusable and decoupled
  • Actions and action bars as containers for actions are defined and bound to the components in XML configuration files. Appearance and visual status of actions can be managed using either annotated server side methods or simple expression language within XML.
  • All dialogs are created dynamically from XML which allows us to present different dialog depending on the current execution context
  • User interactions with the system which requires several steps could be easily implemented using built in Wizards framework.Appearance of components presented in a particular wizard step is evaluated upon request and can be different depending on the current execution context.

Application tier

  • Java or Groovy methods are easily exposed for invocation from client using simple @Remote annotation
  • Required authentication or transaction mode for particular method exposed is configured in a non evasive manner with additional annotation
  • Form data validation logic is contained within Java or Groovy annotated method and easily bound to forms or form fields in XML configuration
  • Visual indication of progress on long running remote methods is switched on with an additional annotation @Progress

Data tier

Powered by Google Project Hosting