From 8f42ee3fbd7a058cd51c85be0ec970ae5703b682 Mon Sep 17 00:00:00 2001 From: Luke Shumaker Date: Sun, 25 Sep 2011 16:21:01 -0700 Subject: Remove obsolete sections from README.txt --- README.txt | 61 ------------------------------------------------------------- 1 file changed, 61 deletions(-) diff --git a/README.txt b/README.txt index e1a7280..5a8f065 100644 --- a/README.txt +++ b/README.txt @@ -5,64 +5,6 @@ MessageManager is a mailing list program, much like GNU Mailman, but with sub-lists, SMS messages, and easier configuration. Also, social networking. -MVC/ICM/PAC ------------ - -So there's a bit of a controversy on what MVC actually is (namely, the -C). `Controller' is an ambiguous word, it means something different -in each of the above acronyms. - -A common (mis)interpretation of MVC is actually more correctly -described as ICM. In this (mis)interpretation `controller' is the -logic glue between the model and the view, where the original/correct -interpretation of MVC has the controller being the user's feedback, -which is considered part of of the view in this (mis)intrepretation. -This (mis)interpretation is ICM (view=interface). Because of this, in -several places (here, and in code), I refer to interfaces as views. So -sue me. - -MessageManager sort of has a interface-controller-model. - -But it also has a bit of a God Class going on. This might be -considered the controller in a PAC architecture. But that would -require me to rework this section, and I want to get back to coding. - -The relationship between ICM and PAC is: - ICM - P AC - -We've got our main, "God" class, `MessageManager'. It basically does -three things: - 1. abstract away all database access - 2. handle authentication (which is just #1 with password hashing) - 3. serve as a factory for all the other resources we may need - -There are 4 objects that are models: - - User - - Group - - Message - - Plugin -These have a little logic in them, but are mostly just wrappers around -the various database getX and setX methods in MessageManager. The -coolest thing that they do is handle permissions on whether the -currently logged in user can read or write to them. - -The interface is in the directory `src/views' (the directory name -comes from the incorrect interpretation of MVC). The Template class -provides a pretty low-level wrapper for (X)HTML, that should make -converting fairly painless, and makes it easier to generate pretty, -valid markup. It also handles a few common cases (mostly form stuff). -These do a lot of what could be considered belonging to a controller, -but that is because most of what they do is directly operate on the -models, and any controller behavior is just validating/parsing data -from the view, and is view-specific. There were too many `and's in -that last sentence. - -The controllers are basically made up of MessageHandler and the -plugins (which plugins to MessageHandler). They are in charge of -parsing incoming messages, storing them into our message store, and -sending them out to recipients. - RESTful ------- @@ -109,9 +51,6 @@ BUGS/TODO 2. During stage 2 (first user creation) the stylesheet is not applied (probably due to number 1) 3. The created user is not activated. -* users/index - 4. It is impossible to de-activate a user (that field is only sent - if the box is checked, so you uncheck it, but that's never sent). The End ------- -- cgit v1.2.3