Vererbung für das APFelSMS

Dieser Bereich dient dazu, eure Tricks und Erweiterungen vorzustellen, damit diese auch andere Anwender nutzen können. // This area can be used to publish your tricks and extensions to the APF to be used by other developers.
Antworten
Benutzeravatar
jwlighting
Beiträge: 466
Registriert: 14.07.2010, 14:23:58
Wohnort: LK Oldenburg
Kontaktdaten:

Vererbung für das APFelSMS

Beitrag von jwlighting » 20.05.2013, 14:11:20

Hallo zusammen,

ich zerbreche mir momentan den Kopf, wie man dem APFelSMS "Vererbung" beibringen kann. Es geht dabei darum Eigenschaften (z.B. CSS und JS) oder Dekoratoren (z.B. accessCtrl) an Unterseiten zu vererben.
Mir ist dabei aufgefallen, dass der direkte Gedanke von Vererbung wie bei CSS nur bedingt sinnvoll ist. Zum einen, weil man Dekoratoren nicht nur überschreiben, sondern auch entfernen können möchte, zum anderen, weil man dann immer an die Baumstruktur gebunden ist, wenn eine Sammlung an Eigenschaften und Dekoratoren mehrfach verwendet werden soll.
Ich habe euch mal ein paar Überlegungen aufgeschrieben. Es würde mich freuen, wenn ihr eure Gedanken dazu schreibt. Ziel ist es, die benutzerfreundlichste, perfomanteste und flexibelste Lösung herauszuarbeiten!

1. Prototyping
Das Prototyping ist abgeleitet vom Prototyp-Pattern. Dabei wird, statt viele verschiedene Klassen mit unterschiedlichem Verhalten zu implementieren eine umfangreichere Klasse erstellt. Die Objekte dieser Klasse werden dann als "Vorlage" für konkrete Objekte in der Anwendung geklont, dienen also als Prototyp.
Bezogen auf das APFelSMS würde das bedeuten, dass man dem Mapper eine Prototyp-Seite mitteilen kann, die er als Vorlage bei der Erzeugung einer Seite verwenden soll. Es werden dann alle Eigenschaften und Dekoratoren vom Prototyp übernommen und durch angegebene Eigenschaften ergänzt.

Im XML könnte das so aussehen:

Code: Alles auswählen

<apfelsms>
   <page id="news">
      <title>News</title>
      <css>styles/news.css</css>
      <js>script/news.js</js>
      <page id="project-news" prototype="news">
         <title>Projekt-News</title>
      </page>
      <page id="release-news" prototype="news">
         <title>Release-News</title>
      </page>
   </page>
</apfelsms>
Durch den Prototyp werden die CSS- und JS-Dateien auch bei den Unterseiten geladen. Trotzdem ist das Prototyping nicht auf Unterseiten beschränkt, sondern kann von jeder beliebigen Seite im Baum angewendet werden. Probleme sehe ich sobald man Dekoratoren entfernen oder modifizieren will, oder wenn Eigenschaften wie CSS-Dateien im Nachhinein entfernt werden sollen.
Das ist zwar alles realisierbar, führt dann aber zu einer komplexen Datenstruktur mit - in XML - immer neuen Attributen und Tags, die sich nicht mehr gut händeln lässt - ich denke da z.B. an zukünftige Features wie einen Mapper für Datenbanken.



2. PageGroups
PageGroups sind ähnlich wie Prototyping, arbeiten aber nicht über Vorlagenobjekte, sondern stellen eine Sammlung von Eigenschaften und Dekoratoren für die enthaltenen Seiten dar.
Die innerhalb der Gruppe definierten Eigenschaften werden beim Erstellen der Seiten so gemappt, als ob sie direkt bei der Seite definiert wären.

Code: Alles auswählen

