Woko : POJOs on the Web !

Get Displayed : What's a GUI ?

GUI developement is simple in the concept. Basically, it's all about presenting objects to the end-user, and allowing to interact with them. You typically show a product, show a cart, allow to add products to the cart etc. In the end, if you think about it, the GUI can be seen as a set of views of, and interactions with objects. Views present the objects, and interactions allow to trigger some processes (collaborations between objects) in the Domain Model.

Get Into Troubles : GUI developement is often chaotic...

In practise, it's very often a repetitive and boring task. You usually feel like you reinvent wheels all the time just to get things displayed on the screen... annoying, huh ? OK, you have frameworks and tools that help a lot now, but there's almost no really consistent methodology behind them ! Take RCPs for example : they offer a lot of attractive and useful features to build interfaces, but no-one really tells you how to use these tools in order to build an application. You rarely see the concept of views on objects in such tools, they're ingredients, but you still do the cooking yourself ! Not to mention so called "web frameworks" which mostly have their "proprietary" vision and tools, and all require you to learn a new language and concepts just to get started...

Get Organized : Domain Driven Developement

Let's climb a bit in the abstraction levels, and we find much more interesting stuff, like Naked Objects and other frameworks gravitating around the Naked Objects Pattern (JMatter, RomaFramework, Able, etc.).
Basically, the idea is that objects should be self-descriptive to such an extent that GUIs can be completely generated for them ! You feed the system with some Domain Objects, and you've got the GUI for free ! Doesn't thet sound like a dream ??? It's reality !

Get Profiled : The Woko Way !

Woko inspires from this concept too. It's an Object-Oriented Wiki : it allows to put your objects on the web without the hassle of writing UI code. It heavily relies on facets in order to allow profilized browsing of persistent POJOs without effort.
You simply develop your Domain Model using annotations and POJOs, and Woko displays them out-of-the-box in web pages ! Kinda Wiki-style CRUD : you can browse, create, edit and associate objects together directly in an intuitive and easy approach... You can also search in your objects "a la Google" directly, and have RSS feeds for them !!!

Woko is all about presenting some facets of your objects to end-users based on their profile. This is its major difference with other Domain-Driven frameworks. In Woko, almost everything is facet-driven, which means that you can customize the default rendering of some Domain Objects for some particular user profiles ! And that's what all web application developement is about today : you want information to be shared in a personalized fashion !
Last but not least, you don't "scaffold" or generate code in Woko : you extend it ! You don't have any round-tripping issues, you never overwrite the wrong file... you simply add what you want by extending the appropriate facets for the appropriate Domain Object and User Profile.

Woko is more than an framework, it's a full-stack application skeleton, which bundles a bunch of technologies and frameworks together :

• Hibernate + Annotations : Persistence and Domain Model ;
• Stripes + Stripernate : Web MVC, FORMs & validation, Hibernate integration ;
• JFacets : User profiling ;
• Acegi : User authentication, long-term sessions, ACLs ;
• Compass : Object-Oriented search engine.
  

The integration between all these components is almost transparent for the developpers. Of course, you have to understand Hibernate Annotations and JEE webapps to develop Woko apps, but as for the rest, complexity is encapsulated so you often have a very simple answer to your problems.
Developing in Woko is simple : you write Domain Objects, and facetize them for your user's roles !

Get Involved !

Woko is fun : the way you get your objects on the screen in a few seconds is still kinda magic :-)
Woko is disruptive : it completely breaks the model and proposes a new way of building multi-profile, object-and-profile-driven webapps.
Woko is easy : it leverages complex technologies by allowing to use them in a simple way, without even noticing it.

For the moment, it's only a prototype, but it's really promising. We're open to new ideas and contributions, so feel free to speak up !

Try it, and tell us what you think !

JFacets 1.3.5 released...

JFacets v1.3.5 is available for download on sf.net !

It includes some pretty cool improvements that have been tested in several applications recently.

Change List

• Acegi integration : the JFacets core now includes the Acegi integration layer. It revealed very efficient and easy to use, and has now been in use for months without problems. It's now bundled with the JFacets jar for easier use.
  

• fallback profile : JFacets can now default to a fallback profile in case supplied profile is null. For a while, invoking facets for unauthenticated (or guest) users has been painful. You had to manyally check if there was a profile, and decide what to do in this situation (otherwise you had a nice NPE !). With the more and more common use of Acegi as the authentication system, we needed automation there ! So now the JFacets bean can be configured with a fallbackProfileId property, and it'll handle all the null-checks etc ! No profile for the current request ? Fallback profile used :-) This allows to use facets even in the "public" sections of the application without any coding !

