WE 9 - Initalisierung schlägt fehl

[mediavantis]

@Nils
Touché!

Bleibt immer noch die Forderung nach einem geeigneten Ersatz, einer geeigneten Alternative und vor allem auf die vollständige Dokumentation.

Ich habe Stunden damit verbracht, eine Install auf WE 9 umzustellen um dann schließlich kurz vor Schluss festzustellen, dass das ganze ad absurdum geführt wird nur durch den Wegfall einer Funktion, die vorher nicht oder nicht entsprechend dokumentiert wurde.

[mokraemer]

Ich habe Stunden damit verbracht, eine Install auf WE 9 umzustellen um dann schließlich kurz vor Schluss festzustellen, dass das ganze ad absurdum geführt wird nur durch den Wegfall einer Funktion, die vorher nicht oder nicht entsprechend dokumentiert wurde.

verstehe ich nicht.

[mediavantis]

@Marc
na, der ganze Beitrag hier bezieht sich auf des setElement, was entfernt wurde. Um nichts anderes geht es doch hier....

[mediavantis]

ich meine damit, dass der Wegfall der Funktion nicht dokumentiert wurde

[mokraemer]

Ich meine damit, dass der Wegfall der Funktion nicht dokumentiert wurde

Aber sicher haben wir das dokumentiert.
Das steht alles auf dieser Seite:
https://www.webedition.org/de/dokumenta ... tionen.php

Sogar idr. mit Beispielen wie man das ersetzt.
Im Falle von setElement bin ich mir nur nicht sicher ob das ganz stimmt was da steht.

[mediavantis]

@Marc
Na, wenn Du das schon nicht weißt, ob das stimmt!?!?

Ich habe das zumindest - weil in Verbindung mit $GLOBALS['we_doc'] - übersehen.

Dann wäre es prima, wenn das überprüft würde

[ThomasGoebe]

Mir welchem Tag kann ich multiobjekt Felder via PHP schreiben? Oder einen neuen Objektordner (z.B. 2020/08) anlegen, sobald via Frontend ein Objekt gespeichert werden soll? Wie kann ich Felder des Typs Objekt (also Verknüpfungen zwischen Objekten) via we:tag erstellen? Wie kann ich per we:tag hunderte Objekte importieren und solche aktualisieren, die schon da sind (aber da dann nicht alle Felder) und die, die nicht da sind, neu gemäß Namensschema hinzufügen, benennen und untereinnander mit mehreren Sprachen verknüpfen? Habe ich da etwas übersehen?

Wo ist der FR dazu?

Ach Marc, ich will Dir doch auch nichts böses, wünsche mir aber auch von Dir Verständnis. Komplexe Anforderungen entstehen im Laufe eines Projekts und wenn Du dann merktst: mit Standard wE geht es einfach nicht, dann kann ich nicht Monate bis Jahre auf die Umsetzung eines FR warten sondern muss eine Lösung finden. Zumal der FR doch im Grunde da ist: eine API, mit der ich auf PHP Ebene Objekte und Dokumente etc. updatesicher manipulieren kann. Das habe mindestens ich in den letzten Jahren oder fast schon Jahrzent mehrfach angeregt und ich bin mir relativ sicher, dass es von jemandem dazu auch einen FR in den Untiefen von Mantis gibt oder gab.

Das ist richtig und es ist aus meiner Sicht auch kein Problem, dass sich an internen Funktionen etwas ändert. Ich denke allerdings weiterhin, dass es keine echte API gibt, wie ich sie bei einem Web Application Framework erwarten würde.

Wir sind kein WebAppFW - und selbstverständlich sind Tags ne API! Du programmierst damit ja WE.

OK, das Framework Thema war Konsens bei der letzten Konferenz, an der ich teilnahm. Scheint sich da inzwischen geändert zu haben. Also ist wE "nur" noch ein CMS?
Gut, einigen wir uns darauf, dass we:tags eine API mit Einschränkungen sind.
Es reicht eben bei vielen Dingen nicht, nur eine Ziele we:legemaleinobjektan zu nutzen sondern das sind dann komplexere und gteilweise sehr spezielle Prozesse, bei denen mir vielleicht auch der fachliche Horizont fehlt, um das in einen we:tag zu gießen.

Mir fehlt jedoch ein möglichst updatesicherer Weg, um Daten via PHP anzulegen, zu manipulieren und zu löschen.

