hotti: Trennung der Anliegen (Logik - Layout)

Beitrag lesen

hi T-Rex,

--------Abschweif-----

warum nicht mal abschweifen ;)

ORM: Da habe ich eine total abgefahrene Tabelle:

  
objects	CREATE TABLE `objects` (  
  `oid` varchar(100) NOT NULL DEFAULT '',  
  `att` varchar(100) NOT NULL DEFAULT '',  
  `val` longtext,  
  PRIMARY KEY (`oid`,`att`),  
  FULLTEXT KEY `val` (`val`)  
) ENGINE=MyISAM DEFAULT CHARSET=utf8  

Die Tabelle ist natürlich alles Andere als normalisiert: Die Attribute liegen übereinander anstatt nebeneinander in Feldern, das macht die Sache interessant für Objekte, die verschiedene Anzahlen an Attributen haben und dazu noch verschiedene Namen der Attribute. Dazu gibt es eine Tie-Klasse in Perl:

  
  tie my %obs, 'ORM';  # binde einen %hash an die Objektsammlung  
  my $home = $obs{'/'}; # ziehe ein Object heraus  
  $home->{title} = 'Ein neuer Titel für die Startseite';  

Das hat jetzt auf den ersten Blick nichts mit Deinem Anliegen zu tun, ist aber ein Beispiel dafür, wie sich Aufgabenbereiche trennen lassen ohne den Code zu ändern: Eine andere Klasse 'Objects' bindet dieselbe Objektsammlung an eine Datei. Die Klasse wird austauschbar, die Datenstruktur ist dieselbe.

Die Logik freilich, die ist immer irgendwie in den Code geschrieben. Anstelle von Templates bevorzuge ich sog. Funktionstypen (Rollen). Gerne benutze ich für das User-Interface eine Konfigurationsdatei nach dem Stil einer 'system.ini', das Format passt gut auf das Objektmodell, Object-ID mit Attributen:

[oid]
att=foo
isa=hier steht der Funktionstyp

Für den Funktionstyp stehen dann mehr oder weniger verschiedene Methoden zur Verfügung, die das aus der Konfiguration heraus erstellte Objekt benutzen darf. Wenn da z.B. notiert ist: isa=loginform, wird ein Login-Formular erzeugt, mit allen Feldern, die dazu benötigt werden.

Vielleicht konnte ich ein paar Anregungen geben,
viele Grüße,
  Hotti