Parameter von Projekt-Objekten im WIM-System
<2015-03-28>
Ergänzend zu allgemein verwen­deten Info-Objekten besitzen Projekt-Objekte des WIM-Systems weitere Para­meter. Die Para­meter werden hier aufge­führt.

Die nachfolgend aufgeführten Parameter ergänzen die Allgemeinen Objektparameter.

Die (wichtigsten) Parameter eines Projekt-Objektes:

APP (Früher: "CLIENT; obligatorisch):

Im APP-Parameter muss eine Modulparameter-Spezifikation (modulParam) stehen, die die oberste Darstellungsebene beschreibt. Das so beschriebene Modul enthält als Item-Module die Module der aktiven Projekte der Anzeige. Ob die Projektdarstellungen als Stapel, Tabelle oder anders dargestellt werden und ob sie z. B. durch Tabs ausgewählt werden können, ist hier festzulegen.

Hier sollte möglichst ein Standard für alle Projekte verwendet werden. Zumindest sollte aber über eine Variantenangabe ein allgemeiner Standard ausgewählt werden können.

CONTENT (hier obligatorisch):

Enthält die Modulparameter für die Darstellung des Projektes (im Browser). Diese legen Aussehen und Funktionalität der Präsentation dieses Projektes fest.

ContextTopics (stark empfohlen):

Enthält eine Objekt-/Werte-Liste mit den Objekt-Spezifikationen derjenigen Themen, die für den aktuellen Nutzungs-Kontext am relevantesten erscheinen. Als Werte zu den jeweiligen Objekt-Spezifikationen wird deren aktuelle Relevanz (-1 .. +1) angegeben. Die Sortierung ist irrelevant.

Als Startwerte sollten bei einem Projekt die für normale (Erst-) Nutzer relevantesten Top-Themen des "Themen-Busches" des Projektes angegeben werden.
Bei Wiederholungs-Nutzern können die Werte aus den lokal (im Browser) gespeicherten Parametern der vorangegangenen Sitzung verwendet werden.

Im Verlauf der Nutzung werden die Kontext-Themen an die aufgerufenen Objekte angepasst. Dieses geschieht nicht abrupt, sondern "gleitend" über mehrere Nutzer-Aktionen hinweg.

Die Kontext-Themen sollten jederzeit vom Nutzer auf die Initial-Werte zurückgesetzt werden können.

CustomerCareMail (obligatorisch):

Die zentrale E-Mail-Adresse zur Kontaktaufnahme.

DEFINITIONS (obligatorisch):

Enthält eine Anzahl von Werte-Definitionen verschiedenen Datentyps. Alle Datenwerte sollten nur wenig Platz belegen, ad diese Definitionen stets schnell und vollständig von der APP geladen werden.

Die Definitionen sind nach Datentyp sortiert. Der DEFINITIONS-Datensatz enthält Parameter mit den Datentyp-Bezeichnern ObjParamSpecs, ObjSpecs, ProjectNames, Texts, etc. die jeweils wiederum einen Datensatz enthalten deren Parameternamen und -werte dann die eigentlichen Definitionen darstellen.

Durch diese kaskadierte Anordnung von Datensätzen können die Definitionen sehr effektiv überprüft und abgfragt werden. Sobald die Definitionen im PROJECT-Modul eingetroffen sind, wird dort eine Kopie unter .$definitions abgelegt. Diese Daten werden aktuell gehalten.

DefaultInfosCategories (obligatorisch):

Für Objekte dieses Projektes, bei denen kein expliziter Wert für den "owners"-Parameter eingetragen ist, werden hier die ObjektSpezifikationen der "Besitzer" eingetragen.

DefaultOwners (obligatorisch):

Eine Liste von Objekt-Kennungen von Nutzerobjekten, die verwendet werden, wenn bei einem Objekt keine eigenen expliziter Owner eingetragen sind.

DefaultTopicsCategories (obligatorisch):

Eine Liste von Objekt-Spezifikationen. Es sind diejenigen Themen-Rubriken des Projektes aufgelistet, deren zugeordnete Themen standardmäßig angezeigt werden.

generalInfosCategories (obligatorisch):

Eine Liste von Objekt-Spezifikationen. Es sind diejenigen Infos-Rubriken des Projektes aufgelistet, deren Infos im Projekt maximal angezeigt werden können.

generalTopicsCategories (obligatorisch):

Eine Liste von Objekt-Spezifikationen. Es sind diejenigen Themen-Rubriken des Projektes aufgelistet, deren Themen im Projekt maximal angezeigt werden können.

latestPublished (automatisch):

Im Backend-Server wird der Wert dieses Parameters aus der Liste aller dem Projekt direkt zugeordneten Infos bestimmt und bei allen Speicher-Operationen (oder explizit angestoßenen Aktualisierungen) an die ggf. neuen Werte angepasst und allen Abonnenten mitgeteilt.

Datenformat: Als erstes ist der Zeitpunkt der letzten Aktualisierung der Liste eingetragen. Danach folgen die Wertepaare mit der jeweiligen Objektkennung und dem PUBLISHED-Wert für alle gelisteten Info-Objekte, sortiert nach Aktualität und allesamt wie üblich durch Leerzeichen getrennt.

latestPublishedLimit (optional):

In einem Projekt können ggf. sehr viele Infos enthalten sein. Damit die Speicherung und Übertragung der Liste der zuletzt veröffentlichten Objekte nicht zu viele Ressourcen benötigt, kann hier eine Begrenzung der Anzahl im Parameter latestPublished gelisteter Objekte angegeben werden.
Fehlt für ein Projekt diese Angabe, wird die Länge der Liste auf 100 begrenzt.

moreLatestPublished (automatisch):

Die Anzahl der Einträge beim latestPublished -Parameter ist eng begrenzt - und manchmal zu knapp bemessen. Für diese Fälle enthält dieser moreLatestPublished -Parameter weitere Einträge, damit dann ein Nutzer dann nur noch im Extremfall ans Ende der Liste gerät ...

Datenformat: Wie latestPublished.

moreLatestPublishedLimit (optional):
Hier wird abgelegt, wie viele Einträge die latestPublished -Liste und die moreLatestPublished -Liste gemeinsam enthalten können.
Fehlt für ein Projekt diese Angabe, wird die gemeinsame Länge der Listen auf 2000 begrenzt.
ReadingRecommendations: (stark empfohlen)

Eine Liste von Beiträgen, die den Nutzern (auf der initial aufgerufenen Startseite) zum Lesen empfohlen werden sollen. Kann automatisiert durch die meistgelesenen oder meist-erstaufgerufenen Beiträge aktualisiert werden.

ProjectAdminMail (obligatorisch):

Die E-Mail-Adresse der Projekt-Administration.

ProjectRelations: (optional)

Angaben zu Art und Möglichkeiten in Bezug auf andere Projekte. Enthält für die betroffenen Projekte "ProjectRelation"-Datensätze.

TechAdminMail (obligatorisch):

Die E-Mail-Adresse der Technik-Administration.

TrustedProjects: (optional)

Liste mit Namen von Projekten, deren Daten direkt in dieses Projekt eingebunden werden dürfen.

Bei Objekten, die aus einem Projekt stammen, das nicht in der Liste verzeichnet ist, erfolgt der Aufruf der Objektes innerhalb der Darstellung der Projektseite "seines" Projektes.

[[Die obige Liste ist noch unvollständig !
... tbd ... ]]

Themen hierzuAssciated topics:

Objektparameter Projekt-Objekte

Das könnte Sie auch interessierenFurther readings:
Allgemeine Objektparameter
Von: @VB <2015-03-20>
Objekte sind Kern des WIM-Systems. Und "Parameter" (also "Datenwerte") sind essentielle Bestandteile der WIM-Objekte. In dieser Info werden Standard-Parameter kurz vorgestellt.   Mehr »
Objektdaten-Status
<2013-01-11>
Zu den in den Servern gespeicherten Objektdaten gibt es pro Objekt jeweils eine Gruppe von Statuswerten die den Zustand der Daten und laufende Aktionen mit ihnen beschreiben.   Mehr »
Daten-Layer und -Aktualisierung
<2013-01-06>
Im WIM-System spielen "Vorlagen" eine bedeutende Rolle. Oftmals wird beim Zugriff auf einen Objekt-Parameter der Wert von einem Vorlage-Objekt geholt.   Mehr »
Internet-Links für openWIM-Entwickler
<2020-03-10>
In den Weiten des Internets gibt es etliche hilfreiche Internetpräsenzen und Dokumente, die für die Entwickler des openWIM-Systems hilfreich sein können. Hier sind einige aufgelistet:   Mehr »
Wie kann man die WIM-App durch vorausschauende Anforderungen von Objektdaten beschleunigen ?
<2014-08-03>
Zwischen der Anforderung von darzustellenden Daten beim Internetserver und der Anlieferung der Daten entsteht eine Wartezeit, die nicht beliebig verkürzt werden kann. Daher können bei Modul-Spezifikationen bereits Daten angefordert werden, die erst etwas später wirklich benötigt werden.   Mehr »
Entrümpeln der (alten) Objekte-Datenbasis
Von: @VB <2015-03-16>
In den alten Datenbasen haben sich im Laufe der Jahre viele Objekte angesammelt, die an dieser Stelle sehr wahrscheinlich nie wieder benötigt werden. Hier soll erläutert werden, wie man sie automatisiert wieder los wird und die Datenbasis entschlackt.
   Mehr »
Datentypen von WIM-Datensätzen (wimRecord)
<2014-03-15>
WIM-Records mit gleicher Datenstruktur sollten immer vom gleichen "Datentyp" sein. Die wichtigsten Datentypen sollen hier gelistet werden.   Mehr »
ModuleSpec -Datensätze im WIM-System
<2014-05-25>
Der Datentyp "ModuleSpec" dient zur Definition von Modulen. Die entsprechenden Datensätze können verschiedenste Parameter enthalten, die hier beschrieben werden.   Mehr »
Ausnahme-Situationen:
Wie kann man mit "Unerwartetem" umgehen?
<2019-04-14>
Wie sollte in konkret unvorhergesehene Ereignisse und Situationen agiert werden? Wie sollten try und catch etc. sowie Problem-Einträge in Logfiles und Nutzer-Benachrichtigungen eingesetzt werden?   Mehr »
"Strukturierte" String-Daten in Parameterwerten beim WIM-System
<2013-05-19>
Manche String-Daten im WIM-System werden auf spezielle Weise interpretiert. Sie stellen oft eine kompakte Form von Datensätzen dar, von denen nur die Parameterwerte speziell angeordnet abgelegt werden.   Mehr »
Die Bildrechte werden in der Online-Version angegeben.For copyright notice look at the online version.

Bildrechte zu den in diese Datei eingebundenen Bild-Dateien:

Hinweise:
1. Die Bilder sind in der Reihenfolge ihres ersten Auftretens (im Quelltext dieser Seite) angeordnet.
2. Beim Anklicken eines der nachfolgenden Bezeichnungen, wird das zugehörige Bild angezeigt.
3, Die Bildrechte-Liste wird normalerweise nicht mitgedruckt,
4. Bildname und Rechteinhaber sind jeweils im Dateinamen des Bildes enthalten.