DevForce Classic: TabViewController

TabViewController - View Communication

Printed From: IdeaBlade
Category: DevForce
Forum Name: DevForce Classic
Forum Discription: For .NET 2.0
URL: http://www.ideablade.com/forum/forum_posts.asp?TID=520
Printed Date: 11-Jun-2026 at 1:38pm

Topic: TabViewController - View Communication

Posted By: Linguinut
Subject: TabViewController - View Communication
Date Posted: 23-Oct-2007 at 6:29pm

If I have a control on a view, and the view has a presenter, and the view has a TabViewController...

(pause for a breath...)

...and I want to get the value of the control from the TabViewController, how do I do that? The catch...the control is associated with a ListConverter.

Thanks,

Bill

Replies:

Posted By: Bill Jensen
Date Posted: 24-Oct-2007 at 11:11am

As we'ver discussed in other threads, the mechanism for communicating between a presenter and its view controller is the view context.

The steps are:

1. The controller creates the view context and adds it to the workitem under a unique view id.

2. The controller then creates the view, possibly using the ViewFactoryService, and adds it to the workitem under the same unique view id.

3. The object builder injects the presenter into the view (causing its creation by the object builder).

4. The view informs the presenter itself and its unique view id.

5. The presenter uses the unique view Id to retrieve the context for this particular view instance.

If the presenter needs to communicate information back to the controller, there are a couple of approaches:

1. Just put the value you want to communicate in the view context. Both the presenter and controller have access to it.

2a. For event signalling, put a reference to an object (use an Interface!) in the view context with methods to signal the event and call them in the presenter. This couples the presenter to the controller (or at least to the interface type).

2b. Supply one or more delegates (to methods of the controller) in the view context that the presenter can call when necessary. This has the advantage of looser coupling--the presenter is only coupled to a method with a particular signature, and if the delegate is not set, it simply doesn't signal that information.

Of course, in keeping with good MVP architecture, the view should field the raw "ValueChanged" or "Click" event from the control and do nothing except call a method on the presenter.

I'm not sure of the significance of the ListConverter.

Bill J.

Posted By: Linguinut
Date Posted: 25-Oct-2007 at 10:29am

I am drawing a blank on our other discussions. Sorry...must be the lack of coffee in my diet today.

I am intrigued by 2b. I really want to maintain good MVP architecture; however, it is very difficult to break old programming patterns. It is an everyday struggle.

Thanks for the info!!

Posted By: Linguinut
Date Posted: 27-Oct-2007 at 11:49am

Originally posted by Bill Jensen

Would you mind presenting an example? I have no idea what you mean by supplying a delegate in the ViewContext. I do not see a mechanism for me to do that.

Why couldn't I make the controls public? I suppose this is a major violation of something. I tried this. It works nicely. I created a view with just a bunch of DevEx controls. I made them public. I added a type-bound ControlBindingManager in the view code (not the GUI) because I have to pass the ControlBindingManager to the presenter (it breaks in every other way that I tried). In the presenter I setup the ControlBindingManager. No GUI involved. Build and run. Works fine.

I am guessing that this ViewContext thing has done something like this already. Perhaps it registers the controls somewhere in the WorkItem, or something like that. From there maybe the presenter or controller can grab the control and do something with it. I don't know...things are getting really muddy, again. What I thought I understood yesterday is all turned on its head today.

Posted By: Linguinut
Date Posted: 29-Oct-2007 at 10:23am

http://www.codeplex.com/smartclient/Thread/View.aspx?ThreadId=5260 - http://www.codeplex.com/smartclient/Thread/View.aspx?ThreadId=5260

So, Chris Holmes suggests that one should avoid making controls public, but he doesn't say why. Can anyone shed some light on this?

Posted By: Bill Jensen
Date Posted: 29-Oct-2007 at 12:29pm

So, Chris Holmes suggests that one should avoid making controls public, but he doesn't say why. Can anyone shed some light on this?

Loose coupling between components.

If a view exposes its controls publicly, then the classes that reference it are permanently bound to the view's type and to the specific control types. If you later decide to replace a text box with a combo box, all the referencing classes need to change.

A view's only responsibility is to pass information to and from the user. The presenter and the rest of the app shouldn't care how it does it. That's why the presenter only interacts with the view through its interface.

