Aleks Grinberg

March 20, 2010

SmartParts

Filed under: Smart Client — aleksgrinberg @ 9:46 pm

[Back to Table of Contents]

SmartPart is a synonym with View. View class derives from UserControl and has the [SmartPart] attribute. The [SmartPart] attribute is required to support the inversion of control functionality.

Since loosely couple relationship Workspaces have no knowledge about SmartParts being displayed inside Workspaces. At the same time SCSF allows to pass additional class when a SmartPart is being added to a Workspace. This class should implement the ISmartPartInfo interface which contains two properties: Title and Description. This information could be used for example in the caption of the tab within a tabbed workspace.

private void AddViews()
{
    MySampleView myView = this.WorkItem.SmartParts.AddNew();
    SmartPartInfo spInfo = new SmartPartInfo("Title", "Description");
    this.WorkItem.Workspaces[WorkspaceNames.RightWorkspace].Show(myView, spInfo);        
}

March 14, 2010

List of WorkItem Collections

Filed under: Smart Client — aleksgrinberg @ 8:06 pm

[Back to Table of Contents]

Smart Client Software Factory facilitates loose coupling communication between objects that are members of collections. Being properties of WorkItems these collections are stored in well-known locations. Below is the list of WorkItem Collections:

Collection Description
Commands SCSF implementation of the Command design pattern. Commands are used to call business modules from the menu or from the tool bar.
EventTopics Contains information of a specific events and stores list of subscribers and publishers of events.
Services Encapsulates functionality that could be common for the application, module, WorkItem.
SmartParts User controls with the [SmartPart] attribute.
State State maintenance collection.
WorkSpaces Controls for dynamically loading and displaying UI of separate modules.
WorkItems Child WorkItems
Items Objects that do not belong to any strongly typed collection.

Smart Client Software Factory Services

Filed under: Smart Client — aleksgrinberg @ 4:40 pm

 [Back to Table of Contents]

A SCSF service is a loose coupled singleton object stored in the Services collection of a WorkItem class. The collection is indexed by the interfaces implemented by the services. The SCSF offers build in services and allows to create custom services.

Below is an example of the build in service. The ActionCatalogService service implements the IActionCatalogService interface. It is initialized in the  AddServices() method of the SmartClientApplication class of the Infrastructure.Library project:

RootWorkItem.Services.AddOnDemand<ActionCatalogService, IActionCatalogService="1">();

The code to consume this service is:

IActionCatalogService actionCatalog = workItem.Services.Get<IActionCatalogService>();

The steps to create a custom SCSF service following the pattern above are:

  • Create an interface
  • Create a class that implements this interface
  • Initialize (register) a service
  • Consume a service

An interface could be packaged into the Infrastructure.Interface project and the implementation class into the Infrastructure.Library project or a separate foundational module could be created to hold custom services.

Using SCSF Wizard to generate event codes

Filed under: Smart Client — aleksgrinberg @ 1:04 am

[Back to Table of Contents]

SCSF provides a graphical interface enabling generate event publication and subscription codes. Basics steps are:

  • Open Solution explorer, select the class you want to subscribe to the event and open SCSF content menu:
  • Click on Add Event Subscription to open the Wizard:

  • Type new or select existing Event Topic Name and select Event Argument Type:
  • Click Finish button and the Wizard will generate event subscription code.
  • Publication and subscription codes in the Smart Client Software Factory Events are generated by Wizard.

    March 10, 2010

    Smart Client Software Factory Events

    Filed under: Smart Client — aleksgrinberg @ 2:21 am

    [Back to Table of Contents]

    SCSF Events are coming to the picture when the announcer of the event, for example the “Refresh” button and the listener of the event – let’s say a grid control that needs to be refreshed with the latest data belong to separate loosely coupled components.  

    SCSF objects responsible for events   

    Workitems objects contain WorkItem.EventTopics collections of EventTopic objects. An EventTopic object contains information of a specific event and stores list of subscribers/publishers of this event.  

    Loosely coupled events communication within Smart Client applications is provided by the Event Broker service. It receives notification from the event publisher and fires it to the event subscribers.  

    Registering publications or subscriptions using attributes  

    A SCSF event publication method need to be declared with the [EventPublication] attribute with uniquely identified string. Subscriptions need to have a method with the same signature as the event publisher and need to be declared with the [EventSubscription] attribute. 

    Let’s look at the auto generated StatusUpdateHandler function in the ShellForm.cs. It updates the status strip of the Shell form.  This function is declared as subscriber of the event named EventTopicNames.StatusUpdate and could be called from the user interface thread. EventTopicNames.StatusUpdate constant is stored in the EventTopicsName.cs file of the Constants folder of the Infrastructure.Interface project.

    [EventSubscription(EventTopicNames.StatusUpdate, ThreadOption.UserInterface)]
    public void StatusUpdateHandler(object sender, EventArgs<string>e)
    {
        _statusLabel.Text = e.Data;
    }

    To call this function we need to add a functionlity which will fire this event – the even publisher functionality.

    In the sample below I put an event declaration in the business module’s ModuleController and the code which fires this event in the begining and in the end of the Run() to update the user when the module is ready for usage: 

    [EventPublication(EventTopicNames.StatusUpdate, PublicationScope.Global)]
    public event EventHandler<EventArgs<string>> StatusUpdateTest;
    
    public override void Run()
    {
      StatusUpdateTest(null, new EventArgs<string>("Module is loading..."));
    
      AddServices();
      ExtendMenu();
      ExtendToolStrip();
      AddViews();
    
      StatusUpdateTest(null, new EventArgs<string>("Module is ready."));
    }

    Let us create an another subscriber of the same event since the first was auto generated. We may add the code below into ShellForm.cs:

    [EventSubscription(EventTopicNames.StatusUpdate, ThreadOption.UserInterface)]
    public void OnStatusUpdate(object sender, EventArgs<string>eventArgs)
    {
        MessageBox.Show("The module is ready!");
    }

    After loading the module which is firing the event both subscibers will receive the event’s notification.

    If the publication scope is global like in our example, the publisher may notify multiple modules’ subscribers of the same event. And in another scenario a subscriber could be notified by multiple global publishers!

    The code generation Wizard

    The good news is SCSF provides a graphical interface enabling generate event publication and subscription codes.

    March 1, 2010

    Dependency Injection

    Filed under: Smart Client — aleksgrinberg @ 1:44 am

    [Back to Table of Contents]

    The Smart Client Software Factory implements the Dependency Injection Pattern to decouple classes from its dependencies.  

     This functionality is provided by ObjectBuilder – a foundation component of Smart Client Software Factory.

    Dependency Injection allows to use a dependent class by expressing it declaratively in main class without directly referencing dependent class.

    ObjectBuilder obtains instances of main object’s dependencies and pass them to main object during the object creation and/or initialization.

    February 28, 2010

    WorkItems

    Filed under: Smart Client — aleksgrinberg @ 4:35 am

    [Back to Table of Contents]

    WorkItems are containers of other Smart Client Software Factory objects.

    Every business module loads a ModuleController WorkItem, which acts as a root WorkItem within a module and is added as a child to the root WorkItem.

     

        public class Module : ModuleInit
        {
            private WorkItem _rootWorkItem;
    
            [InjectionConstructor]
            public Module([ServiceDependency] WorkItem rootWorkItem)
            {
                _rootWorkItem = rootWorkItem;
            }
    
            public override void Load()
            {
                base.Load();
    
                ControlledWorkItem<ModuleController> workItem =
                   _rootWorkItem.WorkItems.AddNew<ControlledWorkItem<ModuleController>>();
                workItem.Controller.Run();
            }
        }

    Navigation through objects tree 

    WorkItem class contains RootWorkItem, Parent and WorkItems collection property that allow to traverse the Smart Client Software Factory objects tree. The root WorkItem in the top of the hierarchical tree is created by the Shell application that acts as container for global services and WorkItems added by modules.

    WorkItem also holds collections of other objects being used in the scop of the given WorkItem.

    Dispose WorkItems

    WorkItem class implements IDisposable interface.  The call of the Dispose() method of WorkItem iterates it’s collections and calls Dispose() method on every item that implements IDisposable interface.

    Packaging WorkItems

    Logically related WorkItems need to be packaged into modules – units of deployment of the SCSF application. However WorkItems that could be allowed based on users security roles and re-usable WorkItems could be packaged into separate modules.

    Modules

    Filed under: Smart Client — aleksgrinberg @ 2:57 am

    [Back to Table of Contents]

    A composite smart client application allows a number of discrete functional pieces – modules to be integrated within a common host environment.

    The Smart Client Software Factory architecture enables modules being loaded dynamically on application startup or later at runtime. It supports for loosely coupled communication between modules and components of these modules, based on a publish/subscribe pattern.

    Business modules. A business module has at least one WorkItem (specifically, a ControlledWorkItem) and contains business logic elements. Typically, it includes services, views, presenters, and business entities.

    Foundational Modules. A foundational module typically provides services to the shell and other modules. It does not implement a use case or contain a WorkItem.

    The Shell as the base of UI

    Filed under: Smart Client — aleksgrinberg @ 1:10 am

    [Back to Table of Contents]

    The Shell project contains the startup form and the root WorkItem. We will discuss the role of the root WorkItem later. Initially loaded the Shell form includes MenuStrip and a ToolStrip on the top, two DeckWorkspace controls in the middle, and a StatusStrip on the bottom. It is the basic user interface for every module loaded into the Smart Client application.

    Shell

    Workspaces are used for replacing parts of the user interface when modules are dynamically loaded into the application. The Shell developer may replace DeckWorkspace workspaces with any out-of-box workspaces.

    Smart Client Software Factory allows extend menus such as adding a menu to the menu bar, tool-strips, or add a message to a status-strip using UIExtensionSites as a shell-extensibility point.

    Workspaces and UIExtensionSites are publicly available to all components of the smart client application.

    February 27, 2010

    Workspaces

    Filed under: Smart Client — aleksgrinberg @ 6:13 pm

    [Back to Table of Contents]

    Workspaces are containers for dynamically loading and displaying views. Smart Client Software Factory contains the following out-of-box workspaces:

    • DeckWorkspace – enables to show and hide controls and SmartParts in an overlapped manner (topmost is displayed) with no visible frame.
    • TabWorkspace – enables to show and hide controls and SmartParts inside a tabbed page, usually one SmartPart per Tab.
    • ZoneWorkspace – multiple zoned workspace layout to display multiple controls and SmartParts in one workspace.
    • WindowWorkspace – shows and hides controls and SmartParts framed in a window. A SmartPart could be configured to be displayed modaly inside WindowWorkspace.
    • MdiWorkspace – enables to show and hide controls and SmartParts in MDI child forms.

    The DeckWorkspace, the TabWorkspace, and the ZoneWorkspace workspaces are available through the toolbox:


    To add CAB controls into toolbox we need: right-click the Toolbox and select Choose Items; click on browse In the .NET Framework Components tab and navigate to the folder where the CAB assemblies reside; select the Microsoft.Practices.CompositeUI.Winforms.dll assembly and click OK.

    The WindowWorkspace and the MdiWorkspace could be created only by writing code, for example:

    WindowWorkspace winWS = new WindowWorkspace();
    RootWorkItem.Workspaces.Add(winWS);
    Older Posts »

    Create a free website or blog at WordPress.com.