Effective Application Components (Magic xpa 4.x)

How do I build my projects with components?

You now know what a component is, what a Magic xpa component is, and how to use a Magic xpa component. Now you need to understand how to go about building your projects with components, which will be explained in this section.

When Should I Use a Component?

The key to assembling projects rapidly is the ability to reuse existing code, in other words a write once, use again and again strategy.

There are no hard and fast rules on what to place in a component or what factors should be taken into account when designing a component-driven project. Nevertheless, we can supply some guidelines and techniques.

If your application has various modules, consider making each one a component. If the module can exist on its own and be sold separately, that module should definitely be created as a component. For example, if your application consists of a Sales module, a Financial module, and a Payroll module, consider making each module a component.

• Put all frequently used models into a component.

• Put all frequently used helps and rights into components.

• Put all frequently used data sources, and all frequently used programs based on those data sources, into a component.

• Put all frequently used events into components.

• If you need to provide default handlers for the entire project, it is good practice to make components using global handlers, as we will explain later on in the concept paper.

• Look for behavior that exists in more than one place in the system, and create a utility component that can be used in multiple projects. For example, you can make a program that checks the parity digit of a number into a component.

• Customer customizing – If the application is the same for all customers but there are a few modules, or interfaces, that can be different for each customer, this is a good opportunity to take advantage of components. An example of this would be a customized package. If the main application remains the same but each customer has different reports, the reports can be written in a component.

• If a program or feature is modified more often than others, this may also be a good opportunity to take advantage of components. An example in an accounting application would be when the base remains the same but the taxation module changes periodically.

• Outsourcing – When you outsource part of the project, it is good practice to make the outsourced module a component.

Let's illustrate this with a simple example using a model. Take a simple case of the use of a serial number. You want this number to be numeric with 9 digits without negative values. The number appears in a few tables, and you want to use it in various programs as a virtual variable. You could define this each time. But if you wanted it to be displayed in a specific format, you would have to remember exactly how you set it up each time. In this case, you would probably choose to use a model. Assuming that each project you write uses that same serial number in the same format, it would make sense to place this model into a component, thereby defining it in one place but having it available for every project.