JFacets is an open source (LGPL) MVC framework that deeply integrates the concept of user profile. It handles different representations of model objects for different user profiles through facets that you write, and that are invoked at run-time by the framework. This allows to easily perform custom operations on objects (including final rendering) depending on the end user.

JFacets' key features include:

• Based on simple, but yet powerful concepts (the "Profile-Based MVC Paradigm")
• Focuses on the Controller level (view-technology agnostic, model-agnostic)
• Defines a generic API for profile management, allowing to re-use existing User Directories, legacy databases etc. by developing small adapters
• Defines a generic Authentication mechanism, allowing re-use of existing authentication processes
• No intrusion at the back-end level (use your business objects as is with no changes)
• Small configuration (only one very simple XML file, which could be replaced by annotations)
• Fully J2EE compliant (WebFacets is built on top of the servlet API as a Servlet Filter)

In short, JFacets allows development of customized views ("facets") of the application's business objects for the application's profiles, in a consistent and effective fashion.

In JFacets, controller code is bound to the requesting profile at run-time, as well as to a target object, which allows driving the rendering process for the user and the object you want to display to the user who requests it.

A typical example is the typical read-only/update case, where user of role "A" can update the properties of an object "O" whereas user "B" is only able to read the values.
In JFacets, you would define one facet for each of the profiles (A and B), that would do the necessary job to display the object as needed (e.g. disable all inputs for users of role B). At runtime, the framework will locate and execute the appropriate facet for object O and authenticated profile.

At the moment, JFacets includes a fully functional Web implementation of the Profile-Based MVC paradigm (which has already been used in several applications), and work has started on SwingFacets, to build profile-based Swing apps.

JFacets uses only two external libraries, Spring for IOC and configuration and Log4J for logging.

Other resources:

• JFacets Wiki

Another MVC framework.

Another MVC framework.

Erf.
Did you give it a try ?
Did you only read the home page of the wiki ?

Consider having a look to it, you'll see that you may be wrong, and consider checking things out before posting...

JFacets is precisely not Yet Another MVC Framework.

To say it short, you can see it as a thin Control layer that you rely on when it comes to developing profile-driven applications.

It's no intrusive by any mean w/ your model and view technology, and you should be able to use it with a "regular" MVC framework (e.g. WebWork, Struts etc.).

Ho, BTW, I'm currently investigating integration with JSF.

Have fun,

Remi - the author

I forgot...

Check this out :

http://jfacets.rvkb.com/index.php?n=WebFacets.WebFacets

Have fun,

Remi

I will be very eager to look into JFacets's integration with JSF. JSF has the faces-config controller which provides Navigation control. How would JFacets integrate to it? Looking forward to your results on JSF integration.

Thanks much

I'm on it :-)

Well, the thing is that I'm a complete newbie with JSF and it's quite huge (I still have a headache from sunday's JEE tutorial !).
But that's definitly interesting, I'm progressing little by little.
At the moment I have a working example app, but it's too basic to be revelatory, I only have one managed bean, and one view per profile, thereby I don't use... navigation :-P

I'll let you know about my results.

Have fun,

Remi - to be continued

Hi Sheetal,

I've been digging that stuff a bit more, and I think I found something...

But as I'm a laaaaaame with JSF, now I'd like your opinion (and others can speak as loud as they want as well :-) !

In my case, I wanted to do a login form (index.jsp, JSF controls in there) with two different navigation outcomes (guest, and admin) that respectively send to a page with read-only text (text.jsp, JSF controls in there), and send to a page with a textarea and submit to modify the text (text_admin.jsp, JSF controls in there). This correspond of course to some "guest"/"admin" roles in the app.

I've defined the following navigation rule in faces-config.xml :

<navigation-rule>
    <from-view-id>/index.jsp</from-view-id>
    <navigation-case>
        <from-outcome>guest</from-outcome>
        <to-view-id>/text.jsp</to-view-id>
    </navigation-case>
    <navigation-case>
        <from-outcome>admin</from-outcome>
        <to-view-id>/text_admin.jsp</to-view-id>
    </navigation-case>
</navigation-rule>

Now, in the login form, there's a text input and a button that fires the event :

<h:commandButton id="submit" action="guest/admin" value="Go!"/>
</h:form>

What we want is to dynamically set the "action" attribute of this UIcomponent to "guest" or "admin".

Once clicked, the button would submit the request, and JSF would handle the dirty job and forward to the appropriate page. Pretty cool.

The even more interesting thing is that the action tag can reference an action-method of a backed bean (yeah, with bacon & eggs please). You may see where I want to come to...

Let's have a looks to the WebFacets side of the story now.
 
The thing is that navigation could be controlled by the execution of appropriate facets, with no changes to the JSF Navigation Model (actually it could apparently be REALLY cool if it works !).

I've tried to do this with the "bootstrap facets" at the moment (and it seems to work), but I think the concept can be generalized to all facets (I'll make sure it is).
In short, the "boostrap facet" is the one that's executed just after the user has logged in.
The process is similar to the other facets : the servlet filter retrieves the appropriate facet for the current profile and executes it. This happens for each request that can be handled by the filter (it detects that a facet has to be retrieved and executed).

