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