Caffeine Web Framework

Planned Development

(0)

Author	Message
Admin 2009.02.10 20:02:48	This topic is meant to serve as an overview of the framework features that are being developed right now, or seen as relatively short-term candidates for being developed. Framework Core: - Security. Session-free text CAPTCHAs. CSRF forgery prevention mechanism. Advanced session management (optional IP binding, timed regeneration). HTML input filtering. (Many of those are in the repository already.) - Package management system written in pure PHP. The goal it to have a system where an administrator can install/remove software through the web interface, without messing with FTP or command line. Packages will be zip-based. (Some classes for this are also in the repository.) - Email subscription. There should be a central router that allows to deal with email notifications on the logical level. Individual modules should not deal with messy details like subscribing, unsubscribing and scheduling for notifications. Modules: - User profiles. Users should be able to enter contact information for others to see. - Private messages. - Full-fledged forum package.
Admin 2009.06.30 22:06:05	Since PHP 5.3 was just released, it is necessary think about how the Framework could use its new features. Many of the uses are quite obvious and natural, the way the Framework is written: 1. Get rid of "throwaway objects", i.e. the need to create an object to call certain methods, which use none of the objects' properties. Late static binding would finally make static methods a feasible replacement. This alone warrants a rewrite of the core codebase, since it would have a lot of design implications for Module and Record classes, as well as many others. Methods like Module#permits and Record#delete are currently dynamic only because of inheritance. In fact, all Module derivatives are completely static by design. 2. Use __callStatic whenever applicable. I cannot immediately recall any classes that would benefit from it, but it's a useful construct that can reduce the codebase in some cases. 3. Use Phar to manage packages. This would require moving package manager out of alpha state first, though. 4. Possibly, use namespaces. "Possibly", because the way they are done, their use would result in more, not less code being written with no benefit, aside from avoiding hypothetical name collisions. The additional code would be mostly boilerplate. 5. Rewrite modules to use lambda functions when applicable, because this can simplify some of the classes. 6. Use SPL for class autoloading. Possibly, use an ini_set to point to the libs/ directory, so that the default autoloading function could be used instead of out own. A lot of these changes will work better with the version of the framework that's in the svn right now. Among other things, that version has a vastly simplified Record class (called SimpleRecord) and a Module class replacement that's made of SimpleModule and ComplexModule. Overall, this warrants a complete rewrite.

Author

Message

Admin
2009.02.10 20:02:48

This topic is meant to serve as an overview of the framework features that are being developed right now, or seen as relatively short-term candidates for being developed.

Framework Core:
- Security. Session-free text CAPTCHAs. CSRF forgery prevention mechanism. Advanced session management (optional IP binding, timed regeneration). HTML input filtering. (Many of those are in the repository already.)
- Package management system written in pure PHP. The goal it to have a system where an administrator can install/remove software through the web interface, without messing with FTP or command line. Packages will be zip-based. (Some classes for this are also in the repository.)
- Email subscription. There should be a central router that allows to deal with email notifications on the logical level. Individual modules should not deal with messy details like subscribing, unsubscribing and scheduling for notifications.

Modules:
- User profiles. Users should be able to enter contact information for others to see.
- Private messages.
- Full-fledged forum package.

Admin
2009.06.30 22:06:05

Since PHP 5.3 was just released, it is necessary think about how the Framework could use its new features. Many of the uses are quite obvious and natural, the way the Framework is written:

1. Get rid of "throwaway objects", i.e. the need to create an object to call certain methods, which use none of the objects' properties. Late static binding would finally make static methods a feasible replacement. This alone warrants a rewrite of the core codebase, since it would have a lot of design implications for Module and Record classes, as well as many others.

Methods like Module#permits and Record#delete are currently dynamic only because of inheritance. In fact, all Module derivatives are completely static by design.

2. Use __callStatic whenever applicable. I cannot immediately recall any classes that would benefit from it, but it's a useful construct that can reduce the codebase in some cases.

3. Use Phar to manage packages. This would require moving package manager out of alpha state first, though.

4. Possibly, use namespaces. "Possibly", because the way they are done, their use would result in more, not less code being written with no benefit, aside from avoiding hypothetical name collisions. The additional code would be mostly boilerplate.

5. Rewrite modules to use lambda functions when applicable, because this can simplify some of the classes.

6. Use SPL for class autoloading. Possibly, use an ini_set to point to the libs/ directory, so that the default autoloading function could be used instead of out own.

A lot of these changes will work better with the version of the framework that's in the svn right now. Among other things, that version has a vastly simplified Record class (called SimpleRecord) and a Module class replacement that's made of SimpleModule and ComplexModule.

Overall, this warrants a complete rewrite.

Name:	Password:	Want to register?