Prism 4.0 Feedback Needed

Coordinator
Jan 15, 2010 at 6:27 PM

Now that the new year is hear, there are lots of questions regarding Prism 4.0 - schedule and capability. I am starting this thread to get feedback on the next release.

Schedule: Early Spring through Summer. Note: Yes this is vague as we will get started as soon as we finish Web Client Guidance Project.

Features / Capabilities: We are considering the following for the release - ViewModel pattern, navigation, out of browser applications, developer/designer workflow, user experience patterns, visual studio templates, and a whole host of other areas. We need feedback on this list so please let us know your thoughts using this thread. In February, I will put together a feature survey that I will ask you to take to help us pick the actual scope for Prism 4.0. The survey will be based upon this discussion thread and feedback we heard from customers. Once the survey is available, I will announce the survey on my blog: http://blogs.msdn.com/blaine so check it out.

We will use the results of the survey to create the vision/scope for the project and then get started. The will be a fun release. The hard part will be picking what is in the release because there are lots of things to cover - so we need your help :).

Blaine Wastell

Program Manager p&p Client Program

 

Jan 15, 2010 at 8:40 PM

Can we get both .NET 3.5 and 4 in this release. I'd like to move to 4 but I want to be able to do it between Prism releases.

Jan 15, 2010 at 10:57 PM

When you say "ViewModel pattern" what are you referring to, specifically? I'd love to see the following:

  • Some mechanism or behavior for binding viewmodels with dependencies, i.e. being able to bind a view model with constructor-injected or tagged property dependencies and have the IoC instantiate it and wire up the dependencies
  • Strongly typed regions
  • Definitely navigation that fully supports dynamic module loading triggered by a navigation ... perhaps an extension to the navigation definition (attached behavior) that attributes the path with the module name so PRISM knows to load that module when the navigation happens
  • RegionAdapter for grids
  • Multicontrol adapter that can handle multiple views becoming visible/invisible through the VisualStateManager (i.e. can I raise some navigation event such that if I have several views, the target view goes to a visible viewstate and the views that aren't the target go to a hidden viewstate)

Those are the top wishes I have based on what I've had to manually wire up to support this. Looking forward to the release!

Jan 17, 2010 at 1:21 AM

Definitely looking for the integration story with MEF and a best practices approach for using both Prism and MEF to create modular, extensible apps.  Also, more information on the 'ViewModel' pattern would help to cast more votes in that direction. :)

Jan 18, 2010 at 3:11 AM

I would like to see some of the work provided in the WPF Composite Contrib and Calcium migrated to Prism 4.0

In particuliar

Calcium did a log of work on extending the GetModuleCatalog()

Add dialog workspace support out of the box and some others from the Contrib

Auto wiring of MVVM out of the box with BindableObject support in some form of base class.

DispatchedObservableCollection from WPFExtensions to help with threading issues ( WPFExtensions)

These would be my wishes

 

 

Jan 18, 2010 at 6:30 AM

Some things I'd like to see:

  • Better support for bootstrapping with alternative IOC containers. The use of Unity "resolve anything" feature makes it very difficult to use a custom container. Ward Bell's post could be used as a starting point here. 
  • A non-generic DelegateCommand with no parameters - e.g., new DelegateCommand(() => DoSomething(..));
  • A signed binaries release, so third party libraries that extend prism can also be signed
  • Some kind of IEventAggregator.UnsubscribeAll(target); which deletes all subscriptions by the target object - makes it much easier to ensure a view model/presenter is cleaned up
  • Easier ability to make views aware of regions - e.g., a view can implement an interface to be notified when it is activated, deactivated, becomes the selected view, is closing/closed (if the region supports closing), ability to throw up "are you sure" dialogs, etc.

The WPF team have already released an MVVM template - what would a Prism MVVM class add to that?

Jan 18, 2010 at 6:55 AM
Edited Jan 18, 2010 at 6:57 AM

