Two weeks ago, Simon Brown posted a Stripes entry to his "Comparing Web Frameworks" series, and now Gavin King has posted a Seam entry. It's becoming a common even to post implementations of the read-only blog, even though many have stated that the problem domain is too simple to really show off framework capabilities or make the implementations worthwhile.

The Stripes entry uses an annotation to specify an "action" method. Stripes is based on a standard Model 2 MVC architecture, where classes implement specific functionality. In this implementation, the model forwards to standard JSP pages, and uses JSTL to render the view, with the use of one custom tag to build link tags.

Stripes is one of a new breed of frameworks that takes advantage of the new features provided by Java 5 and this really shows. Where other frameworks adopt verbose XML files to map HTTP requests onto classes that will process them, Stripes adopts a much simpler annotation based approach, which really seems to work. Likewise, its use of returning explicit Resolutions is a nice change from the complexities of defining return values/views in XML. In Stripes, the easy stuff is easy. I'm looking forward to revisiting it with some read/write behaviour in the web application.

The Seam entry uses none of Seam's state management machinery, as Gavin points out in the introduction, but follows the normal implementation fairly well, with the introduction of an application-level Seam component to replace the data access mechanism Simon presented. In terms of implementation complexity, it's nearly as simple as the Stripes version, mainly uses JavaServer Faces rather than simple JSP for presentation.

What do you think of the framework comparisons? Are they complex enough to give you a valid idea of what each framework capable of doing, or should the competition involve something more complex such as the Petstore, suggested by Clinton Begin in another thread related to the competition?

Wow. Isnt there anything else for these talented developers to be working on besides frameworks?

Wow. Isnt there anything else for these talented developers to be working on besides frameworks?

Um .... no, why?

Hi Gavin

I would like to know how the framework is different from Struts. What kind of applications is suitable for these frameworks? What adventage they provide over Struts. Can these framework works for high traffic public sites like ebay.com.

Wow. Isnt there anything else for these talented developers to be working on besides frameworks?

Absolutely. My day job involves working on software to expedite research into cancer and other diseases with a genetic component (no kidding). And in my spare time I develop Stripes so that I and people like me can be more efficient in our day jobs ;)

-Tim Fennell
Stripes: Because web development should just be easier.

It's great to increase efficiency, but dont you think the current quantity of frameworks is actually disruptive to the community? I feel like there is too much division, and not enough standard.

Is there any way you can wrap your framework into an "extension" of another framework rather than having folks start from scratch?

It's great to increase efficiency, but dont you think the current quantity of frameworks is actually disruptive to the community? I feel like there is too much division, and not enough standard.

Is there any way you can wrap your framework into an "extension" of another framework rather than having folks start from scratch?

http://weblogs.java.net/blog/jhook/archive/2006/03/the_new_servlet_1.html

I've been tossing around the idea of using JSF/Seam to create an Action-based framework, from the samples I've generated, it looks to be fairly straight forward since Seam piggy backs on JSF's lifeycle phases which are constant in all frameworks, including Struts.

I really think a solution like that, with hybrid capabilities of the normal JSF component stack would be a total win-win for developers today.

Is there any way you can wrap your framework into an "extension" of another framework rather than having folks start from scratch?

Sure. Seam is built entirely as a set of extensions to JSF and EJB3. It's doing stuff that the standard frameworks don't do yet. Reimplementing Struts is simply not interesting to me. I want to implement new stuff that older frameworks can't do.

It's great to increase efficiency, but dont you think the current quantity of frameworks is actually disruptive to the community? I feel like there is too much division, and not enough standard.Is there any way you can wrap your framework into an "extension" of another framework rather than having folks start from scratch?

I agree that the quantity of frameworks is disruptive. It actually makes it hard for new frameworks that do have potential to get noticed ;)

Several people have commented on Stripes that "couldn't it have been an extension to X". And, well, no. One of the goals of Stripes is to make life simple and efficient for developers across the board. This mean that all the APIs have to be well thought out, simple and intuitive. It means that the documentation has to be good. It means that there can't be a list of dependencies as long as your arm so that it takes you hours to configure things and just get started.

In short, what Stripes strives for is just not possible to do by extending/adding on to existing frameworks. If you take the time and play with Stripes you'll realize that there's no way I could have generated such a positive experience without starting over :/

As an aside though, Stripes makes heavy use of existing standards where possible. It doesn't have it's own template language. It sits on top of the Servlet spec. It integrates effortlessly with JSTL instead of having a huge tag library. Etc.

-Tim Fennell
Stripes: Because web development should just be easier.

It means that there can't be a list of dependencies as long as your arm so that it takes you hours to configure things and just get started.

As an aside though, Stripes makes heavy use of existing standards where possible. It doesn't have it's own template language. It sits on top of the Servlet spec. It integrates effortlessly with JSTL instead of having a huge tag library.

Those are definitely strong points that I noticed when I tried out Stripes. It's a very "bloat-free" framework, and very fast to get up and running.

I also appreciated the lack of a proprietary template language. Personally, I prefer to chuck JSP and use FreeMarker instead, and this was very easy to do with Stripes. You can access your action bean through the ${actionBean} name, and you can use the tag libraries since FreeMarker supports them.

The NameBasedActionResolver is a good friend too :-)

I know many people find there are too many frameworks out there. Personally, I think it's great to see different approaches, and to have these choices available; but professionally, I can see how the diversity can be a problem. I don't know what I'd do if I had to choose tomorrow which framework to use and commit to for a relatively long-term project within a big company with many developers.

Frederic

It's great to increase efficiency, but dont you think the current quantity of frameworks is actually disruptive to the community? I feel like there is too much division, and not enough standard.Is there any way you can wrap your framework into an "extension" of another framework rather than having folks start from scratch?

+ 2!

Even if Seam can be factored into separate pieces.

Wow. Isnt there anything else for these talented developers to be working on besides frameworks?

Absolutely. My day job involves working on software to expedite research into cancer and other diseases with a genetic component (no kidding). And in my spare time I develop Stripes so that I and people like me can be more efficient in our day jobs ;)-Tim FennellStripes: Because web development should just be easier.

No offense meant here, but maybe 1 in a 1000 developers get to do something really meaningful in their job. Wouldn't you be better off putting in the hours spent developing yet-another-web-framework on your day job where you're helping to fight cancer?


PJ Murray, CodeFutures Software
Data Access Objects and Service Data Objects

Wow. Isnt there anything else for these talented developers to be working on besides frameworks?

Sure, docs and examples for these frameworks ;-)

Wow. Isnt there anything else for these talented developers to be working on besides frameworks?

Sure, docs and examples for these frameworks ;-)

And don't forget blogginh about it and spamming this and other news sites :)

Spamming, Eelco? Nothing appears in the news of TSS without editorial approval. Even so, there's only one RIFE post in the news that I sent in ("Comparing Web Frameworks: RIFE") during the last three months. There was one written by Joseph Ottinger ("RIFE compliments and possible future directions") and one written by Stephan Meslin-Weber ("Transparently adding metadata to POJOs"). As for the other news sites, please show me where, it would be really nice to see one covering RIFE and me not even knowing about it.

Spamming, Eelco? Nothing appears in the news of TSS without editorial approval. Even so, there's only one RIFE post in the news that I sent in ("Comparing Web Frameworks: RIFE") during the last three months. There was one written by Joseph Ottinger ("RIFE compliments and possible future directions") and one written by Stephan Meslin-Weber ("Transparently adding metadata to POJOs"). As for the other news sites, please show me where, it would be really nice to see one covering RIFE and me not even knowing about it.

Hey Geert, it was a joke! I was just refering to people like us posting on this list instead of doing all the other things we might do. Nothing wrong with this thread or the way you reacted on it :) Btw, did you notice I didn't try to promote W... W... nah, I'm not gonna say it ;)

Eelco, you have a wicket sense of humour.

OK I promise it's the last time I use that pun ;-)

For my needs, a good web framework should have the following:
 1) Components: little blocks that the framework will allow me to put together in a plug-and-play way. JSF, Tapestry, RIFE among others seem to be good at this.
 2) URL control: all component-based frameworks list their hiding the request/response handling details as a plus. I personally like to have access to request/response handling details. The framework should allow me to use custom URL schemes. In a world where the success of most sites rely on how effectively Google indexes them, developers should have the flexibility to manage the pathinfo rather than relying on cryptic urls.
I think RIFE and Struts are good here. I have never used WebWork so I can't say whether it allows url handling but I would reckon so.
 3) Easy integration with Spring framework. I personally feel guilty as a developer if I am not using Spring in a new project. I think most frameworks out there have a wiki page for Spring integration. I didn't measure the level of complexity in each case.
 4) Ability to use a POJO as a command object. Here I will simply say that I don't like Struts ActionForm.
 5) Easy integration with leading AJAX libraries.

I appreciate Simon Brown's and everyone else's efforts to compare the Java Web Frameworks out there. As it's becoming a daunting effort to select which framework to use.

Based on my requirements above, I am currently in favor of RIFE. And I would very much like to hear your thoughts.

For my needs, a good web framework should have the following:

RIFE indeed totally fits the bill here, and in that it's quite unique being a component framework that still allows you to have total control over your URLs. The pathinfo handling is very powerful and one of the most liked newer features, more info about this here:
http://rifers.org/wiki/display/RIFE/Pathinfo+mapping+for+element+inputs

We also now have direct Ajax support for DWR, so you're set there too.

RIFE indeed totally fits the bill here

Geert my friend. You've pitched your framework a number of times here, which is fine seeing as how all of this conversation started with RIFE. But I'd like to see some code where some keyboards are. ;-)

Would you be willing to attempt the PetStore challenge using RIFE?

JPetStore 5 Online Demo
Download JPetStore 5
Test Coverage

Cheers,
Clinton

Hi Clinton,

short answer, yes.

Longer answer:
http://thread.gmane.org/gmane.comp.java.rife.user/2393

I will however try to get the RIFE community to develop this, instead of doing it myself. Not only would this be a better challenge, but I also will have much less time in the coming months. If you want to see some code now, feel free to download any of the open-source projects and examples using RIFE: Javapaste, Bla-bla List, Drone, eCalendar, Bamboo, Elephant. (https://svn.rifers.org/)

See you tomorrow evening in Vegas at TSSJS :-)

Geert

For my needs, a good web framework should have the following:

For my needs, a good web framework should have the following:

Make me think I am coding a desktop app.

I don't do web sites, message boards or B2C. I have applications that have to expose functionality via a non-plugin browser UI.

For my needs, a good web framework should have the following:
Make me think I am coding a desktop app.

Something like this?

...
hwndMain = CreateWindow("MainWndClass", "Sample",
  WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT,
  CW_USEDEFAULT, CW_USEDEFAULT, (HWND) NULL,
  (HMENU) NULL, hinst, (LPVOID) NULL);
 
if (!hwndMain) return FALSE;
 
ShowWindow(hwndMain, nCmdShow);
UpdateWindow(hwndMain);
 
while(GetMessage(&Msg, NULL, 0, 0) > 0)
{
    TranslateMessage(&Msg);
    DispatchMessage(&Msg);
}
...

For my needs, a good web framework should have the following:Make me think I am coding a desktop app.

Something like this?

...hwndMain = CreateWindow("MainWndClass", "Sample",   WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT,   CW_USEDEFAULT, CW_USEDEFAULT, (HWND) NULL,   (HMENU) NULL, hinst, (LPVOID) NULL);  if (!hwndMain) return FALSE;  ShowWindow(hwndMain, nCmdShow); UpdateWindow(hwndMain);  while(GetMessage(&Msg, NULL, 0, 0) > 0){    TranslateMessage(&Msg);    DispatchMessage(&Msg);}...

You brought up the worst example of a desktop api there is, well the second worst, the worst still is raw X :-)

For my needs, a good web framework should have the following:Make me think I am coding a desktop app.

