Your concept is almost the same as a complete system with restrictions to certain modules. In your case, you are just saying the modules aren't there rather than being restricted. Your idea for having a script that would build the menu is good for a system with user level restrictions because things change depending on who is logged in. But I wouldn't build the menu from scratch every time if you are just checking for modules. The menu should be built when a module is installed or removed. That's the only time it will change anyway.
If you are looking for dynamic discovery of the modules that are present, then you are doing something similar to WDS and UDDI.
On Mar 21, 2005, at 6:56 PM, Chris W. Parker wrote:
Hello,
So I was thinking about building some modularity into future projects and wanted to bounce some ideas off my fellow list members.
My definition of "modular application" is: A modular application is one that can have it's major functions added/removed with the click of a button, or the creating/deleting of a file without breaking the application on any level. The user should be able to add/remove a module* from the filesystem and have the application update itself automatically without any (or very little) interaction with the user of the application.
For example, here is what I've come up with at this point for how a modular application could be built.
First of all there would need to be some kind of script that
controls/integrats/manages the individual modules. I imagine this task
to be performed within an include file that is included at the top of
every file in the application (let's call it adjuster.php). This include
file would determine how to build the main menu based on certain factors
within the applications directory tree. Said another way, this file
would take an inventory of the available modules and build a menu based
on what it found. In this way a module could be added/removed without
any interaction** from the user and the menu would update automatically.
This in and of itself is not difficult. What I think the difficult part of it will be is finding the appropriate way to construct modules. At this point I'm imaging a directory called modules/ where each directory within the modules/ directory is a module itself. It would contain all the classes and functions associated with that module as well as a definition file for that module (could be a simple .txt file). Adjuster.php would read the modules/ directory and recursively discover each module and then build the main menu accordingly.
Having said all that I think what I'm looking for is some feedback from experienced person(s) on the list with building modular applications. I can see this being really helpful for something like a shopping cart, CRM, or CMS app.
Thanks, Chris.
* In the short time I've been thinking about what a "module" is I've determined it to be one of a few things (or a combination thereof). A module could be (a) a single file, (b) a set of files, or (c) a directory containing one or more files and/or directories.
** Not having any interaction with the user does not have to be a requirement, but it would sure be helpful when upgrading the application. For example: Customer comes to your website, buys a new module (or downloads for free, however you choose to license the software), and simply adds it to the module repository. Yadda yadda yadda, a new, full functional menu option is available.
p.s. Are there any lists out there that deal with programming in general?
-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
-- Brent Baisley Systems Architect Landover Associates, Inc. Search & Advisory Services for Advanced Technology Environments p: 212.759.6400/800.759.0577
-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
