Old page (JFacets 1)

This page explains the concepts behind JFacets. It shows a detail functional view of the system, with no implementation or configuration stuff. The aim is to show you how the framework handles the Profile-based MVC paradigm, through explicit examples.

What's JFacets ?

JFacets is a framework that aims to add profile-awareness to controllers, as defined in regular MVC architectures. The purpose of this framework is to allow application logic to be bound to client profiles, and thereby to behave in a personalized fashion based upon who is interacting the application.

The typical example is to display personalized views on some objects for particular users. Most applications rely on the concepts of roles or groups to present different informations to the end user.

JFacets defines a set of interfaces and generic principles to allow easy development of profile-based applications in a clean and consistent fashion.

NOTE: JFacets is only a specificiation and does nothing in itself. It's the foundation for WebFacets ? and SwingFacets ? which provide running implementations for their respective environments. This page explains the general principles that applies to both implementations.

Executing facets for objects

Before we talk about the profiles, let's have a look at how JFacets, as a controller layer, is aware of the application model.

A GUI is usually a program that allows the user to view and manipulate some of the application's object instances through some various screens. A page typically displays the object's state, allows to navigate through somme associations with other objects, and allows to invoke some methods on the object through some interface widgets (labels, lists, textfields, buttons, etc.).

Let's think about a basic e-Commerce site. The web application allows the user to view the catalog (let's say a Catalog instance), view some items of the catalog (some Product instances, or more probably subtypes like Book, DVD, etc.), add items to and view contents of his cart (a ShoppingCart instance). Thereby, each "screen" can be seen as a particular "view" on a particular "target object".

JFacets heavily relies on this concept. Base idea is that a screen that is displayed to an user is the result of a facet executed on a particular object instance. A facet is a piece of code that knows the target object's type, and has capabilities to display a "screen" for this particular object. Facets are thereby identified by a symbolic name, and a target object type.

NOTE: JFacets is NOT a view technology per se, but controllers usually end up by "forwarding" the rendering to a view. So even if JFacets stays at the controller level, of course, its main use is to customize final rendering.

Back to our example. A screen that displays the catalog would correspond to the execution of a "view" facet on the Catalog instance. The code in the "view" facet would generate a screen presenting the catalog to the user.

The table below shows possible facets :

name	Target object type	Description of the facet's code
view	Catalog	Displays the catalog, products "shortforms" with links to full descriptions, search the catalog...
view	Product	Displays a product
view	Cart	Displays the contents of the user's cart
addProductToCart	Product	Adds a product to the cart, and "redirects" to the view action on object Cart to display the updated user's cart
...	...	...

Here is a figure showing a typical web-like request/response scenario based on the concept of facets. It consist in the execution of the view facet on a Catalog object :

As one can see, the controller is aware of the model. The execution framework locates the target object, and passes it to the appropriate facet for execution. The result of this execution is the generation of an HTML page dispalying the Catalog object to the end-user.

Facets and target object types : handling inheritance

We've seen above that a facet contained a piece of code, this one being executed for a given object to get a web page for it. But we forgot something...

Let's have a closer look at our (view, Product) facet. This one is supposed to generate an HTML page which shows the details of the target Product, allows to add it to the cart, etc. But if the facet is identified by the (name, target object type) pair, how can it handle the Product subtypes like Book, DVD, ... ? As a matter of fact, the facets code has to know the real execution type of passed Product to display it well !

This is basically what is called facet overriding in JFacets. If you want to display a DVD instead of a Product, then define a facet for this type.

At run time, the framework tries to locate the facet for the target object 's real type. If found, the facet is executed. Otherwise, JFacets looks if the facet is defined for target object 's super types/interfaces.

This nice mechanism allows us to implement our example with the following facets :

name	Target object type	Description of the facet code
view	Catalog	Displays the catalog, products "shortforms" with links to full descriptions, search the catalog...
view	Cart	Displays the contents of the user's cart
addProductToCart	Product	Adds the product to the cart, and "redirects" to (view, Cart) to display the user's cart
view	Book (extends Product)	Displays a book with specific infos (author, pages, summary, ...)
view	DVD (extends Product)	Displays a DVD with specific infos (length, bonus sequences, ...)
...	...	...

As you can see, there is a view facet for the Book target object type, and one for DVD. These two facets provide different representations for different types.

Now, let's have a look at the (view, Catalog) facet. We assume that this facet generates a page with all products with a link to the "view" facet for each of these Products. When the user clicks the link, the framework tries to locate the "view" facet for the real execution target object type. As a matter of fact, the real type is Book or DVD. Since we've defined a facet for (view, Book) and (view, DVD), JFacets will execute the appropriate code to display the target book or DVD.