While I was playing with the backed beans, I've had a revelation : what I've done is to use the facets themselves as the backed beans !
I wrote an implementation of IWebFacet (from jfacets.web) that binds itself to the request (with the name "facet") when executed. Is also has an important public String outcome() method. He he :-)

My two bootstrap facets extend this base class and override outcome() to return the appropriate navigation outcome. The facets are assigned like this :
* "bootstrap", "guest", java.lang.Object -> jsftest.GuestBootstrap
* "bootstrap", "admin", java.lang.Object ->
jsftest.AdminBootstrap

Now, back to the JSF side. Since the facet has bound itself to the request (with the name "facet", I can use it in my button as a backed-bean like this :

<h:commandButton id="submit" action="#{facet.outcome}" value="Go!"/>

So, to summarize :
* the user points his/her browser to index.jsp ;
* he fills in the login form and submits the button control is clicked, firing an event via HTTP request ;
* the WebFacets filter intercepts the login request, authenticates the profile, retrieves the bootstrap facet and executes it (this binds the facet to the request) ;
* JSF handles the request, it dynamically generates the navigation outcome and the appropriate page is displayed.

And guess what ?
I effectively see two different screens depending on what I enter in the textfield.

:-)

Any comments warn welcome after this JSF marathon !

Have fun,

Remi - The Need For Sleep II

"Check this out :

http://jfacets.rvkb.com/index.php?n=WebFacets.WebFacets"

Curious...is your site running on PHP or JFacets?

Curious...is your site running on PHP or JFacets?

The reasons for this are actually obvious :
* Would you rewrite a nice wiki that works fine, has an active community and plenty of plugins ?
* Do you know any free of charge java hosting ?

I love Java, no doubt, and I would certainly not switch to PHP for my own projects, with my own reasons.
But I have no problems using good software, whatever the implementation language. For once, I'm the end-user, so I do like the word Java does not mean anything else to me than an Island somewhere :-)

PmWiki is pretty cool actually, set-up is easy and so is usage. These were my requirements, not the fact the wiki is "JFacets-powered" (even if it could have been a pretty good basis actually !).

Cheers

Remi

"* Would you rewrite a nice wiki that works fine, has an active community and plenty of plugins ?"

You might also ask:

"Would you rewrite a nice MVC framework (of which there are many) that works fine, has an active community and plenty of plugins (addons)?"

My point is that the same question is valid for your and any one else's attempt to solve yet again the MVC framework problem with Java.

It seems like Java folks enjoy using the language to create frameworks; it seems like PHP folks enjoy using the language to create usable products (like Wikis, forums, image gallery software, blogs, etc...).

As for the free-of-charge java hosting question...no, I don't know of any off the top of my head...but why? You can't afford a few dollars a month to pay for Java hosting? Maybe it's time to find a job in something else that allows you to afford your hobby interests ... lol. ;-)

Cheers!

I'm sorry you miss the point to that extent, but honestly I don't see why I should even reply to you.

Don't get me wrong, I have no problems in explaining things, but apparently you did not even take time to look at JFacets (or you're just too intellectually limited to get what's new in it - but then shut the f*ck up twice !), so why should I take time to explain it to you ???

Sorry but I prefer saving my time to enhance the framework, and try to explain what it has to offer to interested and constructive people. Apparently these words aren't part of your vocabulary.

Anyway, you've been damn constructive, it's so great to have such kind of feedback, thanks for this ! People like you do push Open Source and community initiatives, for sure.

Of course, you can keep on screaming your ignorance loud and reveal it to the whole world, we're living in the TSS democracy so every opinon can be expressed. It's just that some posts are far more dumb than others.

