> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
