Jucas -

Components

As stated in the introduction components handle the Model and Controler part of the web-application.

There are two types of components. JucasBeans which represent the web-app for one user and Services which provide the common part between users. The two types are very different (see the table) but they have a few things in common:

Both types of components are retrieved from the org.jucas.BeanManager by their name. The BeanManager is the component-manager used by Jucas.

The name of both components is an URI. The scheme is 'jucas' for JucasBeans and 'service' for Services. The host denotes the type of the component. For Services it is the HiveMind id as defined in the modules which specify the services for JucasBeans the host denotes the full qualified class name. The (optional) path and query are only used for JucasBeans. For these they denote the instance. The (optional) fragment is a org.apache.BeanUtils properties-path, which is evaluated on the component.

Both JucasBeans and Services may implement the org.jucas.Peer interface. The Peer interface indicates that on the implementing class through the request-parameters properties can be set and methods can be called.

Differences between JucasBeans and Services

	JucasBean	Service
Purpose	Used to represent the state of the web-app for one user. (ie ShoppingCard).Generally used for Form input and processing.	Represent the part of the web-app which is shared between all users (ie the product-catalog). Generally used to connect to the Bussinesslogic, Databases etc.
Scope	Request or Session	Application
Life-Time	Till the end of the Request or Session	During the whole web-app
Instances	Each user has his own set of JucasBeans. Mulitple instances can exist of one type.	There is only one instance in the web-app of each Service. Services are Singletons.
Concurrency	Always used only in one thread.	Generally used concurrently however they may be 'single-threaded' (one instance per thread).
Implementation	JavaBeans which implement the org.jucas.JucasBean interface	Consist of an (any) Interface which represents the Service methods and a class which implements this Interface. No special Interfaces have to be implemented.
Configuration	No configuration	Configurable in the module.xml file.
Instantiation	Automaticly by the BeanManager when it is asked for (based on the BeanNames URI host). There is no special configuration needed that a JucasBean can be instantiated.	Have to be defined in the module.xml file.
References held to	References in field may be only held to JucasBeans which belong to the same PageJucasBean otherwise have to be retrieved from the BeanManager used and loaded. A sepecial class is provided for references (org.jucas.BeanLink)	May be held.
Interception of calls (ie for logging)	Not provided	Can be specified in the module.xml file
Encapsulation of state in Session and Request	Provided	Not provided
Can have child-components	Yes	No
Always access to HttpServletRequest and -Response	Yes	No

The org.jucas.BeanManager

The BeanManager is the component-manager used by Jucas.

An instance of the BeanManager can be gotten in three different ways:

through the ViewHelper which is provided under the name 'jucas' in the HttpServletRequest,
from any JucasBean component (the BeanManager is provided to it when it is created)
and from the static method ViewHelper.getStaticBeanManager().

For each request there is a BeanManager therefore the BeanManager may never be stored in a field-variable, in Session, Request or Application scope. Each time a BeanManager is needed it should be retrieved as described and must than be released.

The BeanManager provides the following three functionalities:

Retrieving of Components (either JucasBeans or Services) by their name (an URI) and loading the component if is not loaded yet.
Keep loaded JucasBeans loaded in Request or Session scope
Provide different services to JucasBeans

Services are not managed directly by the BeanManager but rather by a HiveRegistry (the one gotten through BeanManager.getHiveRegistry()). However they can be retrieved from the BeanManager (which delegates further to the Registry).

The BeanManager provides retrieving of Components by their name

Each Jucas component has a unique name, which is a java.net.URI. The name both identifies the component and defines how the component is loaded. Through the method BeanManager.getBean(uri) the bean can be retrieved. If the bean is not loaded yet the BeanManager will load it automatically.

The BeanName of a JucasBean can be retrieved through JucasBean.getBeanName(). The BeanName is set on the JucasBean by the BeanManager when the JucasBean is instantiated by the BeanManager.

The scheme of the URI of a JucasBean is 'jucas'. The host of the URI denotes either the full qulified class name of the JucasBean or for xml-defined JucasBeans the file location. To resolve the file forr the xml-defined Jucas Beans the dots in the host are replaces with '/', the extension '.jucas.xml' is appended and this path is searched from the path WEB-INF/jucas/resources/beans.

The (optional) path and query of the URI indicate different instances of the same type of JucasBeans. Finally the (optional) fragment of the URI (after #) is treated as BeanUtils properties path which is evaluated on the JucasBean.

The name of a Service component has the scheme 'service', the host denotes the HiveMind id the path and query are ignored and the fragment is interpreted as a BeanUtils path. For services the BeanManager just takes the host and retrieves the Service from the HiveMind-Registry. If a fragment is given it evaluates it on the Bean.