Something like this?

...hwndMain = CreateWindow("MainWndClass", "Sample",   WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT,   CW_USEDEFAULT, CW_USEDEFAULT, (HWND) NULL,   (HMENU) NULL, hinst, (LPVOID) NULL);  if (!hwndMain) return FALSE;  ShowWindow(hwndMain, nCmdShow); UpdateWindow(hwndMain);  while(GetMessage(&Msg, NULL, 0, 0) > 0){    TranslateMessage(&Msg);    DispatchMessage(&Msg);}...

You brought up the worst example of a desktop api there is, well the second worst, the worst still is raw X :-)

lol. I guess I should have said OO [like] development. I was gonna say like Swing but I figured I would avoid the flames.

lol. I guess I should have said OO [like] development. I was gonna say like Swing but I figured I would avoid the flames.

You have to agree that the following is "OO [like] development" in its prime:

oldClassProc=(WNDPROC)GetClassLong(hWnd,GCL_WNDPROC);
SetClassLong(hWnd,GCL_WNDPROC,(LONG)NewClassProc);

I don't really like Swing, it is too convoluted for a higher-abstraction environment, partly because Java does not have method pointers. Did not mean to start a flame either ;)

lol. I guess I should have said OO [like] development. I was gonna say like Swing but I figured I would avoid the flames.

You have to agree that the following is "OO [like] development" in its prime:

oldClassProc=(WNDPROC)GetClassLong(hWnd,GCL_WNDPROC);SetClassLong(hWnd,GCL_WNDPROC,(LONG)NewClassProc);

I don't really like Swing, it is too convoluted for a higher-abstraction environment, partly because Java does not have method pointers. Did not mean to start a flame either ;)

And that is why I avoided saying Swing. It was the concept I was going for. I could have said VB(classic) or WinForms or Swing or SWT or so on, but people would focus on the technology and not the technique. All of those are very much alike and not much like what you posted. As I have said before, I like Echo/Echo2 for web app development. I have done some pretty dynamic UIs that would have been difficult if I had to write it using Struts or jsps or ... . To be honest, it would have been tough in VB too. :)

For my needs, a good web framework should have the following:

For my needs, a good web framework should have the following:Make me think I am coding a desktop app.

Absolutely.

For my needs, a good web framework should have the following:Make me think I am coding a desktop app.

Yeah ! Swing2HTML Renderer most wanted :-)

I don't do web sites, message boards or B2C. I have applications that have to expose functionality via a non-plugin browser UI.

Mmmhh, I'd like to react on this, since I feel the same ! I also see apps as gateways to some object models, not only as configurable portals.

In my ongoing web frameworks review, I've noticed that most of them seem really "page-based". They all offer nice and useful stuff for many things, but the core idea is flawed to me.

In my mind, a GUI (e.g. a webapp) is nothing but a way for the end-users to interact with some objects.

As a software developer, I specify and implement the model, and I provide a GUI so that the end-users can interact with this model (view some objects and their props, manipulate them by invoking methods etc.).
The GUI is nothing but human-interpretable views of my objects, with buttons/links/etc that triggers execution of some code, and possibly modify the display in consequence.

If you look at regular action/component-based frameworks out there, none proposes this by default. I mean, they don't care about your objects, they will just provide ways to build pages.

I've been building and delivering apps for a long time with my own framework (JFacets), which is highly based on the concept that you build GUIs by defining facets on objects (for some profiles too btw, but it's another story).

This is pretty different than defining pages. For me, it's a very good way to see GUIs as what they really are, and to develop them in a consistent way too.
To me, the frameworks should contain more semantics than what they currently do, or at least an other type of semantics.
Once again, I don't build dynamic pages, I build dynamic views on objects !

All this is pretty hard to explain in a single post... I've tried to sum up my thoughs about this here, I really think this is a definitly better way of developing webapps that really use an object model behind (btw, a blog site could -should!- have such a model, even if minimalistic ! it's OO time folks :-P).

Have fun,

Remi

The GUI is nothing but human-interpretable views of my objects, with buttons/links/etc that triggers execution of some code, and possibly modify the display in consequence.

The problem with this approach is that the most usable systems are use-case driven, not object driven. And with good reason. End-users, unlike developers, rarely think in objects, consciously anyway. They tend to work in processes: "what do I have to do to achieve this".

A process may display/manipulate a resource, or 2 resources, or 10, or 150 or none at all, all in one hit. The point is that if the GUI is too object-focussed, the process-focussed user finds it either tedious or impossible to achieve their goal. So you can end up with a logically correct but unusable system, ie, the user can theoretically do what they want but it is an utter bitch to use. This is one of my gripes about RoR. It is so object focussed, whereas users aren't.

Kit

The problem with this approach is that the most usable systems are use-case driven, not object driven.

Of course, my point has no meaning in a plain procedural world (which I don't live in any more), but Use Cases don't matter.
Even more, they encapsulate a set of interactions (scenarios) between the end-user and objects of the system !

 And with good reason. End-users, unlike developers, rarely think in objects, consciously anyway.

End-users are not supposed to know there's objects under the hood, and at the end he/she only sees the HTML representation of something...
But you know, in the apps I usually sell, the users precisely tell which stuff I have to manage in the system and how. I specify them as objects, to them they are "concepts that they manipulate in their everyday job".

So see it like this : "The GUI is nothing but human-interpretable views of the domain model concepts, with buttons/links/etc that triggers execution of some code, and possibly modify the display in consequence".

If you're an OO proponent like me, the "domain model concepts" are represented by classes...

 They tend to work in processes: "what do I have to do to achieve this". A process may display/manipulate a resource, or 2 resources, or 10, or 150 or none at all, all in one hit.

So what ?
No issue, you have facets that provides views on objects (most of them is about presenting things) and others that actually trigger a process/change a state in a state machine, whatever...

Think about the basic eCommerce website :

1/ the user can browse the catalog to see some products
2/ he can click a "buy" link on a product to buy it, this adds to cart and show updated cart to user

In 1/ a ("view", com.company.Catalog) facet is executed on the catalog instance. This facet can invoke other facets for compositing the output. Here we'll include a reduced view of each product in the page : in a loop, we dynamically render ("viewAsListItem", com.company.Product). This "viewAsListItem" facet on products generates the "buy" link.

In 2/, the user hits the "buy me !" link. That triggers the ("buy", com.company.Product) facet. This one simply adds the product to the user's cart, and dispatches to ("view", com.company.Cart).

Ho, BTW, looks like it also solves the problem that Michael and Alexandre are discussing ;-P

 The point is that if the GUI is too object-focussed, the process-focussed user finds it either tedious or impossible to achieve their goal.

I don't think so, really, and end-users that use my applications don't either.
OO is supposed to provide an understandable abstract representation of concrete things of the domain model.

To me, what's important in an application is precisely the model. And a GUI is nothing but a set of screens and actions that allow the user to manipulate the objects.

Of course, the developer can represent objects by facets of his choice, that could completely hide the fact that they are executed on this object.

But the most natural way of doing it is to write facets that display ojects (or parts of them).

I typically have a "view" facet on application's "first class objects". Most of the times, I also have "update" and "delete"...

So you can end up with a logically correct but unusable system, ie, the user can theoretically do what they want but it is an utter bitch to use.

Well to me the usability is not related to the fact that you put your objects on the front line.
You can have unusable interfaces outside of the OO world as well...

Honestly, thinking "pages" as "facets on objects" makes development very intuitive and simple. I have applied this methodology to several prrojects, and it has always gracefully fits with the OO approach in general. The transition from the Object Model to the User Interface is just so natural like this...

Really, you should try it :-)

Have fun,

Remi

The problem with this approach is that the most usable systems are use-case driven, not object driven.

Of course, my point has no meaning in a plain procedural world (which I don't live in any more), but Use Cases don't matter. Even more, they encapsulate a set of interactions (scenarios) between the end-user and objects of the system !

 And with good reason. End-users, unlike developers, rarely think in objects, consciously anyway.

End-users are not supposed to know there's objects under the hood, and at the end he/she only sees the HTML representation of something... But you know, in the apps I usually sell, the users precisely tell which stuff I have to manage in the system and how. I specify them as objects, to them they are "concepts that they manipulate in their everyday job". So see it like this : "The GUI is nothing but human-interpretable views of the domain model concepts, with buttons/links/etc that triggers execution of some code, and possibly modify the display in consequence".If you're an OO proponent like me, the "domain model concepts" are represented by classes...

 They tend to work in processes: "what do I have to do to achieve this". A process may display/manipulate a resource, or 2 resources, or 10, or 150 or none at all, all in one hit.

So what ? No issue, you have facets that provides views on objects (most of them is about presenting things) and others that actually trigger a process/change a state in a state machine, whatever...Think about the basic eCommerce website : 1/ the user can browse the catalog to see some products2/ he can click a "buy" link on a product to buy it, this adds to cart and show updated cart to userIn 1/ a ("view", com.company.Catalog) facet is executed on the catalog instance. This facet can invoke other facets for compositing the output. Here we'll include a reduced view of each product in the page : in a loop, we dynamically render ("viewAsListItem", com.company.Product). This "viewAsListItem" facet on products generates the "buy" link.In 2/, the user hits the "buy me !" link. That triggers the ("buy", com.company.Product) facet. This one simply adds the product to the user's cart, and dispatches to ("view", com.company.Cart). Ho, BTW, looks like it also solves the problem that Michael and Alexandre are discussing ;-P

 The point is that if the GUI is too object-focussed, the process-focussed user finds it either tedious or impossible to achieve their goal.

I don't think so, really, and end-users that use my applications don't either.OO is supposed to provide an understandable abstract representation of concrete things of the domain model.To me, what's important in an application is precisely the model. And a GUI is nothing but a set of screens and actions that allow the user to manipulate the objects.Of course, the developer can represent objects by facets of his choice, that could completely hide the fact that they are executed on this object.But the most natural way of doing it is to write facets that display ojects (or parts of them).I typically have a "view" facet on application's "first class objects". Most of the times, I also have "update" and "delete"...

So you can end up with a logically correct but unusable system, ie, the user can theoretically do what they want but it is an utter bitch to use.

Well to me the usability is not related to the fact that you put your objects on the front line. You can have unusable interfaces outside of the OO world as well...Honestly, thinking "pages" as "facets on objects" makes development very intuitive and simple. I have applied this methodology to several prrojects, and it has always gracefully fits with the OO approach in general. The transition from the Object Model to the User Interface is just so natural like this...Really, you should try it :-)Have fun,Remi

Hi Remi,

I don't deny that the implementation of a use case will do its work by manipulating objects underneath. But you seem to make the domain model the focus of the UI design and I think there is a very big risk that this approach will lead to an unusable system. When the use case is the primary focus of the UI, IMO you are much more likely to get interfaces acceptable to the user. The use case is more than just the sum of its parts.

Kit

Hi Remi,I don't deny that the implementation of a use case will do its work by manipulating objects underneath. But you seem to make the domain model the focus of the UI design and I think there is a very big risk that this approach will lead to an unusable system.

Don't get me wrong, I'm not saying that all pages in a webapp sould be the exact representation of an object if that's what you think.

But zoom out for a moment and think about how you do it yourself.
From the moment you use objects (and not plain JDBC), what you do in your webapp is creating views on it, in some way, don't you ?
The "regular" scenario :
* handle request with params (e.g. blog_entry_id)
* retrieve the BlogEntry object for blog_entry_id (Back-end code, DAO, JDBC, etc.)
* put the BlogEntry object in the page context
* send all this to a JSP where you display... the blog entry object :-)

Believe it or not, but I've handled far more complex use cases in real-life apps, following this principle, and the users did not complain : they don't see this, all they see is that they can do their job faster cause the "things they do" are in the box, and available through the browser.

