[shale] Another dialog idea

[Sean Schofield <se...@gmail.com>]

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.

sean

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

Re: [shale] Another dialog idea

[Rahul Akolkar <ra...@gmail.com>]

On 11/10/05, Sean Schofield <se...@gmail.com> wrote:
<snip/>
> I suppose we could have
>
> <action name="Import Wizard State" method='#{wizardHelper.importWizardState}">
>     <transition outcome="next" target="First Real Step"/>
> </action>
>
> for every dialog.  It just adds 3 lines of XML for every single
> dialog.  Kind of a pain.
>
<snap/>
>
> Anyways, just bouncing an idea around.  I thought it might be too
> application specific.  Perhaps other users will have similar needs and
> we can revisit it at that time.
<snip/>

I have absolutely no doubt that other users will come forth with the
same need. I also have little doubt that given enough time, someone
will come forth with a perfectly valid usecase for carrying out a
certain action at the end of a dialog, and will probably request a
seemingly obvious notation to handle that.

But this is, IMO, classic "shorthand vs. creep". If you can do what
you need to with the available constructs, proposals to introduce
shorthand notations that might save some markup should be very
carefully evaluated. As framework authors, be wary, because (lessons
learnt first hand from authoring a framework):

 * Shorthands are less expressive (already pointed out in this thread)
 * There is one more construct to code, maintain, document
 * Creep is exponential (hey, you allowed foo, now give me bar,
freddy, frog and baz -- when I can already do everything I need)

-Rahul

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

Re: [shale] Another dialog idea

[Craig McClanahan <cr...@apache.org>]

On 11/10/05, Sean Schofield <se...@gmail.com> wrote:
>
> I know this conversation was over a week ago but I finally had some
> time to get back to my mailing list backlog... (see inline comments
> below)
>
> > 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.
>
> I suppose we could have
>
> <action name="Import Wizard State" method='#{
> wizardHelper.importWizardState}">
> <transition outcome="next" target="First Real Step"/>
> </action>
>
> for every dialog. It just adds 3 lines of XML for every single
> dialog. Kind of a pain.


Is it really more painful than adding a prestartMethod="#{
wizardHelper.importWizardState}" attribute to the <dialog> element?

Especially considering that doing it this way means (a) no new concept to
learn, and (b) you can transition different directions if, say, your
database connection is down and you can't acquire the resources that you
need.

> 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.
>
> I believe that is what we are already doing. See the wizard "helper"
> bean in the above example. Is this what you mean?


Yes.

Anyways, just bouncing an idea around. I thought it might be too
> application specific. Perhaps other users will have similar needs and
> we can revisit it at that time.
>
> > Craig
>
> sean


Craig

Re: [shale] Another dialog idea

[Sean Schofield <se...@gmail.com>]

I know this conversation was over a week ago but I finally had some
time to get back to my mailing list backlog... (see inline comments
below)

> 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.

I suppose we could have

<action name="Import Wizard State" method='#{wizardHelper.importWizardState}">
     <transition outcome="next" target="First Real Step"/>
</action>

for every dialog.  It just adds 3 lines of XML for every single
dialog.  Kind of a pain.


> 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.

I believe that is what we are already doing.  See the wizard "helper"
bean in the above example.  Is this what you mean?

Anyways, just bouncing an idea around.  I thought it might be too
application specific.  Perhaps other users will have similar needs and
we can revisit it at that time.

> Craig

sean

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

Re: [shale] Another dialog idea

[Rahul Akolkar <ra...@gmail.com>]

On 10/27/05, Craig McClanahan <cr...@apache.org> wrote:
> On 10/27/05, Sean Schofield <se...@gmail.com> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: [shale] Another dialog idea

[Craig McClanahan <cr...@apache.org>]

On 10/27/05, Sean Schofield <se...@gmail.com> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>