Developing tailor-made applications used for a specific purpose has been around for a long time. The watchword then was to develop an application for a client, tailored and customized for his own needs. Those were days where clients had little or no knowledge about technologies around. But now, the scenario is different altogether. Clients have become more technology-aware thanks (rather, shouldn't I thank) to the Internet. I would just say that an end user buying a payroll package would expect it to work for his factory, his shop and where ever he needs to pay people regularly, of course, by just changing the business logic to calculate the pay. As a result of this, the whole community of application developers has taken a U-turn towards building generic applications, which need little or no tailoring before they can be shipped to different classes of users.
Developing a component to add two objects (be it a string, an integer or an object), could be just coded without a second thought to its design. But to make a whole application generic may seem a bit difficult. The more you think of it, the more confused you would be, on how it could be implemented. Panic not, its just possible. Thanks to XML!!
This article does not go into the detail on the implementation but limits itself to discussing how to make your application 'almost' generic using XML. I stress on the word "almost," as to my knowledge I believe that it is not possible to make every application completely generic using the method discussed. However, having implemented the design, rather the idea successfully, I trust that the readers would be convinced that creating a generic application is not much of an over head as thought.
What is expected from the audience?
A little bit of exposure to XML would definitely be an advantage in understanding the examples in this article. However, there is no specific requirement or qualification necessary to read this article. Developers of any language can use the design. It deals from the basics of the idea and gives an overview of the design.
Installation has become routine for the developers. Now imagine that you want to install something on your computer. Given two ways to do, either doing it all manually, or following a set of steps finally leading to the successful installation of the package. Which one would you prefer? As an end user, I would rather go for the latter method. This is what an end user expects nowadays.
Likewise, an application that can be customized by the users themselves would be more appreciated than an application that needs the developer to perform customization for different business needs. The user would like your application to adapt itself to the environment they are using it in by just reading the instructions that they give your application. I suppose the reader would have got a rough idea of what I would like to stress here. The further reading would give a clear picture of the same.
Overview of XML
Talking about XML with this article on my mind, I would describe it as a formatted way to present a text in a readable form (may be not for us but certainly for the code) along with its meta-definition.
XML is the Extensible Markup Language basically designed to improve the functionality of the Web by providing more flexible and adaptable information identification. It has the virtues of HTML without its limitations. It is a meta-markup language that provides a format for describing structured data and allows specific markup to be created for the user data. In short, XML is strong in intelligence, adaptation, maintenance, linking, simplicity and portability.
XML documents are very easy to create. It's just <, >, and /. Remember that for every opening
<MARKUP> there needs to be a closing
</MARKUP> and you can write your XML file without any hitches. It is easy to access and modify data in XML. When looking at XML, an average user may not find it as simple as HTML But against other languages that let you do what XML does, it is quite simple.
It's quite easy to write programs which process XML documents. That reminds me of what I had mentioned in the beginning, that XML is easy to be understood by the code. The test of a XML's usefulness is how much and what you can do with it. Making it as easy as possible for an application to use the XML is in the best efforts of the developers.
To put it in plain English text, the design is as simple as this. List down your steps to perform your function and make your code read it and then work accordingly. For instance, consider a payroll application. It might be required to calculate salary in terms of hours worked in one of the offices and in terms of standard monthly payment in another. Just mention this in the format that your code can understand and perform salary calculations accordingly. This calls for the developer to explore all possibilities of calculating the pay and provide ways to list them down in the XML files.
Now speaking more technically, we are going to design the necessary XML files that define the rules to the application code. This may seem vague but it could be easier when you look at the following section to design your XML files.
Design the XML Files
The major challenge now lies in designing your XML files. The code needs to understand the rules so they just can't be plain-English sentences. They need to be specific tags and their values that speak to the code.
This file looks very simple right? Yes, it is. The company_name is the business group for which the payroll has to be calculated. This could be a repeating tag under the root tag payment_method which gives the rules to calculate salaries for that business group. The tag names indicate what has to be done and their inner nodes provide the corresponding values.
Now, if the basic_pay section depends on the number of hours worked;
<hour_rate>Field of the data base that tells the rate per hour</hour_rate>
This tag could instruct the code as the salary is per number of hours. Now, again all employees do not have same rate paid per hour. So the inner text of the hour_rate could give the field name in the data base mentioning the corresponding employee's rate per hour. The incentives tag could give the inner text as the field name which gives the amount of the incentive to be paid to that employee and similarly the deductions tag could give the deduction amount. The tag name could also instruct if the amount has to be subtracted or added to the basic pay. If the data base to access itself differs for each tag, then the name of the database can be given as the first inner child as given below. This rate could be multiplied later with the number of hours giving the total basic pay.
If all the tags correspond to one database then at the beginning we could have a single tag giving the database name as follows;
If the incentives and deductions are either direct amount or a percentage of the basic pay, then they could be indicated as follows
instructs the code to calculate the percentage of some field value
instructs the code to calculate the percentage of some field value
instructs the code to take the amount specified
Let's try and write an XML file for the following package stored in a database for each employee.
Basic_Pay : 10,000
HRA : 10% (incentives)
TA : 2000
PF : 4000
Leave_deduction : 5%
How does the code recognize the tags and performs the actions? This is discussed in the following sections.
The Implementation details
Having the business rules in hand, making the code interpret it is the next challenge. The first step would be to write a function or a component to read and write from an XML file
After this we should make the code understand the tags in the file and perform the corresponding actions. Now this calls for the imposition of a few constraints. Let us consider the latest XML file we wrote for the salary calculation. Here the XML file should not contain any tag names that the code cannot understand for your payment amount to be calculated correctly. Let's try to write a simple pseudo code which understands the latest XML file we designed and calculate the pay.
Step 1: Load the XML file
Step 2: Declare a root node pointing to the parent tag ("Payment method")
Step 3: Search the child tags with your company name, once the tag is located make its first child as your root node. This makes your root node point to the tags inside the tag with your company name.
Step 4: Open the table that is given as the root tag's inner text. (Say DB)
Step 5: Read the sibling tags one by one till they exist and make them as root tag and perform the following steps for each tag.
Step 6: salary = 0;
case basic_pay : salary = salary + root node case incentive : if (root node salary = salary + DB.root node else(root node salary = salary + DB.root node DB.basic_payfield /100
case deduction : if (root node salary = salary + DB.root node else(root node salary = salary + DB.root node DB.basic_payfield /100
Generally, in calculating pay you might have incentives and deductions and nothing more. In case you have a new type of operation, add a corresponding tag and include a case statement in your code to handle it. (If a business group has a new type of tag to be included, then the developer's help would be required for shipping it to that business group). For example, if there are more rules like the HRA is calculated as a percentage of the whole year's basic pay make a new tag like incentive_per_year and frame the business logic under it. Simultaneously, add a case statement to handle that new tag.
Now this might look quite simple, but don't you think now when you port the application to different places the user just needs to know how to write an XML file and your code works.
To further optimize your application, try making the major functionalities as components or class libraries so that they could be reused with any other application as well. The other advantages and trade offs could itself call for another article. So, I stop with this. Dig on more and you are sure to find a treasure.
Try this one! You might have heard about it, but with this article it wears well as an optimization technique. We have always known that database connections are costly in terms of time involved to connect to them. When they are to be given a thought, XML could even prove a solution for it. You could frame tags as the field names and their values as the values for the fields. The master tags could serve as the data base names and its child nodes as the table names. This is as simple as that. Now let's try to port the table we used above into an XML file.
<Payroll> /* data base name*/
<salary> /* table name*/
<record> /* for each record*/
<Name></Name> /*name of the employee*/
<Emp_id></Emp_id> /*id of the employee*/
<basic_pay></basic_pay> /* basic pay */
</record> /* end of record*/
</salary> /*end of table*/
<Payroll> /* end of data base*/
The advantages of using XML are that it helps a lot to avoid connections to database and thus reduces the time involved in making the user wait. Your application is sure to run much faster. But it does require an investment in the developer's time to handle the XML files with synchronization implemented. This may not be such an overhead for those developers who are going to use the above mentioned way to build their application as they would be writing code to read from the XML file and a little extension to write into the file would serve the purpose.
Every method that is used would definitely have a trade off made when compared to the other methods available to implement the same. The major trade off made is by the developer to go about and manage the complexity to code and make the application "almost" generic. The word "almost" is stressed because still it is required that the XML files be changed at a minimum.
The trade off made is that the optimization technique mentioned is an overhead to code in implementing such constraints as a unique key constraint. In the case of foreign key constraints the code becomes more complex and in a few cases even impossible to manage. If this happens then other techniques should be used rather than this idea. Optimizations don't always make the work easier. It could prove to be the other way round in few cases. This optimization method is similar to an ancient method where data could be stored in flat text files separated by commas. The method was used if the size and the complexity of the tables were small and easy to handle. The case here is the same; it may be that using XML instead of flat text files is a better way to present data but it does carry with itself the limitations of storing data in a flat file. It is up to the complexity of the database that the developers make a choice to use XML as their backend.
You are here
Design and try fitting your application into this model, may be it's just the perfect and best-fit that you can ever find.