The thing I wanted to say is that many of the frameworks around are not focused on doing this, but on creating pages, independently of the object model... even if finally, that what we all do finally IMHO.

When the use case is the primary focus of the UI, IMO you are much more likely to get interfaces acceptable to the user. The use case is more than just the sum of its parts.Kit

Once again don't get me wrong : the use case is a cornerstone in development process (links with customer, per use-case validation, etc.) !
But that's precisely where facets excel ! Once again it's closer to OO semantics than page-building frameworks, so it fits quite well with UML and associated development methodologies.
Since use cases are linked to the business model (classes) through scenarios (collaborations), facet-based developement is very natural.
In fact, you only have to get a drawing of the expected pages, and the UML use case and sequence diagrams. Then you start facetizing your objects so that the collaborations can be done... and the use case realized :-)

Have fun,

Remi

Once again don't get me wrong : the use case is a cornerstone in development process (links with customer, per use-case validation, etc.) ! But that's precisely where facets excel ! Once again it's closer to OO semantics than page-building frameworks, so it fits quite well with UML and associated development methodologies.Since use cases are linked to the business model (classes) through scenarios (collaborations), facet-based developement is very natural.In fact, you only have to get a drawing of the expected pages, and the UML use case and sequence diagrams. Then you start facetizing your objects so that the collaborations can be done... and the use case realized :-)Have fun,Remi

Hi Remi,

We probably have different sorts of customers! To me, the use case often becomes a very detailed description of the expected customer experience. The operation of the UI is fundamental and though it involves object manipulation eventually, it is not that that makes the customer satisfied (IME). So JFacets may be very useful for object manipulation, but it can only be a part of the whole, the whole being the use case.

Best wishes
Kit

Hi Remi,We probably have different sorts of customers! To me, the use case often becomes a very detailed description of the expected customer experience. The operation of the UI is fundamental and though it involves object manipulation eventually, it is not that that makes the customer satisfied (IME). So JFacets may be very useful for object manipulation, but it can only be a part of the whole, the whole being the use case.Best wishesKit

Hi Kit,

You've just put good words on my feeling about the facet approach :-)
(As other froggies out here, I sometimes can't find the english words to express what I think...)

I fully agree that the customer thinks in a more "process-oriented" way, and that's why I also consider that Use Cases are the most they can see of my UML spec. I mean, they don't know about the objects behind, all they express is the visual aspect of each screen (using drawings), and the expected result of each action (probably in a textual fashion).

That's the starting point : interactions, which are defined from requirements, expressed by the customer (under torture :-P).

Then, we (architects, analysts, developers... software builders in general) have to open the black box and design the inside (the other stuff in the UML model).

To do so, we follow scenarios for each use case, and end up with a domain model.
Basically, the "back end" guys handle implementation of the persistence and business logic, and provide API so that the model can be manipulated throug a UI.
The "front-end guys" have to cerate "screens" that the user will use to interact with the objects.
If you forget about how you present the information, what you do then is display objects and interact with them (navigate through links, changing properties through forms, etc.).

Actually, the "user experience" is always the result of "object manipulation" in some way... then it's more a graphical design question than an architectural or methodological one.

Oh, yeah, btw, another interesting stuff related to UML and methodology...
Use Cases are also about actors.
Typically, a Use Case is realized by an actor, and some collaboration between objects allows it.

Facets are not only linked to object types, they also are linked to profiles, which can be organized as a graph (like UML actors can inherit from other actors)...
This provides once again a very natural transition from the model to UI implementation !
Facets being assigned to object types (classes) and profiles (actors), they provide a consistent way to structure UI code related to particular use cases. In fact I do it this way 99% of the time ! The actors graph almost always ends up to a trivial JFacets ProfileRepository mapping, and screens (or parts of screens) and events almost always end up to be implemented as facets linked to the profiles and executed on application objects.

You may check this tuto, it briefly explains how a typical facet-based application is built.
As you'll see, the starting point is use cases :-)

Last but not least, I think facets fit well with MDA, since they provide semantic information about the application, independant of implementation.
As an example, I was thinking of a JFacets AndroMDA cartridge last time...
You would define the facets by creating a class in your CASE tool, stereotyping it (e.g. <readable and understandable in the model !
You know what an actor can do with any object just by following dependency links...

You could also define facet compositions, execution flows (state diagrams), generate facets for a given environment (Swing, Web, ...) and probably a lot of other stuff (I only use a little of UML actually, only the "pragmatic part of it" ;-P)...

What do you think of this ?

Have fun,

Remi

And with good reason. End-users, unlike developers, rarely think in objects, consciously anyway.

But oddly, they do tend to think in tables and records.

 This is one of my gripes about RoR. It is so object focussed, whereas users aren't.Kit

It seems that RoR (at least runnning with the defaults) is very database focused. That's one of my gripes.

And with good reason. End-users, unlike developers, rarely think in objects, consciously anyway.

But oddly, they do tend to think in tables and records.

Well yes, though I think tables and records are sufficiently familiar to the average end user from everyday use that it is not a problem presenting such in a UI.

Remember the problems many developers had (still have?) moving from a procedural way of thinking to an OO way. Bruce Eckel became rich on that premise.

Regards
Kit

Well yes, though I think tables and records are sufficiently familiar to the average end user from everyday use that it is not a problem presenting such in a UI.

Well, a collection of beans with properties is similar then.
The OO way : iterate on a collection and get props
The Relational way : iterate on a recordset and get field values

I don't think the end-user's representation of a table is similar to these ones anyway, you know... so the way you implement it does not matter : it all goes down to the way you present it.

And actually, the way you'd present a list of BlogItem objects is completely independent of the way you have implemented the system.

If you look at it, honestly, this "Blog" sample does not even need Object Orientation.
I'm sure that a good old CGI would beat any framework-driven implementation in terms of LOCs ;-)

Remember the problems many developers had (still have?) moving from a procedural way of thinking to an OO way

Well, no offense, but that may be your case right now ;-P

Actually, executing actions is procedural (struts or webwork or JSF events), whereas facets executed on objects, handling polymorphism etc, is closer to OO semantics, and very easy to use when you "think object" from the beginning.

Object Orientation is good to abstract concepts of the real world.
Facets are good way for representing these concepts to human beings.

Have fun,

Remi

Actually, executing actions is procedural (struts or webwork or JSF events), whereas facets executed on objects, handling polymorphism etc, is closer to OO semantics, and very easy to use when you "think object" from the beginning.Object Orientation is good to abstract concepts of the real world.Facets are good way for representing these concepts to human beings.

Huh? JSF isn't bound to any particular object model for invocation. That's why you have Shale dialogs/whatever, Seam's IoC model, or even Spring beans.

If you would actually do a little reading, you'd probably be suprised to find out that JSF is probably more ideally suited to your Facet stuff than anything else out there. JSF components act upon the model, not the other way around. With that, I'm not grandstanding JSF, just that your statement is utter bullox.

Huh? JSF isn't bound to any particular object model for invocation. That's why you have Shale dialogs/whatever, Seam's IoC model, or even Spring beans.

I don't get your point sorry, I was talking about an UI design methodology... You could apply it virtually with any programming language or technology, just like you can do OO with procedural.

What I meant is that all frameworks, as far as they are presented, focus on building and navigating in pages instead of providing a higher abstraction level : interacting (and thereby representing, one of the first stuff you need) with objects.
BTW, JSF could be used with (to represent) non OO backends doesn't it ?
The facets concept can't.

Did I express myself better this time ?

If you would actually do a little reading, you'd probably be suprised to find out that JSF is probably more ideally suited to your Facet stuff than anything else out there.

Lesson time, "Go back to school".

Anyway, that's also my opinion so I don't focus on the sarcastic remark.
"Facetized components" are probably the ultimate model as far as I see it...

JSF components act upon the model, not the other way around. With that, I'm not grandstanding JSF, just that your statement is utter bullox.

If you think JSF components (probably the "views and panels") are representing objects, and I think that's how you do too, then we agree from the beginning.
What I want to say is that facets are designed to do this. In that sense, they're closer to model objects than regular UIs which tend to be more "decoupled" from the model.

The facets story is applicable to Swing design also I think.
I haven't been very far in that direction yet, but it would obviously be even more adapted (far less technical issues, related to the protocol and other general web crap).
Since JSF (correct my ignorance if you feel to, master ;-P), is closer to Swing than regular request-response based approaches, of course facets would probably be even more powerful in that environment.

In short, keep kewl mate, I wasn't pissin' on JSF anyway :-D

Have fun,

Remi

I read about your Facets stuff when it was first mentioned on TSS, and what you are promoting, I'm seeing others already develop this kind of solution; piggy backing on JSF's component model such that there is a middle negotiation as to what properties/components are presented to the user based on objects referenced in the events (actions for the most part). Others, like Rick, have actually taken this 'scaffolding' logic to the next level with dynamically building the UI's based on the objects you request to act upon. So if you do have multiple facets in page, JSF will not only support your delivering of agnostic presentation segments, but also routing their events back to the segments. I'm sure most component models today would be able to support this, just that JSF's model separation seems to integrate easier with these types of customized solutions.

I read about your Facets stuff when it was first mentioned on TSS, and what you are promoting,

Promoting ?
I'm just sharing my own receipies.
No offense, but there's more politics around JSF, facelets etc. I think ;-P

I'm seeing others already develop this kind of solution;

Really ? The idea might not be so bad then don't you think ?
BTW, I'm very interested in a talk about this with other people doing it.
Clearly my own implementation of the concept lacks a lot of what you can find in other frameworks (validation, state, etc.). I'd love to get an enhanced one :-)

piggy backing on JSF's component model such that there is a middle negotiation as to what properties/components are presented to the user based on objects referenced in the events (actions for the most part).

That's how I saw it for swing, more or less.
But I have a completely different view of webapps. Even if I'm a component addict in general, I think that the "heavyweight" JSF targets a problem I don't even want to solve. I don't plan to develop desktop apps in web browsers, even if I respect and keep an eye on the state of the art there. I try to keep the component model simple (some useful taglibs are a good example of those IMHO).

As far as I'm concerned, web UIs are "simpler" than complex desktop apps, and that's also why they're successful (my mom wouldn't shop ebay if she had to open an eclipse perspective for it). They also require different skills to be created.
That's why, like others, I have a preference for simple concepts, and stick to the environment (I still use the servlet API programmatically, and I'm happy I can in many circumstances) instead of trying to conpensate its lacks with heavyweight technologies.
Just my opinion, the future will tell.

  Others, like Rick, have actually taken this 'scaffolding' logic to the next level with dynamically building the UI's based on the objects you request to act upon.

Excellent :-)
I have done the similar stuff in what I call ReflectionFacets.
It's a set of generic facets that use reflection to represent virtually any object (its properties and methods).
Like this, I have a (minimalistic) UI with almost no code : I provide the first object, and I can already navigate the object graph through properties. Of course all these facets are overridable to allow customization of the display.
This is very interesting and leads us to another debate : we can show something and play with the app incrementally by developing facets over the time to get other views & interactions on the objects. I feel this "generic facet" concept is pretty suited in RAD approaches (UC driven with short iterations etc)... a very interesting track to follow !

  So if you do have multiple facets in page, JSF will not only support your delivering of agnostic presentation segments, but also routing their events back to the segments.

