--------------------------------------------------------------------------------------
-
-
-Database/Entity:
--------------------------------------------------------------------------------------
-
-
------------ old german stuff ........................................................
-1. Database / Entity Klassen
-
-Die zugrundeliegende Speicherungsschicht wird von den StorageObjekten realisiert. StorageObjekt ist eine generische Klasse, die zur Zeit nur als Datenbankablage realisiert ist. Es waere jedoch mehr oder weniger einfach auch eine Ablage im Filesystem zu implementieren, womit offline-Arbeit mit dem Produktionssystem denkbar waere.
-
-Die Databaseklassen sind als Singletons (es gibt fuer jede Tabelle nur ein Database-Objekt) implementiert und kuemmern sich um den Zugriff auf eine Tabelle in der Datenbank.
-Wird von der Database-Klasse eine Zeile aus der Datenbank ausgelesen, so wird die Zeile als entsprechendes Entity-Objekt repraesentiert. Eine Entity ist also die Objektversion einer Datenbankzeile.
\ No newline at end of file
+-------------------------------------------------------------------------------
+
+- This one is a little grey... It's pretty much a wrapper around Database
+and Entity combined, so it's a half level higher up or so. It's not always
+necessary to use/have a Module either.. A usage example: you can do
+ModuleName.getByWhereClause() and it returns a list of Entities that match
+the query. Like entities you must have a StorageObject to access the DB.
+but unlike Entity, you can start out without one. Modules use Entity and
+Database objects internally. [Actually it uses Database object internally
+and returns Entitys...]
+
+Also I believe the intention was/is that it should be used in place of
+Entity for any *logic* that would normally have to into an Entity as
+Entity should be free of a case specific logic in theory. But that's not
+always true if you use EntityImages as an example, but that seems to be
+because EntityImages needs low-level DB connections.
+
+Producer
+-------------------------------------------------------------------------------
+
+Well, what makes Mir different than other Content Management Systems is
+that it does not generate the content pages dynamically or use simple
+caching methods. Rather it generates static .[s]html files exclusively.
+This makes mir very fast under high viewing loads as it does not use
+servlets for this at all. It also makes it very easy to mirror as the
+mirrors do not have to run any Mir code, they only have to have a static
+webserver. In fact the first site to use Mir, germany.indymedia.org is on
+a whole other machine on another continent than the machine that
+*produces* the static files. Germany.indymedia.org already has 3 mirrors.
+
+The mircoders.producer.* classes are responsible for creating these static
+.html files and the filesystem structure that they reside in. This
+includes files that are article summaries and files that are the whole
+article themselves. Some media types also require Producers.
+
+If the main content *viewing* server is on another host, the FS tree is
+then rsync'ed to the viewing host.
+
+The Producers are called exclusively from the ServletModules in
+mircoders.servlet.*. They are called when a new article/comment is added,
+or when an administrator/moderator makes modifications to the site or when
+a manual update is desired. The method "handle()" is the one that does all
+work it takes parameters that tell it to force update all files even if
+their contents is unchanged, etc.. some Producers take an article ID as an
+argument telling them to create the html page representing the article and
+any summary pages that might be changed due to the addition of the
+article.
+
+Producers of course use Entities, Database, MediaHandler and Module
+objects internally.
+
+A dB field called is_produced is used to determine wether or not an Object
+needs to be produced.
+
+Oh and before I forget, it generates the pages based on a template. It
+uses the Freemarker templating system. Doc on freemarker is available at
+freemarker.sourceforge.net I believe.
+
+TODO: In theory it would be cool if we could abstract the output mechanism
+further to use other types of templates and to generate content other than
+HTML (like WAP for example).
+
+Media Handlers
+-------------------------------------------------------------------------------
+They are kind of helper classes to deal with different representations of
+media types. They are called via the java reflection API. The class names
+are resolved through the media_type table. See
+source/mir/media/MirMedia.java for documentation.
+
+Helper classes
+-------------------------------------------------------------------------------
+mir.misc.* (source/mir/misc/*) contains a bunch of classes that do Regexp,
+file handling and those sorts of things. Always look here first before
+writing such a thing.