|
TabViewController - View Communication |
Post Reply 
|
| Author |
 Share Topic Printable Version Delicious Digg Facebook Furl Google Boomarks Google Buzz MySpace Newsvine reddit StumbleUpon Translate Twitter Windows Live Yahoo Bookmarks Topic Search  Topic Options
|
Bill Jensen 
IdeaBlade 
Joined: 31-Jul-2007 Location: United States Posts: 229 |
 Post Options
 Quote Reply
 Topic: TabViewController - View CommunicationPosted: 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.
|
|
 |
|
|
Linguinut
Senior Member 
Joined: 14-Jun-2007 Location: United States Posts: 394 |
Post Options
Quote Reply
Posted: 12-Nov-2007 at 4:43pm |
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
|
|
|
|
|
Bill Jensen
IdeaBlade
Joined: 31-Jul-2007 Location: United States Posts: 229 |
Post Options
Quote Reply
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
|
|
|
|
|
Bill Jensen
IdeaBlade
Joined: 31-Jul-2007 Location: United States Posts: 229 |
Post Options
Quote Reply
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.
|
|
|
|
|
Linguinut
Senior Member
Joined: 14-Jun-2007 Location: United States Posts: 394 |
Post Options
Quote Reply
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).
|
|
|
|
|
Linguinut
Senior Member
Joined: 14-Jun-2007 Location: United States Posts: 394 |
Post Options
Quote Reply
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?
|
|
|
|
|
Bill Jensen
IdeaBlade
Joined: 31-Jul-2007 Location: United States Posts: 229 |
Post Options
Quote Reply
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 contextcontext.Callback = new MyViewContext.MyCallbackType(callback);} // Called by presenter via delegate when new data available. Must have delegate's signatureprivate 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 delegatemContext.CallBack(data); } } |
|
|
|
|
Linguinut
Senior Member
Joined: 14-Jun-2007 Location: United States Posts: 394 |
Post Options
Quote Reply
Posted: 29-Oct-2007 at 10:23am |
|
|
|
Linguinut
Senior Member
Joined: 14-Jun-2007 Location: United States Posts: 394 |
Post Options
Quote Reply
Posted: 27-Oct-2007 at 11:49am |
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 |
|
|
|
|
Linguinut
Senior Member
Joined: 14-Jun-2007 Location: United States Posts: 394 |
Post Options
Quote Reply
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!!
|
|
|
|
|
Bill Jensen
IdeaBlade
Joined: 31-Jul-2007 Location: United States Posts: 229 |
Post Options
Quote Reply
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.
|
|
|
|
|
Linguinut
Senior Member
Joined: 14-Jun-2007 Location: United States Posts: 394 |
Post Options
Quote Reply
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 |
|
|
|
|
Post Reply
|
| Forum Jump | Forum Permissions You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum |