[shale] Please provide more information concerning DialogController interface

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

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.

Thanks,

sean

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

Re: [shale] Please provide more information concerning DialogController interface

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

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

That's what I figured.  I'm looking forward to seeing what emerges.  I
definitely think this is and the ViewController stuff will be nice
value-added to JSF.  I'll try to provide some ideas of my own shortly.

> Craig

sean

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

Re: [shale] Please provide more information concerning DialogController interface

[Craig McClanahan <cr...@gmail.com>]

On Fri, 21 Jan 2005 13:50:30 -0500, Sean Schofield
<se...@gmail.com> 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

Craig


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

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