Jucas is a web-framework which brings together the pull MVC
concept with component orientated design GUI programming.

Struts (like other Model II frameworks) have brought the
separation between View and Model and Controler to the web
programming. On the other hand recent frameworks like Java Server
Faces (JSF) or ASP.NET try to provide the advantages of object
(component) orientated GUI-Design known from 'fat-client' apis like
Swing or Visual Basic (stateful objects, event-mechanismus).

Jucas combines both approaches. Stateful components (JavaBeans)
are used to represent the model and the controller and templates use
this components to render the view.

Compared to the object orientation given by Jucas (or JSF,
Tapestry, ASP.NET etc), Struts and other Model II approaches are
rather like a 'procedural-language'. (Please note: if in the
following I will compare Jucas mainly with Struts it is because
Struts is (rightfully) a de-facto standard and I also think it is a
very good web-framework to which it is worth to compare)

In Struts Actions are like global-methods, which operate on a
global variable scope (the Request-Attributes). The central
controller is some kind like a big switch-case 'main-method' which
calls the appropriate 'global-method's (Actions) and than also calls
the next 'global-method' for rendering (the view). Everything is
coordinated with struct like DataObjects which reside in the global
'variable-scope' - the HttpServletRequest. This way Struts uses the
view for rendering and
pushes
the
data to the view. This result is tighter coupling of the Model,
Controller and the View and it restricts the flexibility of the
page-designer.

In Jucas it is different.
Jucas provides to the View templates
through
the HttpServletRequest
only one standard object (a
ViewHelper). From this ViewHelper all components present in the
web-app can be retrieved. The view-designer
pulls
together the
components she needs and renders them
. This way the view
designer can decide which components she wants to display on which
page. One time she can show components together on one page and if
requirements change she can split the components up between different
pages etc. All without any change to the components.

If this sounds to you like a Model-I approach, where the template
uses JavaBeans to get the Data to display, than you are right. The
difference is that user-input (the request-parameters) is processed
in Jucas like in a Model-II approach - through a central
ServletFilter directly in the components without any code in the
views. The view does not have to care about the request-processing.
This way Jucas brings together through its Pull MVC the advantages of
both approaches. Flexible, fast and easy implementation of the View
and separation of concerns, maintainability, reuse and little code in
the view as known from the Model-II approach.

In Struts the Action programmer decides which html-form-input
names are used by which action and which actions can be called
through urls. In Jucas the view designer defines which of his
form-input-fields or request-parameters map to which properties or
method-arguments on which components. It is than the responsibility
of Jucas to read the request-parameters, set the properties and call
the methods on all the affected components. This way without change
to the components ie multiple components can be used together in one
form. It also helps Jucas to work together with other web-frameworks.

