Home / Forum / Optimale Vorgehensweise/ eZ-Systematik bei (Inhalts-) Klassen

Optimale Vorgehensweise/ eZ-Systematik bei (Inhalts-) Klassen

Um Zugang zu den Foren zu erhalten, müssen Sie angemeldet sein

Autor Nachricht

Andi B.

Registriert seit: 02.03.2006

Beiträge: 61

Dienstag, 27. März 2012 21:08:04

Hallo Community,

ich nutze zwar nun schon eine gewisse Zeit eZ Publish, aber die "optimale" Vorgehensweise habe ich bisher noch nicht gefunden. Insbesondere stellen sich mir (immer wieder) verschiedene Fragen bzw. suche ich (bis heute) nach einem geordneten Ablauf, so dass es bei Updates oder Extension-Anpassungen (durch den Entwickler) nicht zu unnötigem Aufwand kommt:

1. Ist es wirklich ratsam, die Original-Standard- bzw. Vorgabeklassen der Installation bzw. aus fertigen Extensions auf eigene bzw. Kunden-Bedürfnisse anzupassen?
Dass man die bereits vorhandenen Attribute (insbesondere die "Bezeichner"/ ID) wohl besser nicht ändern sollte, kann ich mir gut vorstellen. Aber gibt es eigentlich für Klassen auch so etwas Ähnliches wie ein "Override-System". So dass vorrangig die individuellen "Abweichungen/ Spezialregelungen" übernommen werden und ergänzend (z.B. falls es auch zu Fehlern käme) immer als "fall-back" auf die Ursprungsversion zurückgegriffen würde? Oder bleibt wirklich nichts anderes übrig, als die bei der Installation/ Extension "mitgelieferten" Klassen anzupassen und bei evtl. späteren Updates/ Änderungen diese immer wieder konkret im Einzelnen zu prüfen und ggf. zu ändern?

2. Ist es überhaupt sinnvoll, viele eigene, individuelle Klassen mit speziellen Attributen anzulegen?
Wenn man z.B. für einen bestimmten Inhaltstyp eine neue Klasse bräuchte, die mehrere, verschiedene Texteinträge/ -blöcke, Dateien, Bilder, Links etc. in Kombination erfordert, ist es dann wirklich sinnvoll, den gesamten Aufbau in der jeweiligen Klasse (als Gesamtheit bzw. Eintrag in einer Node) zu definieren oder sollte man möglichst nur die einzelnen Inhaltsarten nacheinander, in mehreren Einträgen/ Nodes über die bereits vorhandenen Standardklassen integrieren und ausgeben lassen? Für das Handling des Endnutzers ist es aber wohl sinnvoller, wenn in der jeweiligen Klasse möglichst alle Eingabemöglichkeiten erschlagen werden - bei Updates oder Änderungen der Extension ist dies aber bestimmt problematisch - oder?


Gibt es evtl. noch weitere Punkte/ Tipps,
... die man "für eine optimale, strukturierte Arbeitsweise" grundsätzlich beachten sollte, abgesehen vom Einsatz des Override-Systems bei den Templates und Settings. Ist im Web evtl. auch eine Art "Checkliste" oder "Empfehlung zur optimalen Vorgehensweise" (vorzugsweise in Deutsch) vorhanden? Bin für Anregungen, Tipps, Erfahrungsberichte, etc. diesbezüglich sehr dankbar.


Mit der Bitte und Hoffnung auf ein kurzes Feedback verbleibe ich
mit den besten Grüßen

A.B.

Sebastian v. Roos

Registriert seit: 27.01.2006

Beiträge: 361

Mittwoch, 11. April 2012 15:01:18

zu punkt 1

Also ich hab mal mit den Standard-Klassen von eZ Webin irgendwann in grauer Vorzeit angefangen. Einige Klassen hab ich erweitert, aber auch ganz neue sind hinzugekommen.

Wenn ich jetzt eine neue Install aufsetze, importiere ich einfach die letzte, am besten und weitesten entwickelte Datenbank. Dadurch hab ich alle geänderten und neu hinzugekommenen Klassen. (mehr noch als die Klassen, sind ja manchmal die Benutzerrechte nervig)

