Hallo zusammen
Ist es möglich verschiedene Eingabemasken im Frontend zu verwenden? Also, Seite A wird die Maske A angezeigt und auf Seite B die Maske B.
Druckbare Version
Hallo zusammen
Ist es möglich verschiedene Eingabemasken im Frontend zu verwenden? Also, Seite A wird die Maske A angezeigt und auf Seite B die Maske B.
Da das über die MM Rechte gesteuert wird, sollte das mit unterschiedlichen Mitgliedergruppen und entsprechender Zuordnung klappen. Gleicher User mit unterschiedlichen Masken ist von Haus aus vermutlich nicht mit drin.
Auch nicht über die MM-API? z.B. mit dem PreEditModelEvent?
korrekt - per se wird das so nicht unterstützt...Zitat:
Zitat von cliffparnitzky
zwei Möglichkeiten, das umzusetzen: "Sub-Masken" A und B müssen in eine Maske und dann
* jeweils die Sachen per CSS ausblenden, die man nicht angezeigt haben möchte - wenn man entsprechende Legenden einfügt, erleichtert das die Sache; oder per vergebenen CSS-Klassen like "mask_a" | "mask_b" bei den Widgets
* es gibt ein Event, der die Anzeige der Widgets in der Maske steuert - der macht auch die Ansichtsbedingungen im BE (und FE) ... müsste man mal suchen, welcher das ist...
Dann mache ich mich auf die Suche :cool: Ist dieser Event im MM-Core oder im DC-General zu finden?
Müsste eigentlich im DCG sein ... irgendwas mit "visible" & "property" - kannst am Montag gern mal auf Mumble kommen ... dann ist auch Xtra mit da
Am saubersten ist es, wenn Du eine eigene Ansichtsbedingung erstellst, analog den vorhandenen Ansichtsbedingungen - z. B.
https://github.com/MetaModels/core/b...itions.yml#L37
https://github.com/MetaModels/core/b...ionFactory.php
https://github.com/MetaModels/core/b...eCondition.php
wichtig ist die Methode "match", die dann true oder false zurück liefern muss - siehe https://github.com/contao-community-...erface.php#L50
aktuell kann man die Property noch mit einem kleinen Hack in dem BuildDataDefinitionEvent raus kegeln, das wird aber nicht lange mehr so machbar sein...
das Kochbuch würde sich über ein paar Snippets freuen
Habe mir nun einen eigenen Property erstellt und funktioniert wunderbar (Eintrag ins Kochbuch kommt!!!!!!)
Nun wollte ich mal schauen was den alles möglich ist und habe mir gedacht, einen Bedingung auf eine Seitenansicht wäre doch noch was.
Habe über die tl_metamodel_dcasetting_condition.dca ein weiteres Feld mit dem Typ "pageTree" angelegt.
Nun erhalte ich beim erstellen meiner Ansichtbedingung nachfolgende Fehlermeldung ...
Anhang 26798PHP-Code:call_user_func_array(): Argument #1 ($callback) must be a valid callback, class "contao.listener.data_container.page_use_ssl_default" not found
Was muss ich da machen?
Hast Du den Fix vom DCG schon gezogen? stand im MM 2.3 Newsletter...
wenn es das nicht ist, dann Issue schreiben inkl. wie ich das nachbauen kann bzw. mir Dein Git frei geben für den Quelltext
Super das wars!!! Besten Dank!!!
Immer schön den Newsletter lesen! :eek:
Kann es sein, dass in den "tl_metamodel_dcasetting_condition" den Feldtyp "pageTree" nicht richtig funktioniert?
Der Wizard geht auf und man kann auch eine Seite auswählen, nur wird diese nach dem Schliessen des Wizard nicht angezeigt und auch nicht gespeichert.
Anhang 26800
Kann sein ... vielleicht auch nicht? Mit dem Screenshot kann man nichts anfangen - wie der Button aussieht, ist hinlänglich bekannt...
Gibts JS-Errors? was sagt der Debugmodus?
Generell solltest Du hier nochmal Dein Vorgehen überdenken - Lt. Screenshot bist Du in einer vorhanden Ansichtsbedingung, d. h. das "Eltern-Attribut" wird aufgrund der ausgewählten Bedingung(en) in der Maske angezeigt oder nicht.
Du musst eine eigene Ansichtsbedingung erstellen - so wie das was im Select steht wie "Eigenschaftswert ist..." ein "Seite ist..." - als Typ z. B. "conditionpropertypageidis"
Diese Bedingung kannst Du dann per AND/OR/NOT mit den anderen verknüpfen.
siehe #7
in MM werkelt keine KI :eek:
Die vorhanden Ansichtsbedingung habe ich nur als Test angepasst. :)
https://vimeo.com/889370290
Eingebunden habe ich die eigene Ansichtsbedingung so ...
PHP-Code:$GLOBALS['TL_DCA']['tl_metamodel_dcasetting_condition']['metapalettes']['conditionpropertyitemcreate extends default']['+config'][] = 'only_page';
$GLOBALS['TL_DCA']['tl_metamodel_dcasetting_condition']['metapalettes']['conditionpropertyitemedit extends default']['+config'][] = 'only_page';
/*
* Fields for land
*/
$GLOBALS['TL_DCA']['tl_metamodel_dcasetting_condition']['fields']['only_page'] = [
'label' => &$GLOBALS['TL_LANG']['tl_metamodel_dcasetting_condition']['only_page'],
'exclude' => true,
'inputType' => 'pageTree',
'eval' => [
'fieldType' => 'radio',
'tl_class' => 'w50 wizard'
],
'sql' => "int(10) unsigned NOT NULL default '0'"
];
prima! soweit ich das sehe, muss die nur noch im Select auswählbar sein und es muss sich jemand darum kümmern, das die Bedingung auch validiert wird...
... was ich noch nicht so recht verstehe, warum Du zwei Conditions definieren möchtest? Wenn ich die Sache richtig verstehe, hast Du sagen wir 20 Eingabefelder (Attribute) - 10 davon sollen auf Seite A angezeigt werden und 10 auf Seite B.
Dann muss ich bei jedem Attribut eine Condition einstellen und angeben, auf welcher Seite (Id) es angezeigt werden soll.
Bei der Validierung der Condition prüfe ich ob aktuelle Seiten-Id === Condition-Seiten-Id - wenn ja, anzeigen vs. wenn nicht, keine Anzeige
Ergo: ich muss bei jedem Attribut nur die "Ziel-Id" hinterlegen