View Single Post
  #1   Spotlight this post!  
Unread 24-05-2005, 16:39
Astronouth7303's Avatar
Astronouth7303 Astronouth7303 is offline
Why did I come back?
AKA: Jamie Bliss
FRC #4967 (That ONE Team)
Team Role: Mentor
 
Join Date: Jan 2004
Rookie Year: 2004
Location: Grand Rapids, MI
Posts: 2,071
Astronouth7303 has much to be proud ofAstronouth7303 has much to be proud ofAstronouth7303 has much to be proud ofAstronouth7303 has much to be proud ofAstronouth7303 has much to be proud ofAstronouth7303 has much to be proud ofAstronouth7303 has much to be proud ofAstronouth7303 has much to be proud ofAstronouth7303 has much to be proud ofAstronouth7303 has much to be proud of
New Module system

Due to the fact that the current module system is so easily broken, it is going to undergo a massive restructuring. (The first evidence of this is the openfirst.info.php files found in CVS.)

The basic idea is that a module could be installed, uninstalled, or updated without worry about conflictions. This would include DB tables, translations, hooks, or anything else.

There would be several core "modules", which are used by the central code and likely universally. They would include:
  • The Module Manager (installing, uninstalling, and configuring modules)
  • Documentation (the "help files")
  • Users (sessions, option storage, login, permissions)
  • Edit (universal markup parser)
  • Language (translations)
  • Hooks (low-level extensions)

Each of these provides a functionality that is used by several (if not all) modules. They would be implemented mostly as a seperate module, but are used by the core.

The directory structure of modules could be as follows:
  • /<module> - The basic files.
  • /skins/<module> - CSS and images needed by the module
  • /documentation/<module> - documentation for that module.
  • /language/<module> - Translations of the text used in that module.
None of these are required. However, a mature module should have all that are applicable.

Any ideas? Comments?
Reply With Quote