Well in the facets world everything (or almost) is done through a facet being executed. This makes the event model pretty simple, but very powerful.
The whole think is KISS, and the web environment is pretty suited for this : you want to do something (view blog entry, checkout cart, I-don't-know-what), just execute a facet.
Send request, Execute facet (or more probably several chained ones) and Generate response.

  I'm sure most component models today would be able to support this, just that JSF's model separation seems to integrate easier with these types of customized solutions.

Of course, the most pluggable & extensible it is...
And I generally trust the J2EE spec when it comes to pluggability.
But as explained in the JSF tuto (which I dived into, contrary to what you think), and in general examples and code I could look at, it's very "page-oriented". Just look at the nav... it looks like completely opposite to facet-driven navigation, where you go from a facet to a facet through some facets (!).

Anyway, you clearly have grasped the "facet" concept, at least the "custom view on target objects" part of if (facets are not necessarily producing results), even if IMHO you have a very complex interpretation of something very simple and effective.

What do you think of the approach then ?
I'd be interested in an expert's analysis of the pros and cons of developing like this on top of JSF...

Have fun,

Remi

But as explained in the JSF tuto (which I dived into, contrary to what you think), and in general examples and code I could look at, it's very "page-oriented". Just look at the nav... it looks like completely opposite to facet-driven navigation, where you go from a facet to a facet through some facets (!).

Many of us in the EG groan over the tutorials out there and even some of the books since they all focus on doing very simple/struts-like things when JSF is able to do so much more (just like component frameworks in general).

An example was brought to light be a developer yesterday where he had a bean with a list of users. Within that UI you wanted to edit the parent bean, and add/remove/edit users. No where, do your beans need to have any JSF code, yet the UI components are freely able to 1) operate on the beans and 2) update the UI to reflect that there's 3 or 4 or 5 users being edited. Even as an EG member, simple solutions like this to do what would be otherwise overly complex with event routing and state management in many other frameworks.

What do you think of the approach then ?
I'd be interested in an expert's analysis of the pros and cons of developing like this on top of JSF...

Well, even the JSF cardemo, you have different types of cars, each with different features that need to be displayed. So the Java model/negotiation layer can customize all of the controls and state on the fly from backing logic-- similar to what it looks like you're doing with Facets. I've even seen some people use Facelets and conventions to take some property of a bean to resolve fragments of the view without any middleman logic.

Well, even the JSF cardemo, you have different types of cars, each with different features that need to be displayed. So the Java model/negotiation layer can customize all of the controls and state on the fly from backing logic-- similar to what it looks like you're doing with Facets.

For the view part, yes I think you could say it like this.
JFacets (the framework) actually provides a full-blown implementation of this "model/negociation layer".

Basically the developer creates facets and assigns them to object types (and profiles). Then at run-time the appropriate facet is located for the real execution type of the target object, and executed.
It's very simple, and has proven to be working and efficient several times.

I've even seen some people use Facelets and conventions to take some property of a bean to resolve fragments of the view without any middleman logic.

I think you just made my initial point : there's no out-of-the box support for such stuff (not mentioning the profiles once again which unleashes the power of facets), so you end up tweaking with naming conventions whereas you're supposed to have a high abstraction level framework to rely on !

That's what almost everybody does. But this is pretty limited compared to full-blown facets.

Naming conventions can't replace typing info IMHO, so they're very far from the semantic value of the facet assignation model.
Looking at a facet description file (especially with the minimalistic but pretty revelatory JFacetsIDE browser : check the screenshot) can give you a lot of infos about what the application does, and how it is built.
Finding the piece of code responsible for doing something in the UI tier is just natural and easy.
Erf, I think I begin to promote here ;-P

I have started investigations about JSF / Facets integration, but I could not go as far as I should if I want to get a deep view of it.
Unfortunately I had to stop just when I started playing with facelets ! As you can guess, since I worked with JSPs, I have a pretty bad souvenir of this experience where doing simple things looked very complex (what's that "verbatim" crap please ?? did we really need this ??) !
Facelets looked far more usable and sexy, I must admit they are tempting despite the lack of tooling around it :-)

I'll probably have a closer look to this, and I'll try to give a precise feedback of my experience.

Have fun,

Remi

blockquote>Remember the problems many developers had (still have?) moving from a procedural way of thinking to an OO way

Well, no offense, but that may be your case right now ;-PActually, executing actions is procedural (struts or webwork or JSF events), whereas facets executed on objects, handling polymorphism etc, is closer to OO semantics, and very easy to use when you "think object" from the beginning.Object Orientation is good to abstract concepts of the real world.Facets are good way for representing these concepts to human beings.Have fun,Remi
Well, I certainly don't advocate a procedure-only view of the world. But nowadays I see a healthy mix of procedures and objects being used. The reason, as stated previously, is that real-world systems involve people and people tend to think procedurally. OO is a great way of managing the complexity of data & behaviour, but it needs a "process facade" on top to manage the interaction with the user (I'm thinking of things like workflow, rule-based programming, screen design). Without wanting to deny the benefits JFacets no doubt brings to handling teh objects themselves, I'm not sure this "process facade" can be reduced to facets on objects.

Regards
Kit

Well, I certainly don't advocate a procedure-only view of the world. But nowadays I see a healthy mix of procedures and objects being used. The reason, as stated previously, is that real-world systems involve people and people tend to think procedurally. OO is a great way of managing the complexity of data &amp; behaviour, but it needs a "process facade" on top to manage the interaction with the user (I'm thinking of things like workflow, rule-based programming, screen design).

Erf, the BPM* stuff I guess... interesting, looks like we definitly have different views ;-)

I'm not ready to break the encapsulation paradigm yet, and as you may have guessed, I'm in favor of objects !
(btw very interesting stuff, well explained IMHO, in Naked Objects)

But still, the facets concept apply as well to more "procedural" worlds.

Let's thinks about the façade being a session EJB (or a WebService). Some methods (shall I say procedures ?) in there allow the realization of the use cases. The methods probably accept "object" parameters (by-value serialized instances for EJB, (de)serialized XML into mapped instances), and probably also return some stuff.

The UI has to expose the facade as web page(s) that allow the user to interact with the service : create parameters, invoke methods, view results, invoke other methods etc...

Using facets, you could easily define a facet (or more probably several ones) that's bound to the EJB's business interface, as well as facets to create/view/update params and view results etc.

I even think you could "drive the facet execution flow" (which facet executed on which object, and when) using workflow approaches... but I'm not a workflow specialist, I still believe in coding ;-P

Have fun,

Remi

Well yes, though I think tables and records are sufficiently familiar to the average end user from everyday use that it is not a problem presenting such in a UI.

And it causes us endless problems. People think they are familiar. The just don't understand as well as they think they do. Some do. Most don't.

Remember the problems many developers had (still have?) moving from a procedural way of thinking to an OO way. Bruce Eckel became rich on that premise. RegardsKit

Only because they put technology first, not design. I can't count how many times I see use cases that contain "Save in database" and "Get from database".

have u seen Web on Swing?

have u seen Web on Swing?

No I didn't know this. But as far as I understood from a quick browsing, it looks more like a "rich-client building platform" than real web development.

Of course, everyone lives life like he wants and it's great that people work on various stuff, but actually I don't trust this stuff yet.
I love Swing, and now that WebStart is here well... I tend to more and more keep the two environments separate and use them appropriately.

I was just talking about development processes behind regular Web Frameworks, and comparing it with my own experience.

But still these "RIA" (I used to call this client-server... fashion fashion ;-P) initiatives are interesting... I've been playing a bit with the ZK Framework this afternoon and got enthusiastic : looks like it could be a really cool view technology behind my facets :-)

Have fun,

Remi

ill like to add a feature
 No more tags i prefer the the use of attributes like tapestry and facelets use.

ill like to add a feature&nbsp;No more tags i prefer the the use of attributes like tapestry and facelets use.

I just don't get why all of these developers don't start to collect around the JSF API to produce frameworks. I'm looking at what these one off frameworks are doing and most all of it can be integrated into JSF. Long term, we'll probably see more expansion on JSF that will consume features of other frameworks into a single platform (like Tapestry/Facelets/Clay).

Don't get me wrong, a majority of the choices out there are brilliant in their own right, just that I think the java community would be better served if these developers would utilize the JSF API as a point of integration into the MVC stack instead of re-inventing everything just to differentiate a few unique features. Then these frameworks can leverage components, EL, IDE tooling, Seam, Spring, Shale, etc.

Jacob
----------------
Sent from my FrankenBerry Wireless Handheld

because it isn't ready yet?

Facelets aren't part of the spec and it is unusable when having to work with a design team in it's current incarnation. I've tried stripes and rife in the past few hours and all I need is a couple of jars files and I'm ready to go.

I don't want to have 20+ jars to get a small web application up and running, not because I want to save HDD space and memory, I just don't want to have to deal with all the dependencies when I upgrade a component. Everytime I upgrade hibernate I lose a day trying to straighten out my classpath!

There is a lot of talk about "lightweight" components in java, from my perspective, "lightweight" means a (very) small list of dependencies which means I can get going quickly and don't lose time on java's lack of standard versioning.

because it isn't ready yet?

Facelets aren't part of the spec and it is unusable when having to work with a design team in it's current incarnation.

I've tried stripes and rife in the past few hours and all I need is a couple of jars files and I'm ready to go.I don't want to have 20+ jars to get a small web application up and running, not because I want to save HDD space and memory, I just don't want to have to deal with all the dependencies when I upgrade a component.

What says it's not ready? There's lots of developers out there using JSF 1.2 and MyFaces-- I would argue that the stability of these projects is no different than any other project out there.

Facelets is preparing a 1.1 release which cleans up all of the script/browser-specific issues. Announcement soon :-)

Isn't 1.2 still at "proposed final draft" status? If a framework implements a non-final API then it can only be considered a "beta" at best and things are bad enough in this area without using frameworks that are (potentially) subject to change.

I'm not having a pop at you or your work, in fact I agree that JSF needs a lot of help to get going, but JSF 1.1 and JSP integration is dreadful and it *needs* facelets or something similar to be successful.

I also find it disconcerting how far behind Tapestry and Wicket, JSF really is. But I don't think the other two will ever gain enough market share that tool vendors will take notice and we can't keep editing 5+ files for every change we make forever...

Isn't 1.2 still at "proposed final draft" status? If a framework implements a non-final API then it can only be considered a "beta" at best and things are bad enough in this area without using frameworks that are (potentially) subject to change.

Right now everything in 1.2 is going in and final. You will always see tweaks in the implementations (most all of the issues we see come up are browser-related quirks).

I'm not having a pop at you or your work, in fact I agree that JSF needs a lot of help to get going, but JSF 1.1 and JSP integration is dreadful and it *needs* facelets or something similar to be successful.

I also find it disconcerting how far behind Tapestry and Wicket, JSF really is. But I don't think the other two will ever gain enough market share that tool vendors will take notice and we can't keep editing 5+ files for every change we make forever...

I do agree that Tapestry and Wicket have been able to innovate in this field a bit, but take a look at how Tapestry's able to use annotations or Wicket's Java model. Nothing's stopping someone from creating a similar Annotation model for JSF (look at Seam) or supporting designers with Clay/Facelets as Tapestry does. With Wicket, JSF delegates the whole stack to interchangable contracts such that one could use Java helpers to produce a Component tree/model and simply using JSF's 'binding' ability within the UI to gain the same 'feel' as Wicket.

So your observations of the market are correct, JSF is quickly swallowing the market but isn't capturing the IP that it should from talented developers. Keeping pragmatic, while JSF isn't the perfect solution to everyone, it very well could be if more developers would focus their attention on JSF's pluggable stack instead of doing everything from scratch.

because it isn't ready yet?Facelets aren't part of the spec and it is unusable when having to work with a design team in it's current incarnation. I've tried stripes and rife in the past few hours and all I need is a couple of jars files and I'm ready to go.I don't want to have 20+ jars to get a small web application up and running, not because I want to save HDD space and memory, I just don't want to have to deal with all the dependencies when I upgrade a component. Everytime I upgrade hibernate I lose a day trying to straighten out my classpath!There is a lot of talk about "lightweight" components in java, from my perspective, "lightweight" means a (very) small list of dependencies which means I can get going quickly and don't lose time on java's lack of standard versioning.

Use Maven 2 it resolves dependencies and works fairly nice. Better yet, create an archetype so setting up a new project is easy.

