|
![RSS Feed: [COMPLETED] Widget View Template](forum_images/rss.png "RSS Feed: [COMPLETED] Widget View Template")
[COMPLETED] Widget View Template |
Post Reply 
|
Page 123 4> |
| 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
|
Linguinut 
Senior Member 
Joined: 14-Jun-2007 Location: United States Posts: 394 |
 Post Options
 Quote Reply
 Topic: [COMPLETED] Widget View TemplatePosted: 29-Sep-2007 at 10:36am |
|
Hey Dan,
Certainly. I am leaving for the day, so Monday I will try to put something together as a summary of this widget view creation.
Have a good weekend!
Bill
|
|
 |
|
|
orcities
Senior Member
Joined: 28-Aug-2007 Location: United States Posts: 454 |
Post Options
Quote Reply
Posted: 29-Sep-2007 at 10:32am |
|
Can you supply your final findings and paths to final product. This thread was rather long and hard to keep track of what exactly was going on.
|
|
|
|
|
Linguinut
Senior Member
Joined: 14-Jun-2007 Location: United States Posts: 394 |
Post Options
Quote Reply
Posted: 28-Sep-2007 at 4:53pm |
|
Thanks for all of your help, Bill. I am going to end this thread. It is a bit long. And, I think I can pursue other questions separately, now. The new widget control view works quite well.
|
|
|
|
|
Bill Jensen
IdeaBlade 
Joined: 31-Jul-2007 Location: United States Posts: 229 |
Post Options
Quote Reply
Posted: 27-Sep-2007 at 3:45pm |
|
Yeah, that sounds reasonable. It'll probably be generic <boundType>. Be sure to follow the template pattern so a specific TabViewController can override the Add, Delete and Edit methods.
Bill J.
|
|
|
|
|
Linguinut
Senior Member
Joined: 14-Jun-2007 Location: United States Posts: 394 |
Post Options
Quote Reply
Posted: 27-Sep-2007 at 2:10pm |
|
I should create a new ControlViewTabViewController in the IdeaBlade.Cab.UI project under the TabViewController folder. When I add a new control view to a tab controller, I would just add the view using this controller. What I am trying not to do is have to create all of that add/edit/delete code every time I add a new view.
Please let me know if there are any gotchas for doing it this way. Edited by Linguinut - 27-Sep-2007 at 2:11pm |
|
|
|
|
Bill Jensen
IdeaBlade
Joined: 31-Jul-2007 Location: United States Posts: 229 |
Post Options
Quote Reply
Posted: 27-Sep-2007 at 1:55pm |
|
Sorry, you have to provide the handlers to add, edit or delete objects. In MasterDetailTabViewController (in IdeaBlade.Cab.UI), look at the method
ConfigureMasterViewContext()
You'll need to create handlers and register commands in much the same way in your ContactViewTabViewController. Just walk thru the code to see how it's done.
The point of the command pattern is to decouple the source of the command's firing (button, menu item) from the actual command processing. The view controller is where you "know" about how to create, edit and delete elements of your data mode. You don't want to couple the general-purpose presenter or the ToolStripAdapter to this information.
Bill J.
|
|
|
|
|
Linguinut
Senior Member
Joined: 14-Jun-2007 Location: United States Posts: 394 |
Post Options
Quote Reply
Posted: 27-Sep-2007 at 1:35pm |
|
From what I can tell, I would have to implement the actual add/save/delete calls (EntityManager.SaveAll(), or something like that). This kind of thing should already be wrapped up above this toolbar somewhere and accessible to it. I do not want to rewrite any of the code found in the MasterDetailTabViewController. Shouldn't it have "bubbled up" someplace else, already? Well, I hope Ward can come to the rescue and point the way on this. I do want to duplicate code unnecessarily. If the wheel has already been created...
|
|
|
|
|
Linguinut
Senior Member
Joined: 14-Jun-2007 Location: United States Posts: 394 |
Post Options
Quote Reply
Posted: 27-Sep-2007 at 12:05pm |
|
Here is the method in the DotNetNavigatorControlViewToolStripAdapter:
protected void AddButtonToControlViewToolStrip(ToolStripButton pButton, string pCommandRootName, bool pHideIfNoCommandHandler) { string commandName = ViewContext.MakeViewSpecificId(pCommandRootName); ControlViewToolStripSite.Add(pButton); CabWinFormFns.AddCommandToButton(WorkItem, pButton, commandName); if ( pHideIfNoCommandHandler ) { CabFns.ResetStatusIfNoHandlers(WorkItem, commandName, CommandStatus.Unavailable); } } What if I added the following into the above code?
CabFns.RegisterCommandHandler(WorkItem, commandName, pButton.Click);
Bill
Note: pButton.Click cannot be used as the EventHandler passed in the argument. The eventhandler must be presented another way. Edited by Linguinut - 27-Sep-2007 at 12:09pm |
|
|
|
|
Bill Jensen
IdeaBlade
Joined: 31-Jul-2007 Location: United States Posts: 229 |
Post Options
Quote Reply
Posted: 27-Sep-2007 at 11:12am |
|
In the DotNetGridViewToolStripAdapter (and presumably your ControlView version), the method AddButtonToGridViewToolStrip() contains the code: if ( pHideIfNoCommandHandler ) { CabFns.ResetStatusIfNoHandlers(WorkItem, commandName, CommandStatus.Unavailable);Basically this hides the button if its attached command doesn't have a handler registered.
The ToolStripAdapter (and in fact the presenter that owns it) doesn't care what happens when a button is clicked--it merely sets up a command (with a name that includes the unique ViewId) and fires it.
The handler for the command must be registered somewhere. It remains a mystery to me where this is done for the detail grid view case. However, the MasterDetailTabViewController contains this function:
/// <summary>Register CommandHandler for a Command on the detail view.</summary>
/// <param name="pCommandRootName">The root name of the CommandName to make (e.g., "Edit").</param>
/// <param name="pHandler">CommandHandler of this command.</param>
protected void RegisterDetailCommandHandler(string pCommandRootName, EventHandler pHandler) {
string commandName = mDetailViewContext.MakeViewSpecificId(pCommandRootName);
CabFns.RegisterCommandHandler(WorkItem, commandName, pHandler);
} I can't find any invocations of this method, but at least it shows you how to register a command handler. You'll need to register handlers for the button events (probably in your ContactViewTabController). I'll try to get some more information out of Ward.
Bill J. |
|
|
|
|
Linguinut
Senior Member
Joined: 14-Jun-2007 Location: United States Posts: 394 |
Post Options
Quote Reply
Posted: 27-Sep-2007 at 10:55am |
|
I much appreciate the quick refresher. I wanted to make sure that my thinking was straight on these issues. Thanks.
Btw, I am going to start a new thread regarding the toolbar buttons.
|
|
|
|
|
Linguinut
Senior Member
Joined: 14-Jun-2007 Location: United States Posts: 394 |
Post Options
Quote Reply
Posted: 27-Sep-2007 at 10:54am |
|
I created a DotNet Grid View and added it to the customer tab controller. No toolbar is displayed, so I cannot even tell if the buttons will show up.
Bill, can you verify that the add/edit/delete buttons, in fact, do show up on a DotNet Grid View?
Thanks!
|
|
|
|
|
Bill Jensen
IdeaBlade
Joined: 31-Jul-2007 Location: United States Posts: 229 |
Post Options
Quote Reply
Posted: 27-Sep-2007 at 10:19am |
|
A quick refresher on object-oriented 101, C# style:
The ControlViewToolStripAdapter has a protected virtual method defined called AddToControlViewToolStrip.
Correct. It has an empty body. The virtual declaration indicates that a child class may provide a non-empty implementation. The protected modifier merely restricts the visibility to the base and child classes. A virtual method can be public or internal, but private virtual doesn't make any sense.
The class DotNetNavigatorControlViewToolStripAdapter is derived from ControlViewToolStripAdapter; therefore, has the implementation of the AddToControlViewToolStrip method.
Correct, though it doesn't have to provide an implementation, since an empty implementation is provided in the base class. If it were marked abstract in the base class, the child class would be required provide an implementation.
When a call is made to ControlViewToolStripAdapter.Configure, the method AddToControlViewToolStrip is called. This is where I get confused. The abstract class then calls the concrete class to run the method defined there? Is that right?
Yes, that's the meaning of the override modifer on a method; when the method is invoked, the implementation in the overriding method is called, even if the invoker thinks it is holding a reference to an instance of the base class.
Does the protected virtual designation make a difference over the protected abstract designation?
Does this clarify things?
Bill J.
|
|
|
|
|
Linguinut
Senior Member
Joined: 14-Jun-2007 Location: United States Posts: 394 |
Post Options
Quote Reply
Posted: 27-Sep-2007 at 10:12am |
|
I can walk the code. Btw, I changed the virtual tag to abstract, then back to virtual--the code does the same thing either way. The call is being made to the concrete class (as expected). The buttons are being built. But they are not showing up on the toolbar. The UIExtensionSite looks like it is being registered properly. The buttons are being added to that defined site. Nothing is showing up. This remains a mystery.
|
|
|
|
|
Linguinut
Senior Member
Joined: 14-Jun-2007 Location: United States Posts: 394 |
Post Options
Quote Reply
Posted: 27-Sep-2007 at 8:15am |
Slowly wrapping my brain around this.
The ControlViewToolStripAdapter has a protected virtual method defined called AddToControlViewToolStrip. The class DotNetNavigatorControlViewToolStripAdapter is derived from ControlViewToolStripAdapter; therefore, has the implementation of the AddToControlViewToolStrip method. When a call is made to ControlViewToolStripAdapter.Configure, the method AddToControlViewToolStrip is called. This is where I get confused. The abstract class then calls the concrete class to run the method defined there? Is that right? Does the protected virtual designation make a difference over the protected abstract designation?
Thanks. Edited by Linguinut - 27-Sep-2007 at 8:51am |
|
|
|
|
Linguinut
Senior Member
Joined: 14-Jun-2007 Location: United States Posts: 394 |
Post Options
Quote Reply
Posted: 27-Sep-2007 at 5:33am |
|
Hey Bill,
No problem with your posting frequency. I am glad whenever you can offer help. I do wish that there were more of us out here, though.
This is getting to be a long thread; however, it is all related to my desire to create the control view widget with a toolbar. I am at the very final stages of this journey.
Thanks a bunch for the bird's eye overview of the adapter classes. I will work through this for understanding. Unfortunately, the classic template is a relatively new animal for me. I am still doing a lot of catch-up reading to get more acquainted.
Thanks, again. I'll update here when I get more answers or have more questions regarding this.
Bill Edited by Linguinut - 27-Sep-2007 at 8:57am |
|
|
|
|
Bill Jensen
IdeaBlade
Joined: 31-Jul-2007 Location: United States Posts: 229 |
Post Options
Quote Reply
Posted: 26-Sep-2007 at 4:20pm |
|
Sorry not to post sooner today--I've been out for some appointments and errands. You've got a couple of things going in this thread which has become rather long. At some point we should close this thread and start a couple of new ones.
Anyway, to address your most recent post:
First, the tool strip adapter is implemented as a classic template pattern:
GridViewToolStripAdapter is an abstract template class that delegates its implementation details to a concrete implementation class. It always looks the same to its client class, GridView (or more precisely, GridViewPresenterBase). In this case, Ward has provided only one concrete implementation: DotNetGridViewToolStripAdapter.
Second, the template pattern is extremely common and occurs again:
GridViewPresenterBase is itself an abstract template that delegates its implementation to concrete classes, two in this case: DotNetGridViewPresenter and DevExGridViewPresenter.
Once the view context is set, the OnContextSet() method configures the grid view. One of the steps is to invoke SetGridViewToolStripAdapter() that delegates to the concrete implementation of SetGridViewToolStripAdapterCore() which creates a new DotNetGridViewToolStripAdapter, passing the tool strip object itself, the binding source and the view context.
Immediately after calling SetGridViewToolStripAdapter(), GridViewPresenterBase calls its Configure() method. Among other things, Configure() invokes AddToGridViewToolStrip() which is again delegated to the concrete implementation.
Your ControlView-based versions of these classes should work in exactly the the same way.
N.B.: The GridViewToolStripAdapter and DotNetGridViewToolStripAdapter classes have "GridView" appearing all over the place. On closer examination however, almost all of these are just class, member and variable names.
The only real dependency is on the view context being a GridViewContextBase and even that is only used to provide three items:
The binding source (actually available from the base BindingViewContextBase class)
The GridViewToolStripVisible flag.
and
The GridViewToolStripChanged event.
These last two could be made optional by moving them to an interface, IGridViewToolStripContext, then having GridViewToolStripAdapter check if the view context implements this interface and hook them up if so.
Once that's done, the dependency on GridView (and ControlView, in your case) could be eliminated and it becomes possible to add a tool strip to any binding view. If there were a BindingViewPresenterBase class (there isn't) we could move the logic there but for now, we can just leave it in our specific base presenter classes.
This kind of refactoring is constant in a framework like Cabana. We start with specific implementations for initial use cases (i.e., GridView tool strips in this case), then, rather than duplicating code, refactor to a more abstract implementation to cover more use cases. In the process we eliminate dependencies and increase reusability.
My battery is going dead...gotta post this.
Hope this helps.
Bill J.
|
|
|
|
|
Post Reply
|
Page 123 4> |
| 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 |