On 10/27/05, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> On 10/27/05, Sean Schofield <[EMAIL PROTECTED]> 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.
> >
<snip/>
I agree with your bit about reuse of declarations in general, though
you were probably coming at it from your use case. I chose to have the
state and activity/view wiring outside the dialog declaration when I
wrote a custom DialogNavigationHandler for my Shale distro, but OTOH,
I'll be hesitant to push on it for the default dialog-config.xml,
which is Enough of A Good Thing, IMO. One of the things I'm interested
in is the effort required to package an individual Shale dialog and
the deltas involved in its reuse across multiple applications.
> > 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 #{dialog.data}. 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.
>
<snap/>
Indeed, chaining ActionStates already gives us the temporal axis for
"before" and "after".
-Rahul
> Craig
>
> sean
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
