Objekte vorkonfigurieren (z.B. "Template" oder "User")

Hallo!

Ich habe ein globales Skript (global.inc.php), auf das alle Anfragen per =

Mod-Rewrite umgelenkt werden, welches dann das eigentliche Skript läd. =

In diesem globalen Script lese ich z.B. die Konfigurations-Datei aus,=20
führe die Benutzer-Authentifizierung durch usw.

Die eingebundenen Skipte (z.B. liste.php) sollen jetzt z.B. so aussehen:

$liste =3D new Liste($_GET['id']);
$tpl =3D new Template();
$tpl->assign('tabelle', $liste->getTable());
$tpl->display('liste.tpl');
?>

Die problematische Zeile ist "$tpl =3D new Template();". Ich möchte das=
=20
Template-Objekt gerne vorkonfigurieren, z.B. den "template_dir" angeben, =

ein Header- und Footer-Template einbinden, usw.

Die Frage ist jetzt, wie ich das vorab im global.inc.php Skript=20
konfigurieren kann, da das Objekt ja erst später, im liste.php Skript=20
initialisiert wird. Mir fallen drei mögliche Lösungen ein:

1. statische Eigenschaften von Template:
in global.inc.php setze ich statische Eigenschaften, z.B.
Template::$settings['template_dir'] =3D "/pfad/...";
Die kann ich dann im Konstruktor des Template-Objekts als Eigenschaften=20
übertragen:
$this->template_dir=3D self::$settings['template_dir'];
Nachteil: Wenn ich andere/zusätzliche Eigenschaften verändern will, m=
uss=20
ich die Template-Klasse ändern - was ich vermeiden will

2. Singleton:
Ich speichere die Template-Instanz in der Template-Klasse und gebe immer =

nur diese Instanz zurück.
Nachteil: nur eine Template-Instanz möglich - allerdings, braucht man=20
jemals mehr?

3. Wrapper:
Template speichert eine Smarty Instanz, und leitet Aufrufe wie assign()=20
und display() weiter.
Nachteil: Ich müsste jede Methode die ich benötige implementieren, si=
nd=20
allerdings nicht so viele. Außerdem müsste die Template Klasse dann=20
entweder statisch sein, oder ebenfalls ein Singleton.


Das gleiche Problem tritt auch an anderen Stellen auf, z.B. wenn ich ein =

User-Objekt habe, welches den aktuell eingeloggten User repräsentiert. =

Irgendwie benötige ich das User-Objekt an verschiedenen Stellen in der =

Software (z.B. User::getUserId()), aber ich möchte hierauf zugreifen=20
können, ohne mir Gedanken machen zu müssen wie ich das User-Objekt=20
instanziere (z.B. mit der User-ID aus der Session...). Bleiben wieder=20
nur ein Singleton oder eine globale Variable.


Wie geht Ihr mit vergleichbaren Problemen um?


Viele Grüße
Andreas

Re: Objekte vorkonfigurieren (z.B. "Template" oder "User")

Andreas Korthaus schrieb:

> Ich habe ein globales Skript (global.inc.php), auf das alle Anfragen per
> Mod-Rewrite umgelenkt werden, welches dann das eigentliche Skript läd.
> In diesem globalen Script lese ich z.B. die Konfigurations-Datei aus,
> führe die Benutzer-Authentifizierung durch usw.
>
> Die problematische Zeile ist "$tpl = new Template();". Ich möchte das
> Template-Objekt gerne vorkonfigurieren, z.B. den "template_dir" angeben,
> ein Header- und Footer-Template einbinden, usw.

Manch das doch über Deine Konfig! Ich denk Du lädst auch die
Konfigdaten. Dann kannste auch diese Daten dort holen.

> 2. Singleton:

Eine Templateklasse als Singleton? Das past irgendwie nicht zusammen.

> Nachteil: nur eine Template-Instanz möglich - allerdings, braucht man
> jemals mehr?

Ich hab sehr oft viele davon. Aber das hängt in 1. Linie von der
Arbeitsweise der Klasse und von der Notwendigkeit ab.

MfG, Ulf

Re: Objekte vorkonfigurieren (z.B. "Template" oder "User")