I am not sure I buy the argument that you should pick the framework that comes in one huge jar file. I'd prefer to pick the best of breed apps and integrate them.

We picked our toolset (JSF, Spring, Hibernate, Facelets, Acegi, AspectJ, Maven). Then created a sample app. Then created an archetype so creating future apps is easier. We use Maven to manage dependencies and it works out well. HDD space is cheap.

BTW I am not knocking Rife. It seems interesting.

because it isn't ready yet?Facelets aren't part of the spec and it is unusable when having to work with a design team in it's current incarnation. I've tried stripes and rife in the past few hours and all I need is a couple of jars files and I'm ready to go.I don't want to have 20+ jars to get a small web application up and running, not because I want to save HDD space and memory, I just don't want to have to deal with all the dependencies when I upgrade a component. Everytime I upgrade hibernate I lose a day trying to straighten out my classpath!There is a lot of talk about "lightweight" components in java, from my perspective, "lightweight" means a (very) small list of dependencies which means I can get going quickly and don't lose time on java's lack of standard versioning.

Use Maven 2 it resolves dependencies and works fairly nice. Better yet, create an archetype so setting up a new project is easy.I am not sure I buy the argument that you should pick the framework that comes in one huge jar file. I'd prefer to pick the best of breed apps and integrate them.We picked our toolset (JSF, Spring, Hibernate, Facelets, Acegi, AspectJ, Maven). Then created a sample app. Then created an archetype so creating future apps is easier. We use Maven to manage dependencies and it works out well. HDD space is cheap.BTW I am not knocking Rife. It seems interesting.

This is not to say that dependency management isn't an issue. I just think a better solution is to use Maven (or if you hate Maven... Ivy) to manage it instead of looking for a one size fits all framework. I like to use a certain stack of technlogies, and I don't feel hindered by dependency management. (This is not a knock on Rife since I have not used it, and am interested in what it offers.)

Rife would make sense (possilby) to me if it had a version that was built on top of JSF (if possible). I am looking for value adds to JSF, not reinvention of problems that have already been solved.

Rick Hightower (linked in),blog
JSF, Spring, and Hibernate training and consulting

We picked our toolset (JSF, Spring, Hibernate, Facelets, Acegi, AspectJ, Maven). Then created a sample app. .

Hey, we have picked the exact same stack where I work. But we are also using Struts Shale as our application controller. It might seem a lot of tools but man I have never been that productive before :)

We picked our toolset (JSF, Spring, Hibernate, Facelets, Acegi, AspectJ, Maven). Then created a sample app. .

Hey, we have picked the exact same stack where I work. But we are also using Struts Shale as our application controller. It might seem a lot of tools but man I have never been that productive before :)

Great minds think alike. We use a little Shale too.

If you get time, you should do a little write up on why you use Shale as an application controller. I know I would read it. I've looked into Shale several times. It seems to be a collection of ideas and not a cohesive framework. Last I checked the documentation was very lacking. The one thing I really liked about Facelets was it had some documentation (at least enough to explain the value add).

What do you think of the framework comparisons? Are they complex enough to give you a valid idea of what each framework capable of doing, or should the competition involve something more complex such as the Petstore, suggested by Clinton Begin in another thread related to the competition?

To be fair to Simon, he stated from the outset that he wanted to investigate how easy it was to do the basic 80% read-only stuff with each framework, and leave the more complex 20% till later, as (he reasons) it is the 80% that ultimately determines productivity.

If <insert-favourite-framework> makes the basic 80% hard, is it really worth using, even if it makes the remaining 20% easy?

Kit

What do you think of the framework comparisons? Are they complex enough to give you a valid idea of what each framework capable of doing, or should the competition involve something more complex such as the Petstore, suggested by Clinton Begin in another thread related to the competition?

To be fair to Simon, he stated from the outset that he wanted to investigate how easy it was to do the basic 80% read-only stuff with each framework, and leave the more complex 20% till later, as (he reasons) it is the 80% that ultimately determines productivity. If <insert-favourite-framework> makes the basic 80% hard, is it really worth using, even if it makes the remaining 20% easy?Kit

I'd disagree with this use of the 80/20 rule - IMO its misleading. Seems to me that whatever the % - updates are a core part of most web applications and to ignore that makes the comparison unrealistic.

Also while the readonly part of a web app may be 80% of it, I don't believe that it represents 80% of the effort. Probably the readonly parts are pretty easy to do in any of the frameworks and its on what they provide on the update side that frameworks can really start to differentiate from each other.

An simple example is not enough to show the simplicity behing a framework. Try to make hello word! in GwBasic (one line of code), but try to make a complex bank application... a real spagheti.

How many real business application developed with JBoss Seam?
How many with Stripes?

And the feedback of the developer (after developing an not trivial application)?

Javier Paniza
OpenXava: Business Component Application Framework

An simple example is not enough to show the simplicity behing a framework. Try to make hello word! in GwBasic (one line of code), but try to make a complex bank application... a real spagheti. How many real business application developed with JBoss Seam?...

Everyone likes to talk about "complex" business apps and boast about the need for "flexibility" and "power" in the frameworks that they use.

But the reality is that most apps are not complex and ultra-critical like banking apps. In fact, I would argue that there are many many more projects that don't even come close to filling their J2EE shoes and where even the most common web-app frameworks are over-kill.

Right now there are lots of people who earn a living simply because they can navigate an over-complicated framework and convince others that framework XYZ (which they happen to be an expert in) is the shizzle. Over time these people will find it harder to get work as potential clients realize that they don't need pay someone $250/hr to put together a useable and pleasant CRUD app.

Perhaps its not all bad that we have a new framework every damn week? It certainly indicates that the java world has some serious problems, but it can also be seen as a form of evolution.

Perhaps its not all bad that we have a new framework every damn week? It certainly indicates that the java world has some serious problems...

Why? I take it as a sign that the Java world is very healthy and interesting.

I'd really like to see this happen. The de facto standard is Struts, estimated by some to be used by 70% of Java web applications (I'll look for the source of that).

The first goal any web framework should aim to achieve is that of being "better" than Struts. Pick your benchmark: lines of code, lines of XML, component based, action based, available components, quality of components, performance, etc. Doesn't matter.

I'd rather not define a set of benchmarks. I'd rather have each "team" implement PetStore with their web framework, then explain why they think it is better. That will create an opportunity for the community (here) to discuss the various alternatives.

Overall, I think it's a good starting point for a community based effort, as opposed to ivory tower solutions, which I personally think JSF may suffer from...

What can I do? Consider the current implementation to be my submission for Struts...which raises another point -- everyone's invited. You don't have to be the author of the framework, or even a contributor.

If you believe in a certain framework, post your entry.

I estimate it should only take a week or so to replace the presentation tier for PetStore with any given framework.

Feel free to use the existing JPetStore 5 as a starting point. It's Apache licensed, unit tested, builds in one step and deploys in one step.

Download JPetStore 5

Cheers,
Clinton

Here's an online demo of JPetStore 5, which will help you estimate the amount of effort to rebuild the presentation tier.

http://codehammer.org:81/jpetstore/

Cheers,
Clinton

Whoops....TSS URL rendering doesn't handle ports....here's a better link...

JPetStore 5

Clinton

Don't worry about there being 'too many' frameworks. It's great. It's capitalism to the max. There are thousands of open source developers out there working there asses off - and ignoring their wifes in the process - just because they believe they can make the wheel a little bit rounder this time. Be happy with it. Does having this abundance of frameworks make choosing the right tools for the job more difficult? Probably. Just as it probably decreases the life-span per framework. But welcome to the new world! You either complain about the information overflow or you cope with it and improve your search and selection skills :)

It's capitalism to the max

It's freedom to the max. I doubt many are making a bunch of money off their frameworks. And that even making money is their main motivation.

The problem is - developing web apps is not easy. You have to deal with everything from web sites to full blown applications. So everyone is trying to figure out how to pound the square peg into the round hole (sans pure web sites cause they are round peg/round hole). Well, at least in the Java space they are. For [almost] everywhere else it is "one size fits all". And they'll like it and think it is the "cat's meow." And think everyone else is not "using the right tool for the job." :)

It's capitalism to the max

It's freedom to the max. I doubt many are making a bunch of money off their frameworks. And that even making money is their main motivation.

True. I invested a lot of time in them the last few years without ever thinking about making money off them. Regardless of what is sometimes said by guys like Fleury, I think most open source enthiousiasts at least start out doing it because they want to help out other people, seek craftsmanship's satisfaction, etc... all but just bluntly making money off of it. I was refering to capitalism with competition in mind. There's a lot of competition and thus a lot of rendundant effort. It's harder to 'fight your way in' and sometimes the commercially stronger frameworks win over just the better ones. But at least in general you can say that capitalism gives you freedom of choice from a customer's perspective, and that - again generally - the best ones win.

I invested a lot of time in them the last few years without ever thinking about making money off them.

But you know what? You never know how things pay off. I met the girl of my dreams because of my involvement in OSS. Isn't that great? All you bachelors out there, start writing OSS now (or then again, maybe I am just a lucky bastard).

I met the girl of my dreams because of my involvement in OSS. Isn't that great?

Miko Matsumura said that "W.... is good for your sex life?".

Q.E.D.

Testability is pretty important so I'd like to see each comparison include some test cases.

Here's the coverage report for JPetStore 5.

JPetStore 5 Test Coverage (Emma)

Cheers,
Clinton

The simpler comparison test can be used to bring your choices down to a short list (although I also question the usefulness of a read-only simple test application :-)
Then use a petstore app to make a final choice because it illustrates how the framework handles errors, localization, and more complex navigation (little stuff like handling users click on post buttons multiple times, refreshing the browser, handling errors, etc.)

I'd agree w/ H23 on most apps being trivially simple so they don't even require most of J2EE...

The simpler comparison test can be used to bring your choices down to a short list (although I also question the usefulness of a read-only simple test application :-)Then use a petstore app to make a final choice because it illustrates how the framework handles errors, localization, and more complex navigation (little stuff like handling users click on post buttons multiple times, refreshing the browser, handling errors, etc.)

You call this "little stuff"?

The simpler comparison test can be used to bring your choices down to a short list (although I also question the usefulness of a read-only simple test application :-)Then use a petstore app to make a final choice because it illustrates how the framework handles errors, localization, and more complex navigation (little stuff like handling users click on post buttons multiple times, refreshing the browser, handling errors, etc.)

You call this "little stuff"?

Maybe it's not, but it should be.

Typical user interaction:
Thought: Whoops, that was wrong.
Action: Click back button
Result: Cryptic error about "POST DATA" and suggestion to refresh
Thought: Darn computer...
Action: Click refresh
Result: Form comes back up
Thought: There we go...
Action: Change a couple fields and hit submit
Result: Webapp is confused because form already posted once, sits there pondering what to do...
Thought: Hmmm...I must not have clicked submit...
Action: Click submit five times to make sure computer understands
Result: User's credit card is charged 7 times for his order despite the fact he never actually saw a confirmation

------------

Ok, so maybe that's dramatization. But really, how many times have you seen "Only click this button once because we charge you for every click.." on a form (our corporate travel booking site has on of these...looks like I booked a whole row to myself! That will teach them to make me fly economy class!)

------------

I know these can be complex to handle. In many cases (like the back button) the correct behavior is rather context sensitive. But aren't frameworks supposed to handle the "complex" behaviors, especially ones users should reasonably expect to be handled?

Maybe it's not, but it should be.Typical user interaction:

LOL. Perfect example scenario. Exactly the kind of stuff I was thinking of and why the thought of a "read only benchmark app" is extremely amusing to me because you never hit stuff like this that would be extremely aggravating to web users :-)

BTW, when I said "little", I was being sarcastic...hard to get that across w/ text msgs sometimes... ;-)

Maybe it's not, but it should be.Typical user interaction:

