Simple Web Framework 1.0 has been released. The Simple Web Framework (SWF) is an event based framework targeting Struts developers who want to build rich Web applications but do not want to migrate to JSF. The SWF is built upon the same Jakarta commons basis as Struts, but uses a different request processor (front controller.) The SWF event model supports XmlHttpRequest (as well as form/submit) based event posting, similar to VB.NET or JSF, with In place Page Updating (IPU) rather than page reloading.

The overview says:

We have created the SWF for our team, not for world domination. If you are like us, the SWF may be useful; if not, perhaps not. For the past three years, we have used Struts to create Web applications for intranet deployment. Like many others, we wanted to move to an event model, such as JSF, and cobbled up Struts to support events for the short term. For reasons in common with other teams, JSF has fallen short of our needs. We looked at a number of interesting frameworks, Tapestry being the front runner, but ultimately decided to build a second framework on the same Jakarta Commons foundation as Struts. Using Jakarta Commons and fragments from the Struts source reduces the amount of new (read: unproven) code we inject to a minimum while still achieving our two primary objectives: event processing and IPU. This reuse also reduces the SWF learning curve for those already familiar with Struts. If this reasoning resonates with you, perhaps the SWF is a good fit.

A SWF contraindication would be an Internet application with very high numbers of users, such as The Server Side or Slashdot. The SWF must keep a modicum of session state even if you use client side Page state. Sites with high numbers of concurrent users may not be able to tolerate session creation for each user. As a rule of thumb, use the SWF for building Web applications, not Web sites.

What do you think of the approach and implementation?

We have created the SWF for our team, not for world domination.

Well said, that approach might even lead to world domination;-) If you are not after it, it might come to you.

JSF has fallen short of our needs.

Can you please explain why.

Sites with high numbers of concurrent users may not be able to tolerate session creation for each user.

It would be nice to know numbers. max 10 max 100 max ???. And is that not dependent on your server's internal memory. I actually think that keeping state on the server saves performance of parsing state over and over again. Are stateless apps not shooting themselves in da foot?

[quote]
Sites with high numbers of concurrent users may not be able to tolerate session creation for each user.
[/quote]

What do you mean by "session creation for each user" ???

As what I seen in SWF I think it's to cumbersome.
Released earlier Stripes framework is easies,
also annotation based, also with simple but wery handy AJAX and AJAX-IPU support and more intuitive (with several exceptions). Althought SWF developers explicitly states
"If you do not like our framework just don't use it", they definately can learn something from similar project in terms of "reals simplicity".

What do you think of the approach and implementation?

There are obviously some issues with JSF, but my impression is that it is more powerful than this article suggests: there is no reason why JSF should not use and work AJAX for example:
https://bpcatalog.dev.java.net/nonav/ajax/jsf-ajax/frames.html

Although the POJO component model of this framework is a good idea in principle, I'm not certain it is a good idea to invent "yet another web framework", especially if there are browser compatibility and potential problems dealing with large numbers of users, as the article suggests.

I would have taken an open source JSF implementation and worked to deal with any problems using that.

Is this comparable to Spring's MVC?

AFAIK Spring MVC is controller based, whereas this is component based, like Wicket, Tapestry etc.

I don't get why there is no framework adding components support and facelets/wicket/tapestry-like presentation handler to struts. I mean developers may continue to use ActionForms and Actions and use component extensions (similar or even compatible/adaptable to wicket) if necessary. This framework could add several other extensions to struts:
1) Optionally replace struts-config XML files with annotations - no need to use XML for describing navigation rules.
2) Add interfaces instead of obligatory inheritance for flexibility etc.
3) Built-in Spring integration.
etc.

Regards,
Theodore Kupolov

I don't get why there is no framework adding components support and facelets/wicket/tapestry-like presentation handler to struts.

I think the reason is that people are tired of dealing with a lot of the other short-comings in Struts, and figure if they're going to build something they may as well build on top of a more suitable foundation. I know this is true in my case. Struts does a good job of enforcing some consistency on a web application, but it falls down in too many areas for me to want to use it in a new web application. Things like validation not being tied to type conversion, lack of formatting, how hard it is to do incremental development (your form, action and page all have to be there just to get started). If you're interested in a longer list of reasons take a look at this comparison.

I don't get why there is no framework adding components support and facelets/wicket/tapestry-like presentation handler to struts. I mean developers may continue to use ActionForms and Actions and use component extensions (similar or even compatible/adaptable to wicket) if necessary.

You can try Struts Dialogs library to create CRUD components, embedded controls and robust wizards. Not exactly Wicket style though ;-)

IMHO this is not simple at all!

That JSP source looks like hell!