Hallo Ulf!

Ulf Kadner schrieb:
> Andreas Korthaus schrieb:
>=20
>> Ich habe ein globales Skript (global.inc.php), auf das alle Anfragen p=
er
>> Mod-Rewrite umgelenkt werden, welches dann das eigentliche Skript lä=
d.
>> In diesem globalen Script lese ich z.B. die Konfigurations-Datei aus,
>> führe die Benutzer-Authentifizierung durch usw.
>>
>> Die problematische Zeile ist "$tpl =3D new Template();". Ich möchte =
das
>> Template-Objekt gerne vorkonfigurieren, z.B. den "template_dir" angebe=
n,
>> ein Header- und Footer-Template einbinden, usw.
>=20
> Manch das doch über Deine Konfig! Ich denk Du lädst auch die
> Konfigdaten. Dann kannste auch diese Daten dort holen.

In meiner Konfig habe habe ich nur statische Einstellungen, vor allem=20
Sachen wie DB-Verbindungsdaten, Pfade... also Daten die für jede=20
Applikation/Installation individuell sind und sich normalerweise nicht=20
ändern. Diese Daten habe ich in einer config.ini die ich in meinem=20
global.inc.php Script lade. Danach werden dann z.B. Konstanten=20
definiert, DB-Verbindung herstellt (ebenfalls singleton), der User=20
Authentifiziert usw., das heißt es wird alles was bei jedem Request=20
sowieso benötigt wird initialisiert. Dazu zählen auch User- und=20
Template-Objekt.

In Bezug auf die Template-Klasse meine ich mit Konfiguration aber etwas=20
anderes. Zwar habe ich hier auch Einstellungen, die aus der config.ini=20
bis an Smarty weitergereicht werden, aber z.B. das "template_dir"=20
unterscheidet sich sich je nach Modul, oder die Sprache unterscheidet=20
sich je nach User.

Mein Problem wird vor allem dadurch verursacht, dass ich eine=20
Template-Klasse (basierend auf Smarty) in eine Art Komponenten Sammlung=20
auslagern will, um die Klasse in verschiedenen Anwendungen verwenden zu=20
können. Jetzt übergeben verschiedene Anwendungen z.B. jeweils=20
verschiedene Daten an die Template-Engine (per assign()), die im=20
Template verwendet werden können (z.B. bestimmte Pfade, Benutzername us=
w.).

Ich suche nach einer Möglichkeit, wie ich gleichzeitig:

1. im eingebundenen Skript ("liste.php") ohne globale Variablen an das
Template-Objekt komme
2. dem Template-Objekt vorher verschiedene Daten/Einstellungen übergebe=
n
kann
3. die Template-Klasse verallgemeinern und auslagern kann, so dass sie
unverändert aus verschiedenen Anwendungen verwendet werden kann

Unter diesen Bedingungen wüsste ich auch nicht, wie ich aus der=20
Template-Klasse irgendwas aus der Konfig auslesen soll - abgesehen davon =

wird dann wieder die Information benötigt, wie man an die Konfig Daten =

kommt. Aber OK, das könnte man ja noch in eine Klasse kapseln (schon=20
wieder Singleton, oder woher kenne ich in der Template-Klasse das=20
Objekt? im Konstruktor übergeben? Hm...).

Aber woher bekomme ich dann z.B. den Benutzernamen, Pfade, Informationen =

zu Headern, Footern... die ich in meinen Templates benötige?


>> 2. Singleton:
>=20
> Eine Templateklasse als Singleton? Das past irgendwie nicht zusammen.
>=20
>> Nachteil: nur eine Template-Instanz möglich - allerdings, braucht ma=
n
>> jemals mehr?
>=20
> Ich hab sehr oft viele davon.

Für eine normale Web-Anwendung? Sagen wir mal ein klassischer=20
Online-Shop - da kommt ein Request um sich den Warenkorb anzusehen -=20
wozu braucht man da mehr als eine Template-Instanz in einem Script? Ich=20
kann mir da vielleicht abgesehen von einem CMS das statisches HTML=20
erzeugt, kein sinnvolles Szenario vorstellen.


Viele Grüße
Andreas