"evanhutnick: Definitely looking for the integration story with MEF and a best practices approach for using both Prism and MEF" ...

My vote for that, as well :)

Jan 18, 2010 at 4:39 PM

Eliminate the Get/Act Pattern

I would like to see the Get/Act pattern for IRegionManager and EventAggregator eliminated.  It makes testing much more difficult than it needs to be.  The extension method wrapper for AddViewToRegion almost needs to be avoided to make things work well.  In tests we are forced to build up a full Regionmanager instance versus any mocking, which isn't terrible in-and-of itself, but its dirty.

The Get/Act pattern that shows up forces you to Setup the root with a Stub/Mock instance of the thing to be acted upon which reduces the readability of the tests.

Resolve MarkupExtension

I'd like to see a ResolveMarkupExtension in Prism.  You can more easily create isolated components or features for your application by Resolving ICommand instances (over hooking the command up through some arbitrary ViewModel or Presenter).

IRemovedFromRegionAware

The name is a bit facetious, but support for a view being notified when it is removed from a region would allow for Unregistering events and CompositeCommands much the same way we Activate/Deactivated when a view IsActive changes.

Jan 19, 2010 at 8:30 AM

At now it's difficult completely separate  the design of UI (how to display the model) from the writing of viewmodel (what to presenter of the model and how to manage the model itself) because the region dependency is between the two worlds.

It's can define the region subdivision in xaml of the views, but I have to specify in the module's code in witch region register a view, but I think it's more appropriate define in the view's properties in witch region insert itself. So, I define the view, specified the name of the region in witch register it (by an attached property or something else), specified the viewmodel/presenter interface to link the DataContext of the view (by constructor argument, but I prefer an attribute solution), in this way who design the UI is completely independent from whom is writing the viewmodel.

With this feature when I write the viewmodel I can think only to the presenting the model and business by delegate command, demands the region subdivision to UI's programmers. I think it's fundamental that in the UI there is less code behind as possible, in particular relative to the prism mechanism, for me it is optimum when I can completely write the UI by tools like Blend.

Jan 19, 2010 at 12:15 PM

1.  Get the story for the MEF and PRISM integration down pat.  Is it going to replace Unity, Is it going to replace the Module Loader,  or Both.  Do the intergration and then have a story for each model and provide quick starts for them/it.

2. A lot of the requests above seem to want to couple views to Regions. IMO that is a bad thing.  Views should remain region agnostic.  They should have an interface that allows them to know when they are added, and removed, and activated, but other than that, they should not know the region they are going to be in until they are placed in it.  That IMO is the module or controllers responsibility.

3. Keep .net 3.5 and 4.0 support in this version.

4. Add Rx extensions where appropriate.  Things like the Event Aggregator could be Rx enabled.  It is close now, but moving to the Rx mindset would be nice.

5. Add more quickstarts that show extensibility ( remote and role based module loading, etc.  )

6. Provide some Visual Studio helpers ( Dont go the level of the SCSF stuff to provide whole subsystems, but some simple templates would be nice )

7. Keep it light weight.  Dont become SCSF 2.  Use the Quick Starts to show best practices, but dont bloat the core with stuff that most dont need. 

8. Provide some more region adapters.  As things are added to the WPF Toolkit and Silverlight Toolkit, make sure that there are adapters for them in Prism.  Provide a Region adapter for the Ribbon Control. 

9. Provide more quickstarts which show where and how to add Authentication and Role based solutions. 

10.  Provide a quickstart that shows asynchronous services. 

11.  Show Integration with RIA Services and WCF Data Services. 

12.  Because this is meant to be the Enterprise Pattern to use, provide more quickstarts that show your ideas for how best to integrate the other enterprise level tools that MS provides. 

13. Do not be scared to show quick starts that take advantage of the platform they are meant to run on.   Do some WPF specific quickstarts, and some Silverlight specific quickstarts.  They dont all have to run on both environments.   Let some WPF ones use 3D or Multi-Process, or local Storage.  Strut the capabilities of each envirionment.  Dont always program to the lowest common denominator.