LOL. Perfect example scenario. Exactly the kind of stuff I was thinking of and why the thought of a "read only benchmark app" is extremely amusing to me because you never hit stuff like this that would be extremely aggravating to web users :-)BTW, when I said "little", I was being sarcastic...hard to get that across w/ text msgs sometimes... ;-)

That stuff IS little. It should be handled pretty easily by the framework. WebWork does.

That stuff IS little. It should be handled pretty easily by the framework. WebWork does.

Only if the framework is worth putting on your short list ;-)
I've found that too many don't handle those little things right (being a Tapestry fan myself).

I'd love to see a framework-free solution to this, for comparison. Lots of people complain about frameworks, and insist developers just do their jobs and stop obsessing over frameworks.

I'd love to see a good implementation of anything, including this read-only blog, using JSPs, servlets, JDBC, and whatever singletons, factories, and pojos people use.

The Sun blueprints are probably a good start. I know there was the initial petshop app, but no one codes that way. I'd like to see this way of coding web apps that everyone talks about when dismissing frameworks, but never blog about because they are too busy doing their day jobs.

I'd love to see a framework-free solution to this, for comparison.

Framework-free as in "developed with custom in-house framework"? ;-)

Note that Simon Brown implemented a number of versions of this application, focusing on JSP, servlet, struts, and a few other things - including a slew of non-framework versions.

I'd love to see a framework-free solution to this, for comparison. Lots of people complain about frameworks, and insist developers just do their jobs and stop obsessing over frameworks.I'd love to see a good implementation of anything, including this read-only blog, using JSPs, servlets, JDBC, and whatever singletons, factories, and pojos people use.The Sun blueprints are probably a good start. I know there was the initial petshop app, but no one codes that way. I'd like to see this way of coding web apps that everyone talks about when dismissing frameworks, but never blog about because they are too busy doing their day jobs.

We desisted to use Struts of similar frameworks for the MVC pattern implementation. I found a very common mistake when using Struts relating the confusion with MVC and Template View patterns.

We are currently using no framework, but a plain jsp MVC architecture: POJM (Plain Old JSP MVC).

We desisted to use Struts of similar frameworks for the MVC pattern implementation. I found a very common mistake when using Struts relating the confusion with MVC and Template View patterns.

We are currently using no framework, but a plain jsp MVC architecture: POJM (Plain Old JSP MVC).

JSF offers similar model 1 benefits with POJOs such that you don't need to coordinate concerns across the view and pair them with some other controller logic. JSF components are self-sustaining, and have a well defined, multi-phased lifecycle that corrects a lot of the problems with just using model 1 with JSP.

We desisted to use Struts of similar frameworks for the MVC pattern implementation. I found a very common mistake when using Struts relating the confusion with MVC and Template View patterns.We are currently using no framework, but a plain jsp MVC architecture: POJM (Plain Old JSP MVC).

I followed the link and read your blog post; quite interesting! I think one of the reasons that in the web world the controller ends up meditaing access to the model even for the view is just because it's easier to write correct code in a Java class than it is in a template or JSP. In a thick-client world where the view is a Java class itself (spare me the technicalities about JSPs being translated into classes), writing model-access code in the view is not problematic.

It's also nice to note that although I usually dislike the use of the phrase "MVC" in the web context and have never read of the Template pattern, that Stripes avoids pretty much all of the problems you cite!

In Stripes you tend to group actions like "create", "delete" and "view" into a single ActionBean so that the logic is all in once place. So if you want to mediate view access through the "controller" it can all be in the same place in a single method. It's also possible to use Stripes ActionBeans as view helpers, instantiated through a tag on the page and then have properties accessed through EL etc. And of course, if you want, you can write scriplets right on the JSP...I just don't recommend it because frankly it's harder to debug etc.

-Tim Fennell
Stripes: Because web development should just be easier.

We desisted to use Struts of similar frameworks for the MVC pattern implementation. I found a very common mistake when using Struts relating the confusion with MVC and Template View patterns.We are currently using no framework, but a plain jsp MVC architecture: POJM (Plain Old JSP MVC).

I followed the link and read your blog post; quite interesting! I think one of the reasons that in the web world the controller ends up meditaing access to the model even for the view is just because it's easier to write correct code in a Java class than it is in a template or JSP. In a thick-client world where the view is a Java class itself (spare me the technicalities about JSPs being translated into classes), writing model-access code in the view is not problematic.It's also nice to note that although I usually dislike the use of the phrase "MVC" in the web context and have never read of the Template pattern, that Stripes avoids pretty much all of the problems you cite!In Stripes you tend to group actions like "create", "delete" and "view" into a single ActionBean so that the logic is all in once place. So if you want to mediate view access through the "controller" it can all be in the same place in a single method. It's also possible to use Stripes ActionBeans as view helpers, instantiated through a tag on the page and then have properties accessed through EL etc. And of course, if you want, you can write scriplets right on the JSP...I just don't recommend it because frankly it's harder to debug etc.-Tim FennellStripes: Because web development should just be easier.

I've taken a quick look on your framework, and I'm glad to see a framework that definitely seems to follow a pragmatic approach and principles. Particularly the evitation of configuration, and the central point of the ActionBean, a resemblance of the Jsp bean, boosted to a higher degree.

Although I will write a post on POJM, I will be watching Stripes. Thanks

We desisted to use Struts of similar frameworks for the MVC pattern implementation. I found a very common mistake when using Struts relating the confusion with MVC and Template View patterns.We are currently using no framework, but a plain jsp MVC architecture: POJM (Plain Old JSP MVC).

I've read your blog. It is sad that an architecture you presented is typical for many Struts applications. An action is used as view delegate for a specific view. Therefore, every Struts action renders a specific, usually hardcoded view. This architecture is view-centric. Using a controller/dispatcher does not make a lot of sense in view-centric architecture, Page Controller pattern works better here.

If you want to work primarily with views, then Page Controller framework is your choice. Struts, on the other hand, allows to work with web resources, that is, with Model. A web resource can have different states and a different view for every state. See some thoughts on this matter in Struts wiki and in Struts Dialogs documentation.

Therefore, instead of having a zillion of actions like DeleteAction, CreateAction, UpdateAction, ViewAction that work with their respective views, you would have only two actions that work with a web resource. One action would process all input for a webresource and would change resource state. Another action would render a view that corresponds to current resorce state. This way you will have resource-centric architecture, which allows action-type frameworks like Struts to show their best qualities.

Conceptually JSF, for example, is no better than Struts, it just has a different idea (besides components, I know, I know). JSF is view-centric, while Struts is resource-centric. The issue is that many people try to use Struts in view-centric mode and this does not work well.

I think I understand now the gripes of many Struts users. They use Struts improperly. Coming from VB or from plain JSP MVC1 background they continue to think in terms of views ("need to display a specific page, so should prepare data for it"), while Struts can be used more productive in a resource-centric pattern ("need to update resource state, then find and display a view appropriate to current state").

We desisted to use Struts of similar frameworks for the MVC pattern implementation. I found a very common mistake when using Struts relating the confusion with MVC and Template View patterns.We are currently using no framework, but a plain jsp MVC architecture: POJM (Plain Old JSP MVC).

I've read your blog. It is sad that an architecture you presented is typical for many Struts applications. An action is used as view delegate for a specific view. Therefore, every Struts action renders a specific, usually hardcoded view. This architecture is view-centric. Using a controller/dispatcher does not make a lot of sense in view-centric architecture, Page Controller pattern works better here.If you want to work primarily with views, then Page Controller framework is your choice. Struts, on the other hand, allows to work with web resources, that is, with Model. A web resource can have different states and a different view for every state. See some thoughts on this matter in Struts wiki and in Struts Dialogs documentation.Therefore, instead of having a zillion of actions like DeleteAction, CreateAction, UpdateAction, ViewAction that work with their respective views, you would have only two actions that work with a web resource. One action would process all input for a webresource and would change resource state. Another action would render a view that corresponds to current resorce state. This way you will have resource-centric architecture, which allows action-type frameworks like Struts to show their best qualities.Conceptually JSF, for example, is no better than Struts, it just has a different idea (besides components, I know, I know). JSF is view-centric, while Struts is resource-centric. The issue is that many people try to use Struts in view-centric mode and this does not work well.I think I understand now the gripes of many Struts users. They use Struts improperly. Coming from VB or from plain JSP MVC1 background they continue to think in terms of views ("need to display a specific page, so should prepare data for it"), while Struts can be used more productive in a resource-centric pattern ("need to update resource state, then find and display a view appropriate to current state").

I totally agree with you and I think you have enlighted very well the problem but let me explain it in a more pattern-oriented way. (I am a pattern groupie;))
The problem I see with Struts and Action-oriend MVC framework is that the application controller and the input controllers are mixed together.

Input controller is the C in MVC. As it name implies, it has to handle the input and dispatches it to the correct model service. It is typically implemented as a front controller in the Java world which dispatch input *events* to the registered listeners. Event handlers are what you call "view-centric mode", their tasks is to react correctly to user actions (modifying the view, calling some model logic). By the way, a page controller or front controller are equally good at implementing input controllers. The problems I see with action-oriented frameworks is your input controllers are ALWAYS global to the whole application. It is so easy to call them from anywhere unless you really enforce yourself not to do so. An input controller usually should have a much narrower scope, as they have in client-side technologies like Swing. A given input controller should only be callable from a given page or a given flow. Action-oriented frameworks make it to easy to confuse input controllers responsabilities with application controllers responsabilities. In this case, I think they are the same kind of evil that global variables used to be not so long ago.


The application controler job is to mediate the interactions between the user interface and the model. It doesn't have anything to do with MVC except it shares a common goal, disconnect the UI from the model. Application controllers object are what you call "resource-centric" actions. Their role is to handle the global flow of the application, ie navigation, loading some datas before displaying a given view, ... An application controller is by definition global to the whole application and this why those responsabilities are so easily handled in Struts or any action-oriented framework. All the support is already in place. Contrary to popular belief, it isn't harder to put in place an application controller in any MVC components-oriented frameworks. It seems more difficult because MVC component-oriented frameworks don't mix those two essential patterns. They stick to their MVC role and therefore give little support to implement an application controller (well they usually offer some basic navigation handling functionalities so they can be of any practical use). You have to install some add-ons to get those functionnalities. It is one of the thing, Struts Shale offer to the JSF world :)

What do you think?

Input controller is the C in MVC. As it name implies, it has to handle the input and dispatches it to the correct model service. It is typically implemented as a front controller in the Java world which dispatch input *events* to the registered listeners. Event handlers are what you call "view-centric mode", their tasks is to react correctly to user actions (modifying the view, calling some model logic).

Umm, depends on implementation ;) First of all lets clear the fog by saying that Struts as well as any other HTTP-based web application can have events. Just pick any request parameter and call it an event. The frameworks differentiate on a higher abstraction level, but there is absolutely nothing that prevents a Struts application or pure JSP-based application to have an event system.

Now, what is the result of an event? That depends on the framework paradigm. View-centric frameworks like ASP.NET or JSF work primarily with views. It is important, what widget triggered an event, or what component (as part of a page) an event is sent to. Based on event, the components update themselves and then page is redisplayed (please, correct me if I am wrong in my judgement on JSF features).

In resource-centric paradigm, it does not matter which view an event came from. At most what matters is the type of output device, which is usually the same as input device, so if event came from HTML browser, output will be in HTML. If event came from webservice, output will be in SOAP or whatever else. I would say that in resource-centric application events are usually more coarse-grained. It is not like "a selection was changed in a combobox" but more like "here is a bunch of new data, but you can tell what widget in belongs to". Then application (input dispatcher in your terms) updates the model and checks model state. It has some kind of algorithm or a simple table to associate model state with a view. So, if a resource is in "update" state, input dispatcher returns edit form, if resource is in "view" state, dispatcher returns read-only page, etc.

