CONTENIDO Forum

Das Datenmodell der Contenido Datenbank erweitern :

in Tabellen
con_properties, con_sytem_properties

eine Spalte
description varchar(255)

hinzufügen, sodass man dort eine kleine Beschreibung einfügen kann. Wäre wichtig zur Dokumentation selbstdefinierter Einstellungen.

Viele andere Tabellen haben ja bereits so eine Spalte description, zB con_type, con_mod, con_lay, etc. Damit wäre das Datenmodell auch einheitlicher.

Für die vordefinierten Systemproperties type, name, value (zB. backend, preferred_idclient, 22) sollte 4fb eine kleine Beschreibung schon in die tabelle eintragen was die Eigenschaft macht. Mit anderen Worten, die Description sollte nicht nur in HTML Dateien in docs/techref/backend angegeben sein. Dort meinetwegen das Konzept etwas ausführlicher beschreiben.

Die Spalte kann auch gerne länger als varchar255 sein.

Die description sollte auch im Backend angezeigt werden.

Das Contenido Objektmodell und API sollten ggf. auch entsprechend erweitert werden.

Also bei der con_system_prop kann ich mir das evtl. noch vorstellen. Bei der con_properties verballert man damit aber schnell Speicherplatz, da die Tabelle ja für beliebige Module/Erweiterungen genutzt werden kann (und zum Teil schon wird).
Bei 1000 Newsletter-Empfängern und 10 Plugins haben wir dann 10000 mal den Text "Hier steht eine tolle Beschreibung drin.", das halte ich nicht für sinnvoll.
Der Vergleich mit con_type, con_mod, con_lay hinkt auch irgendwie. Z.B. gibt es in der con_template natürlich eine Beschreibung, aber nicht in der con_template_conf.

eine description hinzuzufügen ist wirklich nicht sinnvoll...

Es spricht aber nichts dagegen, für eine Property eine Beschreibung als Property zu speichern...

Ich hoffe, das war jetzt verständlich...

Gruß
HerrB

Bei der con_properties verballert man damit aber schnell Speicherplatz, da die Tabelle ja für beliebige Module/Erweiterungen genutzt werden kann (und zum Teil schon wird).
Bei 1000 Newsletter-Empfängern und 10 Plugins haben wir dann 10000 mal den Text "Hier steht eine tolle Beschreibung drin.", das halte ich nicht für sinnvoll.

Der varchar Datentyp allokiert doch nur diejenigen Bytes (von max 255) die auch wirklich belegt werden (deshalb ja auch der Name "varchar" und nicht "char"). Von daher kann ich das Speicherplatzverbrauch Argument nicht nachvollziehen.

Also um ganz genau zu sein: der Datentyp für die vorgeschlagene Property-Description sollte
varchar(255) NULL
heissen. Und er würd auch bei den meisten Einträgen NULL sein.

Bei 1000 Newsletter-Empfängern und 10 Plugins haben wir dann 10000 mal den Text "Hier steht eine tolle Beschreibung drin.", das halte ich nicht für sinnvoll.

Ich habe hier einen mandanten mit 2000 Newsletterrecipients und 2000 Newslettergroupmembers, aber nur 5 einträge in der con_properties mit dem Itemtype clientsetting, type newsletter.
Was ist der zusammenhang zwischen Plugins und Newslettern?

Mein Vorschlag kommt daher, dass ich gerne all die Magic Numbers, die jetzt in unseren Modulen stecken, gerne rausziehen würde in selbstdefinierte "Mandanteneinstellungen". Diese landen nun mal in Tabelle con_properties mit dem Itemtype "clientsetting".
Wäre gut wenn man diese Mandanteneinstellungen zentral "administrieren" könnte, und so hätte man sie auch gleich besser dokumentiert.

