struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Jouravlev <>
Subject Re: Struts Dialogs (was HTTP method for action-mappings)
Date Wed, 06 Jul 2005 01:22:49 GMT
On 7/5/05, Frank W. Zammetti <> wrote:
> So are you saying you've implemented the Portlet specification, or some
> subset of it?
> If not, I'm not sure I see the point.
> If so, why would I choose this over an actual portlet implementation
> (which can be built on top of Struts, which is exactly what we use at
> work in the form of IBM's portal product).
> I'm not asking this in a confrontational way, it's a legitimate
> question... convince me! :)
> Frank

* No, I am not implementing Portlet spec or subset of it.
* I am not saying that my stuff is better than portlets.
* Originally, the whole thing was not about portlets and controls.

Have you read my answer to Don? Please do, it should explain a lot. Or
my English is really that bad? Or it is not the language, it is my
ability to explain?

I will try once again. The original reason why I started this project,
was to implement Post-redirect-Get pattern in Struts.

If this pattern does not ring a bell, this is the idea: to split one
"submit data with POST, return with page" request into two separate
* submit data with POST, update domain model, generate error messages,
then redirect to result page;
* load result page with GET.
Why? To avoid implicit resubmits and POSTDATA messages. If you do not
care for Refresh, Back and Forward buttons then this reasoning will
not convince you. But for me this is important. I hate POSTDATA
messages, I hate to answer "Yes" to "Do you want to resend POSTDATA?"
messages, I hate to log in, then to click Back button and to see the
same login form again.

Is the above clear? I'm not asking this in a confrontational way, it's
a legitimate question. :)

By the way, this pattern is official in Ruby on Rails, is official in
Wicket, can be easily configured in JSF, so I am not creating
something controversial of ground-breaking. But Struts does not have
it. Struts does not have _any_ UI support besides automatic form bean
population and dispatching of submit buttons to DispatchAction. What I
want is to add better support for stateful UI objects to Struts.

Please, try this demo once again, I know you tried, but try once more:
Notice, that two pages, login page and logout page are served from the
same location. This is important. You cannot log in and then go back
and see login page. Also, you can refresh any page after you submitted
an HTML form, and you won't get POSTDATA message. Also, despite how
may login attempts you made, it takes only _one_ click on Back button
to leave login component. This is what Struts Dialogs does. It also
helps to manage error messages.

After I implemented this, I realized that I could easily embed these
components into a JSP page with little efforts. Why? Because of
two-phase processing (aka redirect-after-post) that I implemented

I am not saying that I implemented portlet API or created a framework
competing with portlets. I am saying, that often all that needed, is
to visually embed a component into a page. Do you really need portlet
container and portlet API to do this simple thing? No, you don't. All
you need is master JSP page and <jsp:include> directive to include a
JSP component.

Why <jsp:include> and not, for example, SSI? Because with
<jsp:include> I can include dynamic component, and I can share data
using standard servlet/JSP data structures like session.

Why two-phase components make a difference? Because user data is
submitted directly to the component instead of being submitted to the
portal container or master JSP page. This allows to get rid of portlet
container altogether _if all you need is simple inclusion of a

Please, check out the second demo with the same login component, but
this one is embedded in JSP page:
The only changes are mappings in struts-config.xml, the Java code is
_the same_ as in previous example. You can log in, and the master page
is redrawn, and control shows current user logged-in state. Also, the
prices on the servers are $50 lower, but this is just a sample page

Wrapping up, the goals:
* To provide better user experience and easier development of stateful
components like, for example, login dialogs.
* To develop JSP controls, which do not need any other container
besides parent JSP page.

Is it clearer, or I was not able to explain what my stuff does again ;-) ?

No, really, if I could not explain it this time, I will try again and
again, but remember that I know only this many English words :)

This is what I can do. Do you have login page in your app? I can
create a login control based on my sample, and you can just plug in it
into your app.

Actually, this is the direction I want to move. To create JSP
controls. Try to search for "asp (component or control)" using Google.
It would ask you back, 'Did you mean: "asp (component or control) " '
This is sad, but JSP has no notion of visual component or control. Ok,
so now portlet spec and JSF give us the components. But ASP had them
long ago, and ASP is no better than JSP. So, why not to create
components using pure JSP? I showed that this is possible.

If I could not explain it again, please reply, so I could think on
better wording ;-)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message