Forum Moderators: coopster

Message Too Old, No Replies

PHP Script Modules

         

lobo235

9:12 pm on Nov 18, 2005 (gmt 0)

10+ Year Member



I have written a PHP application that numerous companies are paying to use. There are a few companies that request features to be added to the application that don't always benefit the other companies using it. In these situations I have typically used a few if and else statements to use the new functionality for that company but leave the default funcionality intact for everyone else. There are lots of these little "features" in the system and the code is becoming spaghetti code. I need a way to organize these features.

Are there better ways of doing this? What I would like to ultimately acheive is a way to add the new functionality as a module or something that can be turned on and off for each company depending on their preference. I have been brainstorming on this topic for a while now and I can't seem to come up with any simple solutions. Any ideas you have are greatly appreciated!

coopster

5:32 pm on Nov 30, 2005 (gmt 0)

WebmasterWorld Administrator 10+ Year Member



How about putting the base code into "versioned" directories? Then in each company-specific organization scheme that you have (virtual host driven, database-driven, etc) you identify which version they are using or allowed to use?

dmorison

5:59 pm on Nov 30, 2005 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



(..i'm assuming we're talking about a web app rather than a distributed product here..)

What Coopster is describing is developing a platform for your web app that executes the first two A's of "AAA" - Authentication and Authorisation (the 3rd A is "Accounting").

Rather than simply having a login through which all authenticated users are considered equal; you develop your application in such a way that having authenticated a user, you then say "Now what is this user allowed to do?".

This "authorisation" feature of your web app can then drive what menu options are visible to that user, and also moderate access to individual scripts within your app.

Typically; this is done by creating "roles". Your system should define a default role, something like "Authenticated User"; through which access to all generic functionality is controlled such as managing their user profile (change password etc.).

In addition; every user could also be associated with a role name that is equal to their username (or perhaps account ID). The first benefit of doing this is that you can create a feature for one customer, and control their access to it through the exact same role management interface that controls access to functions available to groups - no more spaghetti code!

Extending that benefit; if the feature that was initially specific to a client (perhaps they agreed to alpha test it with you) is then ready to be rolled out to more users; you simply create a new role that control access to the feature; and give all your beta testers that role (including your original customer).

The techniques required to do this are straight forward - a simple database schema and basic SQL queries are all that is required to implement role based authorisation in your app, and therefore I doubt you will find much benefit in trying to find an existing product or codebase that will make doing this any quicker than rolling your own solution.

Hope this helps!

lobo235

6:17 pm on Nov 30, 2005 (gmt 0)

10+ Year Member



That's an excellent idea. In the past I have just given the new version to everyone and sometimes it has caused problems for them and I've had to make additional modifications.

I also have come up with a system to manage specific features. I have determined a default set of features that all of the companies use. Everything else is a feature and I have put the code for those features into separate files. I then have a prefs table that I use to see if a particular company uses the feature, if they do use it I include the file that has the code for that feature. If they do not use the feature it will just use the default behavior. In many cases I have to change/add code in many scripts to add a feature so I just create a separate file to be included at each one of those points. This helps to keep the code to a manageable size and makes it easier to turn features on and off at will.