Wenn man klar wäre was gebraucht wird, kann man das implementieren. Es ist ja nicht richtig, das Tags langsam sind - das sind ja auch am Ende PHP-Funktionen. Was langsam ist, wenn Funktionen fehlen und dann drum herum gebaut wird, also wenn bspw. ein Tag eben nur eine ID verarbeitet, obwohl eine Liste benötigt wird. Da man eben teilweise mit php drum herum bauen kann, macht sich eben auch keiner die Mühe das mal in Tags updatesicher zu gießen - aber wenn du mal in die Tag-Doku schaust, sind viele ID-Felder auf CSV erweitert worden.

Es ist doch klar, was gebraucht wird. Im Grunde alle Methoden von we_object_file etc. als öffentliche und stabile Methoden. Und langsam waren zum Beispiel immer wieder listviews mit tausende von Einträgen und sehr umfangreichen Objekten. we:field hat da z.B. mehrfach bei jedem Durchlauf immer die gleichen Prüfungen und Prozesse durchgeführt, die ich aber gar nicht brauchte! Das hat sicher auch mit der fehlenden Typisierung zu tun, aber eben auch an fehlenden Methoden. Wenn ich z.B. alle 80 Felder eines Objekts innerhalb eines we:repeat in einem array brauche, dann kann ich natürlich 80x we:field nameto machen oder aber einmal $lv->db_we->record (sinngemäß, habe gerade nicht die korrekten Bezeichner parat) abfragen. Letzteres reicht durch nur den Datensatz aus der DB Klasse weiter.

Ich freue mich, wenn es nicht nur ein Abblocken sondern eine Überlegung gibt, wie so ein Wunsch nach einer API (über die we:tags hinaus) umgesetzt werden könnte. Ich bringe da erneut Processwire ins Spiel, in dem das echt gut klappt. Anderes ist da auch nicht toll, also nicht als allgemeiner Vergleich zu verstehen. Aber ich brauche eben keine we:tags auf php Ebene, um Daten zu manupulieren sondern habe recht stabile Methoden dafür zur Verfügung.

[mokraemer]

Es ist doch klar, was gebraucht wird. Im Grunde alle Methoden von we_object_file etc. als öffentliche und stabile Methoden. Und langsam waren zum Beispiel immer wieder listviews mit tausende von Einträgen und sehr umfangreichen Objekten. we:field hat

Das kann keiner haben wollen und macht auch keinen Sinn. Du brauchst weder die Funktion um ein we-Form zu bauen mit dem man ein Objekt kopieren kann, etc.

Klar kann man auf der Ebene was machen - aber wie du schon sagtest, Mantis hat viele Tickets und jeder hätte gern mal schnell. Die Ressourcen fehlen um das was hier gewünscht wird umzusetzen.

[ThomasGoebe]

Hier einer der FR zu dem Thema:

https://qa.webedition.org/tracker/view.php?id=11165

Wurde leider damals auch "abgebügelt".

[ThomasGoebe]

Klar kann man auf der Ebene was machen - aber wie du schon sagtest, Mantis hat viele Tickets und jeder hätte gern mal schnell. Die Ressourcen fehlen um das was hier gewünscht wird umzusetzen.

Du übersiehst eventuell den Vorteil solch einer API: es können sinnvoll we:tags von extern entwickelt werden. Denn wenn ich aktuell we:tags entwickelt hatte, sind die schon mehrfach nicht mehr funktionsfähig gewesen. Einmal hat sich der we:tag Syntax mindestens zwei Mal komplett geändert - nun sind es Klassen. Und viel gravierender ist eben, dass ich auch auf we:tag ebene keine updatesichere Möglichkeit habe, Daten, Objekte etc. zu verändern. Wenn also die API der erste statt der letzte Schritt ist, könnten ja vielleicht mehr we:tags mit neuen Funktionen entstehen.

Aber da wiederholen wir gerade eine Diskussion zur we Strategiei aus meiner letzten Mitgliederversammlung als Vorstand. Ist nun auch irgendwie verjährt. Daher: einfach weitermachen.

[ThomasGoebe]

Und vielleicht noch ein letztes: Processwire macht das mit der API echt gut und hat auch eine relativ simple Doku dazu.
Im Grunde möchte ich so was für einzelne Bereiche in wE (Objekte, Dokumente, Kunden - die ja auch Objekte sein könnten...)
https://cheatsheet.processwire.com/

[mokraemer]

Und viel gravierender ist eben, dass ich auch auf we:tag ebene keine updatesichere Möglichkeit habe, Daten, Objekte etc. zu verändern.

