struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <>
Subject Re: [shale] Another dialog idea
Date Fri, 28 Oct 2005 00:35:53 GMT
On 10/27/05, Sean Schofield <> wrote:
> Just wanted to bounce an idea off of people. We have our own custom
> Dialog class that makes use of a "beforeStart" attribute. Basically
> there are certain steps we take before each dialog. We can't really
> reuse a state using XML entities because the "next" transition is
> always different depending on the dialog.
> So we have "beforeStart" which points to an "Import Wizard State."
> That state is application specific and in our instance we use it to
> load all of the javascript variables from the underlying page (the
> page runs in a popup) into the #{}. I imagine that most
> dialogs have some common data setup that they might need and this
> helps solve that problem. There is still a "start" attribute which
> gets called after "beforeStart."
> Maybe this is too specific to my situation but I thought I would throw
> it out there. It works well for us in our application.

How is this different from just encapsulating your setup logic into an
action method, and then calling it as the first state of the dialog
explicitly? Besides the readability value of explicit declaration, and the
simplicity of not having to learn yet another concept to do this kind of
thing, this would also give you the opportunity to transition differently
based on outcomes from the setup state.

If the logic to set up a dialog was common across multiple dialogs, you
could easily point at a common method in some utility managed bean, so you
only had to code the server side setup once.


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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message