<apfelsms>
   <page type="group" id="group_jQuery">
      <js>scripts/jQuery,js</js>
      <jsMergeMode>add</jsMergeMode> <!-- Options: add, overwrite -->
   </page>
   <page type="group" id="group_News">
      <groups>group_jQuery</groups>
      <css>styles/news.css</css>
      <js>scripts/news.js</js>
   </page>
   <page type="group" id="group_Project">
      <css>styles/projectPagesRelatedStyles.css</css>
      <cssMergeMode>add</cssMergeMode>
   </page>

   <page id="news">
      <title>News</title>
      <groups>group_News</groups>
      <page id="project-news">
         <groups>group_News,group_Project</groups>
         <title>Projekt-News</title>
      </page>
      <page id="release-news">
         <groups>group_News</groups>
         <title>Release-News</title>
      </page>
   </page>
Bei PageGroups ist also nicht nur die kaskadierte Wiederverwendung (group_News verwendet group_jQuery) möglich, sondern auch, mehrere Gruppen auf eine Seite anzuwenden - das geht beim Prototyping nicht.
Zudem bin ich mir bei PageGroups schon sehr klar über die technische Implementierung:
Es werden zwei neue SMSPage-Implementierungen erstellt: SMSGroupPage und SMSGroupDefinitionPage. SMSGroupPage erbt von SMSStdPage, definiert aber die Methode mapVars() neu, und liest dabei alle angegebenen PageGroups (SMSGroupDefinitionPage) ein. SMSGroupDefinition ist die Klassenrepräsantation für die <page type="group">-Tags aus dem Beispiel; sie dient als Sammlung von Eigenschaften und Dekoratoren. Über das die Methoden des SMSPage-Interfaces lässt sich sicherstellen, dass diese Gruppendefinitionen nicht als Seite in Navigationen auftauchen oder aufrufbar sind.
Das schöne dabei ist, dass ich keinen neuen Objekttyp in das SMS integrieren muss, sondern mit neuen SMSPage-Implementierungen alles abhandeln kann. Möchte man das Feature nutzen, kann wie bisher SMSStdPage als Seitentyp verwendet werden. Damit entfällt dann auch jeglicher Overhead.


Bevor ich mir jetzt weiter den Kopf zerbreche möchte ich mal hören, was ihr zu sagen habt.

LG :)
Jan

Menschen irren - Politiker sind Menschen.
Für den Norddeutschen ist 1kW = 2 Pfund Schlick.

Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: Vererbung für das APFelSMS

Beitrag von dr.e. » 24.05.2013, 23:59:32

Hallo Jan,

sorry, hab's immer noch nicht geschafft mir das Thema anzusehen. Setze mir ein Lesezeichen.
Viele Grüße,
Christian

Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: Vererbung für das APFelSMS

Beitrag von dr.e. » 08.06.2013, 16:26:50

Hallo Jan,

ich halte die zweite Option für die besser und einfacher realisierbare. Die XML-Modellierung finde ich jedoch etwas gewöhnungsbedüftig, da du einmal das <page />-Tag einmal als Gruppe und einmal als "echte" Seite verwendest. Ich würde für alle <page type="group" /> eher ein <group /> einsetzen.

Wenn ich so recht drüber nachdenke, ist das Konzept eher eine Klassifizierung, denn eine Gruppierung. Sprich an der Seite verweist du ja eher auf einen "Tag" und entsprechend getaggte Seiten können die refernzierten Klassifikations-Eigenschaften nutzen. Trotzdem ist die zweite Idee die bessere. :)

Innerhalb einer Gruppe würde ich versuchen auf den <parent /> statt <group /> zu referenzieren (nur Naming-Verbesserung) und die Vererbung der Eigenschaften noch etwas intuitiver zu gestalten (z.B. <jsMergeMode /> als Attribut von <js /> definieren).
Viele Grüße,
Christian

Benutzeravatar
jwlighting
Beiträge: 466
Registriert: 14.07.2010, 14:23:58
Wohnort: LK Oldenburg
Kontaktdaten:

Re: Vererbung für das APFelSMS

Beitrag von jwlighting » 20.07.2013, 14:59:19

