View Injection Quickstart

Topics: Prism v2 - Silverlight 3
Sep 16, 2009 at 7:00 PM
Edited Sep 17, 2009 at 3:11 PM

I've been working my way through the quickstarts and have a few questions about the View Injection Quickstart:

1) The Initialize method of the EmployeeModule registers the view with the following code:

  public void Initialize()
        {
            this.RegisterViewsAndServices();
            EmployeesPresenter presenter = this.container.Resolve<EmployeesPresenter>();
            IRegion mainRegion = this.regionManager.Regions[RegionNames.MainRegion];
            mainRegion.Add(presenter.View);
        }

How is that different than

public void Initialize()
{
this.RegisterViewsAndServices();
this.regionManager.RegisterViewWithRegion("MainRegion",typeof(EmployeeView));
}

2) The QuickStart creates a separate instance of an EmployeeDetails view for every employee, rather than a single instance which refreshes its data context.  Is storing the viewing in the local regionManager the best practice?  I would think it would bloat the footprint overtime.  Please advise.

 3) In the Silverlight version of the quickstart, the tab for Current Projects has no title in the tab, even though the ProjectListPresentationModel implements the HeaderInfo property.  The EmployeesDetailView defines the TabControl, and has a RegionAdapter defined to bind the header template to the model's HeaderInfo property.  I've noticed the Header text is set explictly in the xaml for the "General" tab.   I can bind a textblock to the headerinfo property and see the value, but it isn't getting picked up by the Tab Adapter.

 Thank you.

 

Sep 17, 2009 at 3:17 PM

The same problem is present in the View Discovery Quickstart.

Sep 17, 2009 at 4:49 PM

Issue 3) is actually a Silverlight 3 problem - blogged about HERE

Issue 1) The difference is that in the first code snippet the Presenter resolves the View and in the second I can only assume the View will instantiate the presenter.

Issue 2) I trust this would be dependent on the story/use case requirements.   Like you I would lean towards a single instance however if I needed to be able to work with multiple employees, with some sort of optimistic concurrency, separate instances would make managing state a wee bit easier.