Thursday, July 5, 2012

Wizards and Builders: A Smarter Way to Work Your Magic






















Wizards and Builders: A Smarter Way to Work Your Magic
When a programming task is comprised of a series of atomic but interrelated steps, a wizard is a useful way to build the functionality needed without having to memorize the order of the steps needed to accomplish your objective. While many 3GLs simply expect you to write a series of lines of code that execute functionality in a prescribed order, Magic simplifies this process by eliminating the need to remember the syntax of each step and by eliminating the need to remember the needed steps themselves and their orders. To accomplish this, the Magic xpa Studio includes a number of wizards and builders for creating components and other resources that run on the Magic xpa Application Platform.
A component acts as a building block of an application. They are generally stateless, meaning that each instance of the component can be executed independently of every other instance of that same component. Magic allows you to define project objects as components and export them to share resources among Magic xpa projects and facilitate distribution of revisions. When you make changes to a component, the revisions are inherited by any programs that call the component.
With Magic xpa Studio wizards, you can readily create components, such as Web Services and SQL Stored Procedures. And with the component interface builder, you can even package your own components for use by others. Your components are maintained in the Composite Resource Repository (CRR). Your programs may be highly atomic or they can contain entire programs. The CRR provides repositories that allow you to easily access and maintain models, data sources, programs, helps, rights, menus, events, functions, handlers and environment settings.

The Magic xpa Application Platform Resource Repository

Models Repository. Models are useful objects to expose in components as they provide a way to create programming standards, design standards and so on that you can use throughout your program or across a number of different applications. To expose a model for use by others, you simply give it a Public Name.

Data Sources Repository. In the data sources repository, you should store data objects that will be used in your application. In a world where agile concepts often lead to changing requirements in the middle of a project, you never know when a resource may be needed again elsewhere in your project. So it is a good practice to define all of your data sources in the CRR data sources repository. Whether or not to expose the data sources with a Public Name, however, is a very different question. I recommend giving a Public Name only when a definite need has been defined to share the data model outside your application by a host application.

Programs Repository. In the Magic xpa Application Program, an application program is composed of numerous discrete programs. The CRR provides a repository for all of the programs that make up your overall business application. The ability to provide a Public Name and designate these programs as external means that Magic gives you Service Oriented Architecture capabilities. In addition, of course you can and often will publish your Magic programs as Web Services that can be more easily discovered through UDDI and described via WSDL for full SOA compliance.

Rights, Menus and Helps. Three additional repositories are provided for managing the rights, menus and helps in your applications.
·         Helps – You expose Help objects similarly to models and data sources: just give each object you wish to expose a Public Name.
·         Rights – You expose Rights similarly to models and data sources: just give each object you wish to expose a Public Name.
·         Menus – You expose Menus similarly to models and data sources: just give each object you wish to expose a Public Name.

Events.  In each task you can define user-defined events to be handled in your project whenever these events are raised or triggered.
A user-defined event is a logical definition of an occurrence. For example, you can define an event called ‘Add Customer’. The event definition by itself will not affect the project. This logical definition allows you to define the handling for such a logical occurrence. You expose events as components by giving them a Public Name and selecting the Expose check box.

Functions and handlers. Developer functions set in the Main Program can be published as part of a Magic xpa component by setting the Scope option to Global.

Environment settings.
The loaded component is integrated into another project and appears in the Composite Resource Repository. Any component object can be selected from the Object list. The environment settings selected for a component are accessed for any component object that the end user opens in the project. The environment settings for a component appear in the Environment repository, which is reached by clicking the Environment button in the Magic xpa Component Items repository.

All environment variables not specified for a component are inherited from the environment settings of the project. 

No comments:

Post a Comment