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