Jan 27, 2010 at 1:57 PM

Keeping this thread alive.

 

Jan 28, 2010 at 8:06 AM
pmont wrote:

2. A lot of the requests above seem to want to couple views to Regions. IMO that is a bad thing.  Views should remain region agnostic.  They should have an interface that allows them to know when they are added, and removed, and activated, but other than that, they should not know the region they are going to be in until they are placed in it.  That IMO is the module or controllers responsibility.

I agree with the point, but I have an exception: what about if I would offer to the customer the possibility to completely customize the UI? I explain better: I make an application, I develop the all the presenters with their interfaces, so I realize a first kind of UI with my region definition, where to insert  the views, and so on. The main value of the product is the business logic and the scalable architecture, so I decide to offer the possibility to ISV customer (or some kind of distributor with programming capability) to redesign the UI by its own, only to know the philosophy of Prism's region subdivision and the interfaces of all presenters. Another scenario is the situation where presenter/business team developers have to work completely independent from the UI team developers: the first team doesn't want to know anything about interface, just the interface of presenter, and the module/service to implement.

IMO, in this kind of scenario is essentially to couple views to Regions, in this situation the region subdivision and  behaviour is part of UI design and not presenting the model.

Jan 28, 2010 at 8:15 AM

I have another suggestion for the code sample:

- a floating/pop-up region to view a keyboard, it regroups more aspect about region behaviour in a useful tool for touch application.

Some one could adding the capability to pop-up the keyboard when the focus is on a entry field by an event aggregator, defining an attached property to use in xmal ,... but tih is another story ^__-

 

Jan 28, 2010 at 3:09 PM
Edited Jan 28, 2010 at 3:18 PM

The requirements you stated, could be solved in several ways.

If you want to use attributes, you could create some custom attributes that allow your views to specify the region they want to be in.  Then let the Module those views are in, read those attributes and place them into the proper region.  That way, you have control over what flexibility the "users" have.  They dont have full access to all of the regions.  Only the ones you surface in the attributes.  That way it could be "typed" to the user.

If you are in a free for all situation, and the user has the ability to code, then you have no control over the number and form of the reqions, so let them write the modules too and make your presenter code just something that they use. 

But the ability to have a view be able to specify a region sounds to me more like an app specific thing. 

Paul

 

Jan 28, 2010 at 4:15 PM

For developing LoB apps in Silverlight, it's essential to use WCF RIA Services. Please be sure Prism 4, MEF and RIA are considered to work seamlessly from the beginning and does not become an after-thought solution. Any large apps will be doing lots of database related activities, and Prism and MEF should see that as the core of any apps. Another words, give us a way to build LARGE modular apps with SL and RIA.

 

Thank you in advance!

Jan 29, 2010 at 1:16 PM

Another item.

MS has been horrible with a story for Inter-Process communication in a fashion that is as robust as the Aggregator or Mediator pattern in CAL.  Yes there are named pipes, but it would be nice if CAL could lead the way to a true pub/sub IPC mechanism between CAL processes.  Extend the Aggregator to be cross process.  Keep it limited to the same box for now, but a robust IPC mechanism would be very welcome.

Just a thought

Paul

Jan 29, 2010 at 1:30 PM
pmont wrote:

MS has been horrible with a story for Inter-Process communication in a fashion that is as robust as the Aggregator or Mediator pattern in CAL.

 

'Robust' might not be the best term here.  WCF is certainly robust.  It's also gotten easier and easier to implement.  As for a smooth pub/sub model that is as simple as the EventAggregator (Get/Act pattern aside) you might be on to something there.  Looking to something like NServiceBus or Agatha as a model for this might generate an interesting UberAggregator experience.

It might be pushing the charter of the Prism toolset to include this though.