Re: Objekte vorkonfigurieren (z.B. "Template" oder "User")

Andreas Korthaus schrieb:

> Ich suche nach einer Möglichkeit, wie ich gleichzeitig:
>
> 1. im eingebundenen Skript ("liste.php") ohne globale Variablen an das
> Template-Objekt komme

Werf es in den RAM und hole es bei Bedarf. (Da Singleton ausscheidet)

> 2. dem Template-Objekt vorher verschiedene Daten/Einstellungen übergeben
> kann

Constructor oder Redesign. Allerdings verstehe ich hier dein Ansinnen
auch nicht wirklich.

> 3. die Template-Klasse verallgemeinern und auslagern kann, so dass sie
> unverändert aus verschiedenen Anwendungen verwendet werden kann

Redesign.

> Unter diesen Bedingungen wüsste ich auch nicht, wie ich aus der
> Template-Klasse irgendwas aus der Konfig auslesen soll - abgesehen davon
> wird dann wieder die Information benötigt, wie man an die Konfig Daten
> kommt. Aber OK, das könnte man ja noch in eine Klasse kapseln (schon
> wieder Singleton, oder woher kenne ich in der Template-Klasse das
> Objekt? im Konstruktor übergeben? Hm...).

Warum schreibst du nicht eine kurze Klasse zum parsen der
Konfigurationsdatei. Diese kannst du dann über ein Singleton ansteuern
und dir die Konfigdaten geben lassen, die du benötigst. Das kannst du
dann im Konstruktor deiner Template-Klasse machen.

> Aber woher bekomme ich dann z.B. den Benutzernamen, Pfade, Informationen
> zu Headern, Footern... die ich in meinen Templates benötige?

Daher, wo du sie hinterlegt hast. Konfigurationsdatei, Session, was weiß
ich :P

>>> 2. Singleton:
>>
>> Eine Templateklasse als Singleton? Das past irgendwie nicht zusammen.
>>
>>> Nachteil: nur eine Template-Instanz möglich - allerdings, braucht man
>>> jemals mehr?
>>
>> Ich hab sehr oft viele davon.
>
> Für eine normale Web-Anwendung? Sagen wir mal ein klassischer
> Online-Shop - da kommt ein Request um sich den Warenkorb anzusehen -
> wozu braucht man da mehr als eine Template-Instanz in einem Script? Ich
> kann mir da vielleicht abgesehen von einem CMS das statisches HTML
> erzeugt, kein sinnvolles Szenario vorstellen.

Wie wäre es mit verschiedenen Templates, die man zu einem Zusammenführt
*rat*. Hängt auch von deren Funktionalität ab - aber das muß Ulf dir
erläutern ^^

Gruß,
Torsten

Re: Objekte vorkonfigurieren (z.B. "Template" oder "User")

Torsten Zuehlsdorff schrieb:

> Warum schreibst du nicht eine kurze Klasse zum parsen der
> Konfigurationsdatei. Diese kannst du dann über ein Singleton ansteuern
> und dir die Konfigdaten geben lassen, die du benötigst. Das kannst du
> dann im Konstruktor deiner Template-Klasse machen.

ACK

> Wie wäre es mit verschiedenen Templates, die man zu einem Zusammenführt
> *rat*. Hängt auch von deren Funktionalität ab - aber das muß Ulf dir
> erläutern ^^

Ich dachte da gäbs nix weiter zu sagen. Naja knapp daneben ist halt auch
vorbei. ;-)

Ich hab jetzt keine Lust da detailierter zu werden. Ist doch nix
ungewöhnliches an mehreren Templates. z.B. zusammengesetzte Templates
oder eine extra Template für Javascript im Html-Head oder oder oder. Da
gibts "tausende" Möglichkeiten.

MfG, Ulf

Re: Objekte vorkonfigurieren (z.B. "Template" oder "User")

Hi Torsten!

Torsten Zuehlsdorff schrieb:

>> 1. im eingebundenen Skript ("liste.php") ohne globale Variablen an das=

>> Template-Objekt komme
>=20
> Werf es in den RAM und hole es bei Bedarf.

Der Ablauf ist etwa so (schematisch):