Normally, the view exchanges information with the rest of the app via the Model--typically supplied by the presenter by setting a data source into the view's BindingSource. Other information may be transmitted via the ViewContext, typically via the presenter.

I have no idea what you mean by supplying a delegate in the ViewContext. I do not see a mechanism for me to do that.

Like this:

// Custom view context for MyView

public class MyViewContext : ViewContextBase

{

// Delegate declaration

public delegate void MyCallbackType(string myData);

// Delegate member - holds a reference to a function with delegate's signature

private MyCallbackType mCallback;

// Make delegate accessible as a property

public MyCallbackType Callback

{

get { return mCallback; }

set { mCallback = value; }

}

// In the page controller:

protected override void CreateViews()

{

MyViewContext context = ...; // Create and add to workitem

// Pass a reference to the callback function in the context

context.Callback = new MyViewContext.MyCallbackType(callback);

}

// Called by presenter via delegate when new data available. Must have delegate's signature

private void Callback(string data)

{

}

// In MyViewPresenter:

private MyViewContext mContext;

// Called by view when value of data control changes

public voidDataValueChanged(string data)

{

// Be sure the callback delegate is non-null

if (mContext.Callback != null)

{

// Invoke the delegate

mContext.CallBack(data);

}

Posted By: Linguinut
Date Posted: 29-Oct-2007 at 1:25pm

Should each view have its own interface? If so, of what is the interface comprised?

Where is the most logical place to create the MyViewContext class? Views folder of the module?

Create and add to WorkItem?

Posted By: Linguinut
Date Posted: 29-Oct-2007 at 2:05pm

Sorry...another question...

You mentioned that the controller creates the view context and adds it to the work item--where is that happening? I cannot find that (unless you are talking about creating my own viewcontext).

Posted By: Bill Jensen
Date Posted: 29-Oct-2007 at 2:05pm

Should each view have its own interface?

It could if it needed to receive unique information from the presenter.

If so, of what is the interface comprised?

The minimum set of members to allow the view to do its job. i.e., to receive the information it needs from the presenter.

That said, we recommend against custom view interfaces. Instead, stick with the (relatively general) IBindingView or IAppView. If the presenter needs to call into the view, define a delegate type (signature of a method) in the presenter together with a Register() method. As soon as the presenter is set (injected) into the view, call Register(), passing a delegate to a method in the view. When the presenter needs to call into the view, it invokes the delegate, if it's been set. If not, it does nothing.

This way, the presenter depends only on the delegate type (that IT defines). The view may or may not register to receive that information as its needs dictate. Because it depends only on the general view interface (like IBindingView or IAppView), the presenter type might be usable by multiple view types, some registering a callback, some not.

Where is the most logical place to create the MyViewContext class? Views folder of the module?

Sounds fine to me.

Create and add to WorkItem?

In the page controller, just before creating the view.

Posted By: Bill Jensen
Date Posted: 29-Oct-2007 at 2:19pm

Page and TabViewControllers have a CreateView() (or CreateViews() or CreateSummaryView() or something like that) method. Just create the view context and add it to the work item before creating the view. There's a static method on ViewContextBase to do it.

Posted By: Linguinut
Date Posted: 12-Nov-2007 at 4:43pm

Originally posted by Bill Jensen

As we'ver discussed in other threads, the mechanism for communicating between a presenter and its view controller is the view context.

The steps are:

1. The controller creates the view context and adds it to the workitem under a unique view id.

2. The controller then creates the view, possibly using the ViewFactoryService, and adds it to the workitem under the same unique view id.

3. The object builder injects the presenter into the view (causing its creation by the object builder).

4. The view informs the presenter itself and its unique view id.

5. The presenter uses the unique view Id to retrieve the context for this particular view instance.

Why would the ViewContext still be null after the view is created and the presenter is injected? Shouldn't I be able to refer to the ViewContext from the presenter like this:

IBindingViewContext mViewContext = this.ViewContext;

Sorry...thought this one was solved. I am finally getting back to it.

Bill

Posted By: Bill Jensen
Date Posted: 13-Nov-2007 at 11:35am

The base class AppViewPresenter contains the virtual method OnViewContextSet() that you can override in your child presenter.

The ViewContext property is not valid until this method has been called.

Bill J.