Guide 86 – Managing Large Applications

Technical Solution:

I am going to try to explain, one by one, the criteria that I have used when defining the objectives.

1.- Divide very large applications into modules.

The use of the “Top-Down” methodology is a criterion used for many years in software development, which is nothing more than the division of the problem/application into modules, in such a way that the decomposition into smaller units makes that are units that are easier to manage and develop. Therefore, if we have an application with many tables, coding, etc., we can surely divide it into units (Modules) that are much easier to define and code.

For example, we have to develop the management of a company and we can do a single development or division into logical modules for the user, for example:

• Purchasing and Warehouse Management.
• Customer Management and Billing.
• General and analytical accounting.
• Treasury.
• Personnel management.
• Payroll and Social Security.

Another way we could divide it could be:

• Billing and Risk Management.
• Sales reports and statistics.

The example that I have left in DEMO has 2 applications and what I want to show is how from one application it connects to another, maintaining the user and changing profiles/groups, according to each application.

The example is very simple.

Event (After successful login):

I save the application and the user login in session variables.

Event (After application initialized):

Controls that if the logged in user has an application other than the one running, log out and log back into this application.

Settings for session variables to be accessed between applications.

For this system to work it is required:

• That the user table is shared for all applications.
• That all interconnected applications work on the same domain (for simplicity, a single web server), so that the sessions of the different applications are shared and accessible.
• It doesn't have to be a single database schema, but if it's not very, very large (300+ tables) it may be an advantage to share the database schema.

Nothing more than this is what is important to go from one application to another.

Advantages of dividing applications into modules:

• Much easier to understand, understand and solve.
• Work can be divided more easily within the development team.
• You can establish different versions of PHP, etc., due to library requirements or obsolescence of a module.
• Less risk in application updates because changes are more controlled. Less load on application tests when faced with updates.

2.- The external libraries, place them outside the PHPRunner project.

I have used this in many of my examples, but there is one in particular, widely consulted, that has this criterion: Create invoice in Word, Excel or PDF and send Email

You can see that the set of external libraries is 34MB of thousands of files and that they are in an external directory that I have called “ ComponentCode ”.

This saves a lot of time in creating the application and also in uploading developments to production.

3.- Work of several developers in the project.

We have already seen that by dividing into modules, the work can be distributed much better in the work team.

If there are several developers working on a single Module, what I have done is that one is dedicated to the “simple” jobs and another works on the difficult parts, developing and integrating external libraries or simply exploiting reports and graphics.

One of the missing options that I understand will be available (I don't know at what stage of the development of version 11 of PHPRunner), is the possibility of copying definitions and code from one project to another.

While this possibility is not available, what I do is write the codes or customization of the PHP events in files in the “Custom File” section that I usually create a directory called “ MyCode ” and in the events what I do is include “MyCode/ file……php”, in this way passing code from one application to another is very simple since it is passing this type of files and doing the includes .

In this way, a lot of progress is made and the tasks can be divided and later integrated into a single PHPRunner project.

This form of construction also makes it easier for me to write and debug the code with the solutions that I have already told you about:

• Guide 22 – Debugging PHP code, line by line . Using NetBeans for PHP.
• Guide 34 – Basic method for code debugging – DEBUG

It is very likely that you will have doubts because some of the concepts that I have tried to explain have not been explained well or because of the simple problem of the language that I have used. For any questions or needs, you can contact me through my email: [fernandohumanes@gmail.com](mailto: fernandohumanes@gmail.com)

As usual, I leave you the sources of the example so that you can install it on your PCs and make the changes you consider appropriate.

Hi Fernando,

thumbs up for your efforts.

Thought of a more modular approach for my largest application too.

But in my eyes, it is not only the external libraries, that make the upload very big, but the fact that the whole structure (basic phprunner functions, CSS, images etc.) of the application has to be uploaded x-times. Furthermore if parts of the modules have many links to each other, I fear that they get hard to maintain.

Perhaps or hopefully v11 will speed up the work with larger projects.

Some great ideas there on how to build bigger projects.

@mbintex I agree, it's all down to speed, hopefully V11 might might larger projects possible in one project. I did try with a large accounting and warehousing system and realised I'd have to break it into modules with PHPRunner, I then decided to go down the pure PHP route.