Request: GET /index.php?module=3Dirgendwas&script=3Dliste

/index.php:
User::load($_SESSION['user_id']);
$user =3D User::getInstance();

$tpl =3D Template::getInstance();
$tpl->template_dir =3D XY_DIR.$_GET['module'].'/templates';
$tpl->assign('USERNAME', $user->getUsernme());
$tpl->assign('TPL_HEADER', XY_DIR.'core/templates/header.tpl');
$tpl->assign('TPL_FOOTER', XY_DIR.'core/templates/footer.tpl');

include "./$_GET[module]/$_GET[script].php"; // vereinfacht (unsicher)
?>

/irgendwas/liste.php:
$user =3D User::getInstance();
$tpl =3D Template::getInstance();
if ($user->isAdmin())
$tpl->assign('foo', 'bar');
$tpl->display('liste.tpl');
?>

Das ist jetzt natürlich etwas vereinfacht...

Die Template-Klasse soll so allgemein funktionieren, dass ich wie oben=20
die Möglichkeit habe, komplett auf das Template-Objekt zugreifen zu=20
können, ohne die Template-Klasse ändern zu müssen. Somit kann ich s=
ie=20
dann in ganz verschiedenen Projekten verwenden, mit verschiedenen=20
Anforderungen und Aufbau von Templates.

Wenn ich an Stelle des Singletons statische Eigenschaften verwende, muss =

ich entweder in der Template Klasse jede Eigenschaft fest=20
einprogrammieren, die ich ändern will (keine Flexibilität), oder ich =

verwende Arrays und foreach:

class Template{

private static $assign_list =3D array();
private static $property_list =3D array();

function __construct() {
foreach (self::$assign_list as $k=3D>$v) $this->assign($k,$v);
foreach (self::$property_list as $k=3D>$v) $this->$k =3D $v;
}
static function addAssign($k,$v) {
self::$assign_list[$k] =3D $v;
}
static function addProperty($k,$v) {
self::$property_list[$k] =3D $v;
}
}

und dann halt in index.php:

Template::addAssign('USERNAME', $user->getUsernme());
Template::addProperty('template_dir',XY_DIR.$_GET['module']. '/templates')=
;

Aber das gefällt mir auch nicht wirklich. Hat da vielleicht jemand ne=20
bessere Idee?

> (Da Singleton ausscheidet)

warum?

>> 2. dem Template-Objekt vorher verschiedene Daten/Einstellungen überg=
eben
>> kann
>=20
> Constructor oder Redesign. Allerdings verstehe ich hier dein Ansinnen
> auch nicht wirklich.

Siehe Beispiel oben, von der Sorte habe ich ca. 10-20 globale=20
Einstellungen. Die will ich nicht wirklich in jedem Skript das ein=20
Template anzeigt im Konstruktor übergeben. Das Skript soll darüber=20
nichts wissen. Was würdest Du denn als Redesign vorschlagen, in welche =

Richtung? Ijm Prinzip funktioniert das alles sehr gut, bis auf eben=20
diese nervige Kleinigkeit mit dem "vor-konfigurieren".

>> 3. die Template-Klasse verallgemeinern und auslagern kann, so dass sie=

>> unverändert aus verschiedenen Anwendungen verwendet werden kann
>=20
> Redesign.

Warum Redesgn? Die Klasse basiert auf Smarty, ist eigentlich nur noch um =

ein paar Kleinigkeiten wie Mehrsprachigkeit ergänzt. Von der=20
Funktionsweise hast sich nichts gegenüber Smarty geändert. Ich suche =
nur=20
nach einem Weg, wie ich die Klasse vernünftig global vorkonfigurieren=20
kann, und zwar so, dass ich weiterhin "new Template()" in den Skripten=20
verwenden kann, aber auf der anderen Seite so flexibel bleibe, dass ich=20
zuvor in der globalen index.php beliebige Einstellungen an den=20
Voreinstellungen der Klasse vornehmen kann, ohne die Klasse selbst zu=20
verändern.