So, until you have a smart question (try to find one, btw, to prove us your great knowledge), I won't answer you posts.

Cheers

Remi - I-don't-get-anything-but-still-I-always-have-to-talk

Actually I am just a complete idiot who likes being a gadfly. Your framework is probably quite nice and I will try it out!

I just need to grow up a little and learn to play nice!

My point is that the same question is valid for your and any one else's attempt to solve yet again the MVC framework problem with Java.

And are you the supervisor over all Java projects? Why vomit on others' attempts to offer something potentially useful to their peers?

IMHO, I think calling JFacets an MVC framework may be a misnomer. It appears to be more of a user profile API, and, quite possibly, something that I will find very useful.

As for the free-of-charge java hosting question...no, I don't know of any off the top of my head...but why? You can't afford a few dollars a month to pay for Java hosting? Maybe it's time to find a job in something else that allows you to afford your hobby interests ... lol. ;-)Cheers!

More vomit. What business is it of yours that he should want free hosting? It's irrelevant whether he use a PHP app to offer needed functionality on his website -- and it's off-topic. Smugness wrapped in a giggle and good cheer only emphasizes the smugness.

TTT

I'm sorry Remi for referring to your project as Another MVC framework, you could see how the first line of the news item led me astray: "JFacets is an open source (LGPL) MVC framework..."

Basically, you've put in place controller factory within an MVC framework so that a user's "profile" (role) determines the view displayed for a given request.

Assuming I'm not too far off the mark, I still am less than enthused by another leaky abstraction layer introduced into the serverside Java space.

Anyways, best of luck with it.

You seem to be a strange person (with all my respect), but I accept your apologies. Strange persons can also be interesting ;-P

you could see how the first line of the news item led me astray: "JFacets is an open source (LGPL) MVC framework..."

Well, you are also right in some way, and honestly I though about it when reading your post.
But actually, it took me like 5 years to get to this name and description !!! So I WON'T CHANGE IT NOW :-)

If you want the little story, the previous name, "JWebViews" was effectively completely ugly, and I had to refactor everything when I decided for JFacets.
Now there's JavaServer Faces, Facelets, and other ressembling terms... I'm sorry for that confusion folks, I've never been good at finding names !

For the "MVC" in it, it's just historical. At the time I built and used the very first versions (Y2K), it was a "Java version" of CorbaWeb which was IMHO something completely awesome : an action-based web framework, with profiled actions written in CorbaScript in a textarea in the browser !!! Think about a "CORBA scripted wiki struts". Can't find anything more agile, for sure :-)
Anyway, MVC frameworks were not a common thing back then, so the framework was mainly used as a regular "action-based" one, with the profiles dimension added, and with other stuff not included (views, taglibs, validation etc.).

Today, it's clear that Web frameworks have reached a very high level of functionalities (navigation, validation, state - this one will have to be investigated more w/ WebFacets btw !) that allows to work faster than using "plain WebFacets", which then acts only as "profile-aware" servlets (more or less).

So you are right too, at least partly : MVC is misleading ;-P

Basically, you've put in place controller factory within an MVC framework so that a user's "profile" (role) determines the view displayed for a given request.

More or less. It actually does not necessary help you for the "view". You can send back PDF (I do this with JasperReports for example), or "personalized XML" if you want. Or you can simply set a few request attributes, or do whatever you want !

You could more or less think about it as a "Profile-based request interceptor", just like an "aspect" that is triggered when the HTTP request is intercepted, before something else is done (render view, forward to another controller, I-don't-know-what).

Assuming I'm not too far off the mark, I still am less than enthused by another leaky abstraction layer introduced into the serverside Java space.

Well, now that we can talk, I would suggest you to consider it again.
The "abstraction layer" you refer to actually exist, yep, but it's the most simple thing you have ever seen in a "web fgramework".
Want a proof ?
Browse the project CVS on sourceforge, and have a look to the interfaces defined in jfacets.profiles .

This is the abstraction layer.
:-)

  Anyways, best of luck with it.

Well, I have no particular business plan about this if you want to know. All I can hope is some developers to like it and contribute to it, this way I would myself be able to develop my apps even faster.

Once again, try it ;-P