Jan 29, 2010 at 1:54 PM
Edited Jan 29, 2010 at 2:01 PM

your term is a better one.  <grin>

But something that extended the Aggregator Pattern into an interprocess model ( CAL apps only ) would be a welcome addition IMO.  Like I said, keep it inside the box for now.  Under the covers it should use WCF, with whatever channels make sense.  The "messages" would have to be in a shared dll, but arent they always for anything other than strings or xml between processes?  And we are talking about an app "family" that would be using this comm, so shared dll's would be expected.  Pub/Sub with the abiility of multiple processes to join in the fun.  An inside the box peer to peer CAL app network.

 I am not familiar with Agatha, do you have a link?

And BTW, I am positive that where I work ( a large, large financial company ) they would welcome this addition and put it to use very quickly.

 

Jan 29, 2010 at 2:03 PM

I do really like the idea of extending the EventAggregator to support pub/sub across processes.

Agatha: http://code.google.com/p/agatha-rrsl/ & http://davybrion.com/blog/category/agatha/

From: pmont [mailto:notifications@codeplex.com]
Sent: Friday, January 29, 2010 9:55 AM
To: cromwellryan@hotmail.com
Subject: Re: Prism 4.0 Feedback Needed [CompositeWPF:80980]

From: pmont

your term is a better one. <grin>

But something that extended the Aggregator Pattern into an interprocess model ( CAL apps only ) would be a welcome addition IMO. Like I said, keep it inside the box for now. Under the covers it should use WCF, with whatever channels make sense. The "messages" would have to be in a shared dll, but arent they always for anything other than strings or xml between processes? And we are talking about an app "family" that would be using this comm, so shared dll's would be expected. Pub/Sub with the abiility of multiple processes to join in the fun. An inside the box peer to peer CAL app network.

I am not familiar with Agatha, do you have a link?

Read the full discussion online.

To add a post to this discussion, reply to this email (CompositeWPF@discussions.codeplex.com)

To start a new discussion for this project, email CompositeWPF@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com

Feb 1, 2010 at 10:33 AM

A recommended infrastructure for hooking up UI to commands with more state than enabled/disabled would be nice.

E.g. Buttons/MenuItems that toggle an option on or off.

I've seen this done with bindings to the command parameter, but it would be nice to have something included in Prism, with samples.

Feb 1, 2010 at 12:51 PM
Edited Feb 1, 2010 at 12:53 PM
swythan wrote:

A recommended infrastructure for hooking up UI to commands with more state than enabled/disabled would be nice.

E.g. Buttons/MenuItems that toggle an option on or off.

I've seen this done with bindings to the command parameter, but it would be nice to have something included in Prism, with samples.

Are you thinking along the lines of a Split button or a Ribbon where Groups/Tabs are dynamically added and removed?  Something like a Menu Registry?

Feb 2, 2010 at 1:56 PM

No, more like menus with a checkmark (or toggle buttons on a toolbar). E.g. In a rich text editor, you would usually want a "Bold" toggle button on a toolbar that toggles it's state depending on whether the selected text is bold or not.

We have similar requirements (although in an entirely different context) for commands that modify some sort of state, that should be reflected in the UI that is bound to the command.

TBH, I don't know if this sort of thing really falls into the Prism remit, but it would be useful to get some guidance from somewhere.

Feb 2, 2010 at 3:32 PM

I hear you.  This is definitely possible today, but there is little guidance or samples.  Remember, you can use most Ribbon controls as standard Regions.

Feb 4, 2010 at 1:57 PM

