struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rich Feit <richf...@gmail.com>
Subject Re: Struts Dialogs (was HTTP method for action-mappings)
Date Fri, 08 Jul 2005 15:07:26 GMT
I just want to clarify on the Beehive angle... it's a common
misperception that Beehive is all about controls, or all about web
services, or all about page flow.  It contains all three fairly
independent pieces (the conceptual link is that all use annotations in
the programming model, and the code link is that the Page Flow and Web
Services Metadata pieces both can consume controls easily).

The Page Flow piece -- basically an annotation-based extension of Struts
-- has the idea of grouping a controller and a set of view elements
(e.g., JSPs or JSF pages) into a reusable package: a "nested page
flow".  It's not exactly what you're describing, but it is much more
relevant than the Controls piece.  :)  The Beehive dist
(http://incubator.apache.org/beehive/downloads.html ) ships with a Login
nested page flow at samples/netui-samples/loginexample/loginflow.

Rich

Michael Jouravlev wrote:

>On 7/5/05, Don Brown <donald.brown@gmail.com> wrote:
>  
>
>>About Struts Dialogs, perhaps I missed it, but how does it differ from
>>Beehive?  They seem to be tackling the same problem and are quite far
>>along.
>>
>>Don
>>    
>>
>
>Beehive is an all-ebracing system, they call a "control" anything that
>exposes some kind of resource. It is more generic. IIt uses
>annotations and metadata, external configuration, etc. It is just too
>complex. Anyway, if there is anything that I would compare Struts
>Dialogs with, it would be either JSF or portlets.
>
>Let me rewind and tell what was the original design goal. It was
>purely UI-related, and was born to life because I was unsatisfied with
>user experience of may web apps. You might see my article about
>redirect-after-post stuff on TSS. So, my library is implementation of
>this pattern in Struts. All you need is to use directly or extend
>DialogAction, and it will do everything else for you: two-phase input
>processing, managing state, saving error messages, correctly working
>with page reload and with Back button. This is the original goal and
>this is what I was selling.
>
>Here is the live demo which illustrates the idea:
>http://www.superinterface.com/strutsdialog/logincomponent.html
>The server is shared, so it may be down from time to time.
>
>The above design goal does not have anything with page controls, as
>you can see. After I implemented it, I thought that two-phase
>processing (aka redirect-after-post) allows to build componentized
>pages easily. You can just include a resource, containing HTML form.
>Then you submit input to the action defined in this form, not to the
>master page location. How to redraw the master page? Simple, the
>component redirects to it, and it reloads all it contains. The
>redirection location can be passed as parameter, but much simpler
>solution is to define it in config file. Now this became a second
>selling point: simple page controls using JSP. So much simpler than
>portlets. Much more limited too, accept input or POST, render youself
>on GET, share data via session object. But in many cases this is
>enough.
>
>Here is the second demo with the same component, embedded in JSP page:
>http://www.superinterface.com/strutsdialog/logincontrol.html
>The only changes are mappings in struts-config.xml, the Java code is
>the same as in previous example.
>
>So, better user experience and possibility to create page controls
>with only one new action class. Is it worth it? One action class (ok,
>two classes if considering SelectAction worth mentioning) versus a
>whole component framework like Beehive or portlet API. I think it is
>worth it. This can bring Struts back in the game, and boy, I want it
>to be back in the game, because I am too lazy to learn new framework
>each year.
>
>I really want people to understand what is that I am actually
>advertising ;-), so questions are welcome.
>
>Michael.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
>
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message