struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <>
Subject Re: [shale] Please provide more information concerning DialogController interface
Date Fri, 21 Jan 2005 19:19:30 GMT
On Fri, 21 Jan 2005 13:50:30 -0500, Sean Schofield
<> wrote:
> Craig,
> I've been rereading your Shale proposal and studying the use cases.
> To me the usecases example shows an interesting way of dealing with
> some of the challenges of a "dialog" situation.  Your general approach
> makes sense.
> What I don't understand is the benefit of the DialogController
> interface in particular.  What real benefits do I obtain from
> extending this interface?  The benefits of the ViewController
> interface are more obvious.  The framework will call the various
> methods at the appropriate point in the Shale lifecycle.  (I'm
> interested in learning more about how you might use those methods but
> for that I will take a look at mailreader.)
> I don't really see that the methods on the DialogController interface
> are guaranteed to be called at any point.  You are of course calling
> them from the appropriate ViewController beans, but that's not a
> guarantee.
> Perhaps this is an area where you had some long term plans in mind?
> Again, I'm not criticizing the approach you are taking in the usecaess
> example, but for now it just strikes me as an example of how you might
> choose to go about it.
> I'm probably missing something so any light you can shed on this would
> be helpful.

Implementing DialogController doesn't add much value yet, but it will
over time as Shale adds more behavior for you.  For example, an
earlier thread today inspired the thinking of a solution to the
"having to know your own attribute key" problem:

* Add the following to DialogController:

    public String getAttributeKey();
    public void setAttributeKey(String attributeKey);

* Customize the JSF VariableResolver (the thing that does managed bean
  creation) such that, if the bean just create was a DialogController, call
  setAttributeKey() to tell the instance what it's name is.

This will become less important if we can identify a way for the
framework to do the delete instead of having the instance do it, but
that will still require implementing the interface (so the framework
can do instanceof checks).

Think of the current interface as a placeholder for functionality as
we figure out what functionality a dialog (or whatever the ending name
is) is supposed to provide.  If that functionality ends up being
nothing, it can of course go away ... but I'm betting there will be
quite a few interesting things we can do with one of these, once we
have one.

> Thanks,
> sean


> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message