I have recently found a framework called nRoute (http://nroute.codeplex.com/) which is IMHO awsome. Though it is in an early stage it may be worth considering several of its concepts for Prism 4.0.

Feb 8, 2010 at 7:20 PM

Hi guys,

1. Improve dynamic modules

  • Shoud support shared styles and other resources. Currently it is not possible because Silverlight try load all styles and if module doesn't have reference to assembly related to style it will fail to load. Currently we implemented it by try catching all styles one by one when new module is loaded.
  • Modules should share common assemblies. Example: Module A depend on assembly x and Module B depend on assembly x. In this if module B is loaded after A it shouldn't load assembly x. Currently we have implemeted it by manual parsing of extmap section in appmanifest

2. Built in integration with MEF

3. Replace all internal logic and public apis with Rx.

4. Silverlight Page Framework is total garbage. Don't try to integrate with it =) Provide some kind of application controller which will build up UI for "use case" or "page". Also it should be integrated with browser history.

5. Commands should be attached with Expression Blend interaction APIs. Currently PRISM require to create thousand attached property for every new invoker different from Button Click. Example: EventTrigger with InvokeDelegateCommandAction. Currently eventtrigger has some hidden traps and you should rewrite it a bit.

6. Some view model helpers? I know there is thousands of projects that try to provide a solution in this area. Perhaps it could include some way to automate creating of ViewModels with tools like Castle Dynamic Proxy 2. Automappers?

7. Validation Framework. Currently build-in validation framework is rather poor. I think it should be based on fluent interfaces instead of attribute based approach.

Our team has 1 year experience in developing of our interal Silverlight Application Framework firstly based on Prism ideas.

We are ready to help and collaborate if needed.

You can contact me through my blog: http://weblogs.asp.net/AlexeyZakharov/

Best regards,

Alexey Zakharov.

Feb 9, 2010 at 8:30 AM

+1 for a better validation framework. WPF's built in support is very poor.

Feb 9, 2010 at 6:55 PM

1. Deployment - For once I'll like to start from the end.

There are no good deployment tools today for application built with CAL (or any application that is not statically built), not as packaged installation and not with ClickOnce.

I'm using a home made msbuild project that take my host, collect all the modules and package them with ClickOnce.

I'm looking for more straight forward deployment project which can have multiple configuration like dev, test, prod, customer1023, customer5. Each configuration will contain manifest of modules require to be package as well as configuration (app.config) file.

For ClickOnce deployment version (not assembly) tracking is also important.

 

2. Navigation

I think navigation should be integral part of ViewModel pattern.

* "web site" navigation style with back and forward. This pattern should allow to open more than one host window since most users find it more productive to open two (or more) windows and watch what they want at the same time, not having to navigation between windows.

* Dialog boxes - Show a dialog box which does not allow the application to continue until closed.

In ViewModel pattern sometime I use a UserControl as the View and sometime I use DataTemplate as the View. In the first case the navigation services should be available to both the ViewModel and the UserControl. In the second case the navigation service should be available to the ViewModel only. It means there must be different ways to get hold of the navigation services. Remember that if we allow more than once host window we cannot use singleton navigation service instance.

3. Toolbar and Context Menus.

Say I have a screen that display grid of objects that can be created, modified and delete.

How can we standardize the way we create and bind commands to toolbar items and context menu items.

4. Event Aggregation - I think the implementation is great. The fact that the event itself define the registrations and execution strategy is interesting.

5. One Stop Shop for unhandled Exceptions

I think it can be nice to create service which will handle all unhandled exceptions in the application. Allow to save the exception details to local file, maybe send it with email and show the client a nice "oops, something went wrong" window.

 

Look this project and keep up the great work.

Ido.

Feb 9, 2010 at 7:28 PM

I just like to add one import thing: User State.

By that I mean a way to store and retrieve the state in which the user leave the application on the last run.

* Size and location of the host window

* width and height of grid splitters

* Selected data in list and combo box (where applicable)

 

There are some great implementation around that use attached properties to set the UI state directly in XAML but there should be way to add state programmatically for state that is not UI directly.

If we link it to ViewModel pattern then the state of the ViewModel should be restore as well as the view state.

 

The user of provider pattern can help make the persistence details transparent to allow different providers such as local file, isolated storage (for web applications), central database, etc.

 

Ido. 

Feb 11, 2010 at 6:47 PM
Edited Feb 11, 2010 at 6:50 PM

Allow view discovery to use scoped regions.  For example, with code like this:

this.RegionManager.RegisterViewWithRegion("MainRegion", typeof(ReportsView));

I would like ReportsView to have a region scope, so that it can register a common-name region for its sub-views: 

<ContentControl regions:RegionManager.RegionName="VeryCommon" />

Feb 11, 2010 at 6:59 PM

I would also like to be able to register the type of my view-model with a view and a region, so that a command would instanciate the view-model and actually ask the region manager to "open" the view-model, while being agnostic of which view(s) in which region(s) will display the view-model.

Feb 11, 2010 at 7:00 PM

invertedrider66,

Can you stub out what you are envisioning, I’m not following what you are asking for.

From: invertedrider66 [mailto:notifications@codeplex.com]
Sent: Thursday, February 11, 2010 2:59 PM
To: cromwellryan@hotmail.com
Subject: Re: Prism 4.0 Feedback Needed [CompositeWPF:80980]

From: invertedrider66

I would also like to be able to register the type of my view-model with a view and a region, so that a command would instanciate the view-model and actually ask the region manager to "open" the view-model, while being agnostic of which view(s) in which region(s) will display the view-model.

Read the full discussion online.

To add a post to this discussion, reply to this email (CompositeWPF@discussions.codeplex.com)

To start a new discussion for this project, email CompositeWPF@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com

Feb 11, 2010 at 7:35 PM
Edited Feb 11, 2010 at 7:37 PM

Yeah, sure

 

Ok, suppose I have a command that gets data from the outside world.  Suppose it gets a Person.  The command is meant to display that Person on the screen.  Generally, the command would be exposed by a view-model and on that view-model, there’s a Person property bound to the UI.  When the call returns, that property would be assigned, firing the PropertyChanged event of the view-model, and the UI would refresh, displaying the Person.

 

That’s in most of the cases.  Now, suppose the command is not exposed by a view-model instance and is unable to directly interact with an instance of a view-model that’s bound to the UI.  The command is floating somewhere and it has no view-model to update with the Person it gets from the outside world.  I guess you would tell me that in this case, my command would use the event aggregator to raise the fact that the Person is now available to be shown, and some view-model somewhere would grab the event, assign its property, and raise PropertyChanged which would display the Person on the UI.

 

What I would like is to formalize this process; when a chunk of data is available (the Person instance in this case), I would like to be able to instanciate a view-model – in fact, a better approach would be to register a view-model type to a data type (PersonViewModel to Person) – and ask the framework to find any view registered with that type of view-model and push the view-model into that (those) view(s).

 

J  I wonder if that’s clear…

 

 

dave.

 

 

Feb 12, 2010 at 1:12 AM
Edited Feb 12, 2010 at 1:24 AM
mkane91301 wrote:

Can we get both .NET 3.5 and 4 in this release. I'd like to move to 4 but I want to be able to do it between Prism releases.

 If all you want to do is work with CAL (Prism) in Visual Studio 2010 using .NET 4.0 then you can download a converted build of the latest P&P drop from The Composure Site.

I started this project two months ago to provide lightly modified builds of popular open-source frameworks for those who want to start working with the new platform right away. There are a number of other builds there that may also be of interest to you.

BTW: There are two builds hosted on Composure for CompositeWPF: one for Silverlight 3 and another for Silverlight 4. Both of them are built against .NET 4.0 in VS2010 Beta 2. ALL of the desktop tests pass except for 2 related to type identification in certain inheritance scenarios. I have not yet had a chance to review all of the tests for SL4, so keep that in mind and run them yourself if you want to make sure everything is working correctly.

Cheers,

Ben 

Feb 12, 2010 at 3:27 PM

The latest prism is a great platform. Having been following this stuff since CAB on WPF I would have to say the pain points of devloping composite WPF applications are:

  • Input binding support (I think fixed in .NET 4)
  • Design time experiance with DataTemplates (really a Visual Studio or Blend team problem). Ie I just want to register DataTemplates that target my ViewModels. This allows me to not have to write UserCcontrols and thus keeping my coverage high. Then I just add ViewModels to regions and WPF just figures the rest out. (sucks that Silverlight cant do this).
  • Building Responsive UIs. This required a lot for Threading and dispatcher knowledge which was overkill for most devs. Rx solves this pretty much in one API. Love Rx
  • IUnityContainer is silly. What developer thinks that an Interface needs 42 methods. Extension methods anybody? Also want easily be mocked by RhinoMocks or Moq. See --> http://leecampbell.blogspot.com/2009/08/how-not-to-write-interface-in-c-30.html. Again this problem I dont think is really the Prism team's (but would be nice if they yelled at the Unity team across the corridor)
  • Unity Convention over configuration. Again not really a problem with Prism but generally Unity and Prism are seen as one product.

The things I like most about Prism is that I only need to know and use 4 things 1) Regions, 2)Modules, 3)Event Aggregator, 4)Commands and Behaviours. Small APIs are good APIs.