If you're looking 4 something simple, you should
try Mentawai (http://mentawai.lohis.com.br/).

IMHO this is not simple at all!That JSP source looks like hell!If you're looking 4 something simple, you shouldtry Mentawai (http://mentawai.lohis.com.br/).

For true component models to come about, they need to dump JSP completely. That reliance on the procedural nature of JSP evaluation forces a lot of stateful overhead that shouldn't be there.

For true component models to come about, they need to dump JSP completely. That reliance on the procedural nature of JSP evaluation forces a lot of stateful overhead that shouldn't be there.

Jacob, could you define what is a "true component" from your point of view.

For true component models to come about, they need to dump JSP completely. That reliance on the procedural nature of JSP evaluation forces a lot of stateful overhead that shouldn't be there.

Yeah, struts is down one more to go. JSP should be massively abandoned. It hurts enough already that what is there now needs maintenance. JSP is not even procedural it is assembly. Model == POJO, why view != POJO?

For true component models to come about, they need to dump JSP completely. That reliance on the procedural nature of JSP evaluation forces a lot of stateful overhead that shouldn't be there.

Yeah, struts is down one more to go. JSP should be massively abandoned. It hurts enough already that what is there now needs maintenance. JSP is not even procedural it is assembly. Model == POJO, why view != POJO?

That's kind of the point here...

When dealing with components as a structual model, interweaving procedural evaluation at construction time means that any given client could have a different structual component model that must be retained across requests.

In the flexibility of JSP, you can pull in any model logic you want to dictate your component model on any request. This has historically caused issues for JSF, yet is being resolved with JEE 5. But, this still doesn't correct the session scoped dependency on model information that's driving your component layer. So throughout your app, you now end up with a bi-directional dependency between your view and model that can be avoided.

As for Struts/Webwork, I see a lot of value in those frameworks since they enforce a declarative ruleset on action mappings and state, which is able to handle much higher loads with volatile memory use (in some cases). The role of the view/component model needs revisiting in seeking ways to simplify/remove the bi-directional dependencies that exist whereby the structual state is no longer retained and is transitively dependent on your model on any given 'render' without requiring unecessary state duplication.

Example, take JSF's component model as specified in your XML document. That XML document is basically shared across 100 users-- the structure/execution of it, just like a piece of Java code. Now, does it make a lot of sense to capture the state of that shared XML document across all calls. Even then, are you guaranteed that the state won't be modified before rendering again such that the state you retained was for nothing.

interweaving procedural evaluation at construction time means that any given client could have a different structual component model that must be retained across requests.

and that is what makes it all so tedious. Building the next screen bit by bit over and over again.

As for Struts/Webwork, I see a lot of value in those frameworks

I cannot speak about Webwork since i don't know it but struts has to go. That thing assumes that we do everything right and we don't need meaningfull messages. How many times have i seen "null" as a message or just a blank screen without any message whatsoever. How hard is it to say "you are trying to write property X from bean Y but it has a null value". No struts gives us "cannot write null" or such. That makes me really really pissed.

JSP-based frameworks are all fundmentally flawed.

If I have a choice between Velocity/WebMacro/OGNL and JSP with it's inferior EL and ugly taglib syntax, I'll go with macro-languages all day.

Seriously, in order to type:

<c:out input="${dfjsdjfl}"/>

I have to hit the shift key about seven times. I'm a decent typist, but those shift key characters bring my typing flow to a complete halt.

Compare that to a simple $dfjskdfl (in velocity at least), and get arbitrary object-introspection.

Tag libraries have simply turned out to be a terrible idea practically speaking, and since they now infect practically every single mainstream java web framework (including JSF), Java continues to be stunted in terms of growth of efficiency in web frameworks. This is the main reason Ruby runs circles around Java in web tiers and still has time to taunt.

Hopefully Groovy and its superior features will help this extensively, but the performance loss is substantial.

JSP-based frameworks are all fundmentally flawed.

If I have a choice between Velocity/WebMacro/OGNL and JSP with it's inferior EL and ugly taglib syntax, I'll go with macro-languages all day.

Seriously, in order to type:

<c:out input="${dfjsdjfl}"/>

I have to hit the shift key about seven times. I'm a decent typist, but those shift key characters bring my typing flow to a complete halt.

Is *this* a fundamental flaw??? Then you should praise God for not having the necessity to type both in English and Cyrillic. Or Chinese.

You can reprogram a keyboard, do you know about that?

Carl, the issues you mentioned are included in pre-JSP 2.0, such that since then you can inline expressions however you choose within XML/HTML.

Along the lines of Ruby, you can always use scriptlets to the same effect with JSP. I think a majority of developers have been there, and left that route for maintainability reasons. The UI based macros are quite nice within Ruby, but not unreachable with JSP as it stands now.

I will agree that JSF possibly has opportunities yet to really boost efficiency if it looks at alternate ways of building the component model in relation to statemanagement. So despite what I said before, JSF still has potential to go much further.

type:<c:out input="${dfjsdjfl}"/>I have to hit the shift key about seven times.

LOL ;-) that is the perfect example of why it is so crappy, and why is it that way anyway, because page designer are less intelligent than programmers, isn't that where it started all. Ever saw a pagedesigner use it, I didn't.

Hopefully Groovy and its superior features will help this extensively, but the performance loss is substantial.

I believe groovy files can eventually be compiled so there should not be to much loss.

... page designer are less intelligent than programmers... Ever saw a pagedesigner use it, I didn't.

Maybe because page designers are more intelligent that that! ;)

Seriously, in order to type:<c:out input="${dfjsdjfl}"/>I have to hit the shift key about seven times.

Don't you now that in JSP 2.0 you can just write $blabla as JSP2.0 supports EL. So don't use ancient technologies... :)

Thanks for noting Mentawai. It seems to be pretty smart easy to learn MVC framework. I have been playing with it for last couple days and it seems to be highly useful. Definetely worth checking out!

<blockquotewho want to build rich Web applications but do not want to migrate to JSF
And the percentage target audience for people writing a new application + Learning a New Framework is 0.00001 %