Code "modules" - Any good information sources?

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Post Reply
DigitalSynthesis
Forum Newbie
Posts: 3
Joined: Thu Jan 29, 2004 5:27 pm

Code "modules" - Any good information sources?

Post by DigitalSynthesis »

Hello,

What I'm trying to find is good theory using the PHP framework, to develop an API for modular code construction - e.g. "modular" in the sense that I can write a "snap-in" for a site which will either add sets of pages, or control (rewrite? alter the behavior of?) various functions. I am developing a very complex application using PHP and standards-based DHTML as a front-end to a database/ordering system for a large corporation and am at the point of developing a next-generation version. We are seriously looking at making the design of this project extensible in the future, so that new features can be added and the interface can be easily "themed" for various sections of the company (or various sub-companies) in the future, and I am having a very difficult time finding any good documentation on API theory, particularly PHP-based (which throws a nice wrench in the works, seeing as its not an "integrated" environment per se).

I think the "wiki" framework is similar, in that you can add "modules" to a wiki, enable or disable certain components, and download extensions. Where could I find good documentation on the "proper" way to develop such an API for my own PHP-based site?

Thanks a lot! :)
DigitalSynthesis
Forum Newbie
Posts: 3
Joined: Thu Jan 29, 2004 5:27 pm

Post by DigitalSynthesis »

Let me further clarify: I am quite familiar with good OOP theory (not the latest and greatest stuff like all the "design patterns" but certainly good design, proper "code modularity") and I'm not talking about that. I'm talking about best practices for using PHP (in specific) for applications development, and these applications will have to be "modular" in the sense that I will be "creating" multiple versions of them, each containing a different subset of features/modules/interfaces/behaviors from a common superset. Thus code reusability is very high across these versions, and obviously within the various pages / sub-applications for each of these "sites".
jaxn
Forum Commoner
Posts: 55
Joined: Fri Jan 16, 2004 1:50 pm
Location: Nashville, TN

Post by jaxn »

You might be interested in a framework that I have developed with another coder.

It is still in development, but I do have a couple of live sites running on it.

We haven't written install/setup docs yet, but the API is fairly well documented with phpDocumentor.

We are developing the framework in conjunction with a rewrite of an app that I do for my day job. As a result most of our modules are not available since they are property of the company I work for, but the framework is released under the PHP license.

We aren't really trying to get adoption right now as it is still in alpha, but I would be happy to give you a tour and get you started writing your own modules.

Core Enterprise PHP at SourceForge:
http://sourceforge.net/projects/cep

Some documentation is available at http://tekzen.net/cataBlog.php?cbCategory=12&cbPage=43

-Jackson
timvw
DevNet Master
Posts: 4897
Joined: Mon Jan 19, 2004 11:11 pm
Location: Leuven, Belgium

Post by timvw »

I didn't really look into it, but here are some things that come up in my mind now and then:

Why does it seem that everybody is trying to write some sort of switchboard? What's the added value of using that instead of counting on your webserver's abilities to find out that a page exists or not?

I like the libraries stuff, but the isEmail function can use some serious tweaking. The way it is implemented right now, it's better to not implement it.

Subclassing an AppClass doesn't seem very usefull. As the AppClasses have no added value/functions.

The use of implementing your own access/error logging is also unclear to me, because apache and php are better suited to do that job.
jaxn
Forum Commoner
Posts: 55
Joined: Fri Jan 16, 2004 1:50 pm
Location: Nashville, TN

Post by jaxn »

Thanks for giving it a look over. I am going to try to explain what we are thinking with what we are doing.
timvw wrote:Why does it seem that everybody is trying to write some sort of switchboard? What's the added value of using that instead of counting on your webserver's abilities to find out that a page exists or not?
It is much more than that. It also has to do with permissions and dynamic content. though we could also rely on the webserver's ability to handle authentication and permissions, but I have done that before.

timvw wrote:I like the libraries stuff, but the isEmail function can use some serious tweaking. The way it is implemented right now, it's better to not implement it.
Excellent point. What is going on there is that some of the code is an example implementation. We haven't seperated them out into a seperate subpackage of the docs.
The example implementation code are the modules and libraries. As of now, there aren't any core libraries and modules but we hope there will be as we get further.
timvw wrote:Subclassing an AppClass doesn't seem very usefull. As the AppClasses have no added value/functions.
We haven't demonstrated the value of the app classes. Here is the thinking:
Some application may want to override functionality in the core classes of CEP. The core classes are:
- cepModule
- cepWeb
- cepCli
- cepSvc

