yes we:can
- e.windmeier
- Member
- Beiträge: 54
- Registriert: Do 17. Jun 2010, 09:44
- Wohnort: Remchingen
- Kontaktdaten:
Re: yes we:can
Meine Meinung, denn mich hat früher schon gestört, dass man in einem Template überhaupt mit PHP hantieren musste.
Re: yes we:can
Gerade die Möglichkeit, mit PHP "zu hantieren" ist eine Stärke von wE!
Z.B.:
Wo interne Funktionen z.B. diverse Abhängigkeitsprüfungen brauchen (neue Kunden anlegen oder was auch immer), kann ich unter kontrollierten Bedingungen darauf verzichten und somit eine deutlich bessere Performance erreichen.
Und ich wir werden nie alle möglichen Anwendungsfälle mit we:tags abdecken können.
Aber: ich stimme Marc dahin zu, dass es für den Zugriff auf interne Strukturen Schnittstellen braucht.
Ein Beispiel ist, per Cronjob 1000 oder mehr Objekte anzulegen bzw. mit bestehenden abzugleichen. Mit Hausmitteln geht das derzeit nicht, da muss im Moment einfach auf die interne we_object Klasse oder auf Importer Strukturen etc. zugegriffen werden.
Die andere Richtung ist auch ein Problem. Ein externes Projekt braucht via API die Möglichkeit, Objekte abzufragen. Aber: eben auch geparkte Objekte. Das macht im Moment kein Tag. Ob es sinnvoll ist, die listview dahin zu erweitern, stelle ich auch in Fragen.
Es braucht also in meinen Augen unbedingt eine einfache Möglichkeit, auf Daten zuzugreifen und auch Daten wieder einzuspielen / zu aktualisieren.
Und das geht mit PHP nun mal deutlich schneller als mit Tags. (Die Listview ist z.B. absolut übertrieben, wenn ich nur die Anzahl der vorhandene Objekte einer Klasse haben möchte.)
Zurück zum Thema:
in der Doku würde ich diese Dinge im Moment schon aufnehmen, aber in einem extra Bereich und als "Achtung, verhindert updatefähigkeit!" gekennzeichnet. Und dann Stück für Stück diese Dinge, wie Marc vorgeschlagen hat, durch andere Möglichkeiten ersetzen. Das braucht aber ein sinnvolles Konzept und kein "Schnellschuß - jetzt ersetze ich mal Methode A und morgen Methode B" und hat m.E. nicht die höchste Priorität.
Gruß
Thomas
Z.B.:
Wo interne Funktionen z.B. diverse Abhängigkeitsprüfungen brauchen (neue Kunden anlegen oder was auch immer), kann ich unter kontrollierten Bedingungen darauf verzichten und somit eine deutlich bessere Performance erreichen.
Und ich wir werden nie alle möglichen Anwendungsfälle mit we:tags abdecken können.
Aber: ich stimme Marc dahin zu, dass es für den Zugriff auf interne Strukturen Schnittstellen braucht.
Ein Beispiel ist, per Cronjob 1000 oder mehr Objekte anzulegen bzw. mit bestehenden abzugleichen. Mit Hausmitteln geht das derzeit nicht, da muss im Moment einfach auf die interne we_object Klasse oder auf Importer Strukturen etc. zugegriffen werden.
Die andere Richtung ist auch ein Problem. Ein externes Projekt braucht via API die Möglichkeit, Objekte abzufragen. Aber: eben auch geparkte Objekte. Das macht im Moment kein Tag. Ob es sinnvoll ist, die listview dahin zu erweitern, stelle ich auch in Fragen.
Es braucht also in meinen Augen unbedingt eine einfache Möglichkeit, auf Daten zuzugreifen und auch Daten wieder einzuspielen / zu aktualisieren.
Und das geht mit PHP nun mal deutlich schneller als mit Tags. (Die Listview ist z.B. absolut übertrieben, wenn ich nur die Anzahl der vorhandene Objekte einer Klasse haben möchte.)
Zurück zum Thema:
in der Doku würde ich diese Dinge im Moment schon aufnehmen, aber in einem extra Bereich und als "Achtung, verhindert updatefähigkeit!" gekennzeichnet. Und dann Stück für Stück diese Dinge, wie Marc vorgeschlagen hat, durch andere Möglichkeiten ersetzen. Das braucht aber ein sinnvolles Konzept und kein "Schnellschuß - jetzt ersetze ich mal Methode A und morgen Methode B" und hat m.E. nicht die höchste Priorität.
Gruß
Thomas
Re: yes we:can
@Thomas:
du hast natürlich auch wieder sehr spezielle Sachen am Start.
Aber: wenn ich die Anzahl der Objekte haben will - glaube dann geh ich sogar direkt auf die DB.
Zum einen muß man einfach sagen, ist vieles ja jetzt sehr viel performanter und vieles geht jetzt gegenüber früher auch mit Hausmitteln - Fragestellungen wie "wie bekomme ich die Kategorie eines Dokuments per php" sollten als Antwort entweder
oder
lauten.
Im Prinzip sind die Tags ja unsere Schnittstelle nach draußen. Ich kann im schlimmsten Fall noch damit rechnen, daß jemand auf we_Document oder we_Object bzw. we_ObjectFiles und der DB-Klasse arbeitet und dort die Methoden aufruft - die anderen Klassen inkl. listview sind für mich aber absolute we-interna!
du hast natürlich auch wieder sehr spezielle Sachen am Start.
Aber: wenn ich die Anzahl der Objekte haben will - glaube dann geh ich sogar direkt auf die DB.
Zum einen muß man einfach sagen, ist vieles ja jetzt sehr viel performanter und vieles geht jetzt gegenüber früher auch mit Hausmitteln - Fragestellungen wie "wie bekomme ich die Kategorie eines Dokuments per php" sollten als Antwort entweder
Code: Alles auswählen
<we:categories to="global" nameTo="kats"/>
Code: Alles auswählen
$tmp=we_tag('categories');
Im Prinzip sind die Tags ja unsere Schnittstelle nach draußen. Ich kann im schlimmsten Fall noch damit rechnen, daß jemand auf we_Document oder we_Object bzw. we_ObjectFiles und der DB-Klasse arbeitet und dort die Methoden aufruft - die anderen Klassen inkl. listview sind für mich aber absolute we-interna!
webEdition-Kern-Entwickler
Re: yes we:can
@marc:
Ja, ich mal wieder
Schönes Beispiel mit den Kategorien: ich brauche aber nicht die Kategorien des aktuellen Dokuments, sondern eines Dokuments oder Objekts von dem ich die ID kenne.
Mir gefällt besonders an wE, dass eben solche Sachen wie Import und Abgleich von 1000 Artikeln, Objekten, Kunden oder was auch immer (das habe ich übrigens in ca. 10 Projekten schon machen dürfen, so exotisch ist das alles nicht).
Und ich fände es auch sehr gut, wenn es einen Standardisierten Weg dafür gäbe, ohne mir immer mühsam raussuchen zu müssen, wie es denn nun mit den we_object Klassen geht. Da ich auch Importe in mehrsprachigen Projekten mache, bei denen ich dann sogar die beiden Sprachversionen - wenn vorhanden, wird anhand einer ID geprüft - miteinander verbinden darf, habe ich jetzt einfach einmal mehrere simple inserts in die languaglink Tabelle gemacht. Schön ist das nicht!
Wir bekommen das aber sicher hin. erst einmal 6.3, das ist eine super Basis für andere Dinge.
Wichtig ist immer: weiterdenken. Du machst Dinge, an die ich nie gedacht hätte und umgekehrt eben auch.
Gruß
Thomas
Ja, ich mal wieder
Schönes Beispiel mit den Kategorien: ich brauche aber nicht die Kategorien des aktuellen Dokuments, sondern eines Dokuments oder Objekts von dem ich die ID kenne.
Mir gefällt besonders an wE, dass eben solche Sachen wie Import und Abgleich von 1000 Artikeln, Objekten, Kunden oder was auch immer (das habe ich übrigens in ca. 10 Projekten schon machen dürfen, so exotisch ist das alles nicht).
Und ich fände es auch sehr gut, wenn es einen Standardisierten Weg dafür gäbe, ohne mir immer mühsam raussuchen zu müssen, wie es denn nun mit den we_object Klassen geht. Da ich auch Importe in mehrsprachigen Projekten mache, bei denen ich dann sogar die beiden Sprachversionen - wenn vorhanden, wird anhand einer ID geprüft - miteinander verbinden darf, habe ich jetzt einfach einmal mehrere simple inserts in die languaglink Tabelle gemacht. Schön ist das nicht!
Wir bekommen das aber sicher hin. erst einmal 6.3, das ist eine super Basis für andere Dinge.
Wichtig ist immer: weiterdenken. Du machst Dinge, an die ich nie gedacht hätte und umgekehrt eben auch.
Gruß
Thomas
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 0 Gäste