Direction of prism

Mar 26, 2008 at 9:45 PM
Could anyone map out the direction for the prism project in terms of Reference implementations.
I have taken the release today, but wondered which direction it might go in say the next 2 months.

For example will the navigation aspects be covered soon, (i.e. covering say a similar aspect as the UIP 2.0 application block)

Will there be something in the Reference Implementation for traditional detail windows in terms of MVP as much as anything, and what about aspects of command pattern implementation for menus or routed events.

There are probably some larger fish to fry than the ones I am interested in here, but just wondered!
Apr 1, 2008 at 11:32 PM
HI cabarch

The major areas we are pushing on going forward is around cross-module eventing. We'll be doing a bunch of work around using WPF's command infrastructure and some kind of cross-module event broker. The other big fish to fry is around module loading. In the RI currently we're using a static loaded model. We're going to do a bunch of quickstarts that illustrate dynamic module loading both Eclipse style (no config) and config driven. We're also looking at module loading on demand. As far as the completeness of the RI we're getting close, but after that our work is not done. We'll be going through several cycles of refactoring, cleaning things up and making them more consistent. Looking at common patterns and seeing if the is library code that emmerges. We'll also be doing a bunch of work around additional quickstarts on different topics.
Apr 2, 2008 at 5:35 AM
Edited Apr 2, 2008 at 6:41 AM

gblock wrote:
The major areas we are pushing on going forward is around cross-module eventing. We'll be doing a bunch of work around using WPF's command infrastructure and some kind of cross-module event broker. The other big fish to fry is around module loading. In the RI currently we're using a static loaded model. We're going to do a bunch of quickstarts that illustrate dynamic module loading both Eclipse style (no config) and config driven. We're also looking at module loading on demand. As far as the completeness of the RI we're getting close, but after that our work is not done. We'll be going through several cycles of refactoring, cleaning things up and making them more consistent. Looking at common patterns and seeing if the is library code that emmerges. We'll also be doing a bunch of work around additional quickstarts on different topics.

Good news. As it stands now, it's not very useful having to rely upon static, hard-coded references (both regions and DI-injected interfaces must be known in the current release). I'm looking forward to dynamic module loading at run-time. Also, I would suggest only requiring the IModule interface be present in external modules. Let the module developer decide if they want to use a presenter or other various services. Keep the number of required, known interfaces to a minimum to ensure it stays light-weight.

One thing I changed in my local copy of the source was I created a generic, abstract Region base class:

public abstract class Region<T> : IRegion where T : FrameworkElement
{
    public T Control { get; set; }
 
    public Region() { }
    public Region(T control)
    {
        Control = control;
    }
 
    #region IRegion
 
    public abstract void Add(UIElement view);
 
    public abstract IList<UIElement> Views { get; }
 
    #endregion
}

If the concept of a Region ever evolves, you have a place to put the common code now. This also allows you to remove the need for the "Wrapped" control in the implementation region class.

public class PanelRegion : Region<Panel>
{
    public PanelRegion(Panel control) : base(control) { }
 
    #region IRegion Members
 
    public override void Add(UIElement view)
    {
        Control.Children.Add(view);
    }
 
    public override IList<UIElement> Views
    {
        get { throw new NotImplementedException(); }
    }
 
    #endregion
}

public class ItemsControlRegion : Region<ItemsControl>
{
    public ItemsControlRegion(ItemsControl control) : base(control) { }
 
    #region IRegion Members
 
    public override void Add(UIElement view)
    {
        Control.Items.Add(view);
        IMetadataInfoProvider metadaInfoProviderView = view as IMetadataInfoProvider;
        if (metadaInfoProviderView != null)
        {
            DependencyObject itemContainer = Control.ItemContainerGenerator.ContainerFromItem(view);
            if (itemContainer == null)
            {
                itemContainer = view;
            }
            IMetadataInfo metadataInfo = metadaInfoProviderView.GetMetadataInfo();
            itemContainer.SetValue(HeaderedContentControl.HeaderProperty, metadataInfo);
        }
 
        Control.SetValue(Selector.SelectedItemProperty, view);
    }
 
    public override IList<UIElement> Views
    {
        get
        {
            List<UIElement> views = new List<UIElement>(Control.Items.Count);
            foreach (UIElement item in Control.Items)
            {
                views.Add(item);
            }
            return views;
        }
    }
 
    #endregion
}
Apr 9, 2008 at 4:24 PM


gblock wrote:
The major areas we are pushing on going forward is around cross-module eventing. We'll be doing a bunch of work around using WPF's command infrastructure and some kind of cross-module event broker. ...... We'll also be doing a bunch of work around additional quickstarts on different topics.


Thanks for the info, sorry for the delay don't seem to be getting email reply alerts, Anyway, can't wait till the RI's get past the first round, why do all of these implementations have to start with "Eclipse like" anything... Its a shame a simple non DI, non module loading on the fly application cannot be produced first,
Remember those Fitch & Mather RI's (mid 90's), they helped so many people get going with multi layered apps. Consider the IT budget in organisations where early proof of reproducing an app with a well known application requirement set in this new world...well we don't need to consider DI and module loading on the fly. Its much less academic than that.;-) Or even the Solutions provider with a limite budget, who just needs to upgrade his succesful VB6 app, to a new world with a longer supportable future.

Not expecting to change your plans really, but maybe something to consider!
Apr 10, 2008 at 4:17 PM


