This project is read-only.

Bxf.Status - Overloaded constructors

Developer
Aug 12, 2010 at 2:38 AM

While the use of the object initialiser syntax is a workable solution to initialising a new instance of the Status class's properties, I would like to propose the following Constructor overloads for common scenario's:

    /// <summary>
    /// Initializes a new instance of the <see cref="Status"/> class.
    /// </summary>
    public Status()
    {
      IsOk = true;
    }

    /// <summary>
    /// Initializes a new instance of the <see cref="Status"/> class.
    /// </summary>
    /// <remarks>
    /// IsBusy will default to false.
    /// </remarks>
    /// <param name="text">The text.</param>
    public Status( string text ) : this()
    {
        Text = text;
    }

    /// <summary>
    /// Initializes a new instance of the <see cref="Status"/> class.
    /// </summary>
    /// <param name="text">The text.</param>
    /// <param name="isBusy">if set to <c>true</c> the status is busy.</param>
    public Status( string text, bool isBusy ) : this( text )
    {
        IsBusy = isBusy;
    }

Please feel free to suggest different constructor overloads.

If you agree with making the change, please create a work item and I'll implement it.

Note: I'll also add XML comments to the properties and class which is triggering build warnings in VS2010.

Coordinator
Aug 12, 2010 at 2:48 AM

I chose to use object initializer syntax instead of ctor overloads because I thought there could end up being a lot of overloads to cover the various possible statuses - especially if someone started creating subclasses to add app-specific status information.

In any case, you've already overlooked the Ok and Visual properties. In fact that's where I made this design choice - because busy and ok are both bool - so you can't have both (text, busy) and (text, ok) overloads, and in my very first app I needed both - so I figured that if I had to use initializer syntax anyway, why not use it consistently.

Developer
Aug 12, 2010 at 2:59 AM

Makes sense... happy with that.

I intentionally skipped the Ok / Visual properties as I felt they weren't too commonly used, but as you pointed out you've already run into basic scenario's where you needed them both in the mix early on. Including them would result additional API bloat, and someone could instead subclass and add the necessary constructor overloads if they really needed it.

Shall I update the XML comments in the mean time? (Could you suggest an appropriate XML Comment for OK and Visual?)

Coordinator
Aug 12, 2010 at 3:47 AM

OK is intended to indicate whether the operation was successful or not - in my app I triggered a graphic element (green or red) to indicate whether the "app was happy".

Visual is intended to allow your viewmodel to insert a visual element into the status display. In my app I used it to show a rating control for the current item, but my original intent was to allow display of something like a progress bar. Since the visual element comes from the viewmodel that's setting the status, it is possible for the visual element to be bound to the viewmodel, so it is kind of like a secondary view over the viewmodel if that makes sense.

Obviously it is up to the runtime presenter implementation to actually display any of this status information. I think an argument could be made that ok and visual shouldn't be in the base implementation at all, but rather that an app should add such things in a subclass if necessary.

Developer
Aug 12, 2010 at 4:22 AM

Thanks that helps. I'll update the XML comments for the class and check it in.

I see what you are saying about Visual (and maybe even IsOK) but I'll leave it as is for now.