Fang gerne damit an, vermutlich am besten in dem man von dem we_contents_objectFile erbt und dann die Funktionen bereitstellt. Wenn wir definieren, das eben alle Klassen die we_API_* heißen versuchen weitestgehend unverändert zu lassen, sollte das durchaus gehen.
Funktionen um aber bspw. setElement abzubilden wären hier halt auch falsch, denn damit greift man auf die interne Datenstruktur zu, die sich im Laufe von php-serialisiertem zu json über Array's vermutlich auf echte Objekte bewegt. Deshalb ist das auch nicht so einfach eine stabile API zu bauen. Die API der Tags ist ja recht stabil (also aus WE; die Umstellung auf Klassen ist etwas Fleißarbeit, aber auch in 8.x bereits in beiden Versionen funktional) , aber auch hier ist es eben nötig manche Anpassungen zu machen, die zum einen von geänderten Anforderungen oder eben auch von der Technik bzw. Sicherheit kommen. Man sollte hier auch nicht ganz verschweigen, das wir mit WE 9 einige inkompatible Umstellungen die PHP im Hintergrund gelaufen sind durchlaufen haben. Auch hier helfen dann die WE-Tags über die API die ja stabil geblieben ist das man keine Änderungen am Kode machen muß - idr. nicht mal einen Rebuild.

Wenn die WE-Tage im Herbst stattfinden, dann kann man sicher noch einiges klären. Ist nicht so, als könnte ich meine Zeit nicht auch besser für andere Dinge nutzen.