The object or component orientated approach of Visual Basic or
Swing - with properties, event-handling etc - has proofed so useful
for program-design, flexibility, code-reuse and maintainability that
both JSF and ASP.NET try to bring it on the server. Jucas follows
this approach. (However as explained next Jucas components generally
don't render themselves). In Jucas components are JavaBean instances
which have properties, methods, their own encapsulated state (also in
request and session scope) and can fire JavaBeans styled events.

In Jucas components handle all the logic of the web-app. There is
no extra central web-application class or something like that.
Because of this components are very easy to implement and are simple
POJOs (Plain Old Java Objects). For page-designers, which do not know
Java, components may also be defined in a combination of XML and
JavaScript.

Different from a 'fat-client' a web-app is used by different users
concurrently. Some parts of the web-app are specific for the current
user (ie a shopping-cards) others are common to all users (ie the
product-catalog, databases etc). Therefore Jucas differentiates
between two types of components:

JucasBeans: are JavaBeans of which each user has his own set
and of which for each user multiple instances can be created. They
represent the state of one user. They are typically used for things
like form input and they are always only used by one thread.
JucasBeans are held either in the Request or Session scope.

Services: Services represent the functionality and data
common to all users. Of each service there is only one instance in
the web-app (Application scope). Services are mostly used for the
(connection to the) business-logic. They are mostly used
concurrently, but can also be defined to be single-threaded (one
instance per thread). (Service are normal (full functional)
HiveMind-Services)

This two types are just two types from which the user can freely
choose. The framework does not regard if the user implements all the
logic in one or the other type of components or splits the web-app
logic up between components of both types(the general approach). The
framework does also not specify how components of the different types
interact. This is totally up to the user. The types are just there
because web-apps are used concurrently and for this fact each type
has its own advantages.

The central part of Jucas is the BeanManager. The BeanManager
manages all the components of Jucas. From the BeanManager all
components can be retrieved by their unique name - an URL.

The second important part of Jucas is the JucasFilter. It is a
ServletFilter which scans the Request for the parameter
'jucas-action'. If it finds this parameter it parses its content.
Based on the content of this parameter the JucasFilter retrieves
Components from the BeanManager and sets attributes and/or executes
methods on the components. Through this the Components can adjust the
model according to the request-parameters and do the control. After this
the JucasFilter gives further in the filter-chain. If the
parameter jucas-action is not present in the request the JucasFilter
just gives directly further in the filter-chain without regarding the request
at all.

Some where down the chain the View comes into play. Typically
the View will be represented by a number of templates - however
Jucas does not define how the output is rendered nor does Jucas 'filter'
the response in any way. The View (Template) than retrieves
the components it needs from the BeanManager and renders them.

The View (Template) also defines - if needed -
how the request-parameters (of forms or url-queries)
map to properties or actions of components in the BeanManager. This
definition is done with a special helper class - ActionCode. The
ActionCode will than be used by the View to produce the
'jucas-action' request-parameter (as a hidden-field or url-query-param).
The output is send to the client and in the next request-cycle the
'jucas-action' request-parameter just created by the View will be interpreted
by the JucasFilter, which again sets the properties and executes
the defined methods on the components and so on ....

Nowadays every component-orientated web-framework is MVC. Jucas
however is a bit stricter on that. Struts showed that the separation
of the Model and Control (programmed in Java classes) from the View
(templates using the model) can be much stricter than on the
fat-client. The reason for this is that it is much easier, much more
powerful and has better tool-support to render different designs with
html-templates than it is to render them with graphics-libraries.
Therefore also recent developments in client-gui programming (like
XUL, SwingML etc) try to mimic the document-orientated approach used
by html.

For this reasons components in Jucas - like in Struts - generally
only handle the control and model of the web-app and they may than be
rendered by any template-technology (JSP, Freemarker, Velocity etc).
Components generally do not like in JSF or ASP.NET render them self.
For me it just makes no sense to encapsulate the (simple) html code
for something like a Label, TextField or ImageButton in - proprietary
- components.

To make it clear components in Jucas may render them self but only
certain components which need a tight integration with the View (ie
sophisticated Trees) should do that. And even than the View is free
to replace this default rendering.

Other component-orientated web-frameworks also use components for
things like footers, headers or borders around other html-chunks etc.
Needles to say that Jucas components are also not meant to do that.
All this can be accomplished very well with existing
template-machines (ie. through includes) and therefore there is no
real need for the page-designer to learn how to implement components
with a new framework.

As said Jucas is like Struts totally
independent on the template-mechanisms used to render the view.
However contrary to Struts Jucas is also independent to the
page-flow-mechanisms used. Simple static-html like linking can be
used as well as Struts like centralized page-flow-definition, a more
advanced work-flow-engine or anything else.

For those who like the central
managed Struts page-flow definition: It is completely possible to use
Struts under Jucas. Struts actions can use Jucas components as the
View does and can than decide what the next view is to render. In
such a case the templates can still use all Jucas components and map
their properties and actions. The same affect can also be achieved
without Struts by using templates which just include other templates
based on the state of Jucas components. (This is by the way also
easier to maintain for the page-designer).

Technically Jucas is implemented as
a ServletFilter. The filter will pass the Request further and will
return to the ouput anything the 'filtered' servlets return. Jucas
does not change the Request, sets Cookies, Header etc. Jucas only
sets attributes in the Request. The attribute 'jucas' contains the
ViewHelper from which the components can be read by the view or
anything else under the filter. (Jucas also uses the ServletContext,
the Request and (optionally) the Session for keeping attributes which
however are only used internal. All these attribute names start with
org.jucas and should only be accessed by Jucas.)

Jucas does also not care about
the form of the Request. It is opaque about the URL or any
request-parameters. The only request-parameter Jucas cares about is
'jucas-action' this parameter contains the mapping of the other
request-param
eters to the components properties and methods ?
as defined by the view. If the 'jucas-action' parameter is not
specified Jucas does just not regard the request-parameters and gives
further in the filter-chain.

And last Jucas is standard-based.
JucasBeans are JavaBeans which implement a simple Interface or extend
from a base Class. This makes it possible ie to use many different
validation-frameworks.