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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
