[shale] New class: LookupDialog

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

Craig,

This is in response to your comment on Bug#36439 (custom DTD's.)  You
asked me to outline some of the "non standard" things I was doing with
dialog.  We have a few different things that we have added to Shale
and I'm happy to outline them in case they are useful for Shale or
other developers who use Shale.

One of these is a LookupDialog that allows you to define a dialog as a
complete subset of another dialog with a defined start and end point. 
Here's how a trivial example ...

<dialog name="Contact" start="firstName">
     <view name="firstName" viewId="/firstName.jsp">
          <transition outcome="next" target="lastName"/>
     </view>
     <view name="lastName" viewId="/lastName.jsp"/>
          <transition outcome="prev" target="firstName"/>
          <transition outcome="next" target="address"/>
     </view>
     <view name="address" viewId="/address.jsp"/>
          <transition outcome="prev" target="lastName"/>
     </view>
</dialog>

Suppose you had another dialog that required just name information
(first two screens) and you wanted to reuse the first and last name
screens.  You would have to break up the original dialog into pieces
and then piece together your two dialogs using <subdialog>.

<subdialog> works fine when you want to mix and match pieces of
dialogs but if you would like to reuse a portion of an existing dialog
this gets tedious.  In our application we have some ten step dialogs
for creating a new "document" which populates a bunch of fields on a
form.  You can then go back and edit specific fields.  Using the
standard approach this requires 10 different dialogs and then a slew
of <subdialogs>.

Instead we have LookupDialog which allows you to do the following:

<dialog name="Just Name" dialogName="Contact" start="firstName"
stop="lastName" className="LookupDialog"/>

One nice thing is that the original ten step dialog is one nice big
chunk 'o XML without any of the <subdialogs> cluttering things up. 
Don't get me wrong, we use subdialog also, but for this type of
usecase, LookupDialog is superior.

What do you think?  I can show you the patch if you're interested but
it will take a little work to refactor to org.apache.shale, etc. so I
won't bother unless there's interest.

sean

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

Re: [shale] New class: LookupDialog

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

>  Hmm ... I'm not sure I agree.  Think of it in terms of the methods of a
> class ... if you needed to share only *part* of the methods, would you try
> to create a subclass that "hid" the bad methods (perhaps by throwing
> UnsupportedOperationException) , or would you refactor the class in question
> for real?  I'd certainly do the latter.

Yes but in a programming language you have interfaces, inheritance and
other tricks to help you with this.  Writing ten dialogs (each with
their own name) and then adding subdialogs around all of those is very
cumbersome and difficult to read/maintain.

Its certainly ok to use certain methods of an object and not others. 
That's more like what I'm describing.

>  Think also about the testing implications ... when the original dialog was
> written, it was probably designed as a unit, with side effects  between
> states as something to be expected.  The moment you take a slice out of an
> existing dialog, you are breaking all those implicit contracts about
> preconditions and postconditions -- and creating a testing nightmare for the
> person responsible for the dialog as a whole, because he/she cannot control
> *where* you might think you can set starting and stopping states.

I recall you making this argument before.  Our dialogs run as popups
and they are populated from javascript.  They don't do anything except
return values to the underlying page.  Therefore there is no real
"contract" except for what values to read/modify in #{dialog.data}.

I can see a scenario where dialogs would be used in the manner you are
describing but this is an alternate way of using them.  There are
plenty of real world dialogs (date pickers, zip code finders, etc.)
that don't do anything but supply values to an underlying page.  So if
you have a dialog screen with an input bound to 
#{dialog.data['firstName']} you can reuse this screen as long as the
underlying page is aware of the naming convention.

We have a step that imports values posted from javascript into the
dialog.data in the first step and exports them back to javascript in
the last step (more on that in a later post.)

>  I'd suggest that if you *really* want to do this, you've got most of the
> tools available already, since you can already declare a custom
> implementation class for the elements.  All you'd need to do is maintain
> your own DTD that is a superset of the standard one (the Digester
> ipmlementation uses setProperty() to do the actual property settings, so
> it'll pick up new properties without any modifications).

Exactly.  That is why I requested support for alternate DTD's.  You
mentioned on the Bugzilla issue that maybe we should explore why I
needed the custom DTD in the first place so that's what this post was
about.

>  That way, you can get what you want without introducing what I would tend
> to think of as a "not-best" practice to the general Dialog constructs :-).
> IMHO, dialogs should be defined as a single unit, with entry and exit points
> defined by the *dialog*, not by the *users* of the dialog.  If that means
> you need to refactor dialog definitions later, so be it -- at least that is
> quite easy, already supports reuse of pages and backing beans, and still
> leaves you with clear boundaries on what kinds of inter-state contracts your
> state implementations can expect.