I would love to see some really good TDD walk through videos. Every place I end up building Prism apps does it differently at the start and once we move to TDD looks the same(as previous projects) but not really similar to the samples or what we started out as. This may be due to me pushing my architecture on the team tho ;-)

So answering the actual question:

  1. Get unity to get better
  2. Provide better TDD samples and guidance (Videos!!)
  3. Keep the Api really small or at least an Opt-in framework.
Mar 3, 2010 at 8:07 AM
Edited Mar 3, 2010 at 8:08 AM

Unity 2.0 brings some major advantages over version 1.2 that is currently used in Prism.

1) Support Unity 2.0

and maybe

2) Bring in a convention based registration extension to Unity like [THIS ONE]

 

Mar 12, 2010 at 4:44 PM

Any news on the development and the time frame  for RTW? Will it release along the same time as SL4?

Thanks!

..Ben

Coordinator
Mar 17, 2010 at 5:13 AM

As I mentioned in my blog, we plan to ship around September. We will have a minor update to fix a couple of issues with the RI and unit tests shortly after Silverlight 4 releases. My blog provides links to what needs to get fixed if you want to start with Prism and Silverlight 4 before we release.

blaine

blog: http://blogs.msdn.com/blaine

Mar 19, 2010 at 12:39 AM
Edited Mar 19, 2010 at 1:01 AM