[LOOK//one]

Vor dem Hintergrund, dass es sich mit der 9er-Version um ein Major-Update handelt, sollte jedem (schmerzlich) klar sein, dass der eine oder andere Weg oder Workaround eventuell nicht mehr funzt. Das ist im Einzelfall sehr ärgerlich (hatten wir natürlich auch schon), aber doch erwartbar. Generell haben wir als Verein nur sehr beschränkte Ressourcen, weil unsere (zahlende) Community nicht sehr groß ist. Unterm Strich ist webEdition ein System, welches die Funktionsweise der WE-Tags garantiert. Damit geht eine Menge. Alles, was tiefer in die Maschine eingreift, unterliegt dem Risiko, eventuell nach einem Update nicht mehr zu funktionieren. Damit müssen wir leben, können Bugs melden, FRs einstellen und auf dieser Basis schauen, ob für bestimmte Wünsche oder Probleme Prioritäten entstehen. Ich lade alle ganz herzlich ein, im November bei der Konferenz dabei zu sein und gerne bei einer offenen Gesprächsrunde im Forum oder auch hinterher am Wirtshaustisch die Wege und Möglichkeiten gemeinsam auszuloten.
Jens

[ThomasGoebe]

Hallo Marc,

weder war, bin noch werde ich webEdition Core Entwickler, aber ich komme gern zurück auf eine Idee für eine API, die glaube ich auch schon einmal vor Jahren mit Armin in Telefonaten entstanden ist.

Zunächst einmal nur für Objekte:

Beim Speichern einer webEdition Klasse könnte webEdition eine PHP Klasse erzeugen, die den Zugriff auf Objekte dieser webEdition Klasse regelt und einfache getter und setter inkl. der ja durch die webEdition Klassendefinition bekannten Limits der Felder erlaubt.
Also angenommen, wir haben eine we Klasse der ID 1, in der es drei Felder gibt (Titel, Text, Datum), dann würde eine neue PHP Klasse we_object_1 erzeugt.
(Pseudocode)

Code: Alles auswählen

class we_object_1 {
	private $fields = array(
		'Titel' => array( 'value' => 'defaultwert für Titel', 'type' => 'textinput', 'rules' => array()),
		'Text => array( 'value' => 'defaultwert für Text', 'type' => 'textarea', 'rules' => array()),
		'Datum' => array( 'value' => 'defaultwert für Datum', 'type' => 'date', 'rules' => array()),
		'we_path' => array( 'value' => 'defaultwert für Pfad', 'type' => 'property', 'rules' => array())
	);
	

	public function __construct( $id = false ) {
		if( $id !== false ) {
			$this->init_by_id( $id );
		}
	}

	public function destruct() {
	}
	
	public function init_by_id( $id ) {
		... hier Daten wie auch immer laden ...
	}
	
	public function __get( $field ) {
		$field = sanitize fieldname($field);
		$custom_method = '_get_'.$field;
		if( method_exists( $this, $custom_method ) ) {
			return $this->$custom_method();
		} else {
			if( isset( $this->fields[ $field ] ) ) {
				switch( $this->fields[ $field ][ 'type' ] ) {
					case 'textinput':
						return $this->fields[ $field ][ 'value' ]
					break;
					case ...
					break;
					case 'property':
					... evtl. properties wie pfad, titel, parent id nur durch eigene Methode, die bei vererben nicht überschrieben werden können, abbilden
					break;
					default:
					...
					break;
				}
			} else {
				Fehler werfen, ungueltige Eigenschaft angefragt
			}
		}
	}
	
	public function __set( $field, $value ) {
		$custom_method = '_set_'.sanitize fieldname($field);
		if( method_exists( $this, $custom_method ) ) {
			$this->$custom_method( $value );
		} else {
			if( isset( $this->fields[ $field ] ) ) {
				if( $this->validate_value( $value, $this->fields[ $field ][ $rules ] )
				{
					switch( $this->fields[ $field ][ 'type' ] ) {
						case 'textinput':
							$this->fields[ $field ][ 'value' ] = $value;
						break;
						case ...
						break;
						default:
						...
						break;
					}
				} else {
					Fehler werfen, Wert entspricht nicht den Regeln
				}
			} else {
				Fehler werfen, ungueltige Eigenschaft angefragt
			}
		}
	}
	
	private function validate_value( $value, $rules ) {
		return ( $value mets $rules);
	}
	
	/**
	 * evtl. eigene setter Methoden für jedes Property erstellen
	 */
	private function _set_we_path( $value ) {
	...
	}
	
	public function save( ) {
	... hier wie auch immer die Daten speichern, we_objectfile oder was auch immer dazu nutzen
	}
}

Da vieles davon für in allen we Klassen gleicht wäre (bis auf Felddefinitionen vermutlich) kann das dann auch wieder von einer Basisklasse erben.

Dieses ermöglicht dann auf PHP Ebene so was wie

Code: Alles auswählen

$obj = new we_object_1();
$obj->initByID( $myid );

$obj->Titel = 'Der neue Titel';
$obj->Text = 'Der neue Text';
$obj->Datum = datum im definierten format für datumsfelder

$obj->save();

Standardfelder wie Pfad, Parent etc. wären auch vorhanden, z.B. mittels

Code: Alles auswählen

$obj = new we_object_1();
$obj->initByID( $myid );

$obj->we_path = '/2020/08/';

$obj->save();

Beim Speichern werden nicht vorhandene Pfade direkt angelegt. Treten Fehler auf (z.B. falsch formatiertes Datum etc.), wirft das ganze einen Error, der wieder abgefangen werden kann.

Die Klasse wird via autoloader geladen. Bei jedem Speichern der we Klasse kann der PHP Code für die php Klasse neu generiert werden. Ebenfalls kann er wie auch immer in neuen we Versionen optimiert werden, so lange die entsprechenden getter und setter gleich nutzbar bleiben. Wie auch immer webEdition dann im Hintergrund Daten verarbeitet ist damit vollkommen egal.

Diese Klassen können auch als Basis für eigene Klassen genutzt werden, so dass ich davon erben aber mich ggf. in die Funktionen einklinken kann. Z.B. könnte ein Entwickler, eine Entwicklerin eigene getter und setter Methoden für einzelne Felder schreiben.

Aber ob das nun alles einfacher ist, als "nur" dauerhaft einzelne Funktionen von we_objectfile als stabil zu kennzeichnen und ggf. bei internen Upates dann für wrapper zu sorgen, weiss ich nicht. Es braucht aber m.E. wirklich mehr als nur we Tags, wenn auf PHP Ebene komplexere Dinge durchgeführt werden sollen. Wäre es anders, würdet ihr ja intern im Core auch nicht we_objectfile etc. nutzen sondern einfach einen we:tag dafür schreiben

Ähnliches könnte es für Dokumente und auch Kunden geben. Bei Kunden kann dies ebenfalls immer dann neu generiert werden, wenn die Felddefinitionen neu geschrieben werden. Bei Dokumenten ist es sicher ungleich komplizierter, da die Strukturen da nicht so klar sind, wie bei Objekten. Dazu fehlt mir gerade der Ansatz.

Als letztes dann noch PHP Klassen, um Listen von Objekten zu bekommen. Und zwar auch solche, die geparkt sind. Die Nutzung von we:listview ist da auf PHP Ebene für mich zu unübersichtlich.

Aber das sind nur ein paar Gedanken dazu. Gerne können wir über Für und Wider diskutieren, wenn es ernsthaft Interesse gibt, so etwas wie eine API einzuführen.

[ThomasGoebe]

Nachtrag:

das Konstrukt erlaubt dann auch "virtuelle" Eigenschaften, wie z.B. eine Briefanrede.

einfach von der PHP Klasse erben, eine Methode _get_Briefanrede() anlegen, die "Sehr geehrter".$name etc. zurückliefert. Noch weiter gedacht kann natürlich auch ein init_by_array o.ä. eingeführt werden, so dass innerhalb von listviews die Klasse initialisiert wird und we:field auch auf so etwas zurückgreifen kann, also die eigene PHP API nutzen kann...

Wird also dann noch generischer, als es in V 9 anscheinend nun schon ist.