Zugriff auf CMS_VAR im Output teil
-
- Beiträge: 101
- Registriert: So 21. Nov 2004, 23:48
- Kontaktdaten:
Zugriff auf CMS_VAR im Output teil
Hallo zusammen,
ich darf nach längerer Zeit wieder ein Contenido Projekt anpacken und einiges ergänzen. Jetzt habe ich folgendes Problem:
Ein Webseitenbesucher kann auf der Webseite verschiedene Checkboxoptionen auswählen. Sehr gerne würde ich jetzt in einer CMS_VALUE Variable mitzählen wie oft eine bestimmte Option ausgewählt wurde. Leider ist ja der direkte Zugriff auf CMS_VAR nicht möglich im Outputteil und in der Datenbank sind die Variablen sehr umständlich gespeichert.
Hat jemand eine Idee wie es am einfachsten umzusetzen ist ?
Gruss
Georg
ich darf nach längerer Zeit wieder ein Contenido Projekt anpacken und einiges ergänzen. Jetzt habe ich folgendes Problem:
Ein Webseitenbesucher kann auf der Webseite verschiedene Checkboxoptionen auswählen. Sehr gerne würde ich jetzt in einer CMS_VALUE Variable mitzählen wie oft eine bestimmte Option ausgewählt wurde. Leider ist ja der direkte Zugriff auf CMS_VAR nicht möglich im Outputteil und in der Datenbank sind die Variablen sehr umständlich gespeichert.
Hat jemand eine Idee wie es am einfachsten umzusetzen ist ?
Gruss
Georg
-
- Beiträge: 4254
- Registriert: Do 30. Jun 2005, 22:56
- Wohnort: Eltmann, Unterfranken, Bayern
- Kontaktdaten:
Re: Zugriff auf CMS_VAR im Output teil
Hallo Georg,
warum nimmst du nicht eine einfache Textdatei und zählst dort deine Zähler hoch?
Gruß aus Franken
Ortwin
warum nimmst du nicht eine einfache Textdatei und zählst dort deine Zähler hoch?
Gruß aus Franken
Ortwin
ConLite 2.1, alternatives und stabiles Update von Contenido 4.8.x unter PHP 7.x - Download und Repo auf Gitport.de
phpBO Search Advanced - das Suchwort-Plugin für CONTENIDO 4.9
Mein Entwickler-Blog
phpBO Search Advanced - das Suchwort-Plugin für CONTENIDO 4.9
Mein Entwickler-Blog
-
- Beiträge: 101
- Registriert: So 21. Nov 2004, 23:48
- Kontaktdaten:
Re: Zugriff auf CMS_VAR im Output teil
das wäre zu einfach
nein, natürlich hast du recht, sehr gute idee sogar.
bleibt aber die frage ob es über die datenbank irgendwie geht
Danke
Gruss
Georg
nein, natürlich hast du recht, sehr gute idee sogar.
bleibt aber die frage ob es über die datenbank irgendwie geht
Danke
Gruss
Georg
-
- Beiträge: 4254
- Registriert: Do 30. Jun 2005, 22:56
- Wohnort: Eltmann, Unterfranken, Bayern
- Kontaktdaten:
Re: Zugriff auf CMS_VAR im Output teil
Hmm ja, das dachte ich mir...ctschorsch hat geschrieben:das wäre zu einfach
Definitiv, am einfachsten über eine Mandanten-Propertie. Dafür gibt es Funktionen sowohl zum Setzen als auch zum Lesen.ctschorsch hat geschrieben:bleibt aber die frage ob es über die datenbank irgendwie geht
Ich denke aber das es mit einer Datei einfacher und performanter geht. Für solche "Merker" versuche ich DB-Zugriffe zu vermeiden, da sich dort allein schon der Verbindungsaufbau zur DB nicht rechnet.
Gruß aus Franken
Ortwin
ConLite 2.1, alternatives und stabiles Update von Contenido 4.8.x unter PHP 7.x - Download und Repo auf Gitport.de
phpBO Search Advanced - das Suchwort-Plugin für CONTENIDO 4.9
Mein Entwickler-Blog
phpBO Search Advanced - das Suchwort-Plugin für CONTENIDO 4.9
Mein Entwickler-Blog
Re: Zugriff auf CMS_VAR im Output teil
Diese sind zum Zählen einigermassen schlecht geeignet, da diese nicht typengerecht sind. Es handelt sich dabei um ein Quasi-EAV. Bloss, dass alle Werte als Typ Text gespeichert sind. Grundsätzlich möglich, jedoch aus meiner Sicht wenig praktikabel.Oldperl hat geschrieben:Definitiv, am einfachsten über eine Mandanten-Propertie. Dafür gibt es Funktionen sowohl zum Setzen als auch zum Lesen.
Die Datenbankverbindung steht zu diesem Zeitpunkt ja schon. Typischerweise sogar mehrfach. Also mindestens eine offene Verbindung steht sicher. Im Modulbereich über die globale Variable $db. Wenn die Verbindung steht, läuft ein Update in deutlich weniger als 1 ms ab. Das Dateisystem ist in der Tat sehr schnell; diese zusätzliche Leistungseinbusse tritt jedoch nur bei einer Interaktion auf und darf als marginal angesehen werden. Gegen das Dateisystem spricht die Art und Weise, wie ein Zugriff für ein sicheres Zählen vorgenommen werden müsste. Also sperren, auslesen, hochzählen, schreiben und anschliessend wieder sperren. Und das auch gleich noch mehrfach. Man sollte dabei nicht vergessen, dass mehrere Anwender gleichzeitig einen Schreibzugriff vornehmen könnten. Und dazu ist eine Sperre erforderlich.Oldperl hat geschrieben:Ich denke aber das es mit einer Datei einfacher und performanter geht. Für solche "Merker" versuche ich DB-Zugriffe zu vermeiden, da sich dort allein schon der Verbindungsaufbau zur DB nicht rechnet.
Die einfachste Lösung dürfte deshalb die DB sein. Also eine Tabelle mit Bezug zum Artikel (idartlang), zur Checkbox (je nachdem als Relation oder auch als Varchar) sowie ein Integer, der die Anzahl Klicks repräsentiert. Also zum Beispiel so:
Code: Alles auswählen
CREATE TABLE `mytable` (
`idartlang` INT UNSIGNED NOT NULL ,
`id` VARCHAR( 255 ) NOT NULL ,
`checks` INT UNSIGNED NOT NULL DEFAULT '0',
PRIMARY KEY ( `idartlang` , `id` )
) ENGINE = MYISAM ;
Code: Alles auswählen
update mytable set checks = checks + 1 where idartlang = 12 and id = 'myCheckBox';
Wenn man bereit ist, die con_art_lang in eine innoDB-Tabelle umzustellen (das hat ansonsten keine negativen Konsequenzen), dann kann man auch eine automatische Löschweitergabe zu diesen Informationen vornehmen.
aitsu.org :: schnell - flexibel - komfortabel :: Version 2.2.0 (since June 22, 2011) (jetzt mit dual license GPL/kommerziell)
-
- Beiträge: 4254
- Registriert: Do 30. Jun 2005, 22:56
- Wohnort: Eltmann, Unterfranken, Bayern
- Kontaktdaten:
Re: Zugriff auf CMS_VAR im Output teil
Hmmm
Natürlich kann man nun (wieder mal) aus einer Mücke einen Elefanten machen.
Der Kollege wollte einen einfachen Mehrfachzähler. Dazu bietet sich immer eine Zählerdatei an.
Und auch in der DB müßte ich entsprechend Massnahmen für ein "sicheres Zählen" vorhalten.
Aber wie auch immer, mag es Jeder machen wie er will, ich hab anderes zu tun als deswegen eine Grundsatzdiskussion vom Zaun zu brechen.
Gruß aus Franken
Ortwin
Natürlich kann man nun (wieder mal) aus einer Mücke einen Elefanten machen.
Der Kollege wollte einen einfachen Mehrfachzähler. Dazu bietet sich immer eine Zählerdatei an.
Ganz im Gegenteil, da ich hier nur einfache einstellige Zähler habe, kann ich diese problemlos in einer Datei unterbringen, zumal offensichtlich deren Anzahl bekannt ist.kummer hat geschrieben:Gegen das Dateisystem spricht die Art und Weise, wie ein Zugriff für ein sicheres Zählen vorgenommen werden müsste. Also sperren, auslesen, hochzählen, schreiben und anschliessend wieder sperren. Und das auch gleich noch mehrfach.
Und auch in der DB müßte ich entsprechend Massnahmen für ein "sicheres Zählen" vorhalten.
Aber wie auch immer, mag es Jeder machen wie er will, ich hab anderes zu tun als deswegen eine Grundsatzdiskussion vom Zaun zu brechen.
Gruß aus Franken
Ortwin
ConLite 2.1, alternatives und stabiles Update von Contenido 4.8.x unter PHP 7.x - Download und Repo auf Gitport.de
phpBO Search Advanced - das Suchwort-Plugin für CONTENIDO 4.9
Mein Entwickler-Blog
phpBO Search Advanced - das Suchwort-Plugin für CONTENIDO 4.9
Mein Entwickler-Blog
Re: Zugriff auf CMS_VAR im Output teil
Man mag über einiges unterschiedlicher Meinung sein. Klar. Aber sperren musst du in der DB gar nichts. Genau dazu ist sie da. Im Dateisystem hingegen hat du keine Transaktionssicherheit. Du musst also den Wert auslesen, dann um eins erhöhen und anschliessend wieder speichern. Wenn bei zwei gleichzeitigen Zugriffen die Datei geöffnet wird, erhalten beide Requests denselben Wert und speichern folglich auch wieder denselben. Dann ist der Wert jedoch nur um eins hochgezählt worden, anstatt um zwei, wie es richtig wäre. Bei der vorgeschlagenen Variante mit einem Update ist das nicht der Fall, da dieser Abfrage als Einzeltransaktion abgesetzt wird und eine Interferenz mit einem anderen simultanen Zugriff ausgeschlossen ist.
Dann zur Frage der Einfachheit. Wenn man es in der DB macht, genügt für das ganze eine einzige Zeile; die Verbindung zur DB steht längst (Contenido hat zu diesem Zeitpunkt bereits mehrere Dutzend Abfragen abgesetzt). Bei der Variante Dateisystem musst du die Datei zunächst verriegeln, dann öffnen, den Wert auslesen, um eins erhöhen, speichern und die Verriegelung wieder frei geben. Das sind dann mindestens 7 Zeilen. Sind nicht alle Zähler in der gleichen Datei ist das dann für jede selektierte Checkbox zu wiederholen. Beim Update kannst du alle betroffenen Zähler gleichzeitig erhöhen (vgl. Beispiel). Bei aller Leistung, die ein Dateisystem aufweist, ist das bereits bei nur einer Checkbox langsamer und verschlechtert sich mit jeder weiteren.
Soweit ich das sehe, wurde nachgefragt, wie er es am einfachsten lösen könne. Eine Zeile dürfte die einfachste Variante repräsentieren. Denn bei aller Einfachheit soll das Resultat ja zutreffend sein, nehme ich mindestens mal an. Ausserdem ist anzunehmen, dass diese Daten ja dann auch noch irgendwo angezeigt werden sollen. Womöglich mit Bezug zum Artikel. Dann wird es im Dateisystem immer komplizierter.
Wer sich von hinten rum durch's Knie bohrt, darf sich dann nicht wundern, wenn die Systemleistung nachlässt und die Resultate unerwartet ausfallen.
Dann zur Frage der Einfachheit. Wenn man es in der DB macht, genügt für das ganze eine einzige Zeile; die Verbindung zur DB steht längst (Contenido hat zu diesem Zeitpunkt bereits mehrere Dutzend Abfragen abgesetzt). Bei der Variante Dateisystem musst du die Datei zunächst verriegeln, dann öffnen, den Wert auslesen, um eins erhöhen, speichern und die Verriegelung wieder frei geben. Das sind dann mindestens 7 Zeilen. Sind nicht alle Zähler in der gleichen Datei ist das dann für jede selektierte Checkbox zu wiederholen. Beim Update kannst du alle betroffenen Zähler gleichzeitig erhöhen (vgl. Beispiel). Bei aller Leistung, die ein Dateisystem aufweist, ist das bereits bei nur einer Checkbox langsamer und verschlechtert sich mit jeder weiteren.
Code: Alles auswählen
update mytable set checks = checks + 1 where idartlang = 12 and id in ('myCheckBox', 'myOhterCheckBox', 'andEvenAThirdOne');
Wer sich von hinten rum durch's Knie bohrt, darf sich dann nicht wundern, wenn die Systemleistung nachlässt und die Resultate unerwartet ausfallen.
Tja, dieser Meinung darf man durchaus sein. Ein Blick in die Dokumentation (http://dev.mysql.com/doc/refman/5.0/en/update.html) verrät dir vielleicht beim aufmerksamen lesen, dass das nicht zutreffend ist.Oldperl hat geschrieben:Und auch in der DB müßte ich entsprechend Massnahmen für ein "sicheres Zählen" vorhalten.
aitsu.org :: schnell - flexibel - komfortabel :: Version 2.2.0 (since June 22, 2011) (jetzt mit dual license GPL/kommerziell)
-
- Beiträge: 101
- Registriert: So 21. Nov 2004, 23:48
- Kontaktdaten:
Re: Zugriff auf CMS_VAR im Output teil
Tach zusammen,
hui, da hab ich ja ne Diskussion losgebrochen das tut mir leid. Vielen Dank auf jeden Fall für die hilfreichen Tips.
Ich werde wohl die Variante von kummer nutzen, da ich das Problem mit dem gleichzeitigen Zugriff schon für problematisch halte und ich da bei Datenbanken ein besseres Gefühl habe.
Ich hab verdrängt das ich nicht nur auf die Contenidotabellen zugreifen kann, sonder beliebige eigene machen kann )
Danke an alle für das abnehmen des Bretts von meinem Kopf
Gruss aus dem sonnigen Aachen
Georg
hui, da hab ich ja ne Diskussion losgebrochen das tut mir leid. Vielen Dank auf jeden Fall für die hilfreichen Tips.
Ich werde wohl die Variante von kummer nutzen, da ich das Problem mit dem gleichzeitigen Zugriff schon für problematisch halte und ich da bei Datenbanken ein besseres Gefühl habe.
Ich hab verdrängt das ich nicht nur auf die Contenidotabellen zugreifen kann, sonder beliebige eigene machen kann )
Danke an alle für das abnehmen des Bretts von meinem Kopf
Gruss aus dem sonnigen Aachen
Georg
-
- Beiträge: 4254
- Registriert: Do 30. Jun 2005, 22:56
- Wohnort: Eltmann, Unterfranken, Bayern
- Kontaktdaten:
Re: Zugriff auf CMS_VAR im Output teil
Hallo Georg,
na dann ist das Problem ja gelöst.
Gruß aus Franken
Ortwin
na dann ist das Problem ja gelöst.
Gruß aus Franken
Ortwin
ConLite 2.1, alternatives und stabiles Update von Contenido 4.8.x unter PHP 7.x - Download und Repo auf Gitport.de
phpBO Search Advanced - das Suchwort-Plugin für CONTENIDO 4.9
Mein Entwickler-Blog
phpBO Search Advanced - das Suchwort-Plugin für CONTENIDO 4.9
Mein Entwickler-Blog
Re: Zugriff auf CMS_VAR im Output teil
Kein Problem. Das braucht dir nicht leid zu tun. Immerhin nimmt ja freiwillig an einer solchen Diskussion teil.ctschorsch hat geschrieben:hui, da hab ich ja ne Diskussion losgebrochen das tut mir leid.
aitsu.org :: schnell - flexibel - komfortabel :: Version 2.2.0 (since June 22, 2011) (jetzt mit dual license GPL/kommerziell)
-
- Beiträge: 101
- Registriert: So 21. Nov 2004, 23:48
- Kontaktdaten:
Re: Zugriff auf CMS_VAR im Output teil
Ah, eine Sache hab ich noch
die Sache mit der innoDB Was genau ist das ? Und was bedeuted es für mich ?
Kann ich mir das so vorstellen, das wenn ich den Artikel mit der idartlang x lösche auch die counter die sich auf idartlang x beziehen gelöscht werden ?
Das wäre kuuuuuuuuuuuuhl
Gruss
Georg
die Sache mit der innoDB Was genau ist das ? Und was bedeuted es für mich ?
Kann ich mir das so vorstellen, das wenn ich den Artikel mit der idartlang x lösche auch die counter die sich auf idartlang x beziehen gelöscht werden ?
Das wäre kuuuuuuuuuuuuhl
Gruss
Georg
Re: Zugriff auf CMS_VAR im Output teil
Das ist ganz genau so. Dazu ist allerdings die Abbildung einer referenziellen Integrität mit Löschweitergabe erforderlich. Und die gibts bei MyISAM-Tabellen (Normaleinstellung) nicht, bei innoDB-Tabellen schon. Das Vorgehen ist relativ einfach:
- Zunächst wie immer einen Dump der Datenbank erstellen. Die Umstellung von myISAM auf innoDB sollte zwar nicht stören. Aber man weiss ja nie und will auf der sicheren Seite sein.
- Dann in phpMyAdmin einsteigen und die Tabellle con_art_lang auswählen und in den Tabs 'Operation' wählen. Bei mir ist es Englisch. Wie's deutsch heisst, weiss ich offen gestanden nicht. Es müsste das dritte Tab von rechts sein.
- Dort kannst du nun die Storage engine auf innoDB umstellen.
- Bei der neuen Tabelle wählst du bereits beim Anlegen innoDB.
- In der neuen Tabelle hast du ja auch ein Feld mit der Bezeichnung idartlang. Dieses muss vom gleichen Typ sein, wie idartlang der Tabelle con_art_lang und das Feld muss einen Index aufweisen.
- Bei der Strukturansicht der neuen Tabelle müsstest du nun einen Link finden, der bei mir (englisch) 'relation view' heisst. Dort klicken und anschliessend den Bezug zum Feld idartlang der Tabelle con_art_lang erzeugen. In der zweiten Spalte unter der Spaltenbezeichnung 'ON DELETE' wählst du aus dem Dropdown-Feld die Option 'CASCADE'.
- Von jetzt an werden die Einträge automatisch gelöscht, wenn die entsprechenden Einträge in der con_art_lang gelöscht werden. Durch die referentielle Integrität ist auch ausgeschlossen, dass du eine Speicherung für eine idartlang vornimmst, die es gar nicht gibt.
aitsu.org :: schnell - flexibel - komfortabel :: Version 2.2.0 (since June 22, 2011) (jetzt mit dual license GPL/kommerziell)
-
- Beiträge: 4254
- Registriert: Do 30. Jun 2005, 22:56
- Wohnort: Eltmann, Unterfranken, Bayern
- Kontaktdaten:
Re: Zugriff auf CMS_VAR im Output teil
Nein, nein, das kann MySQL in seinem "virtuellen" Speicher selbstverfreilich viel besser.kummer hat geschrieben:Nachtrag: Ich bin mir fast sicher, all das würde im Dateisystem noch viel viel besser gehen...
Gruß aus Franken
Ortwin
ConLite 2.1, alternatives und stabiles Update von Contenido 4.8.x unter PHP 7.x - Download und Repo auf Gitport.de
phpBO Search Advanced - das Suchwort-Plugin für CONTENIDO 4.9
Mein Entwickler-Blog
phpBO Search Advanced - das Suchwort-Plugin für CONTENIDO 4.9
Mein Entwickler-Blog
Re: Zugriff auf CMS_VAR im Output teil
Das sind dann eben Themen, die du vielleicht einmal bei MySQL anbringen kannst. Die können offenbar von Contenido noch so einiges lernen, wie es scheint. Vielleicht haben sie für dich ein offenes Ohr. Wobei ich annehmen muss, dass der Umgang von MySQL mit den Ressourcen nicht wirklich bedeutend schlechter ist als der von Contenido. Aber was weiss ich schon...Oldperl hat geschrieben:Nein, nein, das kann MySQL in seinem "virtuellen" Speicher selbstverfreilich viel besser.
Es würde sich übrigens lohnen, einmal ein Profiling zu machen, damit man nicht darüber spekulieren muss, wo wieviel Leistung auf der Strecke bleibt. Es lohnt sich nämlich nicht, dort zu sparen, wo der Überhang gering ist. Man muss die grossen Lecks stopfen. Und wer sich auf die Suche macht, wird schnell fündig werden. Dort gibt es dann wirklich was einzusparen.
aitsu.org :: schnell - flexibel - komfortabel :: Version 2.2.0 (since June 22, 2011) (jetzt mit dual license GPL/kommerziell)
-
- Beiträge: 101
- Registriert: So 21. Nov 2004, 23:48
- Kontaktdaten:
Re: Zugriff auf CMS_VAR im Output teil
Hey,
danke kummer, das scheint ja nicht so schwierig zu sein. dann instaliere ich mal myphpadmin, bin bisher mit der mysql-console gut zurecht gekommen, aber da find ich die dinge bestimmt nicht so schnell
Gruss
Georg
danke kummer, das scheint ja nicht so schwierig zu sein. dann instaliere ich mal myphpadmin, bin bisher mit der mysql-console gut zurecht gekommen, aber da find ich die dinge bestimmt nicht so schnell
Gruss
Georg