From 6760216e1016b6e9dc6e6905b746a475d6589ca8 Mon Sep 17 00:00:00 2001 From: daniel Date: Fri, 14 Sep 2018 16:08:02 +0200 Subject: [PATCH] remove outdated design.txt. While having an overview of the overall design of MediaWiki in the code repository is a good thing, having an outdated design overview that has not been substantially updated in 15 years is not helpful. This is a fun historical document though, so I have put it up at . Change-Id: I85be15a68f4ab9ac77766112e6484f2007da4eec --- docs/design.txt | 106 ------------------------------------------------ 1 file changed, 106 deletions(-) delete mode 100644 docs/design.txt diff --git a/docs/design.txt b/docs/design.txt deleted file mode 100644 index 5c04addef3..0000000000 --- a/docs/design.txt +++ /dev/null @@ -1,106 +0,0 @@ -design.txt - -This is a brief overview of the new design. - -More thorough and up-to-date information is available on the documentation -wiki at https://www.mediawiki.org/ - -Primary classes: - - User - Encapsulates the state of the user viewing/using the site. Can be queried - for things like the user's settings, name, etc. Handles the details of - getting and saving to the "user" table of the database, and dealing with - sessions and cookies. - - OutputPage - Encapsulates the entire HTML page that will be sent in response to any - server request. It is used by calling its functions to add text, headers, - etc., in any order, and then calling output() to send it all. It could be - easily changed to send incrementally if that becomes useful, but I prefer - the flexibility. This should also do the output encoding. The system - allocates a global one in $wgOut. - - Title - Represents the title of an article, and does all the work of translating - among various forms such as plain text, URL, database key, etc. For - convenience, and for historical reasons, it also represents a few features - of articles that don't involve their text, such as access rights. - See also title.txt. - - Article - Encapsulates access to the "page" table of the database. The object - represents a an article, and maintains state such as text (in Wikitext - format), flags, etc. - - Revision - Encapsulates individual page revision data and access to the - revision/text/blobs storage system. Higher-level code should never touch - text storage directly; this class mediates it. - - Skin - Encapsulates a "look and feel" for the wiki. All of the functions that - render HTML, and make choices about how to render it, are here, and are - called from various other places when needed (most notably, - OutputPage::addWikiText()). The StandardSkin object is a complete - implementation, and is meant to be subclassed with other skins that may - override some of its functions. The User object contains a reference to a - skin (according to that user's preference), and so rather than having a - global skin object we just rely on the global User and get the skin with - $wgUser->getSkin(). - See also skin.txt. - - Language - Represents the language used for incidental text, and also has some - character encoding functions and other locale stuff. The current user - interface language is instantiated as $wgLang, and the local content - language as $wgContLang; be sure to use the *correct* language object - depending upon the circumstances. - See also language.txt. - - Parser - Class used to transform wikitext to html. - - LinkCache - Keeps information on existence of articles. See linkcache.txt. - -Naming/coding conventions: - - These are meant to be descriptive, not dictatorial; I won't presume to tell - you how to program, I'm just describing the methods I chose to use for myself. - If you do choose to follow these guidelines, it will probably be easier for - you to collaborate with others on the project, but if you want to contribute - without bothering, by all means do so (and don't be surprised if I reformat - your code). - - - I have the code indented with tabs to save file size and so that users can - set their tab stops to any depth they like. I use 4-space tab stops, which - work well. I also use K&R brace matching style. I know that's a religious - issue for some, so if you want to use a style that puts opening braces on - the next line, that's OK too, but please don't use a style where closing - braces don't align with either the opening brace on its own line or the - statement that opened the block--that's confusing as hell. - - - Certain functions and class members are marked with /* private */, rather - than being marked as such. This is a hold-over from PHP 4, which didn't - support proper visibilities. You should not access things marked in this - manner outside the class/inheritance line as this code is subjected to be - updated in a manner that enforces this at some time in the near future, and - things will break. New code should use the standard method of setting - visibilities as normal. - - - Globals are particularly evil in PHP; it sets a lot of them automatically - from cookies, query strings, and such, leading to namespace conflicts; when - a variable name is used in a function, it is silently declared as a new - local masking the global, so you'll get weird error because you forgot the - global declaration; lack of static class member variables means you have to - use globals for them, etc. Evil, evil. - - I think I've managed to pare down the number of globals we use to a scant - few dozen or so, and I've prefixed them all with "wg" so you can spot errors - better (odds are, if you see a "wg" variable being used in a function that - doesn't declare it global, that's probably an error). - - Other conventions: Top-level functions are wfFuncname(), names of session - variables are wsName, cookies wcName, and form field values wpName ("p" for - "POST"). -- 2.20.1