The way facets are tied to object types with inheritance can be seen as "dynamic dispatch" in the OO methods world : the system invokes the method for the real execution type of the callee. As you can guess, this is cool :-)

Now that we know how JFacets handles application objects, let's have a closer look to another cornerstone of the system.

Generic profiles management system

JFacets provides a generic approach to profiles management. Since it aims at providing a base solution for virtually any profiles management systems, it cannot bring any restriction to the way you model, organize and manipulate your own profiles.

Whatever the way your users/groups/roles/... are organised (one group per user, many roles per user, composite groups, ...), JFacets can handle it !

In JFacets, a profile can be a user, a user belonging to a group, a group itself, etc... The framework does not care about the real "type" of the profile. The only thing it needs to know about the profile is its unique identifier. The "trick" is that profiles can be associated together through a multiple inheritance relationship, providing hierachical profiles structure. This way, you can model any kind of "user profile" system !

The figure below shows a typical NT-style user account system with basic groups :

As you can see, there is only one "level" of groups. Let's have a look at another profiles structure which reflects a company's organisation :

As you can see, in this organisation we've got composite "departments" as well as multiple inheritance for the employee Ma Baker who is in both Sales and Human Resources departments.

Of course, these two examples are not exhaustive, and you can virtually model any kind of profiles management systems with this multiple inheritance model.

The framework specifies the profiles management system (a.k.a. ProfileRepository) through dedicated interfaces, and it is up to you to provide an implementation of these interfaces as bridges to your own users, groups, roles or the structure of your choice, and to make the relation with your databases.

NOTE: More informations about the ProfileRepository and implementation techniques are available here.

At the moment, the generic profiles model we've just described is not very useful... Don't worry, it will make sense in a minute :-)

Facets meets profiles

We've just discovered how the ProfileRepository works, the multiple inheritance and such stuff. Just before, we talked about the facets that could be executed on objects to provide views on them. We saw that a facet was identified in the system by a (name, target object type) pair. You're probably reading these lines because you want to know more about how we could have personalized views of objects, aren't you ? Well, here we are, [JFacets] is all about facets that are executed on Objects for a given Profile !

If we add the Profile to the key that identifies a facet, we now have a 3-element key (name, object type, profile). By associating some code that can generate an HTTP response to this 3-element key, we've got the basics of our profile-based applications framework.

Remember our facets tables ? So let's now add the Profile as an element of the key and have a look at the updated table :

	Catalog	Product	DVD	Book	ShoppingCart
Content Administrator	view	manage	view	view	view
StockAdministrator	view	viewStock
Client	view	addToCart	view	view	view, empty, order

As you can see, we now have a much better structure, and it's quite simple now to retrieve the facet, and thereby the code to execute, for a given profile (user, group or whatever) and object.

This mechanism is very simple when you look at first sight. But, when you think about it a bit deeper, it reveals to be very powerful (and also to be used with care) ! The system enables to associate the code for a name, a profile and an object type. But you have to take great care of inheritance relationships. Remember, the types makes a multiple inheritance graph (yep, interfaces are handled too !) as well as the profiles !!! This provides great code factorisation capabilities and keeps fine-grain facet overriding available if needed...

The "Profile-based MVC" paradigm

As we've seen, JFacets is a profile-based controller layer. It allows to define and execute profile-aware facets that contain custom code for some profiles and some target objects.

The following figure gives a very high-level architectural view of JFacets 's profile-based MVC paradigm :

The green circles and connectors show how JFacets, as a controller layer, can be used to obtain different representations of a given object for different user profiles. Once again, JFacets is NOT a view technology, but as a matter of fact you can use it to "drive" the rendering process and obtain personnalized views of your objects.

The Model and the View layers are the usual ones, we won't talk about it here. Everything we need to know about them is that the Model is represented by Java objects, and that the View is handled through any technology, depending on the JFacets implementation. In SwingFacets ?, view is handled through Swing components. In WebFacets ?, you can use virtually anything (plain JSPs, Velocity templates, JSF, or whatever).

JFacets stays at the controller level, it is in no way intrusive with the Model, and lets you handle the View as you want.

Conclusion

JFacets provides an abstraction layer for profile-based application through the Profile-based MVC paradigm.

The Profile Repository concept allows to encapsulate virtually any user management system, and facets executed on objects for profiles are a convenient, consistent and effective way to provide customized representations of objects for particular users.

Now that you know everything (or almost :-P) about the concepts in JFacets, you can have a closer look at the more technical docs of each implementation : WebFacets ? and/or SwingFacets ?.

ConceptsOld