Vielleicht verwende ich doch einen Wrapper und 2 Klassen, da ich in den=20
Skripten eh nur 2-3 Methoden von Smarty benötige. Dann kann ich das=20
Smarty-Objekt zuvor ganz normal erzeugen und konfigurieren, und dann an=20
den Wrapper übergeben, der das Objekt in einer Statischen Variable=20
speichert. Hm.

> Warum schreibst du nicht eine kurze Klasse zum parsen der
> Konfigurationsdatei. Diese kannst du dann über ein Singleton ansteuer=
n
> und dir die Konfigdaten geben lassen, die du benötigst. Das kannst du=

> dann im Konstruktor deiner Template-Klasse machen.

Ich habe schon so eine Klasse, allerdings stehen in der=20
Kofigurations-Datei nur ein Teil der Daten die am Template konfiguriert=20
werden (s.o.)

>>>> 2. Singleton:

>> Für eine normale Web-Anwendung? Sagen wir mal ein klassischer
>> Online-Shop - da kommt ein Request um sich den Warenkorb anzusehen -
>> wozu braucht man da mehr als eine Template-Instanz in einem Script? Ic=
h
>> kann mir da vielleicht abgesehen von einem CMS das statisches HTML
>> erzeugt, kein sinnvolles Szenario vorstellen.
>=20
> Wie wäre es mit verschiedenen Templates, die man zu einem Zusammenfü=
hrt
> *rat*. Hängt auch von deren Funktionalität ab - aber das muß Ulf =
dir
> erläutern ^^

Das mache ich auch, ich bezeichne halt das was am Ende rauskommt als=20
eine Template-Instanz. Ich führe keine Templates zusammen, sondern ich =

binde benötigte "Teil-Templates" (Header, Footer, Navigation...) ein.=20
Das muss natürlich noch funktionieren ;-)

Grüße
Andreas

Re: Objekte vorkonfigurieren (z.B. "Template" oder "User")

Andreas Korthaus schrieb:

> Hi Torsten!

Darf ich auch was dazu sagen? ;-)

> User::load($_SESSION['user_id']);
> $user = User::getInstance();
>
> $tpl = Template::getInstance();
> $tpl->template_dir = XY_DIR.$_GET['module'].'/templates';

Nur zur Sicherheit:

12.11. Prüfe importierte Parameter. Traue niemandem
http://www.php-faq.de/q/q-sicherheit-parameter.html

> $user = User::getInstance();
> $tpl = Template::getInstance();

Das ist dann Deine Templateklasse als Singleton? Warum? Schreib doch nen
Manager der die eine Instanze der Templateklasse liefert, wenn Du
unbedingt eine persistente Instanz brauchst.

>> Constructor oder Redesign. Allerdings verstehe ich hier dein Ansinnen
>> auch nicht wirklich.
>
> Siehe Beispiel oben, von der Sorte habe ich ca. 10-20 globale
> Einstellungen. Die will ich nicht wirklich in jedem Skript das ein
> Template anzeigt im Konstruktor übergeben.

Dann nutze eine Singleton-Instanz Deiner Konfig-Klasse um diese zu
setzen. Ich verstehe Dein Problem damit nicht ganz.

> Ich habe schon so eine Klasse, allerdings stehen in der
> Kofigurations-Datei nur ein Teil der Daten die am Template konfiguriert
> werden (s.o.)

Warum? Schreib den rest doch auch rein. Wenn unbekannte Elemente (zur
Initialisierung der Config) existieren dann arbeite mit Platzhaltern.

MfG, Ulf

Re: Objekte vorkonfigurieren (z.B. "Template" oder "User")

Ulf Kadner schrieb:
> Andreas Korthaus schrieb:
>
>>Hi Torsten!
>
> Darf ich auch was dazu sagen? ;-)

Aber gerne - dann muß ich weniger tippen ^^

>>$user = User::getInstance();
>>$tpl = Template::getInstance();
>
> Das ist dann Deine Templateklasse als Singleton? Warum?

Ich behaupte: Java'ler. Oder ein Nutzer einer anderen Sprachen, die eine
behindernde Typisierung an den Tag legen.

> Schreib doch nen
> Manager der die eine Instanze der Templateklasse liefert, wenn Du
> unbedingt eine persistente Instanz brauchst.