Again.  We did this without too much trouble and that is a good sign
that the dialog stuff is pretty extensible.  Support for alternative
(or no) DTD would make it even easier to do this type of
customization.

I disagree that this is a non best practice given my specific
requirements.  A 10 step dialog where the user may later want to edit
a specific value from one of those ten steps.  I argue that from a
maintenance and readability standpoint its much easier to have a one
line lookup dialog that starts and stops at step 8 rather than double
the amount of XML with all sorts of <subdialogs>.  But we can agree to
disagree on that point.  It might also be a bit unusual of a use case.

>  Craig

sean

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

Re: [shale] New class: LookupDialog

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

Hi Sean,

Thanks for the details ... thoughts embedded below.

On 9/26/05, Sean Schofield <se...@gmail.com> wrote:
>
> Craig,
>
> This is in response to your comment on Bug#36439 (custom DTD's.) You
> asked me to outline some of the "non standard" things I was doing with
> dialog. We have a few different things that we have added to Shale
> and I'm happy to outline them in case they are useful for Shale or
> other developers who use Shale.
>
> One of these is a LookupDialog that allows you to define a dialog as a
> complete subset of another dialog with a defined start and end point.
> Here's how a trivial example ...
>
> <dialog name="Contact" start="firstName">
> <view name="firstName" viewId="/firstName.jsp">
> <transition outcome="next" target="lastName"/>
> </view>
> <view name="lastName" viewId="/lastName.jsp"/>
> <transition outcome="prev" target="firstName"/>
> <transition outcome="next" target="address"/>
> </view>
> <view name="address" viewId="/address.jsp"/>
> <transition outcome="prev" target="lastName"/>
> </view>
> </dialog>
>
> Suppose you had another dialog that required just name information
> (first two screens) and you wanted to reuse the first and last name
> screens. You would have to break up the original dialog into pieces
> and then piece together your two dialogs using <subdialog>.


Yep ... pretty standard sort of refactoring, but this time on config files
instead of classes.

<subdialog> works fine when you want to mix and match pieces of
> dialogs but if you would like to reuse a portion of an existing dialog
> this gets tedious. In our application we have some ten step dialogs
> for creating a new "document" which populates a bunch of fields on a
> form. You can then go back and edit specific fields. Using the
> standard approach this requires 10 different dialogs and then a slew
> of <subdialogs>.
>
> Instead we have LookupDialog which allows you to do the following:
>
> <dialog name="Just Name" dialogName="Contact" start="firstName"
> stop="lastName" className="LookupDialog"/>
>
> One nice thing is that the original ten step dialog is one nice big
> chunk 'o XML without any of the <subdialogs> cluttering things up.
> Don't get me wrong, we use subdialog also, but for this type of
> usecase, LookupDialog is superior.


Hmm ... I'm not sure I agree. Think of it in terms of the methods of a class
... if you needed to share only *part* of the methods, would you try to
create a subclass that "hid" the bad methods (perhaps by throwing
UnsupportedOperationException) , or would you refactor the class in question
for real? I'd certainly do the latter.

Think also about the testing implications ... when the original dialog was
written, it was probably designed as a unit, with side effects between
states as something to be expected. The moment you take a slice out of an
existing dialog, you are breaking all those implicit contracts about
preconditions and postconditions -- and creating a testing nightmare for the
person responsible for the dialog as a whole, because he/she cannot control
*where* you might think you can set starting and stopping states.

What do you think? I can show you the patch if you're interested but
> it will take a little work to refactor to org.apache.shale, etc. so I
> won't bother unless there's interest.


I'd suggest that if you *really* want to do this, you've got most of the
tools available already, since you can already declare a custom
implementation class for the elements. All you'd need to do is maintain your
own DTD that is a superset of the standard one (the Digester ipmlementation
uses setProperty() to do the actual property settings, so it'll pick up new
properties without any modifications).

That way, you can get what you want without introducing what I would tend to
think of as a "not-best" practice to the general Dialog constructs :-).
IMHO, dialogs should be defined as a single unit, with entry and exit points
defined by the *dialog*, not by the *users* of the dialog. If that means you
need to refactor dialog definitions later, so be it -- at least that is
quite easy, already supports reuse of pages and backing beans, and still
leaves you with clear boundaries on what kinds of inter-state contracts your
state implementations can expect.

Craig


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