The resource-centric approach can be easily implemented in JSF using subviews, or in plain JSP with conditional sections of markup. My feeling is that approach is not used widely. In Struts this approach can be implemented very simple by having several JSP files and forwarding to an appropriate one depending on Model state.

The problems I see with action-oriented frameworks is your input controllers are ALWAYS global to the whole application. It is so easy to call them from anywhere unless you really enforce yourself not to do so. An input controller usually should have a much narrower scope, as they have in client-side technologies like Swing. A given input controller should only be callable from a given page or a given flow. Action-oriented frameworks make it to easy to confuse input controllers responsabilities with application controllers responsabilities. In this case, I think they are the same kind of evil that global variables used to be not so long ago.

I agree. In my Struts-based apps I have only two actions (or sometimes one two-phase action) per resource, and several JSP views. All events from these views go to input action for this resource, and only to it. Vice versa, only render action of this resource can display a view that corresponds to resource. This way I decouple my resources. With a "*.do" URL I navigate to a resource, not to a particular view. And I don't care what was the previous page. I don't need to combine pages into flows, because all my resources can stand for themselves and can render themselves properly in any situation and in any possible state. If a resource goes out of scope, then there is a catchall location, like a login page when a user logs out, or a item list page, when a particular item is closed. Of course, I have wizards, but for very short state/view sequences, not for a whole application.

The application controler job is to mediate the interactions between the user interface and the model. It doesn't have anything to do with MVC except it shares a common goal, disconnect the UI from the model. Application controllers object are what you call "resource-centric" actions. Their role is to handle the global flow of the application, ie navigation, loading some datas before displaying a given view, ...

I worked on idea of flows, I discout the concept of flow now. Since a webapplication cannot control what URL a user types in address bar, it should be ready to display something meaningful in any situation. Restricting a user with some artificial flow that have nothing to do with Model is a wrong concept to me. Again, there is no "given view". A user knows nothing about views, he requests to render a resource, or to operate on a resource. It is up to resource to prepare itself accordinly and to select a proper view in response.

An application controller is by definition global to the whole application and this why those responsabilities are so easily handled in Struts or any action-oriented framework. All the support is already in place. Contrary to popular belief, it isn't harder to put in place an application controller in any MVC components-oriented frameworks. It seems more difficult because MVC component-oriented frameworks don't mix those two essential patterns. They stick to their MVC role and therefore give little support to implement an application controller (well they usually offer some basic navigation handling functionalities so they can be of any practical use). You have to install some add-ons to get those functionnalities. It is one of the thing, Struts Shale offer to the JSF world :)

In Struts Classic I can do both things: I can act on a resource (hence an "action"), or I can request a resource to render itself. In both cases the resource will display appropriate view in response, only in the former case it will update itself before displaying a view.

In JSF I can request a view, and I can act on a view. This looks to me as a different concept, and from my point of view, it is more restrictive. Right, if I treat JSF file as a container of subviews, then displaying a subview appropriate to container state (that is, resource state) is not a problem. But I cannot act on a resource before I have a view, because JSF events are linked to views and generated by view widgets. This is what I call "view-centric". Until I have a view, I cannot act on its host resource. Am I right here? Does Shale offers an option to act on a host resource (backing bean?) before obtaining a view?

Umm, depends on implementation ;) First of all lets clear the fog by saying that Struts as well as any other HTTP-based web application can have events. Just pick any request parameter and call it an event. The frameworks differentiate on a higher abstraction level, but there is absolutely nothing that prevents a Struts application or pure JSP-based application to have an event system.

We both agreed. I am not saying Struts doesn't support input controlers or input controlers need event, I was using it as a common term but I think it was a bad choice since it so closely associated with component frameworks. It has nothing to do with using components or not. And of course receiving a request is indeed an event.

Now, what is the result of an event? That depends on the framework paradigm. View-centric frameworks like ASP.NET or JSF work primarily with views. It is important, what widget triggered an event, or what component (as part of a page) an event is sent to. Based on event, the components update themselves and then page is redisplayed (please, correct me if I am wrong in my judgement on JSF features).In resource-centric paradigm, it does not matter which view an event came from. At most what matters is the type of output device, which is usually the same as input device, so if event came from HTML browser, output will be in HTML. If event came from webservice, output will be in SOAP or whatever else. I would say that in resource-centric application events are usually more coarse-grained. It is not like "a selection was changed in a combobox" but more like "here is a bunch of new data, but you can tell what widget in belongs to". Then application (input dispatcher in your terms) updates the model and checks model state. It has some kind of algorithm or a simple table to associate model state with a view. So, if a resource is in "update" state, input dispatcher returns edit form, if resource is in "view" state, dispatcher returns read-only page, etc.

Once again, we agree but the event model has nothing to do with the problem here. Here, what I think is important to understand is that it is the input controller (Fowler terms) responsability to call what needs to be call. In a JSF application, you are free to call some services, reload the view, ... as you are in a Struts application.

The resource-centric approach can be easily implemented in JSF using subviews, or in plain JSP with conditional sections of markup. My feeling is that approach is not used widely. In Struts this approach can be implemented very simple by having several JSP files and forwarding to an appropriate one depending on Model state.

Yup, you're right. It not used widely because people always confuse the C in MVC and the application controller (fowler book explains the difference between the two very well).

The problems I see with action-oriented frameworks is your input controllers are ALWAYS global to the whole application. It is so easy to call them from anywhere unless you really enforce yourself not to do so. An input controller usually should have a much narrower scope, as they have in client-side technologies like Swing. A given input controller should only be callable from a given page or a given flow. Action-oriented frameworks make it to easy to confuse input controllers responsabilities with application controllers responsabilities. In this case, I think they are the same kind of evil that global variables used to be not so long ago.

I agree. In my Struts-based apps I have only two actions (or sometimes one two-phase action) per resource, and several JSP views. All events from these views go to input action for this resource, and only to it. Vice versa, only render action of this resource can display a view that corresponds to resource. This way I decouple my resources. With a "*.do" URL I navigate to a resource, not to a particular view. And I don't care what was the previous page. I don't need to combine pages into flows, because all my resources can stand for themselves and can render themselves properly in any situation and in any possible state. If a resource goes out of scope, then there is a catchall location, like a login page when a user logs out, or a item list page, when a particular item is closed. Of course, I have wizards, but for very short state/view sequences, not for a whole application.

It is exactly the point I was making but unfortunately it isn't enforced in Struts. It like global variables, of course experienced programmers won't use them but novice programmers who are hard pressed to deliver will take them as a shortcut. This is where things begin to become ugly.

The application controler job is to mediate the interactions between the user interface and the model. It doesn't have anything to do with MVC except it shares a common goal, disconnect the UI from the model. Application controllers object are what you call "resource-centric" actions. Their role is to handle the global flow of the application, ie navigation, loading some datas before displaying a given view, ...

I worked on idea of flows, I discout the concept of flow now. Since a webapplication cannot control what URL a user types in address bar, it should be ready to display something meaningful in any situation. Restricting a user with some artificial flow that have nothing to do with Model is a wrong concept to me. Again, there is no "given view". A user knows nothing about views, he requests to render a resource, or to operate on a resource. It is up to resource to prepare itself accordinly and to select a proper view in response.

Once again I agree with you. I think I just used some wrong terms (hard to explain yourself precisely when english isn't your native language ;)). A better term would be "application level flow". What I mean by global flow is something like "the user wants to acces page X, but first some data need to be loaded".

An application controller is by definition global to the whole application and this why those responsabilities are so easily handled in Struts or any action-oriented framework. All the support is already in place. Contrary to popular belief, it isn't harder to put in place an application controller in any MVC components-oriented frameworks. It seems more difficult because MVC component-oriented frameworks don't mix those two essential patterns. They stick to their MVC role and therefore give little support to implement an application controller (well they usually offer some basic navigation handling functionalities so they can be of any practical use). You have to install some add-ons to get those functionnalities. It is one of the thing, Struts Shale offer to the JSF world :)

In Struts Classic I can do both things: I can act on a resource (hence an "action"), or I can request a resource to render itself.
Yes this what I don't like you can do both inside actions and yet they are totally different responsabilities. Like I wrote previously, I know a veteran won't do the mistake but since it feels so natural at first (like global variables) new developpers (I did this mistake so many times when I first began) will always do it

In both cases the resource will display appropriate view in response, only in the former case it will update itself before displaying a view.In JSF I can request a view, and I can act on a view. This looks to me as a different concept, and from my point of view, it is more restrictive. Right, if I treat JSF file as a container of subviews, then displaying a subview appropriate to container state (that is, resource state) is not a problem. But I cannot act on a resource before I have a view, because JSF events are linked to views and generated by view widgets. This is what I call "view-centric". Until I have a view, I cannot act on its host resource.

Yeah I think you get the point I was trying to make. Those features are described in the J2EE core book, as being the application controller pattern. It is not supported by JSF, Since it is a specification and it tries to stick to its main goal, being an component oriented MVC frameworks. I think it is one of the main reason of the FUD surrounding JSF.

 

Am I right here? Does Shale offers an option to act on a host resource (backing bean?) before obtaining a view?

This is one of its main features :)


Well, basically I was just triying to summarize it in a pattern way. What you call view centric frameworks are in my opinion just pure MVC frameworks. They lack application controller functionalities on purpose.

On the other hand, Struts provide both functionalities with its global Actions. I am not saying it isn't doable in Struts or harder. The only thing I don't like is that both design concepts are mixed into one implementation concept (action) and it can be a dangerous thing. Scoped actions might be a solution but I think overral it is much better to complety dissociate the two concepts.

Here is the corrected version (there was so blockquote problem), I really want an edit button. It not hard to implement after all.

Umm, depends on implementation ;) First of all lets clear the fog by saying that Struts as well as any other HTTP-based web application can have events. Just pick any request parameter and call it an event. The frameworks differentiate on a higher abstraction level, but there is absolutely nothing that prevents a Struts application or pure JSP-based application to have an event system.

We both agreed. I am not saying Struts doesn't support input controlers or input controlers need event, I was using it as a common term but I think it was a bad choice since it so closely associated with component frameworks. It has nothing to do with using components or not. And of course receiving a request is indeed an event.

Now, what is the result of an event? That depends on the framework paradigm. View-centric frameworks like ASP.NET or JSF work primarily with views. It is important, what widget triggered an event, or what component (as part of a page) an event is sent to. Based on event, the components update themselves and then page is redisplayed (please, correct me if I am wrong in my judgement on JSF features).In resource-centric paradigm, it does not matter which view an event came from. At most what matters is the type of output device, which is usually the same as input device, so if event came from HTML browser, output will be in HTML. If event came from webservice, output will be in SOAP or whatever else. I would say that in resource-centric application events are usually more coarse-grained. It is not like "a selection was changed in a combobox" but more like "here is a bunch of new data, but you can tell what widget in belongs to". Then application (input dispatcher in your terms) updates the model and checks model state. It has some kind of algorithm or a simple table to associate model state with a view. So, if a resource is in "update" state, input dispatcher returns edit form, if resource is in "view" state, dispatcher returns read-only page, etc.

Once again, we agree but the event model has nothing to do with the problem here. Here, what I think is important to understand is that it is the input controller (Fowler terms) responsability to call what needs to be call. In a JSF application, you are free to call some services, reload the view, ... as you are in a Struts application.

The resource-centric approach can be easily implemented in JSF using subviews, or in plain JSP with conditional sections of markup. My feeling is that approach is not used widely. In Struts this approach can be implemented very simple by having several JSP files and forwarding to an appropriate one depending on Model state.

Yup, you're right. It not used widely because people always confuse the C in MVC and the application controller (fowler book explains the difference between the two very well).