Have a look at the WebFacets tutorial (and why not, download and try the downloadable demo), you'll see how a very simple app can be built with absolutely no complicated framework or whatsoever (plain JSPs), and may give you ideas to benefit of the profile-based features of WebFacets in the environment of your choice.

Have fun,

Remi

Hi folks,

First, I'd like to thank Joseph for helping me in getting this news out ! I was impressed by his involvement, and I must admit I wouldn't have imagined that. Thanks a lot to the staff @TSS, you rock it !

Now, back to JFacets. I just want to add to the original post that JFacets is not a professionnal, commercial-level package. It's a fully OSS software that you can re-use, distribute, modify, throw it away, I-don't-know-what ! Feel free !

This piece of code is something that I've developed, on my free time as well as in commercial contracts, through the past 6 years. It helped me a lot to solve the recurrent "user profile" issue, which I think has been under-investigated with respect to its wide penetration (who doesn't have users and roles in his apps ?).

So the idea behind posting on TSS was to create a discussion, share ideas, get some feedback, and why not start a community around this problematic and get other developers involved.

Have a happy reading, I hope you'll enjoy it !

Cheers,

Remi - JFacets author

Hey Remi,

I went thru the website and it's looking good so far. I'm going give it a try in the next few days to see how well this fits into a project I'm currently working on... I was initially going to develop something very similar, but I think I'll give yours a try and if it fits well, you will have an additional client that uses your project :-)

I'll let you know how things go this week... And I'll also post any findings, questions or comments here as well...

Good Job!!

Venkatt

Hey Remi,

Hiya Venkatt,

I went thru the website and it's looking good so far.

Glad you like it !

I'm going give it a try in the next few days to see how well this fits into a project I'm currently working on...

Great !
Don't hesitate to send me some requirements if you want some general advice. Profile-based MVC can be strange at first sight, and I've found a few "design patterns"... mmmhhh, the term may be exagerated : let's say "recurrent solutions" in JFacets applications.
These can help to quickly get into it. Unfortunately I could not take time to write them down on the wiki... so feel free to ask !

I was initially going to develop something very similar, but I think I'll give yours a try and if it fits well, you will have an additional client that uses your project :-)

:-)
Thanks for tryin' it !
I hope it will help.

I'll let you know how things go this week... And I'll also post any findings, questions or comments here as well...

I'll be available, and happy to answer your questions.

Thanks for your curiosity and feedback :-)

Have fun,

Remi

Remi,

How is JFacets different from Portlet technology? Or could it be used to enhance Portlets also?

Remi,How is JFacets different from Portlet technology? Or could it be used to enhance Portlets also?

Hi Frank,

I'm not an expert at Portlets, all I know is they're some reusable components that are managed by a portal engine, where you have users, roles, groups in there, and you want to display some objects (NewsItem, BlogEntry, WhatEver) in these "sub-windows"... Well sure ! I see some similarities in the concept !

WebFacets does not implement any portlet spec, but after all portlets still are "views" that output HTML. And WebFacets is all about presenting customized views of application objects to the end-users, based upon their profile(s).
In a multi-user environment, it certainly makes sense !

You could imagine that a portlet asks for execution of a given facet for the logged user's profile and some target object.
Let's say that you have a wiki portlet, and two roles (guest, editor). You don't want guests to even notice the site is wiki-based, you don't want them so see any geek links or whatsoever.
You would then typically define two facets (at least, "update" is missing below) for displaying some "WikiPage" objects differently for your two profiles :
* ("view", "guest", org.mywiki.WikiPage) : displays the formatted page with a nice style, with no "edit" link etc ;
* ("view", "editor", org.mywiki.WikiPage) : displays the page with edit links allowing to modify the page, view history, and all "geek" stuff.

At run-time, the appropriate facet would be executed, leading in a customized display of the WikiPage object for the "guest" and "admin" users.

Of course, you could probably easily access the users and roles management system of your portal engine (either via raw sql, Hibernate-mapped POJOs, or using an API of the portal engine if any) and wrap it into a JFacets ProfileRepository.

So yes, I think you could use WebFacets in order to customize portlet content (apparently it's just about handling a request and generating a response, as usual).
Maybe even to customize the portal layout, but this may be a bit harder (I guess you have to "hook" into the portal engine in some way to do so) and anyway this is certainly already handled very well by most portal engines.

Actually, it's fun that you ask : I was thinking about all this when I played with a CMS last time, imagining a WebFacets-powered version ;-P

Cheers,

Remi