Speicherung von Daten statt mit dataContainer 'File' in Table? möglich?

Hallo zusammen,

sorry für den komischen Titel, aber mir fiel nix besseres ein :-)

Ich bin nun schon durch ettliche Extension durch und auch das Backend hab ich quergelesen, doch leider kein Erfolg. Vielleicht kann mir jemand helfen.

Mich würde die Möglichkeit interessieren, wie ich eine kleine Erweiterung hinbekomme, die einfach nur einige Werte speichert (ähnlich wie tl_settings). Allerdings möchte ich diese nicht mit dataContainer => File speichern, sondern in einer eigenen Tabelle, also dataContainer => Table.

Doch irgendwie ist jedes Beispiel das ich finde nur mit dataContainer => File umgesetzt. Daher die Frage an die Profis, ob es einen Weg gibt auch einfache Daten in die Tabelle zu bringen.

Zum Quellcode lesen hab ich mir mal den acquistoShop installiert. Dort gibt es auch einen Punkt "Einstellungen" der zwar optisch das macht was ich möchte, Werte speichern, jedoch auch wieder nur in die localconfig.php
Ich sehe da ein Problem, da es dort z.B. gespeicherte Werte gibt wie: $GLOBALS['TL_CONFIG']['strasse']
Diese Variable kann auch mal ganz schnell und einfach von jemand anderen benutzt bzw. überschrieben werden, was in einer 'eigenen' Tabelle nicht passieren kann. Interessant wäre natürlich auch die Möglichkeit bei der Speicherung per 'File' eine eigene Datei zu befüllen und nicht die localconfig.php.

Viele Fragen, wenig Verständnis.... ich hoffe jemand versteht was ich möchte :-)

Danke schonmal
Gruß
Michael

Also das Thema speichern der Einstellungen in einer eigenen Datei habe ich in der htaccess Erweiterung umgesetzt. Dort habe ich eine eigene Config Klasse geschrieben.
Jedoch funktioniert das nur, wenn das Feld einen entsprechenden Prefix hat, bei mir beginnen alle Einstellungen mit htaccess_, das wäre auch eine Möglichkeit für dich, anstatt das Feld "nur" strasse zu nennen, nennst du es meine_extension_strasse.

Ansonsten könntest du das mit der DB Speicherung aber auch mit der DC_Memory hin bekommen, du musst aber das laden und speichern dabei selbst übernehmen.

Eventuell funktioniert das auch mit DC_Table und einer geschlossenen Tabelle und einem einzigen Konfigurationsdatensatz (http://www.contao.org/de/reference.html -> Tabellenkonfiguration -> closed).

Die links sind nun wie folgt, wer das mal sucht:

https://github.com/bit3/contao-htacc...cessConfig.php
https://github.com/bit3/contao-htaccess

Ich möchte das Thema noch mal aufgreifen.

Gibt es inzwischen irgendeine Möglichkeit Einstellungen abzuspeichern ohne Datenbank oder zur Not mit Datenbank, dabei aber nur Verwendung eines einzigen Datensatzes?

Die Lösung wie bei isotope z.B. finde ich Quatsch (mehrere Konfigurations-Datensätze).

Hi,

die Möglichkeit Daten abzuspeichern ohne Datenbank gibts ja schon immer, dann landen die Daten halt in der localconfig.

Ich habe es jetzt bei einigen Projekte so gemacht, dass ich ganz normal über die Tabelle gehe, allerdings mit einem onload_callback prüfe ob es bereits einen Datensatz gibt

Wenn nein => Weiterleitung zu act=create
Wenn ja => Weiterleitung zu act=edit&id=[id des Datensatzes]

Damit überspringt man automatisch den Bereich wo mehrere Datensätze angelegt werden können und das ganze wirkt wie z.B. Einstellungen...... hab ich so mehrfach im Einsatz und funktioniert hervorragend.

Hi,

ich hab deinen Beitrag an anderer Stelle gelesen und das jetzt auch so im Einsatz, vielen Dank.

Aber trotzdem kann das nicht der Sinn der Sache sein, das muss ja standardmäßig vom Core schon bereitgestellt werden.
Das ist ja nun keine Spezialsache, die man nie braucht...

Zitat:

Zitat von Stranger

Aber trotzdem kann das nicht der Sinn der Sache sein, das muss ja standardmäßig vom Core schon bereitgestellt werden.
Das ist ja nun keine Spezialsache, die man nie braucht...

Das sehe ich anders, ich habe das bisher nur 1 mal benötigt und das war bei meiner htaccess Erweiterung :D

Die Aussage ist nicht wirklich objektiv, da du zwar schon 54 Erweiterungen herausgebracht hast, aber keine wirklich "eigenständigen" Erweiterungen dabei sind ;)
Bin die Liste mal durchgegangen und meiner Meinung nach beruht fast alles auf bereits bestehenden DCA-Tables.

Also all deine Erweiterungen bauen zum Großteil auf bereits bestehenden Erweiterungen oder dem Core auf, von daher ist es klar, dass du da großartig keine Settings brauchst. Falls ich mich irre, bitte ich um Verzeihung und Richtigstellung! :)

Ich hab keine Ahnung wie es bei diesen Erweiterungen von Fruitmedia gehandhabt wird, aber bei Isotope z.B. wird auch eine extra Datenbanktabelle für die Settings benutzt.