Hallo Christian,
ich halte die zweite Option für die besser und einfacher realisierbare.
Das sehe ich auch so.
Die XML-Modellierung finde ich jedoch etwas gewöhnungsbedüftig, da du einmal das <page />-Tag einmal als Gruppe und einmal als "echte" Seite verwendest. Ich würde für alle <page type="group" /> eher ein <group /> einsetzen.
Das hängt mit dem generischen Mapper zusammen. Der kann jetzt schon verschiedene Page-Typen händeln, und bedient sich zur Auswahl des Typs dem Attribut "type". Insofern wäre für das neue Feature keinerlei Anpassung des Mappers notwendig.
Du bringst mich damit aber auf eine andere Sinnvolle Idee: Ich sollte den Mapper dahingehend umbauen, dass für jeden Page-Typ ein eigener Tag-Name definiert werden kann. Das dürfte in >90% der Fälle, in denen andere Page-Typen zum Einsatz kommen sinnvoll sein. Und Dank DI-Konfig ist das ja ganz einfach zu realisieren ;)
Wenn ich so recht drüber nachdenke, ist das Konzept eher eine Klassifizierung, denn eine Gruppierung. Sprich an der Seite verweist du ja eher auf einen "Tag" und entsprechend getaggte Seiten können die refernzierten Klassifikations-Eigenschaften nutzen.
Kann ich nachvollziehen. Hast du einen besseren Naming-Vorschlag? "Reference" würde ich ungerne nehmen, da es identisch zu referenzierten Seiten bei Alias- und Redirect-PageDecs ist. "Macro" vielleicht?
Innerhalb einer Gruppe würde ich versuchen auf den <parent /> statt <group /> zu referenzieren (nur Naming-Verbesserung)
OK
und die Vererbung der Eigenschaften noch etwas intuitiver zu gestalten (z.B. <jsMergeMode /> als Attribut von <js /> definieren).
Da sind wir wieder beim generischen Mapper, der das leider nicht unterstützt. Eine Eigenschaft im Objekt ist immer an ein gleichnamiges Tag gebunden.

LG :)

Menschen irren - Politiker sind Menschen.
Für den Norddeutschen ist 1kW = 2 Pfund Schlick.

Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: Vererbung für das APFelSMS

Beitrag von dr.e. » 21.07.2013, 12:33:41

Hallo Jan,
Kann ich nachvollziehen. Hast du einen besseren Naming-Vorschlag? "Reference" würde ich ungerne nehmen, da es identisch zu referenzierten Seiten bei Alias- und Redirect-PageDecs ist. "Macro" vielleicht?
Warum nicht? Finde das nicht schlecht.
Viele Grüße,
Christian

sammy8806
Beiträge: 13
Registriert: 22.07.2011, 20:18:58
Wohnort: Lemmitown
Kontaktdaten:

Re: Vererbung für das APFelSMS

Beitrag von sammy8806 » 22.07.2013, 07:54:47

Hey, ich melde mich auch mal aus der Versenkung wieder :D

Wie währe es denn mit "template" oder "copy"?
Grüße
Steven

Benutzeravatar
jwlighting
Beiträge: 466
Registriert: 14.07.2010, 14:23:58
Wohnort: LK Oldenburg
Kontaktdaten:

Re: Vererbung für das APFelSMS

Beitrag von jwlighting » 23.07.2013, 17:52:18

"template" wäre eigentlich gar nicht so schlecht, da es ja auch eine Art Vorlage ist. Nur wird und Templates sonst etwas anderes verstanden und es kann genau in diesem Zusammenhang auch mal einen Parameter/Tag <template> geben. Den Namenskonflikt würde ich gerne vermeiden ;)

Beim "virtuellen Blättern im Wörterbuch" bin ich grad noch auf "common" gestoßen. Das sind ja Eigenschaften, die mehrere Seiten gemeinsam haben. Mögliche Tags wären <common> und <commondef> (def -> Definition)

LG :)

Menschen irren - Politiker sind Menschen.
Für den Norddeutschen ist 1kW = 2 Pfund Schlick.

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast