Packages are a special class of project items that facilitate reusability and the distribution of third party controls and solutions. Reusability, through sharing of common project items across multiple applications, is quite a useful feature as it saves time and improves productivity.
Reusability can be even more powerful when a section of a project that has strong logical identity is carved out into a separate entity and made available as a self-contained package ready to be added to any project that may require its functionality.
A good example of this scenario is the security and user access functionality which often is required in a web application. Most web applications deal with users and often need to provide access control and some form of user authentication. This functionality can be packaged into a self-contained unit and made available to any project that needs such functionality.
The need for reusability, however, becomes much more acute when it comes to distributing widgets created in Morfik. It could well be the case that many widgets created by Morfik developers may have a wider appeal. Such widgets would have high rates of reusability driven by demand. Packages in Morfik 2.1 are specifically designed to address the requirements of Widget reusability.
Widgets that are defined within a package are automatically added to the Ribbon when the package is added to a project. Widgets can also be assigned individual icons within a package project so that they have their own identity.
Since Morfik itself is used to build Packages and at the same time it has the ability to utilise such packages, there are two completely different experiences that a developer could have dealing with packages. Depending on whether a developer is developing a package or using an already-made package, experiences can be significantly different with little or no degree of commonality.
When a package is under development an entire project is devoted to the process of its creation. When a package is compiled, a single file (.MFPackage) containing all the elements of the package is generated in a compressed format. This file is the only file that needs to be distributed to make the package available to others.
For the rest of this section developing and using a package will be treated separately.
Using Morfik Packages
When packages are added to a project they will appear as a new class of project items similar to forms, reports, tables, queries, modules, WebMethods and now also widgets. To add a Package to a project you will need to use the Used Package dialog.
|Figure 1 Adding Packages to a Project|
Alternatively one can add a package to a project by simply drag-and-dropping the compiled package file (.MFPackage) anywhere onto the project view.
When adding a new package, Morfik checks to ensure there is no name conflict between a package item and any of the existing project items (including package items that are already added). If there is a conflict, Morfik will not allow the package to be added. When conflicts are between package items from the same developer, Morfik will overwrite the existing project item and generate a warning if they are not identical. This way packages from the same developer can share modules.
Creating Morfik Packages
Morfik Packages are developed in a similar manner to Morfik normal projects. The only difference is the project type and the process for creating them. To create a Morfik package a developer must obtain a unique package ticket from Morfik. This package ticket defines a global name space that is unique for every holder of a Morfik account. Obtaining a package ticket is as easy as running a wizard and going through a small number of wizard pages.
To create a new Package one has to select the “New Package” command in the “New Project” menu in Ribbon’s system menu as show in Figure 2.
|Figure 2 New Package Command|
Once the New Package command is selected the New Package wizard is activated. The wizard will prompt the user to provide the location of the user’s unique Package Ticket file. If there is not one available on the particular machine being used, or this is the first time a package is being created by a developer, the wizard will ask for a valid Morfik login username and password along with a unique namespace designator (see figure 3). Once supplied the wizard will login to Morfik’s on-line Package Ticket Manager and will download a signed copy of your unique ticket file. The wizard finally will ask for a location for the Package project file (as per the normal process of project creation) and your new Package project will be finally ready to be developed.
|Figure 3 New Package Wizard - Registering a Namespace|
Morfik Package Namespaces
Since the majority of packages are likely to be developed independent of each other, yet there is a high likelihood of two or more such packages being used simultaneously within a single project, the process of project item naming is managed in a central way by Morfik. This is to minimise the possibility of name conflict between package items created by different producers. Registered namespaces is the way Morfik ensures package items are globally unique between developers.
Morfik uses a globally unique namespace designator and prepends that to all package item names within the project package item that is created. A namespace designator can be any combination of English characters, underscore and digits and must not start with a digit. The length of a namespace designator is limited to between 3 and 6 characters.
All packages created by the same Morfik developer share the same namespace. It is important to note that whilst this approach ensures that there will be no conflict between package item names created by different developers, it does not guarantee that package item names are unique between packages that are created by the same developer. In this case the developer is responsible for managing the namespace for all the packages that he or she creates.
Another area that requires a similar approach is the naming of code entities within a project item. Morfik developers are expected to manage namespaces related to objects within a project item.
|Note:||Namespaces allow you to have identical identifiers in different Packages, for example, and still be able to access both from the same code as shown in the example below.|
Morfik Package Ticket Files
Morfik package ticket files are digitally signed by Morfik and are used to store the namespace designator along with a description of the package publisher. It is important to note that package ticket files are unique per developer and once created a namespace designator cannot change. The publisher name for the package can however change by running the wizard a second time and using a different publisher name. The New Package wizard will ignore the namespace designator if it finds that it has been previously registered.
Once a package project is created it will behave in a similar way to a normal project for all intents and purposes. The package will be compiled and can even be run, which is most useful during its development. When a package is successfully compiled it produces a compiled package file (.MFPackage) which can be added to any project.
Specifying icons for Widgets and Packages
To specify an icon for a widget in a package, one has to supply an .ICO file with the name matching the class name of the widget, and the .ICO file must be put into the _Icons folder inside the package project folder. For example, if there is a widget inside the package named abc_Widget, the icon file name should be abc_Widget.ico. If no icon is provided for a widget, the default icon is used.
Packages themselves can also have icons. To specify an icon that will be displayed next to a package in the Packages dialog, there is a need to place an .ICO file having the same name as the project 32 Getting up and running with Morfik 2.1 name for the package in the package project folder. For example, if the package project is named SamplePackage.mxp, then the icon file should be named SamplePackage.Ico.
General notes about Morfik Packages
Unlike most other RAD tools Morfik packages are added to a project rather than to the environment. There are advantages and disadvantages to this approach. The advantage of using this approach is that package management is generally easier. There will be less potential for problems caused by package version incompatibility, as each project has its own copy of the package. The disadvantage of this approach is that if a package is updated it would have to be added to each and every project that uses it individually.
Morfik Packages are compile-time packages. At run time the content that comes from a package is completely merged with that which comes from the project that is using it.
Morfik Packages can deliver the whole application stack including the back end database layer, the mid-business logic layers and the interface layer. This is possible because packages can contain tables and queries as well as WebMethods. It might be worth mentioning that a form could also be included in a package along with widgets for a more comprehensive coverage of a whole problem domain. Morfik Security and User Access package is perhaps a good example of delivering an entire application stack, as it includes tables and queries for storing user information and session management; it also uses WebMethods for exposing its services to the host and other applications at run time. It has an Admin section that uses forms, and of course it comes with a set of pre-wired widgets that makes using the security package as easy as drag-and-dropping a few widgets and then hitting the Run button.
Since Packages are compile-time entities their source is required during the compilation process. The important implication of this is that in the current implementation of Morfik Packages in the 2.1 release, the package source code is not protected. It is anticipated that a protection mechanism will be added in the next major release of Morfik.
Currently there is no mechanism for package dependencies. If a package relies on the presence of another package within the project being used, the system does not attempt to ensure prerequisite packages are present when a package is added or removed.
All project items (Tables, Queries, Forms, Reports, Modules, WebMethods) are available to a package without any limitation. In addition to project items, other project entities such as Published URLs, Helper methods and Web Actions (a Web Action is a global function with a special metadata tag that allows it to be hooked up to an event handler using the Web Action wizard) can also be used within a package project.
With the exception of Tables, it is possible to exclude certain project items from a package. Tables, if defined, cannot be excluded from a package. To exclude a project item, right-mouse-click on a project item that is to be excluded while in project view and select the Properties command. Then untick the “Include in package” checkbox. (See Figure 4)
|Figure 4 Excluding a Project Item from a compiled Package|