Bei einem Upgrade installier ich mir meist eine frische Version und schaue, - äußerst neugierig ; ob neue Klassen hinzugekommen sind oder sich bestehende geändert haben. Die Standardklassen haben sich nach meiner Erfahrung meist gar nicht oder nur wenig geändert.
Falls ich von den neuen Features wirklich was brauch, muss ich eben meine bestehenden Klassen anpassen.
Wenn es ganz neue Klassen in der neuen Version gibt, und ich brauch sie, leg ich sie entweder an, oder ex- bzw. importier sie über die packagefunktion.

Ich weiß nicht, ob es korrekt ist, hatte aber noch nie Probleme: Mein ganzen siteaccesse leg ich nur als Erweiterungen von ezwebin an, in dem ich unter
extension/ezwebin/settings - design.ini und site.ini die neuen siteaccesse eintrage.
Sie sind also nicht als extension, sondern nur als zusätzliches design, bzw. siteaccess von ezwebin angelegt.
Die Templates von ezwebin selber überschreibe ich beim Upgrade einfach. (streng genommen könnte es jetzt zu Problemen kommen, da ich ja dann "neue" ezwebin-templates benutze, die Klassen aber die alten, von mir angepassten sind. Nach meiner Erfahrung hat man für praktisch alle wichtigen Funktionen sowieso overrides, und dass es bei den paar templates, wo noch direkt von ezwebin kommen mit der neuen Version dann ausgerechnet zu problemen kommt ... unwahrscheinlich, bzw. muss eben kontrolliert werden.)

Punkt 2 und 3 weiß ich nichts zu.

hat dir wohl jetzt nicht viel genützt, aber ich konnte labern

Gruß:

so,

_______________________

http://webdevelopment.artenic.de ARTENIC - Publishing mit allen Mitteln!

Andi B.

Registriert seit: 02.03.2006

Beiträge: 61

Freitag, 13. April 2012 18:45:17

Hi Sebastian,

besten Dank für die vielen hilfreichen Informationen.

So oder so ähnlich habe ich mir das schon gedacht. Ich habe bisher die Setting- und (abweichenden) Design-Dateien für den jeweiligen Site-Access nicht in der Extension sondern unter Settings/Siteaccess bzw. Design/<SiteDesign> im Hauptverzeichnis hinterlegt. Ist es sinnvoller diese direkt bei den Extensions zu hinterlegen - wenn ja: warum?

Fazit: Werde dann wohl zukünftig die eZ-Standardklassen als unveränderte Kopie (Backup/ Sicherung) behalten und anschließend die Original-Klassen auf die konkreten individuellen Anforderungen anpassen. Vor Updates mache ich am besten eine Sicherung der zu diesem Zeitpunkt aktuellen Klassen (Paket => Export) und lass dann beim Update alle meine angepassten Standardklassen vom Programm aktualisieren/ überschreiben. Merci!


Nochmals herzlichen Dank für Deine Rückmeldung, schönes Wochenende und beste Grüße

Andi

Sebastian v. Roos

Registriert seit: 27.01.2006

Beiträge: 361

Freitag, 04. Mai 2012 14:25:34

<<Design - wenn ja: warum?>
gehen tut das schon. Aber ich glaub gedacht ist, aus Ordnungsgründen, dass alle geänderten oder neuen Dateien eben "Erweiterungen" sind und deshalb xtensions ...


<<Programm aktualisieren/ überschreiben ...>
Wenn Du Klassen importierst, und bestehende überschreibst, sind die Änderungen natürlich futsch. Ebenso, wenn Klassen schon Inhaltsobjekte zugeordnet sind, wären diese gelöscht. (glaub ich jedenfalls)
so ganz versteh ich auch nicht, wieso in der Update-Anleitung auf ez.no eben beschrieben wird, Klassen von neuem ezwebin/flow oder so als Package zu importieren. I.d. Regel gibt es doch Content für die Klassen. Also ist es zwar ein Update, aber der Inhalt wäre futsch. Find ich nicht ganz logisch. Wie gesagt, ich kopier mir die neuen Templates von ezwebin/flow und was die Klassen angeht, schau ich mir in einer eigenen frischen Install eventuelle Änderungen der Standardklassen an, und übertrage diese, falls ich sie überhaupt benötige, in die vorhandenen der laufenden Seite.
okay, ganz neue Klassen, noch ohne Objekte, die kann man natürlich importieren.

..
Gruß


_______________________

http://webdevelopment.artenic.de ARTENIC - Publishing mit allen Mitteln!

Um Zugang zu den Foren zu erhalten, müssen Sie angemeldet sein