Du (Andreas) hättest dann quasi:
$objTemplate = Singleton::getInstance('Template');

Dann hast du auch nicht mehr das typische Problem, dass du Objekte in
Klassenvariablen lagerst.

Wo wir gerade dabei sind: Lege dir bitte eine Nomenklatur an. PHP kennt
entgegen aller Behauptungen Datentypen und man sollte wissen, mit
welchen man gerade arbeitet.

Gruß,
Torsten

Re: Objekte vorkonfigurieren (z.B. "Template" oder "User")

Torsten Zuehlsdorff schrieb:

> Ulf Kadner schrieb:
>> Das ist dann Deine Templateklasse als Singleton? Warum?
>
> Ich behaupte: Java'ler. Oder ein Nutzer einer anderen Sprachen, die eine
> behindernde Typisierung an den Tag legen.

Auch in streng typisierten Sprachen gibts diese Möglichkeiten. Nicht
zuletzt über Object und typecasting. Oder man nimmt halt z.B. ein
Interface dazu her. (OK ist nicht genau das selbe aber ähnlich) Ober
verstehe ich Dich falsch?

> Du (Andreas) hättest dann quasi:
> $objTemplate = Singleton::getInstance('Template');
>
> Dann hast du auch nicht mehr das typische Problem, dass du Objekte in
> Klassenvariablen lagerst.

Genau so mein ichs. :-)

MfG, Ulf

Re: Objekte vorkonfigurieren (z.B. "Template" oder "User")

Ulf Kadner schrieb:

>>>Das ist dann Deine Templateklasse als Singleton? Warum?
>>
>>Ich behaupte: Java'ler. Oder ein Nutzer einer anderen Sprachen, die eine
>>behindernde Typisierung an den Tag legen.
>
> Auch in streng typisierten Sprachen gibts diese Möglichkeiten. Nicht
> zuletzt über Object und typecasting. Oder man nimmt halt z.B. ein
> Interface dazu her. (OK ist nicht genau das selbe aber ähnlich) Ober
> verstehe ich Dich falsch?

Nein, dass siehst du ganz richtig und führst auch gleich den Hauptgrund
auf, warum das keine gute Lösung ist: nötiges Casting.
In Java müßte man als Rückgabewert "Object" definieren und dann immer
auf das gewünschte Object casten, was dementsprechend zu lasten der
performance geht. Abgesehen davon, dass es nervt :P

Aber egal wie streng eine Sprache typisiert ist - es gibt immer einen
"untypisierten Typ". Z.b. für solche Fälle, wo man Werte aus einem
Stream liest.

Gruß,
Torsten

Re: Objekte vorkonfigurieren (z.B. "Template" oder "User")

Torsten Zuehlsdorff schrieb:

> Nein, dass siehst du ganz richtig und führst auch gleich den Hauptgrund
> auf, warum das keine gute Lösung ist: nötiges Casting.
> In Java müßte man als Rückgabewert "Object" definieren und dann immer
> auf das gewünschte Object casten, was dementsprechend zu lasten der
> performance geht.

Ist das in Java so problematisch mit der Performance? Hätt ich ja nicht
gedacht. Aber z.B. in anderen Sprachen (C# meinetwegen) ist das eher
kein nennenswertes Problem. Es sei den man übertreibts damit. Man kann
ja alles irgendwie casten ;-)

> Abgesehen davon, dass es nervt :P

Och... das ist subjektiv! :-)

> Aber egal wie streng eine Sprache typisiert ist - es gibt immer einen
> "untypisierten Typ".

Netter Ausdruck!

> Z.b. für solche Fälle, wo man Werte aus einem
> Stream liest.

byte[]? ;-)

MfG, Ulf

Re: Objekte vorkonfigurieren (z.B. "Template" oder "User")

Ulf Kadner schrieb:

>>Nein, dass siehst du ganz richtig und führst auch gleich den Hauptgrund
>>auf, warum das keine gute Lösung ist: nötiges Casting.
>>In Java müßte man als Rückgabewert "Object" definieren und dann immer
>>auf das gewünschte Object casten, was dementsprechend zu lasten der
>>performance geht.
>
> Ist das in Java so problematisch mit der Performance? Hätt ich ja nicht
> gedacht.