Hopeful Prism 4 scope:

  1. MEF
  2. Unity 2
  3. MVVM
  4. RX
  5. Information access including WCF.RIA
  6. Design time support
Coordinator
Mar 29, 2010 at 4:10 AM

Thanks for the feedback everyone. I have captured it and will use this feedback to create a survey that I want everyone to take. The survey will help us prioritize the feedback.

Thanks.

Blaine Wastell

http://blogs.msdn.com/blaine

 

Apr 15, 2010 at 12:50 PM

If it isn't to late to add feedback :)   IDisposable pattern applied to applicable areas of the framework, i.e., ViewsCollection.RemoveAndNotify(items)

Coordinator
Apr 29, 2010 at 5:02 PM

The Prism 4.,0 survey is available. There is too much for us to do so we need you to vote and help guide the focus of our next release.

Blaine Wastell

http://blogs.msdn.com/blaine/archive/2010/04/27/have-you-taken-the-prism-4-0-survey.aspx

 

May 14, 2010 at 2:13 PM
Any news what items were picked from the survey and what decisions were made to incorporate WCF RIA Services into Prism 4? Thanks! ..Ben
Aug 17, 2010 at 1:22 PM

Please provide guidence on Authentication and ROLE based composition

Aug 17, 2010 at 4:24 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Aug 17, 2010 at 4:24 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.