The problems I see with action-oriented frameworks is your input controllers are ALWAYS global to the whole application. It is so easy to call them from anywhere unless you really enforce yourself not to do so. An input controller usually should have a much narrower scope, as they have in client-side technologies like Swing. A given input controller should only be callable from a given page or a given flow. Action-oriented frameworks make it to easy to confuse input controllers responsabilities with application controllers responsabilities. In this case, I think they are the same kind of evil that global variables used to be not so long ago.

I agree. In my Struts-based apps I have only two actions (or sometimes one two-phase action) per resource, and several JSP views. All events from these views go to input action for this resource, and only to it. Vice versa, only render action of this resource can display a view that corresponds to resource. This way I decouple my resources. With a "*.do" URL I navigate to a resource, not to a particular view. And I don't care what was the previous page. I don't need to combine pages into flows, because all my resources can stand for themselves and can render themselves properly in any situation and in any possible state. If a resource goes out of scope, then there is a catchall location, like a login page when a user logs out, or a item list page, when a particular item is closed. Of course, I have wizards, but for very short state/view sequences, not for a whole application.

It is exactly the point I was making but unfortunately it isn't enforced in Struts. It like global variables, of course experienced programmers won't use them but novice programmers who are hard pressed to deliver will take them as a shortcut. This is where things begin to become ugly.

The application controler job is to mediate the interactions between the user interface and the model. It doesn't have anything to do with MVC except it shares a common goal, disconnect the UI from the model. Application controllers object are what you call "resource-centric" actions. Their role is to handle the global flow of the application, ie navigation, loading some datas before displaying a given view, ...

I worked on idea of flows, I discout the concept of flow now. Since a webapplication cannot control what URL a user types in address bar, it should be ready to display something meaningful in any situation. Restricting a user with some artificial flow that have nothing to do with Model is a wrong concept to me. Again, there is no "given view". A user knows nothing about views, he requests to render a resource, or to operate on a resource. It is up to resource to prepare itself accordinly and to select a proper view in response.

Once again I agree with you. I think I just used some wrong terms (hard to explain yourself precisely when english isn't your native language ;)). A better term would be "application level flow". What I mean by global flow is something like "the user wants to acces page X, but first some data need to be loaded".

An application controller is by definition global to the whole application and this why those responsabilities are so easily handled in Struts or any action-oriented framework. All the support is already in place. Contrary to popular belief, it isn't harder to put in place an application controller in any MVC components-oriented frameworks. It seems more difficult because MVC component-oriented frameworks don't mix those two essential patterns. They stick to their MVC role and therefore give little support to implement an application controller (well they usually offer some basic navigation handling functionalities so they can be of any practical use). You have to install some add-ons to get those functionnalities. It is one of the thing, Struts Shale offer to the JSF world :)

In Struts Classic I can do both things: I can act on a resource (hence an "action"), or I can request a resource to render itself.

Yes this what I don't like you can do both inside actions and yet they are totally different responsabilities. Like I wrote previously, I know a veteran won't do the mistake but since it feels so natural at first (like global variables) new developpers (I did this mistake so many times when I first began) will always do it

In both cases the resource will display appropriate view in response, only in the former case it will update itself before displaying a view.In JSF I can request a view, and I can act on a view. This looks to me as a different concept, and from my point of view, it is more restrictive. Right, if I treat JSF file as a container of subviews, then displaying a subview appropriate to container state (that is, resource state) is not a problem. But I cannot act on a resource before I have a view, because JSF events are linked to views and generated by view widgets. This is what I call "view-centric". Until I have a view, I cannot act on its host resource.

Yeah I think you get the point I was trying to make. Those features are described in the J2EE core book, as being the application controller pattern. It is not supported by JSF, Since it is a specification and it tries to stick to its main goal, being an component oriented MVC frameworks. I think it is one of the main reason of the FUD surrounding JSF.&nbsp;

Am I right here? Does Shale offers an option to act on a host resource (backing bean?) before obtaining a view?

This is one of its main features :)

Well, basically I was just triying to summarize it in a pattern way. What you call view centric frameworks are in my opinion just pure MVC frameworks. They lack application controller functionalities on purpose. On the other hand, Struts provide both functionalities with its global Actions. I am not saying it isn't doable in Struts or harder. The only thing I don't like is that both design concepts are mixed into one implementation concept (action) and it can be a dangerous thing. Scoped actions might be a solution but I think overral it is much better to complety dissociate the two concepts.

Hi, I been investigating about new frameworks, for a project that I have in mind, I was thinking to use tapestry but there were some things that didn’t convince me to use it. A few month a go a read about Seam an I really like what I saw, the only thing I still not convince is the use JSF for the view (even with Facelets), I like more tapestry for the view is a bit more simple (I know that Gavin try to integrate Tapestry to seam but seems to be too complicated) but I suppose is just matter of getting use to JSF and read more about it . I have hear a lot of buzz about ruby on rails and I read several tutorials, and a book, but I still don’t like , the strongest reasons that I don’t like Ruby on Rails is because I will loose all the great API and frameworks that java has and I love, hibernate (ruby has Active Record but I don’t think it have all the functionality that hibernate has) all the apache libs, like maven and the jatarka commons just mention a few, and of curse all the java ides, all of this supported by great companies as IBM, Borland, Apache etc…, plus I don’t like to much scripting languages.
      I will like that Gavin and Simon Brown tell us a few things that should be easier to do in Seam and Stripes that should be harder to do in Ruby on Rails (for example the conversations functionality of Seam).
Thanks
Gabriel
Note: Sorry if I wrote something wrong English is not my native language.

Seam is fantastic, I like working on EJBs now :)

Gee... Someone should mention AppFuse in here. AppFuse is a starter web application, and has several versions. (Not to mention a lot of online tutorials to do common things...)

There is a Tapestry AppFuse, JSF AppFuse, Struts AppFuse (the original), WebWork AppFuse, SpringMVC AppFuse and others.

If AppFuse is too big, you can download Equinox which is a scaled down AppFuse.

The last time I used AppFuse it had security support and corresponding CRUD listings for Users and Roles.

http://raibledesigns.com/wiki/AppFuse.html

Matt Raible is not a big JSF fan so I am not sure how much attention the JSF AppFuse gets, but it is out there to compare.

AppFuse is less than the Petstore (or at least it was), and more than a simple app.

Here is some more information on what AppFuse is....

(Taken from appfuse website with some commentary...
http://raibledesigns.com/wiki/Wiki.jsp?page=AppFuseDefinition)

AppFuse is a Framework
This is sort of the 10,000 foot view of what AppFuse is. It is a structure in which web applications of a variety of types and sizes are created. (It supports JSF, WebWork, SpringMVC and Struts.)

AppFuse is a Directory Structure
One of many features of AppFuse is the way it logically separates code into its appropriate locations based on function. Persistence code belongs in src/dao/, manager code in src/service/, controller code in src/web/ and of cource testing code in test/**/. (Debateable)

AppFuse is a Build File
The build.xml file makes for a nice way to create, build, test, package, deploy webapps. It also nicely handles changing dependancies and maintaining properties that may be different in development than in production. (The largest ant script known to man.... AppFuse is a good reason to look into Maven 2).

AppFuse is a Sample Application
AppFuse is an example of how to use and integrate many Java technologies while following best practices. There are examples of how to do everything from performing CRUD opperations from your view all the way to the persistence layer to adding a filter to your webapp. Because the common things that are needed in basically all web applications are already in AppFuse, you will only need to figure out how to do the parts that make your webapp unique. (This is the real value of AppFuse to me.... It is a great sample/starter application...)

Rick Hightower (linked in),blog
JSF, Spring, and Hibernate training and consulting

I think I'll start a new project on java.net which will provide an abstraction layer on top of MVC frameworks! Think "commons-logging for the web"!

Spring, Struts and Webwork actions could extend *my* interfaces and I could pick random versions of cglib and asm libraries to enhance them at runtime! It'd probably be good to make the actions persistent too so you woldn't have to waste time creating POJOs anymore. Think about it, my uber-container will populate the actions and then you can save them straight to the database!

Em, on a serious note, I really like stripes, if only there was something equally productive in the persistence arena.

I think I'll start a new project on java.net which will provide an abstraction layer on top of MVC frameworks!

Lol!

Em, on a serious note, I really like stripes, if only there was something equally productive in the persistence arena.

Have you looked at the persistence engine of RIFE, it might be what you're looking for and you can just adopt that inside other projects. Bruce Tate wrote about it:
http://rifers.org/blogs/gbevin/2006/3/8/bruce_tate_rife_with_promise

Geert: just tried the persistence engine, like it a lot so far. There are lots of things about rife that I like, but even their mothers couldn't love rife templates they're that ugly.

I don't mean to be rude, I just find the syntax too alien. Is there a way to over-ride the view resolution so a different templating mechanism could be used? You'd prolly want to hit me for saying, but I would like to have the choice of using JSP or Velocity behind the excellent Rife engine :$

Hi Analog Boy,

small question, have you looked at the syntax alternatives that were added to the template engine in release 1.4?
http://rifers.org/blogs/gbevin/2006/3/2/rife_1_4_released#1_4_highlight02
Normally, most people should now find something that's easy on their eyes.

Apart from that, RIFE elements are not tied to the template engine. Some of the features are though, like embedded elements, automated form building and error message generation. However, in terms of output, RIFE accepts anything that generates a string or and that can work with an output stream. You should thus have to be able to integrate other solutions.

Best regards,

Geert

yup, but i'm still struggling with it's syntax. I *have* to produce html applications that designers can update and they already know jsp and some velocity. If I were to change to Rife, I'd have to make it as transparent to them because they wouldn't stand to gain much from the upgrade.

If I could upgrade the server-side processing whilst leaving the templates as close to their current format as possible then I wouldn't get any static from the design department.

leaving the templates as close to their current format as possible then I wouldn't get any static from the design department.

Good point, I'll look into adding support for Velocity in the coming weeks.

i wouldn't mind helping out if you're busy over the next few weeks, as long as you give me a few pointers ;)

i wouldn't mind helping out if you're busy over the next few weeks, as long as you give me a few pointers ;)

I think it's better to proceed on the mailinglist, this isn't the forum for concrete development. When you post a message on the users list, I'll give you some pointers there ;-)

leaving the templates as close to their current format as possible then I wouldn't get any static from the design department.

Good point, I'll look into adding support for Velocity in the coming weeks.

Gert,

I signed up for your talk on continuations, but the RIFE talk was at the same time as the Seam talk and Seam is closer to where I eat. The continuation is at the same time as the Spring 2.0 talk, but I went to the Spring Experience (a.k.a. The Spring 2.0 comming out party) in Decemenber in Miami so I figured I'd learn more new stuff at your talk.

You have two talks at TSS so RIFE must have caught someone's attention. :o)

If I get a chance to look at the Seam slides ahead of time, I might attend the RIFE talk. I've done quite a bit of reading on Seam already.

--Rick

but even their mothers couldn't love rife templates they're that ugly.

LOL. I laughed out loud when I read that! Good thing I am working from the home office today.

Rife sounds like something I should check out. I thought it was just a web framework, but it sounds like it is more.

Rick Hightower (linked in),blog
JSF, Spring, and Hibernate training and consulting

Maybe the original example is very simple ant there is no clear need for the framework at all. See for example what Seam is doing: saving data in the application scope and displays them in JSP page. So one JSP page with a grid is enough. Data could be loaded in the preloaded Servlet or in the listener or even in the same JSP. So just one JSP file is enough.

Dmitry
http://www.servletsuite.com

Jdon Framework is the combination of Domain Drive Development( DDD Framework, such as Ruby on Rails) and Ioc/AOP components (such as Spring/HiveMind) .

Jdon Framework combines with rapidity and agility for your J2EE application architecture. and seamlessly supports two service architecture types: JavaBeans(POJO) or EJB. It can easily migrate POJO to EJB, or integrate legacy EJB systems .

https://jdon.dev.java.net/