Ich will mich nicht zu weit aus dem Fenster wagen - da Java nicht mein
Spezialgebiet ist und der Source nicht öffentlich - aber ich habe in ein
paar Archiven Aussagen von Menschen gefunden die Java entwickeln. Gemäß
ihnen werden in Java alle Objekte im Heap, egal wie groß oder klein
lokalisiert. Und auch ein Cast geht über den Heap. Und der Unterschied
Heap/Stack ist gewaltig.

> Aber z.B. in anderen Sprachen (C# meinetwegen) ist das eher
> kein nennenswertes Problem. Es sei den man übertreibts damit. Man kann
> ja alles irgendwie casten ;-)

Zu anderen Sprachen kann ich mich nicht äußern. Bei kleinen bis
mittleren Applikationen fällt soetwas vermutlich auch nur dann auf, wenn
man Performance benötigt.

>>Abgesehen davon, dass es nervt :P
>
> Och... das ist subjektiv! :-)

Das Thema "faule Programmierer" hatten wir schon :P

>>Aber egal wie streng eine Sprache typisiert ist - es gibt immer einen
>>"untypisierten Typ".
>
> Netter Ausdruck!

Der ist nicht auf meinem Mist gewachsen, sondern entstammt einem Essay,
das auf Basis des "ewigen Konfliktes" zwischen Anhängern statisch
typisierter Sprachen und Anhänger dynamisch typisierter Sprachen
geschrieben wurde.

>>Z.b. für solche Fälle, wo man Werte aus einem
>>Stream liest.
>
> byte[]? ;-)

*lach* Das habe ich ja fast schon erwartet :P

B und C kennen im übrigen den Typ
auto ;)

Gruß,
Torsten

Re: Objekte vorkonfigurieren (z.B. "Template" oder "User")

Hallo!

Ulf Kadner schrieb:
> Hi Torsten!
>=20
> Darf ich auch was dazu sagen? ;-)

na gut, ausnahmsweise ;-)

>> $user =3D User::getInstance();
>> $tpl =3D Template::getInstance();
>=20
> Das ist dann Deine Templateklasse als Singleton? Warum? Schreib doch ne=
n
> Manager der die eine Instanze der Templateklasse liefert, wenn Du
> unbedingt eine persistente Instanz brauchst.

Ja, in die Richtung tendiere ich inzwischen auch. Es ist nicht so dass=20
ich unbedingt eine "presistente" Template Klasse brauche, nur weiß ich =

nicht wie ich mein Ziel anders erreichen könnte. Ich habe ja einige=20
Beispiele gegeben für Daten, die ich an jedes Template übergeben will=
.
Manche davon sind statisch für die gesamte Anwendung (das kommt dann=20
entweder aus der Konfig-Klasse oder steht halt fest im Code), andere=20
Daten sind nicht für jeden Request gleich, das heißt ich analysiere d=
en=20
Request (z.B. "welches Modul?") und übergebe dann entsprechende Werte.

Da es sich unterm Strich um ca. 10-20 Smarty-Eigenschaften und/oder=20
Template-Variablen handelt, will ich diese Daten nicht in jedem=20
einzelnen Skript übergeben, sondern einmalig. Aber Du hast schon Recht,=
=20
mit einer Manager-Klasse sieht das irgendwie noch am elegantesten aus.=20
Wie ich um die Persistenz herum komme wüsste ich nicht. Irgendwie muss =

ich die Werte ja übergeben.

>> Ich habe schon so eine Klasse, allerdings stehen in der
>> Kofigurations-Datei nur ein Teil der Daten die am Template konfigurier=
t
>> werden (s.o.)
>=20
> Warum? Schreib den rest doch auch rein. Wenn unbekannte Elemente (zur
> Initialisierung der Config) existieren dann arbeite mit Platzhaltern.

Um z.B. Smarty::template_dir zu bestimmen benötigt man Informationen=20
über den Request, da jedes Modul ein eigenes Template-Verzeichnis hat. =

Das gehört aber meines Erachtens nicht in das Template-Objekt. Daher=20
würde ich es lieber von außen übergeben.


Viele Grüße
Andreas