Manche XML-Attribute, die für das XML-Dokument eine spezielle Bedeutung haben, werden in einigen Versionen des Microsoft DOM-Parsers (, welcher in NanomeCMS verwendet wird,) derart interpretiert, dass sie NanomeCMS beim Parsen des XML-Dokuments nicht mehr zur Verfügung stehen. Eines dieser Attribute ist xmlns. Sollen diese Attribute verwendet werden, müssen sie durch Unterstriche eingeschlossen werden, beispielsweise _xmlns_.
Während Modifikationen des oben genannten Namensraumes (Namespace) sollte der Weg zum Webserver nicht weit sein, auf dem die Anwendung NanomeCMS läuft. Ein Fehler bei der Modifikation kann leicht zum Absturz der Anwendung führen. Grund: In diesem Namensraum befinden sich viele Fehlerbehandlungs-Klassen, die dann zum Einsatz kommen, wenn andere Klassen ungültig sind. Befinden sich die ungütigen Klassen jedoch im selben Namensraum, kann dieser nicht kompiliert werden, und die Fehlerbehandlungs-Klassen stehen ebenfalls nicht zur Verfügung. Es knallt.
Die TCanvas-Operationen in Delphi 2006 (und darunter) haben einen Bug, der sie auf Systemen mit mehreren Kernen in der CPU nicht gut funktionieren lässt. Dadurch werden dynamisch generierte Bilder manchmal nicht korrekt dargestellt, oder es kommt zu einer Ausnahme des Typs EOutOfResource (, die NanomeCMS abfängt). Die Anwendung im Taskmanager auf einen bestimmten Prozessorkern festzulegen, reduziert diese Effekte - wenn sie auch leider nicht vollständig verschwinden.
Nachtrag: durch die Anwendung bestimmter Kniffe und Tricks war es doch noch möglich, die TCanvas-Operationen zur ordentlichen Arbeit zu bewegen. Der Ausnahmetyp EOutOfResources sollte also nicht mehr auftreten können (man bemerke jedoch die leichte Unsicherheit in dieser Formulierung).
Es kann vorkommen, dass es mehrere gleichnamige Objekte im NanomeCMS-Bestand gibt. Wie wird dasjenige Objekt ausgewählt, welches nach der Anforderung eines Browsers tatsächlich angezeigt wird? Zunächst wird geprüft, ob es ein Objekt gibt, das den gewünschten Namen trägt und eine Domainangabe enthält, die genau zur angeforderten Domain passt (NanomeCMS kann beliebig viele Domains verwalten). Ist das der Fall, wird dieses Objekt zurückgeliefert. Wird kein passendes Objekt gefunden, wird eines gesucht, das den gewünschten Namen trägt und keine Domainangabe enthält. Wird ein solches Objekt gefunden, so wird es zurückgeliefert. Anderenfalls wird eine Fehlerseite erzeugt.
Eine besondere Situation tritt dann auf, wenn es zwei gleichnamige Objekte im NanomeCMS-Bestand gibt, von denen eines eine Domainangabe enthält und das andere nicht. Normalerweise würde dann gemäß obiger Definition dasjenige Objekt mit der angegebenen Domain angezeigt werden. Was aber, wenn dieses Objekt augenblicklich als versteckt gekennzeichnet ist? In diesem Fall wird nun tatsächlich das Objekt ohne Domainangabe zurückgeliefert.
Dokumente sind Dateien im htdocs-Verzeichnispfad. Sie werden zunächst in demjenigen Pfad gesucht, welcher der Domain zugeordnet wurde (jeder Domain kann ein beliebiger Pfad zugeordnet werden). Falls das Dokument im htdocs-Verzeichnispfad der Domain nicht gefunden werden konnte, wird es im Standard-htdocs-Pfad gesucht. Ist es auch dort nicht vorhanden, wird eine Fehlerseite erzeugt.
Die Zugriffsberechtigung auf NanomeCMS-Objekte funktioniert sehr ähnlich der in UNIX/Linux. Die Berechtigungsdefinition gliedert sich in drei Kolonnen, die jeweils rwx enthalten. Die linke Kolonne steht für die Berechtigungen des Objektbesitzers, die mittlere für die Berechtigungen derjenigen Rollen, zu denen das Objekt gehört, und die rechte für alle anderen Benutzer. Das r gestattet den lesenden Zugriff im NanomeCMS-Backend, das w den schreibenden Zugriff im Backend und das x den anfordernden Zugriff auf ein Objekt mittels des Browsers (Frontend).
Es gibt sogenannte domain-einschränkende Rollen. In diesen Rollen werden eine oder mehrere Domains benannt. Ist ein Benutzer Mitglied solcher Rollen, so darf er sich ausschließlich auf den benannten Domains bewegen.
Namensräume (Namespaces) werden für Klassen, Objekte und Attribute vergeben: der Namensraum einer Klasse ist immer ihre Pakethierarchie, beginnend mit dem obersten Klassenordner im Dateisystem. Der Namensraum eines Objekts ist ebenfalls seine Pakethierarchie, jedoch ergänzt um den Typ (die Klasse) des Objekts.
Der Namensraum eines Attributs hängt davon ab, ob es sich um ein Klassen-, Objekt- oder Kommandoattribut handelt: Klassenattribute erhalten den Namensraum ihrer Klasse, ergänzt um den Klassennamen. Objektattribute erhalten den Namensraum ihres Objekts, ergänzt um den Typ (die Klasse) des Objekts.
Der Namensraum eines Kommandoattributs hängt davon ab, ob das Ziel des Kommandos eine Klasse oder ein Objekt ist: handelt es sich um eine Zielklasse, so erhält das Attribut den Namensraum dieser Klasse, ergänzt um den Klassennamen. Handelt es sich um ein Zielobjekt, so erhält das Attribut den Namensraum dieses Objekts, ergänzt um den Typ (die Klasse) des Zielobjekts.
Gültige Zeichen für ein NanomeCMS-Attribut sind ausschließlich die großen Buchstaben A-Z, die kleinen Buchstaben a-z, die Ziffern 0-9, der Unter- und Bindestrich, sowie der Punkt als Trennzeichen zwischen dem Namensraum (Namespace) und dem Attributnamen.
Attribute, die von NanomeCMS automatisch aus HTTP-Parametern erzeugt werden, können volatil oder persistent sein. Im ersten Fall müssen sie im Namensraum (Namespace) request erstellt werden, also beispielsweise durch den Aufruf http://localhost/myPage.html?request.myParam=true. Sie gelten dann nur für einen einzigen Seitenaufruf. Wird das Attribut hingegen nicht in request erstellt, so wird es automatisch im Namensraum session (in der Session des Benutzers) abgelegt, und steht für alle künftigen Seitenaufrufe persistent zur Verfügung (bis die Session zeitlich ungültig wird).
Die Liste der in einem Seitenaufruf A verfügbaren Attribute wird in folgender Reihenfolge aufgebaut:
Wird bei der Seitenerstellung von A zusätzlich ein referenziertes Objekt B eingebunden, so werden die Attribute des Objekts B in der oben definierten Reihenfolge an den Anfang der bei der Erstellung von A generierten Liste eingehängt.
Um mittels der in NanomeCMS integrierten Microsoft ActiveX Data Objects (MS ADO) auf Datenbanken zugreifen zu können, ist ein sogenannter OLE-DB-Provider erforderlich. Die folgende Liste zeigt die für verschiedene Datenbanksysteme notwendigen Provider-Strings:
Datenbanksystem | OLE-DB-Provider |
ODBC | MSDASQL |
Oracle | MSDAORA |
Microsoft SQLServer | SQLOLEDB |
Microsoft Access 97 | Microsoft.Jet.OLEDB.3.51 |
Microsoft Access 2000 | Microsoft.Jet.OLEDB.4.0 |
Microsoft Active Directory (ADS) | ADsDSOObject |
Data Shaping Provider | MSDataShape |
In-Memory Database (Windows 2000) | MSIMDB |