Introduction

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.

Pull MVC

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.

Components are JavaBeans which have state, properties, methods and events

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:

1. 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.

2. 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.

Request-Cycle - How does it work

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 ....

Separation of Model and Controller from the View (MVC)

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.

Working together with other web-frameworks and apis

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.