gblock wrote:
HI cabarch

The major areas we are pushing on going forward is around cross-module eventing. We'll be doing a bunch of work around using WPF's command infrastructure and some kind of cross-module event broker. The other big fish to fry is around module loading. In the RI currently we're using a static loaded model. We're going to do a bunch of quickstarts that illustrate dynamic module loading both Eclipse style (no config) and config driven. We're also looking at module loading on demand. As far as the completeness of the RI we're getting close, but after that our work is not done. We'll be going through several cycles of refactoring, cleaning things up and making them more consistent. Looking at common patterns and seeing if the is library code that emmerges. We'll also be doing a bunch of work around additional quickstarts on different topics.


Glenn, on my wishlist for eventing would be two models. The first would be similar to the one that CAB uses i.e. attributes to wire the pub sub eventing up.

But, that doesnt work well if one needs to dynamically create and tear down subscriptions and publications. In other applications, I have had to dynamically create subjects and programmatically wire subscriptions based upon run time data, or actions. So please make sure that any pub sub eventing mechanism also has a "run time" interface in addition to a "build up" interface.

And as far as naming conventions for subscription subjects, it would be nice to have a dot notation for naming. ie. a.b.c. And then be able to subscribe to a.* or a.b.*. This allows a producer to create speciallized messages, and a consumer to subscribe to the generic msg.

Prism Looks good so far and I am looking forward to future drops.
Paul


Apr 16, 2008 at 3:53 PM
By the way, is it possible for Prism team implement cross-module event broker as re-usable application block built over unity just to have an ability to use it outside Prism?
Apr 17, 2008 at 10:03 AM
@Leonid, @pmont

Our first goal is to have an event broker service that is explicitly called, does not rely on attributes and does not depend on depenency injection (though the service itself is likely injected). This type of broker is not dependent on any specific type of contain implementation. The problem with attributes, is it binds you to a specfic container, and in prism our goal is to specifically NOT do that.

As to using EB outside of "Prism", we are planning that you will be able to pull "EB" into your existing apps without having to use any other parts of "Prism'. It will probably not live in a separate dedicated assembly, however whatever assembly it is in, you will be able to directly reference it and use by itself.
Apr 17, 2008 at 10:54 AM
Edited Apr 17, 2008 at 11:54 AM
Oh! Event Broker which doesn't depend on dependency injection sounds very well. Does it rely on ICommand implementations (DelegateCommand etc) that you already have in the last drops? Is there any chance that we would be able to see the first "EB" try in the upcoming drop?
Apr 19, 2008 at 2:25 PM
Edited Apr 19, 2008 at 2:31 PM


gblock wrote:
@Leonid, @pmont

Our first goal is to have an event broker service that is explicitly called, does not rely on attributes and does not depend on depenency injection (though the service itself is likely injected). This type of broker is not dependent on any specific type of contain implementation. The problem with attributes, is it binds you to a specfic container, and in prism our goal is to specifically NOT do that.

As to using EB outside of "Prism", we are planning that you will be able to pull "EB" into your existing apps without having to use any other parts of "Prism'. It will probably not live in a separate dedicated assembly, however whatever assembly it is in, you will be able to directly reference it and use by itself.


Sounds Good!!

I have no problem using it that way. My only other request was to make sure that the "subject" has some way of deliniating groupings of messages and providing wildcards. I used the example of a subject like "a.b.c" so that some code could listen for "a.b.c" or a.b.wildcard or "a.wildcard" and still receive the message. This has proved to be very useful in a system wide pub-sub like Tibco's Rendevous. Things like monitors can listen for groups of messages without having to specifically subscribe to hundreds of different message subjects. Same in a dynamic system, where one part needs to be able to listen to message subjects that it may never know about till run time. If the system uses a subect naming convention, i.e a.b.c, a new component can be built and plugged in that publishes an a.b.c.d message that a listener of a.b.splat can receive. ( a '*' wasnt shoinwg up when I posted, so I edited it to be either 'wildcard' or 'splat' )

The other questions about the eventing then end up being things like the thread of execution for the listener ( UI, or not ), are the listeners pinged in a sequential synchronous manner, or are they async, does the pubilisher return before the all fo the senders receive their messages ( async ), or is it sync to the publisher. Such a simple thing conceptually (Pub-Sub) ends up being a bear to implement properly. <grin>

I understand that you are not building an inter-process messaging system, but the same principles apply in an pluggable intra-process situation IMO.

Thanks again, and keep up the good work.
pmont
Apr 19, 2008 at 7:26 PM
Thanks @pmont. We've discussed the idea of having "Topics" which is something that was illustrated in our original spikes. A "Topic" is a filter that I use to route the messages to the write listener. We didn't consider the wild-card idea though it sounds interesting. Actually at this point we're starting with a basic approach without even a topic.

How important is this topic-level filtering. Can you give us some real scenarios in your app?
Apr 20, 2008 at 12:37 PM
Edited Apr 20, 2008 at 12:37 PM


gblock wrote:
Thanks @pmont. We've discussed the idea of having "Topics" which is something that was illustrated in our original spikes. A "Topic" is a filter that I use to route the messages to the write listener. We didn't consider the wild-card idea though it sounds interesting. Actually at this point we're starting with a basic approach without even a topic.

How important is this topic-level filtering. Can you give us some real scenarios in your app?


I started a new discussion "Event topics and wildcards" instead of having it buried at the end of this discussion.