• @FacetKeyList : you can now have several assignations for the same facet class, when using annotated facets. The @FacetKeyList annotation allows to have several @FacetKey for the same class.
  

Plus some small improvements here and there, and doc writing (don't get mad, it's still pretty messy in there, sorry for that).

Powered by JFacets !

JFacets has been intensively tested recently, in various situations...

We now use it at work in a WebStarted Swing application where facets are used to create a fully profiled UI (actually some JPanels implement IFacet and own a @FacetKey annotation ! we just load them when creating the UI for the current profile). This was the first real attempt at writing facet-based Swing apps, and it's a really successful one. The programmer (a colleague at CSTB) was amazed with the ease of use of the facets, and I think it saved him a few months of work !
Also, JFacets continues to grow in the web tier, and to power more and more webapps, little by little. The integration with Acegi is really a bless, and the full annotations/taglibs makes facet-based web developement really easy.
Last but not least, on a parallel note, Woko gets really serious now, and opens pretty awesome perspectives in Agile Web Developement ! I'm currently trying to set up a flash demo so that you see it in action, it's really cool stuff, kind of "the stack of your dreams" ??? Stay tuned...

Enjoy this new release !

Remi

PS : I've shut the Sourceforge ML since nobody was using it. A forum should be up and running soon, I'm on it...

Automatic discovery of annotated facets

As of v1.3.3, JFacets has a new way of writing facets. After Java/XML and Groovy facets, here comes annotated facets !

The aim of this solution is to enable pure Java facets without any external configuration file (let's get rid of the XML facets descriptor). Basically, you can now annotate some Java classes that implement IFacet, with the @FacetKey annotation. You simply specify the facet assignation parameters as attributes of the annotation. A dedicated Facet Descriptor Manager can be configured so that annotated facet classes are loaded from the classpath at startup.

It's a good tradeoff for people who want anto-discovery but don't want to use groovy.

Read more on the wiki

Acegi Authentication

While working on CMS, I've had a look to Acegi and I really found it simple and nice. So I decided to begin testing with it before going deeper in JAAS...

Since JFacets and Acegi are fully Spring-based, integration has been pretty easy and makes sense ! A single component can be used in order to implement both the ProfileRepository and the UserDetailsService, and both flat and hierarchical roles can be handled.

I've checked a new JFacets2-acegi module in the CVS (an eclipse project) and added a page in the wiki.

Check it out !

Container Managed Security part 2 : exploring users and roles

I've went again through JAAS docs, and apparently there is no standard API for exploring the users and roles "database" :-/

This is similar with Acegi... You can, from a user principal, get a list of "roles" (bottom-up), but you can't get a list of all roles, get all the users in a given role, etc. (I have posted a question on the Acegi forum but got no answer).

Last but not least, realms have to be configured at the App Server level, and so it's not portable from a container to another...

All this just sucks ! Not only the roles/users structure is flat, moreover you can't get the informations in a standard way !
Man, maybe I should propose the Profile Repository concept to the JCP ;-P

So, for using facets with CMS, one has to implement a specific Profile Repository from scratch, that relies on his own stuff...

Today I'll try to work on a base class that already implements most of the stuff for managing Users and Roles, with a higher abstraction level than the base IProfileRepository interface. This should allow easier implementation of the Profile Repository.

This base class will be used for testing with regular CMS (e.g. JAAS Login Module in Tomcat) and Acegi (custom UserDetailsService).

If testing is successful, I'll include the CMS stuff in 1.3.

Container Managed Security part 1 : authentication

It's no secret, J2EE webapps can (and should) rely on Container Managed Security (CMS) in order to perform authentication and authorization.

From anywhere in the application, you are able to retrieve the user name :

String userName = request.getRemoteUser();

In typical WebFacets applications, the user profiles are identified by the user's login name... see where we're coming to ? We could use this user name in order to use facets...
An utility class could be used to retrieve the current user's profile, something like :

public IProfile getCMSProfile(HttpServletRequest request) {
  String userName = request.getRemoteUser();
  if (userName==null)
    return null;
  else 
    return profileRepository.getProfileById(userName);
}

And we could also have a filter that automatically loads the profile, for each incoming request.

Here it is for the authentication part. Next to come : mapping the CMS roles to profiles...

Blog Opened

I've decided to set-up this blog in order to broadcast some infos about my work with (and on) the framework.

More to come soon...

Have fun