They handle things that are needed globally by almost all modules. These things are things like authentication, permissions, error checking/handling, etc. The modules that are written extend one of the core classes (cepWeb, cepSvc, cepCli) depending on their scope (web, web service, command line). Those three core classes extend cepModule.

The idea of app classes is that you can use modules that other people have developed even though you are going to use a completely different authentication source or logging method. The app classes are layers in the middle of the inheritance levels so that you can override methods globally without actually touching the core class files.

timvw wrote:The use of implementing your own access/error logging is also unclear to me, because apache and php are better suited to do that job.
When developing web apps there are errors that should be logged and errors that should be displayed. All we have done is put an API in place to make error checking/handling really easy. My experience is that good error handling/checking is often left for later by developers. If it is easy then I am less likely to leave good practice out.

Also, it gives us much more control over the error messages that are displayed/logged. But, if you don't like our error handling, override it in the app classes so that our API uses the default PHP error logging/handling functions (which would be easy to implement). What we are going for first and foremost is a solid API for developing modular applications. We don't want to lock people in to our choices, we just want an API so that modules and libraries can be shared and reused even though there are different underlying architectures.


Like I said before, we aren't to the advocacy stage of the project yet, so I haven't honed the explaination very well. Hell, we haven't honed the API all the way, but "release early, release often" right?

-Jackson
timvw
DevNet Master
Posts: 4897
Joined: Mon Jan 19, 2004 11:11 pm
Location: Leuven, Belgium

Post by timvw »

jaxn wrote:
timvw wrote:Why does it seem that everybody is trying to write some sort of switchboard? What's the added value of using that instead of counting on your webserver's abilities to find out that a page exists or not?
It is much more than that. It also has to do with permissions and dynamic content. though we could also rely on the webserver's ability to handle authentication and permissions, but I have done that before.
But you can also use the authentication functions of your WebApp class without going through that switchboard. Keeps the design exactly the same, only removes the overhead of going through the switchboard all the time.
jaxn wrote: The idea of app classes is that you can use modules that other people have developed even though you are going to use a completely different authentication source or logging method. The app classes are layers in the middle of the inheritance levels so that you can override methods globally without actually touching the core class files.
Ok, if you're point is to derive from the core classes, i can understand. I just didn't/don't see the value of an extra layer that added nothing (thus deriving from the MyAppClasses)

Imho it would be nice to have a module that is nothing more than a container for classes that implement a given interface. For example a ValidationModule where the coder then registers classes like container.addFilter( isValidMailFilter), isAlphaNumericFilter etc, and then calls container.validate(args).

Btw, keep up the good work :) I don't want to sound too negative, because even without documentation it was rather easy to find out how the framework works, so it's certainly a proof of understandable code :)
jaxn
Forum Commoner
Posts: 55
Joined: Fri Jan 16, 2004 1:50 pm
Location: Nashville, TN

Post by jaxn »

timvw wrote:
jaxn wrote:
timvw wrote:Why does it seem that everybody is trying to write some sort of switchboard? What's the added value of using that instead of counting on your webserver's abilities to find out that a page exists or not?
It is much more than that. It also has to do with permissions and dynamic content. though we could also rely on the webserver's ability to handle authentication and permissions, but I have done that before.
But you can also use the authentication functions of your WebApp class without going through that switchboard. Keeps the design exactly the same, only removes the overhead of going through the switchboard all the time.
This is true. The bootstrap.php is something that we like, but it doesn't have to be used. One of the advantages we see is with using "clean urls".

There is a setting in the cep.conf.php file to turn clean urls on and off. There are two methods (cepCreateURL and cepParseURL) that handle creating and parsing requests. If someone didn't want to use bootstrap.php they could set their system up however they want (one file in the webroot per module or page for instance). They would then override those two methods in thei appClass cepMyWeb to pull the script name as $_SERVER['SCRIPT_FILENAME'] as opposed to the constant set in the conf file (or they could make the change in the conf file too I guess).

We are really trying to not lock you in to too much.
timvw wrote:
jaxn wrote: The idea of app classes is that you can use modules that other people have developed even though you are going to use a completely different authentication source or logging method. The app classes are layers in the middle of the inheritance levels so that you can override methods globally without actually touching the core class files.
Ok, if you're point is to derive from the core classes, i can understand. I just didn't/don't see the value of an extra layer that added nothing (thus deriving from the MyAppClasses)
I tried to find a better way. I tried to have the classes extend a dynamic class so that module classes would look something like:

Code: Select all

<?php
define("CEP_APPCLASS_WEB","myWebAppClass");

require_once(CEP_APPCLASS_WEB.".inc.php");

