Lauri Vain wrote: > Hello there, Hello
> > I'm seriously researching some aspects of writing a content management > system that would be 'relatively' easy to extend. > > My biggest problem is the ground level -- how should the central system > (that registers modules) work? Ideally, it should be possible to easily > extended the system -- running the install.php file (or something > similar) will tell (insert new database rows or will add new rows to the > configuration file) the central module that a new module was just added > and also gives instructions, how to use it, with which other modules it > integrates and where the new files are. I think you're attacking the wrong problem first, especially coming up with a system which defines what modules something else can 'integrate' with. If your modules are designed as essentially standalone pieces of code, any of them should be able to 'integrate' (or, perhaps a better term, interoperate) with each other with little pain, even if it's not what was originally designed for one or more of the pieces of code in question. You'd do better to focus on a common i/o system which the core system uses to talk to each module. > > The basic idea is that modifications to existing files (modules) > shouldn't be made (except the central module, which handles all others). > Each module should be totally *independent*, but should still integrate > with the rest of the modules (when marked as possible in the database). > What I mean by 'integrate' is the following: there are two modules, for > example, "image gallery" and "articles". Both of them should appear in > "What's new" part (when the appropriate checkbox will be checked). Also, > it would be nice when one could choose the option "Publish to articles" > when inserting a new image gallery (a client event for example -- story > in pictures). Yes, that's a simplified example. You need to better define a module, I guess. I our case (with http://www.logicreate.com) a 'module' is a separate section of code pieces. Sometimes as little as two (one logic/one display) and sometimes many more). Our 'forum' system, for example, has I believe 8 files. Your requirement about *never* changing any files is, imo, impossible. *something* will always need to be changed for various implementations, even if it's just one visual change someone wants. > > So, the problem is that there might only be the "article" module at > first. Later, the "articles" and "What's new" module will be added and > all three of them should now work together. I hope you catch my drift. > You could possibly look at phpgroupware.org to see how they implement the 'addition' of modules (different from how we handle it, but perhaps a bit more in line with what you're describing) > I have quite a few ideas, but I'm sure that our team is just > re-inventing the wheel. What are your experiences? Are there any good > books on the subject of creating an extendable content management system > (preferably from the coders point of view, but not language-specific). > > Thanks, > Lauri Michael Kimsal http://www.phphelpdesk.com 734-480-9961 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
