summaryrefslogtreecommitdiff
path: root/src/lib/DB.class.php
AgeCommit message (Collapse)Author
2011-10-23Refactor to *finally* get rid of the god-class "MessageManager".Luke Shumaker
Accomplish this largely by using singletons. Now, I know this breaks the "build", at least in PHP 5.2. But there's a lot here that's good stuff, so just wait for the next commit. Now, a *LOT* changed, as you can see by the size of the diff; it's about a day and a half of editing worth of editing. I'll describe a little of it, but I'm not going to go into a ton of detail, and won't bother trying to break it into separate commits (they're all so interconnected, it would be mental masturbation). 'Cause I'm the only one looking at it at this point. 1. MessageManager did 3 things: A. Act as a global site class. This has been moved into `lib/Site.class.php' B. Act as a registry for singletons. Now there's a `lib/Singleton.class.php' abstract class to let them manage themselves. : Note: With the possible exception of Database, none of the : : singletons *need* to be singletons, but to create : : multiple of them would be wasteful. : C. Check if the database conf file exists, and if it doesn't show an error message. This has been moved into index.php, and the message has been turned into a proper view. 2. Recognize `Auth.class.php' for what it is, a multiton. Rename Auth::getObj to Auth::getInstance to be consistant with singletons. 3. Make Site->baseUrl() (formerly `MessageManager->baseUrl()') figure the base URL each time, either with or without the database. This way we can be more flexible with initing the Template. 4. Init Template (now a singleton) sanely. We can now use views with no DB. I will use the above to shorten the below file changes: index.php: [1C] Also, just tidy up. src/controllers/Users.class.php: [1B] [2] src/lib/Controller.class.php: [4] src/lib/DB.class.php: [1B] [2] src/lib/Database.class.php: [1B] src/lib/Hasher.class.php: [1B] (new file) A singleton wrapper around `ext/PasswordHash.class.php', use bcrypt while exposing fewer internals. src/lib/Login.class.php: [1B] src/lib/MessageManager.class.php: [1] src/lib/Model.class.php: [1B] (new file) A abstract class for models, so they don't have to worry about initing the DB. src/lib/PluginManager.class.php: [1B] src/lib/Singleton.class.php: [1B] (new file) An abstract class that will take care of being a singleton for you; in order to make a class a singleton, just extend Singleton. src/lib/Site.class.php: [1A] [3] (new file) src/lib/View.class.php: [4] src/models/Auth.class.php: [2] [1B] Also make getUsername safely return false if the DB isn't connected. src/models/ContactMethod: extend `Model' src/views/Template.class.php: [1B] [3] src/views/pages/no-conf.html.php: [1C] src/views/pages/plugins/index.html.php: [1B] src/views/pages/users/500.html.php: [1B]
2011-10-09Merge branch 'master' into concurrent-editingLuke Shumaker
So, here's the deal: * The meat of [concurrent-editing]:Form.class got merged into [master]:DB.class * The string-generation stuff in [concurrent-editing]:Form.class didn't fit nicely anywhere anymore, so I got rid of it by makeing datatype explicit. * Users.class: declare datatypes explicitly in attrib() * index.html.php: use this new explicit data * style.scss: add a .small, which we can do because of the datatypes thing. Conflicts: src/controllers/Users.class.php
2011-10-09Move Users->[gs]etConf into a new DB.class.php, add in some wrappers for ↵Luke Shumaker
equivalent stuff with plugin and system config.