Wenn man diese Mandanteneinstellungen alternativ so taggen könnte wie jetzt ein Hochgeladenes File (Itemtype "upload", type "upload", tags wäre medianotes, keywords etc) , wäre mir das auch ganz recht. (Wie's gehen soll weiss ich jetzt auch nicht.). Das war wohl damit gemeint :

Es spricht aber nichts dagegen, für eine Property eine Beschreibung als Property zu speichern.

Systemeinstellungen-Tabelle sollten die Spalte description auf jeden Fall erhalten.

Eine Description wäre sogar in der Tabelle con_sequence sinnvoll, wo dann stehen müsste was die Tabelle enthält und ob sie noch benutzt wird.

knb hat geschrieben:Was ist der zusammenhang zwischen Plugins und Newslettern?

Dabei geht es um (ich war da vorhin nicht genau genug) um die FrontendUser- bzw. Newsletterempfänger-Plugins, mit denen man diese einfach um zusätzliche Daten erweitern kann. Für jede Kombination von FE-User/NL-Empfänger und Plugin wird dann eine Zeile in der con_properties angelegt. Dafür braucht man einfach keine Beschreibung.

Nichtsdestotrotz hast du natürlich recht, dass zumindest die System-, Mandanten-, User-Einstellungen vernünftig dokumentiert werden sollten.

Der Trip geht noch in die falsche Richtung: Die Daten der system_properties usw. werden in Zukunft alle in der con_properties landen und die vorhandenen Tabellen aufgelöst.

Wenn Du pro Newsletter-Recipient wenigstens eine Eigenschaft via Plugin gespeichert hast, hast Du 2000 Einträge in der con_properties - sie haben jedoch einen anderen itemtype und type. Bitte siehe Dir den Code in der class.genericdb.php zur Methode setProperty und getProperty und ggf. beispielhaft ein Empfänger- oder Frontend User-Plugin an.

Wenn Du z.B. ein $oRecipient->setProperty("typ", "bezeichnung", "wert") machst, wobei $oProperty = new Recipient ist, wird ein anderer Eintrag erzeugt (itemtype: idrcp (d.h. der Primary Key), itemid: interne ID des Empfängers, type: "typ", name: "bezeichnung", value: "wert").

Ein itemtype clientsetting entsteht, wenn eine Mandanten-Einstellung vorgenommen wird und ist (leider) ein Sonderfall.

Es wird kein Beschreibungsfeld in der con_properties geben. Es spricht aber - wie erwähnt - nichts dagegen, die Information zu speichern:

Code: Alles auswählen

$oProperties = new PropertyCollection;
$oProperties->changeClient(0);
$oProperties->setValue("property", 0, "description", "wysiwyg;tinymce-styles", "Defines the available styles in the tinyMCE style dropdown.");
$oProperties->setValue("property", 0, "range", "wysiwyg;tinymce-styles", "System, Groups, Users");

Und wieder auszulesen (einzeln):

Code: Alles auswählen

$oProperties = new PropertyCollection;
$oProperties->changeClient(0);
$sDesc = $oProperties->getValue("property", 0, "description", "wysiwyg;tinymce-styles", "");
echo $sDesc;

Und wieder auszulesen (Liste):

Code: Alles auswählen

$oProperties = new PropertyCollection;
$oProperties->changeClient(0);
$oProperties->setWhere("itemtype", "property");
$oProperties->setWhere("itemid", "0");
$oProperties->setWhere("type", "description");
$oProperties->setOrder("name");
$oProperties->query();

while ($oProperty = $oProperties->next())
{
   $aData = explode(";", $oProperty->get("name"), ";");
   echo $aData[0].": ".$aData[1].": ";$oProperty->get("value")."<br />";
}

Die itemid wird auf 0 gesetzt, sie ist ja nicht bekannt. Das changeClient(0) führt dazu, dass die Angabe nur einmal gespeichert wird (als Nachschlagewerk sinnvoll). Sollen nur bestimmte Eigenschaften des einen Mandanten beschrieben werden, braucht man nur jeweils das changeClient wegzulassen...

Ungetestet.

Tatsächlich habe ich sogar vor, dass noch mit der Information "possible_values" und "default_value" dort so zu speichern - das würde nämlich die (optionale) Auswahl der Settings via DropDown ermöglichen, so dass man sich nicht mehr vertippen kann...

Gruß
HerrB

CONTENIDO Forum

spalte description zufügen con_properties, con_sytem_prop

spalte description zufügen con_properties, con_sytem_prop