DevForce Community Forum : TabViewController - View Communication http://www.ideablade.com/forum/ This is an XML content feed of; DevForce Community Forum : DevForce Classic : TabViewController - View Communication Thu, 11 Jun 2026 13:39:11 -700 Tue, 13 Nov 2007 11:35:41 -700 http://blogs.law.harvard.edu/tech/rss Web Wiz Forums 9.69 360 www.ideablade.com/forum/RSS_post_feed.asp?TID=520 DevForce Community Forum http://www.ideablade.com/forum/forum_images/IdeaBlade_logo_tm.png http://www.ideablade.com/forum/ TabViewController - View Communication : The base class AppViewPresenter... http://www.ideablade.com/forum/forum_posts.asp?TID=520&PID=1918#1918 Author: Bill Jensen
Subject: 520
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.
]]> Tue, 13 Nov 2007 11:35:41 -700 http://www.ideablade.com/forum/forum_posts.asp?TID=520&PID=1918#1918 TabViewController - View Communication : Originally posted by Bill Jensen As... http://www.ideablade.com/forum/forum_posts.asp?TID=520&PID=1911#1911 Author: Linguinut
Subject: 520
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
]]> Mon, 12 Nov 2007 16:43:01 -700 http://www.ideablade.com/forum/forum_posts.asp?TID=520&PID=1911#1911 TabViewController - View Communication : Page and TabViewControllers have... http://www.ideablade.com/forum/forum_posts.asp?TID=520&PID=1831#1831 Author: Bill Jensen
Subject: 520
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.

 
B
]]> Mon, 29 Oct 2007 14:19:33 -700 http://www.ideablade.com/forum/forum_posts.asp?TID=520&PID=1831#1831 TabViewController - View Communication : Should each view have its own... http://www.ideablade.com/forum/forum_posts.asp?TID=520&PID=1830#1830 Author: Bill Jensen
Subject: 520
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.
 
B.
]]> Mon, 29 Oct 2007 14:05:54 -700 http://www.ideablade.com/forum/forum_posts.asp?TID=520&PID=1830#1830 TabViewController - View Communication : Sorry...another question... You... http://www.ideablade.com/forum/forum_posts.asp?TID=520&PID=1829#1829 Author: Linguinut
Subject: 520
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).
]]> Mon, 29 Oct 2007 14:05:49 -700 http://www.ideablade.com/forum/forum_posts.asp?TID=520&PID=1829#1829 TabViewController - View Communication : Should each view have its own... http://www.ideablade.com/forum/forum_posts.asp?TID=520&PID=1828#1828 Author: Linguinut
Subject: 520
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?
]]> Mon, 29 Oct 2007 13:25:51 -700 http://www.ideablade.com/forum/forum_posts.asp?TID=520&PID=1828#1828 TabViewController - View Communication : So, Chris Holmes suggests... http://www.ideablade.com/forum/forum_posts.asp?TID=520&PID=1826#1826 Author: Bill Jensen
Subject: 520
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);

    }

}

]]> Mon, 29 Oct 2007 12:29:08 -700 http://www.ideablade.com/forum/forum_posts.asp?TID=520&PID=1826#1826 TabViewController - View Communication : http://www.codeplex.com/smartc... http://www.ideablade.com/forum/forum_posts.asp?TID=520&PID=1822#1822 Author: Linguinut
Subject: 520
Posted: 29-Oct-2007 at 10:23am

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?
]]> Mon, 29 Oct 2007 10:23:00 -700 http://www.ideablade.com/forum/forum_posts.asp?TID=520&PID=1822#1822 TabViewController - View Communication : Originally posted by Bill Jensen 2b.... http://www.ideablade.com/forum/forum_posts.asp?TID=520&PID=1815#1815 Author: Linguinut
Subject: 520
Posted: 27-Oct-2007 at 11:49am

Originally posted by Bill Jensen

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


Edited by Linguinut - 27-Oct-2007 at 11:51am]]> Sat, 27 Oct 2007 11:49:27 -700 http://www.ideablade.com/forum/forum_posts.asp?TID=520&PID=1815#1815 TabViewController - View Communication : I am drawing a blank on our other... http://www.ideablade.com/forum/forum_posts.asp?TID=520&PID=1779#1779 Author: Linguinut
Subject: 520
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!!
]]> Thu, 25 Oct 2007 10:29:50 -700 http://www.ideablade.com/forum/forum_posts.asp?TID=520&PID=1779#1779 TabViewController - View Communication : As we'ver discussed in other... http://www.ideablade.com/forum/forum_posts.asp?TID=520&PID=1767#1767 Author: Bill Jensen
Subject: 520
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.
]]> Wed, 24 Oct 2007 11:11:12 -700 http://www.ideablade.com/forum/forum_posts.asp?TID=520&PID=1767#1767 TabViewController - View Communication : If I have a controlon a view,... http://www.ideablade.com/forum/forum_posts.asp?TID=520&PID=1760#1760 Author: Linguinut
Subject: 520
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


Edited by Linguinut - 12-Nov-2007 at 4:43pm]]> Tue, 23 Oct 2007 18:29:16 -700 http://www.ideablade.com/forum/forum_posts.asp?TID=520&PID=1760#1760