class jaxModule extends CEP_APPCLASS_WEB {
...
}
?>
But... that doesn't work (probably namespace or something). It was a good idea and would remove the appclass layer if it wasn't being used. In the meantime there is an empty layer for some apps. Though the appclasses are a good way to add stuff that you want available globally in your app and we are using them at our day job.
timvw wrote: Imho it would be nice to have a module that is nothing more than a container for classes that implement a given interface. For example a ValidationModule where the coder then registers classes like container.addFilter( isValidMailFilter), isAlphaNumericFilter etc, and then calls container.validate(args).
That does sound cool. We don't have time to focus on the core set of libraries yet, but we would welcome any code contributions. We don't have the project hosted at SourceForge for nothing (hint hint).
timvw wrote: Btw, keep up the good work :) I don't want to sound too negative, because even without documentation it was rather easy to find out how the framework works, so it's certainly a proof of understandable code :)
Thanks. I welcome this kind of dailog and look forward to much more of it as the project matures. It is nice to know it was easy to understand since we have spent very little time trying to explain it.

-Jackson
McGruff
DevNet Master
Posts: 2893
Joined: Thu Jan 30, 2003 8:26 pm
Location: Glasgow, Scotland

Post by McGruff »

timvw wrote:Why does it seem that everybody is trying to write some sort of switchboard? What's the added value of using that instead of counting on your webserver's abilities to find out that a page exists or not?
The client page served up by a dynamic website isn't as closely bound to the http request as in a static site - a front controller is a good option to handle the client-output-to-request mapping as well as all the other stuff going on behind the scenes.
timvw
DevNet Master
Posts: 4897
Joined: Mon Jan 19, 2004 11:11 pm
Location: Leuven, Belgium

Post by timvw »

McGruff wrote:
timvw wrote:Why does it seem that everybody is trying to write some sort of switchboard? What's the added value of using that instead of counting on your webserver's abilities to find out that a page exists or not?
The client page served up by a dynamic website isn't as closely bound to the http request as in a static site - a front controller is a good option to handle the client-output-to-request mapping as well as all the other stuff going on behind the scenes.

I think that in the MVC pattern all input is being validated at the controller, and therefore a switchboard would be nice.

But this is how a see it:

If a client requests a page, the webserver (controller) will know which file is being requested.

Than that file (model) can validate the input, retrieve data from database, and determine which view that should be returned to the client. Opposed to the MVC pattern, i dedide to have the validation done by my model. As my model know's best what input/data it needs (and thus also what rules it are on the data).
DigitalSynthesis
Forum Newbie
Posts: 3
Joined: Thu Jan 29, 2004 5:27 pm

Post by DigitalSynthesis »

Well after following this discussion briefly I can say this: I need to bone up on my "modern" terminology. :) I have also been giving Mojavi a good look-over, and it may well fit what I'm trying to accomplish also. Obviously I am not asking you to make my decision for me, but seeing as a lot of this OOP <-> Web formalization is new to me (not that either the OOP or web concepts are anything new at all - as I said I'm quite familiar with them individually), perhaps you could point at some major areas where you deliberately differentiated your framework from Mojavi's (as I assume you probably looked at it before developing your own) and why you did so. This would give a lot more light on the matter for me than my simply saying "its different, but why?" to myself. :)

Thanks, very much, for posting your framework. The more people become aware of good, well-organized, consistent frameworks, the better the coding quality we can all hope to see in the future for web apps, particularly those of us bucking the micro$oft trend.
McGruff
DevNet Master
Posts: 2893
Joined: Thu Jan 30, 2003 8:26 pm
Location: Glasgow, Scotland

Post by McGruff »

I haven't looked at Mojavi - or any of the others - so 'fraid I can't comment.
jaxn
Forum Commoner
Posts: 55
Joined: Fri Jan 16, 2004 1:50 pm
Location: Nashville, TN

Post by jaxn »

@DigitalSynthesis

We aren't to an advocacy stage really, and we definitely are not trying to enter into comparisons at this stage. I wish we we further along for you so it was easier to compare us to other frameworks. If you have the time to install our framework and develop a test module or two the let me know and I will help you through the process.

What I think is different about CEP is how easy it is to create a module. Here is a hello world module:

Code: Select all

<?php
require_once(CEP_DIR_APP_CLASSES.CEP_CLASSFILE_WEB);

class helloWorld extends cepMyWeb {

    functioncepRunModule() {
        $this->cepSetData('hello world!');
        return true;
    }
}
?>
Now you have a hello world module that you can create multiple page with. It has authentication/permissions and integrates into the site template.

-Jackson
Post Reply