Es ist doch völlig uninteressant ob jemand seine Erweiterungen auf den Core aufbaut oder etwas komplett eigenes macht. Zumal der Core dir ja zwei Varianten bietet, Speicherung in die DB und in die Datei (localconfig).
Selbst ich, der das genauso wie du benötigt hat, sehe hier keine Notwendigkeit, dass der Core soetwas anzubieten hat. Denn schließlich kann ich mir ja selbst einen Weg "bauen" dass es mit genau einem Datensatz funktioniert.

Und wenn du ja eh schon dabei bist dir was "eigenes" zu bauen, dann kannst du dir ja gleich einen DC_Treiber bauen der dann alles so macht wie du möchtest.

In Isotope kannst du aber auch mehrere Shop-Konfigurationen anlegen, also benötigst du dafür auch wieder mehr als nur einen Datensatz, daher fällt dieser Vergleich flach.

Ich arbeite da auch mit einem "save_callback". Bei einer meiner Erweiterungen kann man zwar mehrere Zeilen anlegen, aber ich sorge damit dafür das immer nur eine Zeile aktiv ist.

Zitat:

Zitat von Stranger

Die Aussage ist nicht wirklich objektiv, da du zwar schon 54 Erweiterungen herausgebracht hast, aber keine wirklich "eigenständigen" Erweiterungen dabei sind ;)

Soll ich jetzt lachen oder heulen? :eek: :D :) :mad: :confused:
Ich habe unter anderem die ein oder andere fruitmedia Erweiterung entwickelt, diese nutzen alle die localconfig.php über den DC_File oder aber eigene Tabellen.
Und Avisota nutzt mal so quasi gar nichts vom Core. Die nutzt DC_General, Twig und viele andere Erweiterungen, vom Core wird da vielleicht noch 10% genutzt... :cool:
Außer ich glaube schon dass da mehr als genug "eigenständige" Erweiterungen bei sind :p

Tril: Ok sorry, das ist n Argument ;) Aber ich rede davon, wenn ich 20, 30 Einstellmöglichkeiten habe, das will ich natürlich nicht auch noch alles in die localconfig.php reinkleistern lassen...

the_scrat, hab das mit nem onload_callback gelöst wie hier https://community.contao.org/de/show...irekt-anzeigen
Aber ich bin noch nicht dahinter gestiegen wie man den "Zurück"-Link und diese Speichern/Speichern Schließen Buttons etc. löscht/anpasst.

@the_scrat
Wie machst du das mit dem Backlink? Der ist in der Editansicht leider nicht änderbar und völlig falsch.

Für eine andere Stelle hatte ich einen Trick angewandt, der aber hier auch nicht wirkt.
In den global_operations kann man es ja auch nicht notieren, weil die global_operations Ansicht ja nicht in der Edit-Ansicht verfügbar ist :(

PHP-Code:

'global_operations' => array ( 'all' => array ( 'label' => &$GLOBALS['TL_LANG']['MSC']['all'], 'href' => 'act=select', 'class' => 'header_edit_all', 'attributes' => 'onclick="Backend.getScrollOffset();"' ), 'backlink' => array( 'label' => 'Zurück', 'href' => 'do=test', 'class' => 'header_back', 'attributes' => 'onclick="Backend.getScrollOffset();" accesskey="e"' ) )

Hm blöd, ich kann meinen vorigen Beitrag nicht bearbeiten...

1. Hab auch probiert die config Angaben anzupassen. Er reagiert nicht darauf, weil der Zurück-Button in der Editansicht wohl nicht geändert werden kann

$GLOBALS['TL_DCA']['tl_product_settings']['backlink'] = 'test';

2. Der "Speichern und Schließen" Link geht ebenfalls nicht.

3. "Speichern und Neu" ist ja auch unnötig, aber ich kann ja nicht in der Config die Tabelle auf "closed" stellen.

Also der Backlink ist bei mir zwar vorhanden, ist aber ohne Funktion, ich kann zwar draufklicken, lande aber wieder im gleichen Datensatz. Denn normalerweise würde ich auf der Übersichtsseite landen, was aber der onload_callback verbietet, da es einen Datensatz gibt und mich wieder dorthin leitet.

Warum sollst du die Tabelle nicht "closen" können? Hab ich bei mir auch gemacht. Ist sogar eine der ersten Funktionen im onload_callback

Ich frage ab, ob es für die Tabelle bereits einen Eintrag in der DB gibt und setze dann die Tabelle auf close. Ich hab zwar dann 2 Buttons (Speichern + Speichern und schließen). Beide speichern das Ganze, nur geschlossen wird es halt nicht, weil dann wieder die Methode beim onload_callback greift. Ganz easy ;-)

Ich weiß nicht mehr in welcher meiner Erweiterungen aber irgendwo habe ich den "Schließen und Neu" Button einfach per CSS ausgeblendet.

Hab vor kurzem da noch etwas mit rumgespielt und will euch das nicht vorenthalten.

1. Ich habe keinen Speichern und Neu Button mehr
2. Der "Speichern und Schließen" Button funktioniert jetzt.
3. Der "Zurück" Link geht jetzt.

Kann man sich gerne in der neuesten Version meiner Erweiterung "simple_products" anschauen.

https://contao.org/de/erweiterungsli...oducts.de.html

Datei: /dca/tl_product_settings.php