Hi Sean, Thanks for the details ... thoughts embedded below.
On 9/26/05, Sean Schofield <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
