Systemlast / Module nicht einbinden

[Stefan]

Hallo zusammen,

ich habe ein Perlskript das ich ausgiebig getestet habe.

Das Skript möchte ich nun einsetzen. Soll ich daher die Befehle

use warnings;
use strict;
use CGI::Carp qw(fatalsToBrowser);

kommentieren, um den Server nicht unnötig zu belasten?

Danke im voraus...

Stefan

[Christian Kruse]

你好 Stefan,

Das Skript möchte ich nun einsetzen. Soll ich daher die Befehle

use warnings;
use strict;
use CGI::Carp qw(fatalsToBrowser);

kommentieren, um den Server nicht unnötig zu belasten?

Würde ich lassen. Fehler können immer mal auftreten, auch wenn du sie
bisher noch nicht entdeckt hast. Solange du dein Programm nicht verifiziert
hast, würde ich sie drin lassen oder durch eine Alternative ersetzen.

再见,
 克里斯蒂安

[Stefan]

Hi Christian

was meinst du mit Alternative?

Den Perl Interpreter kann man ja mit dem Schalter w aufrufen. Soll man bei getesten Skript diesen Schalter noch benutzen?

Bye

Stefan

[Christian Kruse]

你好 Stefan,

was meinst du mit Alternative?

Statt CGI::Carp qw/fatalsToBrowser/ würde ich lieber einen Signal-Handler
für die() setzen, der eine nette Meldung für den Nutzer ausgibt:

  
sub sighandler {  
  print <<HTML;  
… Fehlermeldung erzeugen  
HTML  
}  
  
$SIG{__DIE__} = \&sighandler;  

Den Perl Interpreter kann man ja mit dem Schalter w aufrufen. Soll man
bei getesten Skript diesen Schalter noch benutzen?

Du solltest immer den -w-Switch benutzen und nie use warnings, ja. Das ist
der perldoc sogar so wichtig, dass sie es _drei_ mal wiederholen ;)

再见,
 克里斯蒂安

[Struppi]

was meinst du mit Alternative?

Statt CGI::Carp qw/fatalsToBrowser/ würde ich lieber einen Signal-Handler
für die() setzen, der eine nette Meldung für den Nutzer ausgibt:

[code lang=perl]
sub sighandler {
  print <<HTML;
… Fehlermeldung erzeugen
HTML
}

diese Funktion würde ich noch Erweitern und dem admin eine Mail zu schicken, da du (nicht christian) diese Meldung ja nicht zu sehen bekommst und soweit ich weiß auch kein Eintrag im error log mehr gemacht wird. Zudem hat es den Vorteil dass du evtl. noch wichtige Parameter mitschicken lassen kannst.

Darüber hinaus ist die Frage nach der systemlast wegen use strict und Warnungen etwas seltsam, arbeitet ihr mit 8086 Prozessoeren?
Auf allen anderen Rechnern dürfte es keinen meßbaren Unterschied mehr ausmachen ob use strict eingebunden wurde oder nicht.
Du kannst dir die Liste der eingebuinden Module auch mal anzeigen lassen:
print join "\n", keys %INC;
und dann nachschauen was du sparst wenn du struct weg läßt.

Struppi.

[Christian Kruse]

你好 Struppi,

Darüber hinaus ist die Frage nach der systemlast wegen use strict und
Warnungen etwas seltsam, arbeitet ihr mit 8086 Prozessoeren?
Auf allen anderen Rechnern dürfte es keinen meßbaren Unterschied mehr
ausmachen ob use strict eingebunden wurde oder nicht.

Zumal strict.pm eigentlich nichts anderes macht als eine Perl-interne
Variable zu setzen…

再见,
 克里斯蒂安

[opi]

Hallo Christian,

Statt CGI::Carp qw/fatalsToBrowser/ würde ich lieber einen Signal-Handler
für die() setzen, der eine nette Meldung für den Nutzer ausgibt:

sub sighandler {
  print <<HTML;
… Fehlermeldung erzeugen
HTML
}

$SIG{DIE} = &sighandler;

  
genau darüber habe ich mir in den letzten Tagen den Kopf zerbrochen  
und diesen Gedanken aus dem Grund verworfen, da ich nicht immer  
genau feststellen kann, an welcher Stelle in meinem Skript der  
Prozess stirbt. Dabei geht es mir um den HTML-Header, der eventuell  
schon ausgegeben wurde oder auch nicht. Woran soll dies der die  
Handler erkennen? Wird denn nicht ein Serverfehler ausgegeben, wenn  
kein HTML-Header an den Browser gesendet wird? Unschön fänd ich es  
auch widerrum, wenn da über der "netten Meldung" ein "Content-type:  
text/html ..." erscheint.  
  
Wie würdest du das überprüfen?  
  
  
Greez,  
opi

-- 
Selfcode: ie:( fl:( br:^ va:) ls:] fo:) rl:( n4:? ss:| de:] ch:? mo:|  

[Struppi]

Statt CGI::Carp qw/fatalsToBrowser/ würde ich lieber einen Signal-Handler
für die() setzen, der eine nette Meldung für den Nutzer ausgibt:

sub sighandler {
  print <<HTML;
… Fehlermeldung erzeugen
HTML
}

$SIG{DIE} = &sighandler;

>   
> genau darüber habe ich mir in den letzten Tagen den Kopf zerbrochen  
> und diesen Gedanken aus dem Grund verworfen, da ich nicht immer  
> genau feststellen kann, an welcher Stelle in meinem Skript der  
> Prozess stirbt. Dabei geht es mir um den HTML-Header, der eventuell  
  
Doch kann man. Lass dir mal alle Parameter der funktion ausgeben.  
  

> schon ausgegeben wurde oder auch nicht. Woran soll dies der die  
> Handler erkennen? Wird denn nicht ein Serverfehler ausgegeben, wenn  
> kein HTML-Header an den Browser gesendet wird? Unschön fänd ich es  
> auch widerrum, wenn da über der "netten Meldung" ein "Content-type:  
> text/html ..." erscheint.  
>   
> Wie würdest du das überprüfen?  
  
Nur indem du eine Globale Variabel definierst nachdem du den Header ausgegeben hast.  
  
Wenn du den Header mit dem CGI Modul ausgibst, kannst du dies kontrollieren in dem du $CGI::HEADERS\_ONCE = 1 setzt.  
  
  
Struppi.

-- 
[Javascript ist toll](http://javascript.jstruebig.de/)

[opi]

Hallo Struppi,

das mit der globalen Variable hatte ich mir schon irgendwie gedacht
und habe mich dann doch für die "robuste und lange schon im Einsatz"
befindliche Funktion fatalsToBrowser entschieden :-)

Ich habe es einfach so realisiert, das ich für all meine Fehler, die
auftreten könnten und die ich auch abfange, einen Fehlercode ausgeben
lasse. Beispiel:

sysopen(FILE,$file,O_RDONLY) or die "<SOFTWARE_NAME>-ERROR-1223";

Der Fehlercode deshalb, weil es unterschiedliche Skripts gibt, die
auf gleiche Ressourcen zugreifen und ich es lästig finde für alle
Skripts die gleiche Meldung zu schreiben.

Zur Auswertung der error_log habe ich mir noch ein Skript
geschrieben, welches regelmäßig Meldungen ausliest und bei dem
Vorkommen eines Fehlers eine Mail oder WasAuchImmer auslöst.

Ich möchte da auch gerne mal auf die Idee vom Threadersteller kommen,
strict und warnings auszukommentieren. Wenn ein Skript einmal läuft,
können dann noch Fehler auftauchen, wenn strict auskommentiert ist
und keine Änderungen am Skript vorgenommen werden?

Es würde doch für Fixes ausreichen, strict wieder aufzunehmen oder?

Greez,
opi

[Christian Kruse]

你好 opi,

das mit der globalen Variable hatte ich mir schon irgendwie gedacht
und habe mich dann doch für die "robuste und lange schon im Einsatz"
befindliche Funktion fatalsToBrowser entschieden :-)

Hehe, fatalsToBrowser schickt aber auch ein zweites mal den
Content-Type-Header, wenn er nicht per CGI.pm gesendet wurde ;)

再见,
 克里斯蒂安

[opi]

Hallo Christian,

Hehe, fatalsToBrowser schickt aber auch ein zweites mal den
Content-Type-Header, wenn er nicht per CGI.pm gesendet wurde ;)

mhmm... ich benutze nichts von CGI ausser fatalsToBrowser und
natürlich binde ich CGI.pm ein, wenn ich was von GD.pm nutze
(zum Beispiel GD::Graph::lines). Nenn mich altmodisch, aber ich habe
mir selber für die wichtigsten Dinge Funktionen geschrieben, die in
allen Skripts Verwendung finden :-)

Beispiel:

my $arg = getARGV(); # $ENV{QUERY_STRING} Verarbeitung mit untaint

my $user = checkAuthUser($arg->{SESSION_ID}); # Session checken und Benutzerdaten in Hash packen

doHeader($title, $refresh, $divert_to_site); # html, head, title, *.css, meta ...

doNavigation($user); # meine Navigationleiste

und dazwischen ganz normale HTML-Ausgabe ...

print "<table class ...
print "<div class ...
print "<form class ...

doFooter(); # meine Fußleiste mit </body></html>

Greez,
opi

[Struppi]

Was den Header angeht, gibt es da soviele Möglichkeiten dass ich froh bin immer ein Modul benutzen zu können das alle Möglichkeiten abdeckt.

...

und dazwischen ganz normale HTML-Ausgabe ...

print "<table class ...
print "<div class ...
print "<form class ...

einmal sieht HTML code im Skript Code nicht schön aus, außerdem vermeidest du mit Funktionen Verschachtelungsfehler und wie sieht es bei einer komplexen Struktur aus?
z.b. mit einem Formular, dort ist ein Select Feld mit einer Liste IDs und den dazugehörigen Werten als Text und falls das Formular vorher schon angezeigt wurde muss der Wert ausgewählt werden, wenn nicht eine andere vorgegebene ID. Mit dem CGI Modul sieht das so aus:

print CGI::popup_menu(
-name => 'ids',
-values => [keys %$list],
-labels => $list,
-default => $id
);

Natürlich kann man das auch selber machen, aber je mehr du davon brauchst umso glücklicher bist du das das schon mal jemand gemacht hat. Und das es notwendig ist zeigt das es bei der Standardinstallation dabei ist und seit 1995 gepflegt und erweitert wird.

doFooter(); # meine Fußleiste mit </body></html>

print CGI::end_html();

sieht für mich nicht schlechter aus.

Natürlich ist es Geschmackssache, aber warum etwas was andere die evtl. mehr Ahnung haben und x-fach erprobt ist, das getestet wurde nicht wiederverwenden. Dazu sind Module da. Das immer wieder neu Programmieren von schon vorhanden Sachen ist in meinem augen Zeitverschwendung das von der eigentlichen Aufgabe ablenkt, zum Einstieg und lernen ist es vielleicht sinnvoll aber nicht zum Arbeiten.

Struppi.

[Christian Kruse]

你好 Struppi,

und dazwischen ganz normale HTML-Ausgabe ...

print "<table class ...
print "<div class ...
print "<form class ...

einmal sieht HTML code im Skript Code nicht schön aus, […]

Ob der HTML-Code mit CGI erzeugt und ausgegeben wird oder ob er direkt
hardkodiert drin steht, das macht genau gar keinen Unterschied. Ne, HTML
gehört gar nicht in Scripte und/oder Programme. Sowas gehört in Templates.

doFooter(); # meine Fußleiste mit </body></html>

print CGI::end_html();

sieht für mich nicht schlechter aus.

Sieht für mich beides gleich schlecht aus.

Natürlich ist es Geschmackssache, […]

Naja, bedingt. Es gibt bestimmte Richtlinien zum Thema Software-Design, an
die man sich in jedem Fall halten sollte und die keine Geschmacksache sind.
Dazu gehört ganz sicher auch, dass Scripte keinen HTML-Quellcode erzeugen
sollten.

再见,
 克里斯蒂安

[opi]

Hallo Christian,

Naja, bedingt. Es gibt bestimmte Richtlinien zum Thema Software-Design, an
die man sich in jedem Fall halten sollte und die keine Geschmacksache sind.
Dazu gehört ganz sicher auch, dass Scripte keinen HTML-Quellcode erzeugen
sollten.

du nimmst mir jetzt gerade allen Mut :-)

Greez,
opi

[Struppi]

print "<table class ...
print "<div class ...
print "<form class ...

einmal sieht HTML code im Skript Code nicht schön aus, […]

Ob der HTML-Code mit CGI erzeugt und ausgegeben wird oder ob er direkt
hardkodiert drin steht, das macht genau gar keinen Unterschied. Ne, HTML
gehört gar nicht in Scripte und/oder Programme. Sowas gehört in Templates.

Naja, ein Funktionsaufruf ist in meinen Augen weder hartkodiert noch eine HTML Ausgabe.

Ich persönlich finde es einfacher und flexibler, wenn ich meine Ausgabe in den Prozeduren sammle (Natürlich getrennt von Verarbeitung- und Ausgabemodulen) und dabei entscheide ob etwas eine Liste oder eine Tabelle wird, als dann hinterher , falls ich mich doch anders entscheide, die Template Datei umprogrammieren zu müssen. Da ich mich mit HTML::Template nicht gut auskenne weiß ich auch nicht wie dynamisch die ist, aber ich kann mir nicht vorstellen wie ich damit arbeiten soll, wenn ich in einer Ausgabe immer wieder andere Elemente unterbringen muss.

Für ein Gästebuch ist das alles kein Problem bei einer komplexen Anwendung die viele unterschiedliche Ansichten hat, halte ich die Pflege von dutzenden Templates für overkill, zumal in der Laufe der Entwicklung immer wieder neue Elemente dazukommen und wegfallen.

Zumal ein Templatesystem nochmal einiges an Leistung verbrät.

Natürlich ist es Geschmackssache, […]

Naja, bedingt. Es gibt bestimmte Richtlinien zum Thema Software-Design, an
die man sich in jedem Fall halten sollte und die keine Geschmacksache sind.
Dazu gehört ganz sicher auch, dass Scripte keinen HTML-Quellcode erzeugen
sollten.

Naja, die kennt man wohl nur wenn man lange studiert hat.

Struppi.

[Christian Kruse]

你好 Struppi,

Ob der HTML-Code mit CGI erzeugt und ausgegeben wird oder ob er direkt
hardkodiert drin steht, das macht genau gar keinen Unterschied. Ne, HTML
gehört gar nicht in Scripte und/oder Programme. Sowas gehört in
Templates.

Naja, ein Funktionsaufruf ist in meinen Augen weder hartkodiert noch eine
HTML Ausgabe.

Sicher ist es eine HTML-Ausgabe und sicher ist es hardcodiert. Oder kann
man den HTML-Quelltext ohne Programmierkenntnisse ändern?

Ich persönlich finde es einfacher und flexibler, wenn ich meine Ausgabe
in den Prozeduren sammle […]

Du bist da aber nicht gefragt ;) Das HTML müssen auch Leute anpassen können,
die keine Ahnung von Perl haben. Wenn das geht, dann hast du gut gearbeitet.

Da ich mich mit HTML::Template nicht gut auskenne weiß ich auch nicht wie
dynamisch die ist, aber ich kann mir nicht vorstellen wie ich damit
arbeiten soll, wenn ich in einer Ausgabe immer wieder andere Elemente
unterbringen muss.

Ich kenne und nutze HTML::Template nicht. Daher kann ich dir da auch nicht
helfen, sorry.

Für ein Gästebuch ist das alles kein Problem bei einer komplexen
Anwendung die viele unterschiedliche Ansichten hat, halte ich die Pflege
von dutzenden Templates für overkill, zumal in der Laufe der Entwicklung
immer wieder neue Elemente dazukommen und wegfallen.

Nein, im Gegenteil, es ist bei einer grossen Anwendung wesentlich einfacher
einen einheitlichen HTML-Output zu haben wenn man nur ein paar
Template-Dateien (die vornehmlich aus HTML, Platzhaltern und vielleicht
noch ein paar Schleifen und Bedingungen bestehen) als in zig Modulen alles mögliche anpassen zu müssen. Sowohl für dich als auch für einen Perl
unbedarften. Stell dir vor, das CForum würde den Quelltext hardcodiert
ausgeben… eine kleine Design-Änderung und man müsste es neu kompilieren.
Leute, die kein C können, könnten das Design genau gar nicht anpassen. Ne,
du, gerade bei komplexen Anwendungen ist es wichtig, dass man das
3-Tier-Prinzip penibel einhält.

Zumal ein Templatesystem nochmal einiges an Leistung verbrät.

Man kann Rechenzeit sinnvoll und sinnlos investieren. Hier ist eine
sinnvolle Anwendung.

Natürlich ist es Geschmackssache, […]

Naja, bedingt. Es gibt bestimmte Richtlinien zum Thema Software-Design,
an die man sich in jedem Fall halten sollte und die keine Geschmacksache
sind. Dazu gehört ganz sicher auch, dass Scripte keinen HTML-Quellcode
erzeugen sollten.

Naja, die kennt man wohl nur wenn man lange studiert hat.

Nee, du, die kriegt man sogar in der Ausbildung zum Anwendungsentwickler
eingetrichtert.

再见,
 克里斯蒂安

[opi]

Hallo Christian,

Du bist da aber nicht gefragt ;) Das HTML müssen auch Leute anpassen können,
die keine Ahnung von Perl haben. Wenn das geht, dann hast du gut gearbeitet.

nach dieser Aussage ist dann also PHP und CGI absolut gegen die
Richtlinien zum Thema Software-Design?

Denn da passt man das HTML doch überhaupt nicht an. Ausser den
üblichen HTML-Kenntnissen benötigt man Kenntnisse in PHP und in der
Sprache, mit der CGI verwendet wird.

Dann wären da noch JavaScript, BBCode (?) und wer weiß was da noch
alles in einem HTML-Template vorkommen könnte.

Wenn das alles nicht zu den Richtlinien passt, dann sind millionen
von Internetseiten, selbst von den größten Anbieter, falsch designed.

Liege ich da falsch?

Greez,
opi

[Christian Kruse]

你好 opi,

Du bist da aber nicht gefragt ;) Das HTML müssen auch Leute anpassen
können, die keine Ahnung von Perl haben. Wenn das geht, dann hast du
gut gearbeitet.

nach dieser Aussage ist dann also PHP und CGI absolut gegen die
Richtlinien zum Thema Software-Design?

CGI ist eine Schnittstelle. Keine Sprache. Also kann ich deinen Einwand
jetzt nicht nachvollziehen.

Zum Thema PHP: völlig richtig, PHP unterstützt das schlechte Schreiben von
Software ungemein. Aber man kann auch mit PHP Software schreiben, die sich
sauber an diese Architektur hält.

Denn da passt man das HTML doch überhaupt nicht an.

Ähem, ich hab schon mehrfach Programme in PHP geschrieben, die mit Templates
gearbeitet haben ;) die bekannteste Template-Engine für PHP dürfte da wohl
Smarty sein.

Dann wären da noch JavaScript, BBCode (?) und wer weiß was da noch
alles in einem HTML-Template vorkommen könnte.

JavaScript fällt ein wenig aus der Reihe, das ist leider wahr. Das liegt in
der Natur der Sache; JS ist sehr abhängig vom HTML-Output. Was du mit BBCode
hast weiss ich auch nicht so recht.

Wenn das alles nicht zu den Richtlinien passt, dann sind millionen
von Internetseiten, selbst von den größten Anbieter, falsch designed.

Sehr viele Internet-Projekte fangen ziemlich übel an, ja. PHProject wäre da
zum Beispiel zu nennen, was hab ich mich schon über dieses Projekt geärgert…

Liege ich da falsch?

Halb und halb.

再见,
 克里斯蒂安

[Struppi]

Ob der HTML-Code mit CGI erzeugt und ausgegeben wird oder ob er direkt
hardkodiert drin steht, das macht genau gar keinen Unterschied. Ne, HTML
gehört gar nicht in Scripte und/oder Programme. Sowas gehört in
Templates.

Naja, ein Funktionsaufruf ist in meinen Augen weder hartkodiert noch eine
HTML Ausgabe.

Sicher ist es eine HTML-Ausgabe und sicher ist es hardcodiert. Oder kann
man den HTML-Quelltext ohne Programmierkenntnisse ändern?

Warum sollte ausser dem Porgrammierer den HTML Quelltext ändern wollen, das Design ist einzig und allein in der CSS Datei, die natürlich flexibel eingebunden werden kann.

Da ich mich mit HTML::Template nicht gut auskenne weiß ich auch nicht wie
dynamisch die ist, aber ich kann mir nicht vorstellen wie ich damit
arbeiten soll, wenn ich in einer Ausgabe immer wieder andere Elemente
unterbringen muss.

Ich kenne und nutze HTML::Template nicht. Daher kann ich dir da auch nicht
helfen, sorry.

Was nutzt du?

Für ein Gästebuch ist das alles kein Problem bei einer komplexen
Anwendung die viele unterschiedliche Ansichten hat, halte ich die Pflege
von dutzenden Templates für overkill, zumal in der Laufe der Entwicklung
immer wieder neue Elemente dazukommen und wegfallen.

Nein, im Gegenteil, es ist bei einer grossen Anwendung wesentlich einfacher
einen einheitlichen HTML-Output zu haben wenn man nur ein paar
Template-Dateien (die vornehmlich aus HTML, Platzhaltern und vielleicht
noch ein paar Schleifen und Bedingungen bestehen) als in zig Modulen alles mögliche anpassen zu müssen. Sowohl für dich als auch für einen Perl
unbedarften. Stell dir vor, das CForum würde den Quelltext hardcodiert
ausgeben… eine kleine Design-Änderung und man müsste es neu kompilieren.
Leute, die kein C können, könnten das Design genau gar nicht anpassen. Ne,
du, gerade bei komplexen Anwendungen ist es wichtig, dass man das
3-Tier-Prinzip penibel einhält.

Ich halte das Forum nicht für komplex, es hat ja nur eine Aufgabe, ein forukm darzustellen. Du hast im Prinzip nur drei Ansichten, die Ausgabe des Forums, die individuellen Einstellungen werden ja wohl kaum im Template Berücksichtigt. Die Postingansicht und die Benutzereinstellungen.

Zumal, wie oben schon erwähnt, das Design (zumindest bei mir) mit CSS und mit den individuellen Einstellungen erfolgt.

Zumal ein Templatesystem nochmal einiges an Leistung verbrät.

Man kann Rechenzeit sinnvoll und sinnlos investieren. Hier ist eine
sinnvolle Anwendung.

Da ich nur HTML::Template kenne, sehe ich das nicht so. Der Nutzen überwiegt nicht dem zusätzlichen Programmieraufwand.

Struppi.

[Christian Kruse]

你好 Struppi,

Naja, ein Funktionsaufruf ist in meinen Augen weder hartkodiert noch
eine HTML Ausgabe.

Sicher ist es eine HTML-Ausgabe und sicher ist es hardcodiert. Oder kann
man den HTML-Quelltext ohne Programmierkenntnisse ändern?

Warum sollte ausser dem Porgrammierer den HTML Quelltext ändern wollen,
das Design ist einzig und allein in der CSS Datei, die natürlich flexibel
eingebunden werden kann.

Sorry, aber das ist mehr als unrealistisch. Beinahe schon weltfremd. Das
will ich sehen, wie du ohne Anpassung des Sourcecodes ein Design wie das
von WWWTech.de oder ck.kennt-wayne.de hinkriegst, nur mit Templates.

Da ich mich mit HTML::Template nicht gut auskenne weiß ich auch nicht
wie dynamisch die ist, aber ich kann mir nicht vorstellen wie ich
damit arbeiten soll, wenn ich in einer Ausgabe immer wieder andere
Elemente unterbringen muss.

Ich kenne und nutze HTML::Template nicht. Daher kann ich dir da auch
nicht helfen, sorry.

Was nutzt du?

Eine eigene ;)

Für ein Gästebuch ist das alles kein Problem bei einer komplexen
Anwendung die viele unterschiedliche Ansichten hat, halte ich die
Pflege von dutzenden Templates für overkill, zumal in der Laufe der
Entwicklung immer wieder neue Elemente dazukommen und wegfallen.

Nein, im Gegenteil, es ist bei einer grossen Anwendung wesentlich
einfacher einen einheitlichen HTML-Output zu haben wenn man nur ein paar
Template-Dateien (die vornehmlich aus HTML, Platzhaltern und vielleicht
noch ein paar Schleifen und Bedingungen bestehen) als in zig Modulen
alles mögliche anpassen zu müssen. Sowohl für dich als auch für einen
Perl unbedarften. Stell dir vor, das CForum würde den Quelltext
hardcodiert ausgeben… eine kleine Design-Änderung und man müsste es neu
kompilieren. Leute, die kein C können, könnten das Design genau gar
nicht anpassen. Ne, du, gerade bei komplexen Anwendungen ist es wichtig,
dass man das 3-Tier-Prinzip penibel einhält.

Ich halte das Forum nicht für komplex, es hat ja nur eine Aufgabe, ein
forukm darzustellen. Du hast im Prinzip nur drei Ansichten, die Ausgabe
des Forums, […]

Hihi, du solltest mal einen Blick hinter die Kulissen werfen.

die individuellen Einstellungen werden ja wohl kaum im Template
Berücksichtigt.

Doch, fast ausschliesslich.

Zumal, wie oben schon erwähnt, das Design (zumindest bei mir) mit CSS und
mit den individuellen Einstellungen erfolgt.

Die Anpassung des Designs via CSS ist nur innerhalb bestimmter Parameter
möglich. Du bist immer an die durch den Programmierer vorgegebene Struktur
gebunden.

Zumal ein Templatesystem nochmal einiges an Leistung verbrät.

Man kann Rechenzeit sinnvoll und sinnlos investieren. Hier ist eine
sinnvolle Anwendung.

Da ich nur HTML::Template kenne, sehe ich das nicht so. Der Nutzen
überwiegt nicht dem zusätzlichen Programmieraufwand.

Hihi, das sag mal einem ausgebildeten Anwendungsentwickler. Der wird dir
die Brocken um die Ohren hauen. Mal abgesehen davon, dass bei einer
Vermischung der verschiedenen Schichten einer Software diese sehr viel
schlechter wartbar wird ist das Design nur sehr, sehr begrenzt anpassbar.

In grossen Agenturen wird fast ausschliesslich Software geschrieben, die
Templates benutzt – und das ist auch gut so. Nicht umsonst benutzt
inzwischen so ziemlich jedes größere (und meist auch die kleineren)
Web-Software-Projekt Templates.

再见,
 克里斯蒂安

[Struppi]

Warum sollte ausser dem Porgrammierer den HTML Quelltext ändern wollen,
das Design ist einzig und allein in der CSS Datei, die natürlich flexibel
eingebunden werden kann.

Sorry, aber das ist mehr als unrealistisch. Beinahe schon weltfremd. Das
will ich sehen, wie du ohne Anpassung des Sourcecodes ein Design wie das
von WWWTech.de oder ck.kennt-wayne.de hinkriegst, nur mit Templates.

Ich sehe dort keine Besonderheiten. Ich frag mich aber woher die ganzen <p> im Quelltext bei ck.kennt-wayne.de kommen, alle aus dem Template?

Wie baust du dynamische Links ein (evtl. mit SID)? Woher weiß ein template das ich dort an der Stelle X einen Link auf Y haben will?

Was nutzt du?

Eine eigene ;)

und die kann alles?

wie gesagt ich bräuchte wenn ich sowas nutzen würde, if Abfragen um zu bestimmen ob jetzt eine Liste, ein Absatz oder ein Tabelle kommt einen integrierten Parser der weiß ob und welche welche SID an alle internen Links gehängt wird. welcher Menüpunkt aktuell ist ... usw

wobei ich bei der ganzen Diskussion anmerken muss, im Prinzip arbeitet mein Skripte wie eine Templateausgabe. Ich sammle alles und hab an einer einzigen Stelle dann:

print header(),
start_html(),
logo(),
menu(),
action(),
footer(),
end_html()
;

Im Prinzip.
Das ganze wird dann noch ergänzt mit einigen Zusatzfunktionen z.b. für eine Statusanzeige und passende DIVs drumherum um Ausgabeblöcke zu gruppieren. Sonst gibt es in keinem Modul irgednwo eine print Anweisung.

Ich halte das Forum nicht für komplex, es hat ja nur eine Aufgabe, ein
forukm darzustellen. Du hast im Prinzip nur drei Ansichten, die Ausgabe
des Forums, […]

Hihi, du solltest mal einen Blick hinter die Kulissen werfen.

Naja, ist mir schon klar das da eine ganze Menge aufwand intern betrieben werden muss, ich bezog meine Aussage in erster Linie auf die verschiedenen Views und das ist ein Forum nun mal nicht so vielfältig wie andere Systeme (ich hab z.b. eine Ligaverwaltung in der alles vorkommt von Tabellen und Übersichten, Userverwaltung und Boards, Mannschafts- und reine Textseiten usw)

die individuellen Einstellungen werden ja wohl kaum im Template
Berücksichtigt.

Doch, fast ausschliesslich.

Da stellt sich mir die Frage, wie ein Designer damit arbeiten soll ohne Programmierkenntnisse. Für mich sieht das ganze so aus als ob das Problem genau umgedreht wird. du sagst der Programmierer soll sich nicht um Design kümmern verlangst aber das der Designer programmieren kann, ansonsten dürfte es sehr heikel werden wenn dieser an den Templates arbeitet. Ich sage, die HTML Elemente kommen aus der Anwendung der Designern (zugegeben bisher war es fast immer ich selber) fast nur noch den CSS Code an um die HTML elemente entsprechend anzupassen.

Zumal, wie oben schon erwähnt, das Design (zumindest bei mir) mit CSS und
mit den individuellen Einstellungen erfolgt.

Die Anpassung des Designs via CSS ist nur innerhalb bestimmter Parameter
möglich. Du bist immer an die durch den Programmierer vorgegebene Struktur
gebunden.

Das ist tatsächlich so. wobei das sich in Maßen auch noch mit Einstellungen verändert werden kann. Aber letzlich ist eine Struktur eine Struktur die auch einen Sinn machen sollte. Warum sollte z.b. das Logo als letztes im Dokument erscheinen, es dürfte immer zuerst kommen.

Da ich nur HTML::Template kenne, sehe ich das nicht so. Der Nutzen
überwiegt nicht dem zusätzlichen Programmieraufwand.

Hihi, das sag mal einem ausgebildeten Anwendungsentwickler. Der wird dir
die Brocken um die Ohren hauen. Mal abgesehen davon, dass bei einer
Vermischung der verschiedenen Schichten einer Software diese sehr viel
schlechter wartbar wird ist das Design nur sehr, sehr begrenzt anpassbar.

du kennst CSSZengarden?
Für mich ist das alles andere als begrenz.

Struppi.

[Christian Kruse]

你好 Struppi,

Warum sollte ausser dem Porgrammierer den HTML Quelltext ändern
wollen, das Design ist einzig und allein in der CSS Datei, die
natürlich flexibel eingebunden werden kann.

Sorry, aber das ist mehr als unrealistisch. Beinahe schon weltfremd. Das
will ich sehen, wie du ohne Anpassung des Sourcecodes ein Design wie das
von WWWTech.de oder ck.kennt-wayne.de hinkriegst, nur mit Templates.

Ich sehe dort keine Besonderheiten.

Du wirst es schlicht nicht hinbekommen. Nimm den Quelltext der Seite
de.selfhtml.org und lass es aussehen wie wwwtech.de – ohne den Quelltext
zu ändern.

Ich frag mich aber woher die ganzen <p> im Quelltext bei
ck.kennt-wayne.de kommen, alle aus dem Template?

Depends, welche du meinst.

Wie baust du dynamische Links ein (evtl. mit SID)?

Über das setzen einer Variablen.

Woher weiß ein template das ich dort an der Stelle X einen Link auf Y
haben will?

Will ich uU ja gar nicht, darum gehts ja. In der Installation x kann ich den
Link da haben wollen, in der Installation y dagegen nicht.

Was nutzt du?

Eine eigene ;)

und die kann alles?

Alles, was notwendig ist.

wie gesagt ich bräuchte wenn ich sowas nutzen würde, if Abfragen um zu
bestimmen ob jetzt eine Liste, ein Absatz oder ein Tabelle kommt

Nein, das benötigst du nicht.

einen integrierten Parser der weiß ob und welche welche SID an alle
internen Links gehängt wird.

Dito.

welcher Menüpunkt aktuell ist ... usw

Dafür reichen einfache ifs.

wobei ich bei der ganzen Diskussion anmerken muss, im Prinzip arbeitet
mein Skripte wie eine Templateausgabe.

Nein, wirklich nicht ;)

Das ganze wird dann noch ergänzt mit einigen Zusatzfunktionen z.b. für
eine Statusanzeige und passende DIVs drumherum um Ausgabeblöcke zu
gruppieren. Sonst gibt es in keinem Modul irgednwo eine print Anweisung.

Dafür jede Menge .= und dergleichen mehr. Das ist das gleiche in grün.

Ich halte das Forum nicht für komplex, es hat ja nur eine Aufgabe, ein
forukm darzustellen. Du hast im Prinzip nur drei Ansichten, die
Ausgabe des Forums, […]

Hihi, du solltest mal einen Blick hinter die Kulissen werfen.

Naja, ist mir schon klar das da eine ganze Menge aufwand intern betrieben
werden muss, ich bezog meine Aussage in erster Linie auf die
verschiedenen Views […]

Ich auch. Schau hinter die Kulissen. Schau dir die Templates an.

die individuellen Einstellungen werden ja wohl kaum im Template
Berücksichtigt.

Doch, fast ausschliesslich.

Da stellt sich mir die Frage, wie ein Designer damit arbeiten soll ohne
Programmierkenntnisse.

Ein Designer muss ein gewisses Verständnis für Strukturen haben, richtig,
aber er muss nicht programmieren können. Die Komplexität einer
Template-Sprache ist bis auf das Mindestmass heruntergebrochen.

Aber letzlich ist eine Struktur eine Struktur die auch einen Sinn machen
sollte. Warum sollte z.b. das Logo als letztes im Dokument erscheinen, es
dürfte immer zuerst kommen.

Das sagst du. $DESIGNER wird das anders sehen. Und wenn dein Produkt nicht
fähig ist, die CI abzubilden, naja, dann benutzt man es halt nicht. Die
Struktur einer Seite muss aufweichbar sein, sonst hast du etwas falsch
gemacht.

Da ich nur HTML::Template kenne, sehe ich das nicht so. Der Nutzen
überwiegt nicht dem zusätzlichen Programmieraufwand.

Hihi, das sag mal einem ausgebildeten Anwendungsentwickler. Der wird dir
die Brocken um die Ohren hauen. Mal abgesehen davon, dass bei einer
Vermischung der verschiedenen Schichten einer Software diese sehr viel
schlechter wartbar wird ist das Design nur sehr, sehr begrenzt
anpassbar.

du kennst CSSZengarden?

Durchaus.

Für mich ist das alles andere als begrenz.

Die Möglichkeit der Anpassung dort ist sehr begrenzt.

再见,
 克里斯蒂安

[Struppi]

Ich sehe dort keine Besonderheiten.

Du wirst es schlicht nicht hinbekommen. Nimm den Quelltext der Seite
de.selfhtml.org und lass es aussehen wie wwwtech.de – ohne den Quelltext
zu ändern.

Naja, selfhtml ist ja bekannt für seine Tabellenstruktur und das tabellen mit CSS weniger flexibel sind ist ja bekannt.

Ich frag mich aber woher die ganzen <p> im Quelltext bei
ck.kennt-wayne.de kommen, alle aus dem Template?

Depends, welche du meinst.

die vielen

Wie baust du dynamische Links ein (evtl. mit SID)?

Über das setzen einer Variablen.

dynamische Links, also wenn igrendetwas passiert z.b. zeigt du ein Produkt an, wenn derjenige der eingeloggt ist die Berechtigiung dazu hat erscheint ein Link zum editieren, der natürlich alle Informationen (z.b. SID, produkt ID) enthalten muss.

Woher weiß ein template das ich dort an der Stelle X einen Link auf Y
haben will?

Will ich uU ja gar nicht, darum gehts ja. In der Installation x kann ich den
Link da haben wollen, in der Installation y dagegen nicht.

Wir reden ein bisschen einaneinder vorbei mit Y mein ich z.b. ein bearbeiten oder löschen Link, das hängt nun nicht von der Installation ab, das entscheidet die Anwendung.

wie gesagt ich bräuchte wenn ich sowas nutzen würde, if Abfragen um zu
bestimmen ob jetzt eine Liste, ein Absatz oder ein Tabelle kommt

Nein, das benötigst du nicht.

Um auf das Produkt Beispiel zurück zukommen, dort ist es sehr wohl eine Frage ob ich eine Auflistung aller Produkte habe oder eine Auflistung inklusiver einiger Eigenschaften. Oder ob jetzt nur ein Informationstext angezeigt wird. Sicher ist dies mit Templates zu lösen, aber da hätten wir schon drei  unterschiedliche.

einen integrierten Parser der weiß ob und welche welche SID an alle
internen Links gehängt wird.

Dito.

ich habe z.b. ein Modul das mir eine Linkliste ausgibt, selbst bei wordpress das sehr auf Templates setzt kommt die Liste als HTML Code aus der Funktion, ich kann zwar die Ausgabe noch beeinflussen, dies ist aber in erster Linie Möglich weil das ganze unter PHP läuft und somit Programmcode und HTMLcode gemischt werden können in den Templates.

Nach deiner Logik müßte ich dann ein Schleife im Template programmieren können und innerhalb dieser auch die Möglichkeit zusätzliche Elemente (z.b. ein <p> Absatz für eine Beschreibung zu integrieren)

Und dann bin ich nicht, wie du weiter unten sagst, bei einer minimalen komplexen Struktur Sprache.

Da stellt sich mir die Frage, wie ein Designer damit arbeiten soll ohne
Programmierkenntnisse.

Ein Designer muss ein gewisses Verständnis für Strukturen haben, richtig,
aber er muss nicht programmieren können. Die Komplexität einer
Template-Sprache ist bis auf das Mindestmass heruntergebrochen.

Dann ist sie nur für ein Mindestmaß anwendbar. Das ist doch der Punkt, wie Siechfred auf seiner Seite versucht HTML::Template einem näher zu bringen ist das ganze ja kein Problem, doch jeder hat auf seiner Seite wesentlich komplexere Strukturen, die z.T. HTML::Template auch kann, nur bin ich dann nach wie vor an einem Punkt wo ich das Template programmieren muss obwohl ich im Programmcode schon weiß was ich ausgeben muss.

Aber letzlich ist eine Struktur eine Struktur die auch einen Sinn machen
sollte. Warum sollte z.b. das Logo als letztes im Dokument erscheinen, es
dürfte immer zuerst kommen.

Das sagst du. $DESIGNER wird das anders sehen. Und wenn dein Produkt nicht
fähig ist, die CI abzubilden, naja, dann benutzt man es halt nicht. Die
Struktur einer Seite muss aufweichbar sein, sonst hast du etwas falsch
gemacht.

Nein!
Der Designer interessiert sich ja nicht für die Struktur, sondern für das optische Ergebnis und da ist selbst mit meiner Methode das Logo an jedem x-beliebigen Platz platzierbar, nur Die die die Seite nicht optisch erfassen, bekommen das Logo und die Überschrift als erster zu sehen, was meiner aussage entspricht, eine Struktur darf nicht aufweichbar sein, ansonsten ist es keine Struktur.

du kennst CSSZengarden?

Durchaus.

Für mich ist das alles andere als begrenz.

Die Möglichkeit der Anpassung dort ist sehr begrenzt.

Naja, dann reden und sehen wir was anderes ich halte annähernd 200 Vorschläge für ein und die selbe Struktur für mehr als ausreichend.

Struppi.

[Siechfred]

Tag Struppi.

Um auf das Produkt Beispiel zurück zukommen, dort ist es sehr wohl eine Frage ob ich eine Auflistung aller Produkte habe oder eine Auflistung inklusiver einiger Eigenschaften. Oder ob jetzt nur ein Informationstext angezeigt wird. Sicher ist dies mit Templates zu lösen, aber da hätten wir schon drei  unterschiedliche.

Nein, ein einziges mit Alternativen.

Nach deiner Logik müßte ich dann ein Schleife im Template programmieren können und innerhalb dieser auch die Möglichkeit zusätzliche Elemente (z.b. ein <p> Absatz für eine Beschreibung zu integrieren)

Ja, genau. Aber das ist Aufgabe des Erstellers der Software, während die Aufgabe des Designers ist, diese Ausgaben hübsch aussehen zu lassen. Letzterer muss nicht wissen, wie man in dem Template eine Schleife einbaut oder eine bedingte Anzeige. Er muss nur wissen, welches Element er anfassen muss, um eine bestimmte Optik zu erzeugen. Wenn ein Designer auch Templatevariablen oder -anweisungen anfassen muss, dann ist das Template entweder schlecht dokumentiert oder taugt am Ende nichts.

Dann ist sie nur für ein Mindestmaß anwendbar. Das ist doch der Punkt, wie Siechfred auf seiner Seite versucht HTML::Template einem näher zu bringen ist das ganze ja kein Problem, doch jeder hat auf seiner Seite wesentlich komplexere Strukturen, die z.T. HTML::Template auch kann, nur bin ich dann nach wie vor an einem Punkt wo ich das Template programmieren muss obwohl ich im Programmcode schon weiß was ich ausgeben muss.

Du programmierst nicht für dich, sondern für den Anwender, und um nichts anderes geht es m.E., denn darüber, dass es dir als Ersteller der Software egal ist, ob du was im Skript oder an einem Template umstellen musst, sind wir uns sicher einig. Doch was ist, wenn ein Anwender deiner Software mit null Ahnung von Perlprogrammierung einfach nur ein anderes Header-Logo haben will? Dem willst du zumuten, dass er sich durch deine Scripte wühlt, bis er die entsprechende Anweisung gefunden hat? Für manche ist es schon ein Ding der Unmöglichkeit, diese tollen Konfigurationsblöcke am Anfang mancher Scripte anzupassen.

Der Designer interessiert sich ja nicht für die Struktur, sondern für das optische Ergebnis und da ist selbst mit meiner Methode das Logo an jedem x-beliebigen Platz platzierbar

Ja, aber nicht ohne Kenntnisse sowohl in HTML und CSS als auch in Perl. Ein Anwender einer Software muss auf den ersten Blick sehen, was Sache ist, und diese Möglichkeit bietet ihm ein vernünftiges Template. Bei deinem Ansatz ist der Anwender gezwungen, in die Scripte zu schauen, was ein gewisses Maß an Fachwissen voraussetzt, bei Templates hingegen hat er HTML im Klartext stehen und sieht auf den ersten Blick, wo er drehen muss.

Soweit du Software ausschließlich für deinen Einsatz programmierst, ist die Diskussion, ob Templates oder nicht, genauso akademisch wie eine Diskussion über semantisch korrekten Einsatz von HTML-Elementen :-)

Siechfred

[Struppi]

Um auf das Produkt Beispiel zurück zukommen, dort ist es sehr wohl eine Frage ob ich eine Auflistung aller Produkte habe oder eine Auflistung inklusiver einiger Eigenschaften. Oder ob jetzt nur ein Informationstext angezeigt wird. Sicher ist dies mit Templates zu lösen, aber da hätten wir schon drei  unterschiedliche.

Nein, ein einziges mit Alternativen.

Das ist mir nicht klar. Im Template steht dann sowas wie:

<TMPL IF xxx=liste>
<ul>
<TMPL LOOP ???><li> <TMPL eigenschaft_1>
<p> <TMPL text> </p>
<TMPL ENDLOOP>

</li>
<TMPL ELSE IF xxx=produkte>
<table>
<TMP LOOP ???><tr>
<td> <TMPL eigenschaft_1> </td>
<td> <TMPL eigenschaft_2> </td>
<td> <TMPL eigenschaft_3> </td>
</tr>
<TMP ENDLOOP>
</table>
<TMPL ELD IF xxx=text>
<p><TMPL tex></p>
<TMPL ENDIF>

Da kann kein Designer etwas mit Anfangen.

Nach deiner Logik müßte ich dann ein Schleife im Template programmieren können und innerhalb dieser auch die Möglichkeit zusätzliche Elemente (z.b. ein <p> Absatz für eine Beschreibung zu integrieren)

Ja, genau. Aber das ist Aufgabe des Erstellers der Software, während die Aufgabe des Designers ist, diese Ausgaben hübsch aussehen zu lassen. Letzterer muss nicht wissen, wie man in dem Template eine Schleife einbaut oder eine bedingte Anzeige. Er muss nur wissen, welches Element er anfassen muss, um eine bestimmte Optik zu erzeugen. Wenn ein Designer auch Templatevariablen oder -anweisungen anfassen muss, dann ist das Template entweder schlecht dokumentiert oder taugt am Ende nichts.

Das widerspricht zumindest teilweise dem was Christian über den Zweck von Templates sagt. Und entspricht dem was ich teilweise sage.
Ich gebe eine struktrierte HTML seite aus, wie ich das mache ist erst mal egal. Dabei gibt es unterschiedliche Bereiche (mit DIV und ID gekennzeichnet) die der Designer über CSS nach belieben gestalten mag.

Dann ist sie nur für ein Mindestmaß anwendbar. Das ist doch der Punkt, wie Siechfred auf seiner Seite versucht HTML::Template einem näher zu bringen ist das ganze ja kein Problem, doch jeder hat auf seiner Seite wesentlich komplexere Strukturen, die z.T. HTML::Template auch kann, nur bin ich dann nach wie vor an einem Punkt wo ich das Template programmieren muss obwohl ich im Programmcode schon weiß was ich ausgeben muss.

Du programmierst nicht für dich, sondern für den Anwender, und um nichts anderes geht es m.E., denn darüber, dass es dir als Ersteller der Software egal ist, ob du was im Skript oder an einem Template umstellen musst, sind wir uns sicher einig. Doch was ist, wenn ein Anwender deiner Software mit null Ahnung von Perlprogrammierung einfach nur ein anderes Header-Logo haben will? Dem willst du zumuten, dass er sich durch deine Scripte wühlt, bis er die entsprechende Anweisung gefunden hat? Für manche ist es schon ein Ding der Unmöglichkeit, diese tollen Konfigurationsblöcke am Anfang mancher Scripte anzupassen.

Das Header Logo ist eine Einstellung in den Programmoptionen (nicht in der Konfiguration) oder wird in der CSS Datei deklariert.

Der Designer interessiert sich ja nicht für die Struktur, sondern für das optische Ergebnis und da ist selbst mit meiner Methode das Logo an jedem x-beliebigen Platz platzierbar

Ja, aber nicht ohne Kenntnisse sowohl in HTML und CSS als auch in Perl. Ein Anwender einer Software muss auf den ersten Blick sehen, was Sache ist, und diese Möglichkeit bietet ihm ein vernünftiges Template. Bei deinem Ansatz ist der Anwender gezwungen, in die Scripte zu schauen, was ein gewisses Maß an Fachwissen voraussetzt, bei Templates hingegen hat er HTML im Klartext stehen und sieht auf den ersten Blick, wo er drehen muss.

Naja, bei meiner Methode brauch er nur Kenntnisse in CSS (die natürlich ohne HTML Kenntnisse nicht viel bringen), also weniger in HTML und schon gar nciht in Perl. In der CSS Datei steht dan  sowas:

#logo
{
...
}
#logo img
{

}
#logo h1
{
..
}

Da kann jeder beliebig dran schrauben.

Soweit du Software ausschließlich für deinen Einsatz programmierst, ist die Diskussion, ob Templates oder nicht, genauso akademisch wie eine Diskussion über semantisch korrekten Einsatz von HTML-Elementen :-)

Das ist wahr und bisher auch weitestgehend so. Trotzdem interessiert mich wo der Vorteil von Template liegen soll, da diese ja keinerlei Inhalte präsentieren können da diese i.d.R. erst aus der Anwendung kommen und somit erst mal nutzlos sind.

Struppi.

[Christian Kruse]

你好 Struppi,

Das ist mir nicht klar. Im Template steht dann sowas wie:

<TMPL IF xxx=liste>
<ul>
<TMPL LOOP ???><li> <TMPL eigenschaft_1>
<p> <TMPL text> </p>
<TMPL ENDLOOP>

</li>
<TMPL ELSE IF xxx=produkte>
<table>
<TMP LOOP ???><tr>
<td> <TMPL eigenschaft_1> </td>
<td> <TMPL eigenschaft_2> </td>
<td> <TMPL eigenschaft_3> </td>
</tr>
<TMP ENDLOOP>
</table>
<TMPL ELD IF xxx=text>
<p><TMPL tex></p>
<TMPL ENDIF>

Da kann kein Designer etwas mit Anfangen.

Das ist glücklicherweise unwahr. In bisher jeder Agentur, in der ich
gearbeitet habe, war der/waren die Designer problemlos in der Lage, sich
innerhalb kürzester Zeit in derart simple Konstrukte einzuarbeiten. Gut,
die Syntax war angenehmer und übersichtlicher, aber trotzdem.

Ich gebe eine struktrierte HTML seite aus, wie ich das mache ist erst mal
egal. Dabei gibt es unterschiedliche Bereiche (mit DIV und ID
gekennzeichnet) die der Designer über CSS nach belieben gestalten mag.

Es ist unrealistisch und beinahe weltfremd zu behaupten, jede Struktur
liesse sich per CSS in jede andere überführen – und das auch noch für alle
Browser.

Naja, bei meiner Methode brauch er nur Kenntnisse in CSS (die natürlich
ohne HTML Kenntnisse nicht viel bringen), also weniger in HTML und schon
gar nciht in Perl. […]

Bis einer deiner Kunden Anforderungen hat, die sich nur mit Hilfe einer
Änderung im HTML-Code erreichen lassen. Spätestens dann wirst du merken,
dass du etwas falsch gemacht hast.

Trotzdem interessiert mich wo der Vorteil von Template liegen soll, da
diese ja keinerlei Inhalte präsentieren können da diese i.d.R. erst aus
der Anwendung kommen und somit erst mal nutzlos sind.

Denke in Schichten. Die Daten selber haben nichts, aber auch wirklich gar
nichts mit der Darstellung zu tun; unter der Haube kann sich etwas
vollständig anderes verstecken. So hat also eine Software im Idealfall
mindestens drei Schichten: eine Schicht zur Datenbeschaffung und
-speicherung (dadurch wird es ohne Probleme möglich, zwischen einer
Datenbank und einer Text-Datei oder zwei verschiedenen Datenbank-Systemen
zu wechseln), eine zur Aufbereitung der Daten und die letzte Schicht zur
Darstellung der Daten. Dein Programmcode ist also im Idealfall nur das
Bindeglied zwischen Daten und Templates, die die dritte Schicht darstellen:
die Darstellung der Daten.

再见,
 克里斯蒂安

[Struppi]

Da kann kein Designer etwas mit Anfangen.

Das ist glücklicherweise unwahr. In bisher jeder Agentur, in der ich
gearbeitet habe, war der/waren die Designer problemlos in der Lage, sich
innerhalb kürzester Zeit in derart simple Konstrukte einzuarbeiten. Gut,
die Syntax war angenehmer und übersichtlicher, aber trotzdem.

Um die Syntax geht es doch gar nicht, er kann es nicht designen, da nichts angezeigt wird und selbst wenn man Dummys einbaut hat er drei verschiedenen Ansichten die aber nicht unbedingt zusammen gehören.

Ich gebe eine struktrierte HTML seite aus, wie ich das mache ist erst mal
egal. Dabei gibt es unterschiedliche Bereiche (mit DIV und ID
gekennzeichnet) die der Designer über CSS nach belieben gestalten mag.

Es ist unrealistisch und beinahe weltfremd zu behaupten, jede Struktur
liesse sich per CSS in jede andere überführen – und das auch noch für alle
Browser.

Eine Struktur ist eine Struktur, d.h. nach a kommt b auch wen es im einzelnen manchmal strittig ist was das c ist, aber eine Struktur ist Ordnung von Elementen in diesem Falle innerhalb eines Dokumentes.

CSS hat nichts mit dieser Struktur zu tun und verändert diese auch nicht, es dient einzig und alleim Den optischen Anordnen und gestaltet diese Struktur.
Ob das weltfremd ist weiß ich nicht, ich hab zumindest Teile von CSS Dateien wiederverwenden können und muss nur wenige Anpassung an individuelle Elemente dort vornehmen

Browser die kein oder zu wenig CSS können sehen diese Struktur. In der Realität sieht es so aus, dass ohne Probleme eine minimal ausgabe erzeugen kann aus den gleichen Daten.

z.b.
http://die-bunte-liga.de/

Tabellenlayout:
http://www.die-bunte-liga.de/rheinhessen/45/no_css=1
(theoretisch sollte da noch eine minimal CSS Datei rein für Farben und Schrifarten und Größe, war ich aber bisher zu faul für)

und ein Versuch etwas anderes zu Layouten
http://www.die-bunte-liga.de/rheinhessen/49/css=design_2.css
(Ich weiß, ich bin nicht so der Meister was das Layout angeht- so wie es jetzt ist, ist es kaum nutzbar, es geht ums Prinzip)

Naja, bei meiner Methode brauch er nur Kenntnisse in CSS (die natürlich
ohne HTML Kenntnisse nicht viel bringen), also weniger in HTML und schon
gar nciht in Perl. […]

Bis einer deiner Kunden Anforderungen hat, die sich nur mit Hilfe einer
Änderung im HTML-Code erreichen lassen. Spätestens dann wirst du merken,
dass du etwas falsch gemacht hast.

Genauso geht es, wenn ein Element eingeführt wird das nicht im template zu Verfügung steht

Trotzdem interessiert mich wo der Vorteil von Template liegen soll, da
diese ja keinerlei Inhalte präsentieren können da diese i.d.R. erst aus
der Anwendung kommen und somit erst mal nutzlos sind.

Denke in Schichten. Die Daten selber haben nichts, aber auch wirklich gar
nichts mit der Darstellung zu tun; unter der Haube kann sich etwas
vollständig anderes verstecken. So hat also eine Software im Idealfall
mindestens drei Schichten: eine Schicht zur Datenbeschaffung und
-speicherung (dadurch wird es ohne Probleme möglich, zwischen einer
Datenbank und einer Text-Datei oder zwei verschiedenen Datenbank-Systemen
zu wechseln), eine zur Aufbereitung der Daten und die letzte Schicht zur
Darstellung der Daten. Dein Programmcode ist also im Idealfall nur das
Bindeglied zwischen Daten und Templates, die die dritte Schicht darstellen:
die Darstellung der Daten.

Gelesen habe ich das wohl, in mancherlei Hinsicht habe dies auch so umgesetzt, auch wenn es mir nicht immer gelingt. Ich habe Module für das DB Management, Module für die Aufbereitung der Daten und Module für die Erzeugnung des HTML codes, alles unter der Ägide einer "main" Datei die alles zusammeführt. die Schichten sind also da. soweit ich das verstehe müßte zu jedem Modul, dass jetzt die Daten für die Anzeige aufbereitet eine Template Datei erstellen mit hilfe der Output generiert wird. Da die Anwendungen in erster Linie CGI Anwendungen sind wüßte ich nicht wozu dies notwendig ist, zumal ich z.b. mit einem einfachen Parameter dem CGI Modul sagen kann das es nicht HTML sondern XHTML erzeugen soll, d.h. ich kann dies jederzeit zur Laufzeit ändern und könnte je nach Browser darauf reagieren. Das Template system erfordert dort eine Anpassung am Template.

Wie gesagt von meinem Programmierverständniss gibt es keine Notwendigkeit und da ich bisher noch keinen passenden Ansatz gesehen habe, bleibe ich erstmal dabei, aber ich bin ja offen für neues. Was ausser HTML::Template gibt es noch in Perl? Manson (ist das sowas? oder ist das eher der Versuch wie php zu sein)?

Struppi.

[Christian Kruse]

你好 Struppi,

sorry, ich habe im Moment keine Zeit, den Beiträgen genügend Aufmerksamkeit
zu widmen; eine weitere Diskussion müsste ich halbherzig führen. Wenn du
Interesse hast, das Thema weiterzuführen schreibe mir eineMail, dann kann
ich die auch in 14 Tagen noch beantworten.

再见,
 克里斯蒂安

[Siechfred]

Tag Struppi.

<TMPL IF xxx=liste>
<ul>
<TMPL LOOP ???><li> <TMPL eigenschaft_1>
<p> <TMPL text> </p>
<TMPL ENDLOOP>

</li>
<TMPL ELSE IF xxx=produkte>
<table>
<TMP LOOP ???><tr>
<td> <TMPL eigenschaft_1> </td>
<td> <TMPL eigenschaft_2> </td>
<td> <TMPL eigenschaft_3> </td>
</tr>
<TMP ENDLOOP>
</table>
<TMPL ELD IF xxx=text>
<p><TMPL tex></p>
<TMPL ENDIF>

So ähnlich, wie Christian schon schrieb. Allerdings ist es natürlich nicht immer sinnvoll, für alle Aufgaben ein Template zu nutzen, wenn dadurch die Verständlichkeit für einen Außenstehenden auf der Strecke bleibt. Aber nehmen wir ruhig mal dein Beispiel. Was wäre, wenn ein Anwender nun statt der ungeordneten eine geordnete Liste möchte? In einem Template ersetzt er "ul" durch "ol", das war's. Bei deiner Variante müsste er sich erst in eine Programmlogik hineindenken (was zumindest Grundkenntnisse in der verwendeten Programmiersprache voraussetzt) und dann die entsprechende Zeile im Script/im Modul finden, wo er statt "ul" sein "ol" platzieren kann. Dies ist ein Vorteil von Templates.

Ich gebe eine struktrierte HTML seite aus, wie ich das mache ist erst mal egal. Dabei gibt es unterschiedliche Bereiche (mit DIV und ID gekennzeichnet) die der Designer über CSS nach belieben gestalten mag.

Ja, aber dazu muss der Designer erstmal *sehen*, wie das HTML aussieht, das ist bei einem Template wesentlich schneller und einfacher zu überblicken als bei einer scriptgesteuerten Ausgabe.

Das Header Logo ist eine Einstellung in den Programmoptionen (nicht in der Konfiguration) oder wird in der CSS Datei deklariert.

Okay, schlecht gewähltes Beispiel.

Naja, bei meiner Methode brauch er nur Kenntnisse in CSS (die natürlich ohne HTML Kenntnisse nicht viel bringen), also weniger in HTML und schon gar nciht in Perl.

Ja, aber wenn er die *Struktur* der HTML-Ausgabe ändern will (ein Beispiel hatte ich schon genannt), dann muss er doch am Script schrauben, und dafür benötigt er Perl-Kenntnisse. Indem du das HTML von deinem Script ausgeben lässt, nimmst du dem perlunkundigen Designer viele Möglichkeiten, etwas an der Struktur des ausgegebenen Dokumentes zu ändern.

Da kann jeder beliebig dran schrauben.

Es geht nicht allein um die Darstellung, das wäre zu einfach.

Das ist wahr und bisher auch weitestgehend so. Trotzdem interessiert mich wo der Vorteil von Template liegen soll, da diese ja keinerlei Inhalte präsentieren können da diese i.d.R. erst aus der Anwendung kommen und somit erst mal nutzlos sind.

Sie ermöglichen einen einfachen und schnell editierbaren Einblick in die HTML-Struktur. Du könntest ein Script auch ganz ohne HTML-Template ausliefern, damit würdest du dem Designer die Möglichkeit bieten, mit einfachsten Mitteln eine eigene HTML-Struktur aufzubauen, die seinen Wünschen und Vorstellungen entspricht. Eine ungeordnete Liste ist und bleibt ungeordnet, da kannst du mit CSS keine Nummerierungen mehr hinzufügen. Letztlich sähe ein simpelstes Template z.B. für ein Blog so aus:

<TMPL_VAR NAME="HEADLINE">  
<TMPL_VAR NAME="WELCOME_MESSAGE">  
<TMPL_LOOP NAME="THREAD">  
  <TMPL_VAR NAME="AUTHOR">  
  <TMPL_VAR NAME="DATE_TIME">  
  <TMPL_VAR NAME="TOPIC">  
  <TMPL_VAR NAME="MESSAGE">  
  <TMPL_IF NAME="ARE_THERE_ANY_ANSWERS">  
    <TMPL_LOOP NAME="ANSWERS">  
      <TMPL_VAR NAME="ANSWER_AUTHOR">  
      <TMPL_VAR NAME="ANSWER_DATE_TIME">  
      <TMPL_VAR NAME="ANSWER_MESSAGE">  
    </TMPL_LOOP>  
  <TMPL_ELSE>  
    <!-- if there are no answers, place your individual message here otherwise leave blank -->  
  </TMPL_IF>  
  <TMPL_IF NAME="ANSWERS_ALLOWED">  
    <TMPL_INCLUDE NAME="path/to/answerform.tmpl">  
  <TMPL_ELSE>  
    <!-- if answering is not allowed, place your individual message here otherwise leave blank -->  
  </TMPL_IF>  
</TMPL_LOOP>

Was der Designer für einen Doctype verwendet, wie er die Überschrift präsentiert, ob er evtl. noch eine Headergrafik obendrüber haben will, wie er den Nachrichtenblock darstellen möchte - als (un)geordnete Liste oder in einer Tabelle, ob Autor, Datum/Uhrzeit und Thema in einer Zeile nebeneinander stehen sollen oder ebenfalls in einer Liste oder in P-Elementen, das kann er frei nach seinen Wünschen bzw. Kundenvorgaben entscheiden, packt das entsprechende HTML drumherum und stylt das Ganze mit CSS. Bei deinem Ansatz müsste er in den Perl-Code einsteigen und dort drin herumfriemeln - mit nicht absehbaren Ergebnissen.

Siechfred

PS: ich habe den Titel mal geändert, besser spät als nie :-)

[Struppi]

Siechfred
再见,
克里斯蒂安 (heißt das Roy o.ä)

Ihr steckt unter einer Decke

http://siechfred.kennt-wayne.de/2005/11/verlust_eines_geliebten_menschen
http://siechfred.kennt-wayne.de/2005/10/denis-piggy-damour-nachruf
http://kennt-wayne.de/xemacs:-buffer-cycle.el
http://ck.kennt-wayne.de/neue-hardware-eingebaut

Struppi.

[Siechfred]

Moin Struppi.

Siechfred
再见,
克里斯蒂安 (heißt das Roy o.ä)
Ihr steckt unter einer Decke

Nene, lass mal, den Platz werde ich Daniela sicher nicht streitig machen ;-)

Siechfred

[Christian Kruse]

你好 Struppi,

Ich frag mich aber woher die ganzen <p> im Quelltext bei
ck.kennt-wayne.de kommen, alle aus dem Template?

Depends, welche du meinst.

die vielen

Struppi, das ist nicht konstruktiv. Einige Absätze kommen aus den Templates,
andere habe ich als Autor eingetragen. Von der Software selber allerdings
werden keine generiert, wenn du das meinst. Weder das CForum noch Block
erzeugen an irgend einer Stelle HTML-Quelltext, der sich nicht durch
Templates ändern lässt.

Das beste Beispiel für den Sinn von Templates ist immer noch ein Forum. Ich
müsste, um im CForum eine Board-Ansicht zu implementieren, nur die Templates
anpassen, keine Zeile Quelltext. Das ist wäre nicht möglich, wenn ich keine
Templates benutzen würde; dann müsste jemand ran, der C kann.

wie gesagt ich bräuchte wenn ich sowas nutzen würde, if Abfragen um zu
bestimmen ob jetzt eine Liste, ein Absatz oder ein Tabelle kommt

Nein, das benötigst du nicht.

Um auf das Produkt Beispiel zurück zukommen, dort ist es sehr wohl eine
Frage ob ich eine Auflistung aller Produkte habe oder eine Auflistung
inklusiver einiger Eigenschaften. Oder ob jetzt nur ein Informationstext
angezeigt wird. Sicher ist dies mit Templates zu lösen, aber da hätten
wir schon drei  unterschiedliche.

Ich glaube, du verstehst gar nicht, wie man mit Templates arbeitet. Bitte
tu mir den Gefallen und schaue dir wirklich mal einige Projekte an, die
Templates nutzen. Dann wirst du verstehen, warum der Einsatz von Templates
sinnvoll und gut ist.

BTW. wird dich derjenige, der das Aussehen deiner Software anpassen muss
dreifach verfluchen, wenn du nicht mit Templates arbeitest ;)

Da stellt sich mir die Frage, wie ein Designer damit arbeiten soll
ohne Programmierkenntnisse.

Ein Designer muss ein gewisses Verständnis für Strukturen haben,
richtig, aber er muss nicht programmieren können. Die Komplexität einer
Template-Sprache ist bis auf das Mindestmass heruntergebrochen.

Dann ist sie nur für ein Mindestmaß anwendbar.

Natürlich. Für genau das Mindestmaß, das ich benötige.

Der Designer interessiert sich ja nicht für die Struktur, […]

Hihi, nur weil du es gern so hättest muss das noch lange nicht heissen,
dass es so ist. Ein Designer hat nicht nur die Aufgabe, alles schön bunt
zu machen ;)

[…] eine Struktur darf nicht aufweichbar sein, ansonsten ist es keine
Struktur.

So? Wie kommst du darauf? Das musst du schon begründen…

再见,
 克里斯蒂安

[Siechfred]

Tag Christian.

Ich kenne und nutze HTML::Template nicht. Daher kann ich dir da auch nicht
helfen, sorry.

Ich halte HTML::Template für ein mächtiges und sehr performantes Werkzeug, als Speicherfresser ist es mir bis dato noch nicht untergekommen. Ich habe den Einsatz mal etwas ausführlicher beschrieben unter http://sniplets.anaboe.net/cgiperl04.html.

Siechfred

[Christian Kruse]

你好 Siechfred,

Ich kenne und nutze HTML::Template nicht. Daher kann ich dir da auch
nicht helfen, sorry.

Ich halte HTML::Template für ein mächtiges und sehr performantes
Werkzeug, als Speicherfresser ist es mir bis dato noch nicht
untergekommen. Ich habe den Einsatz mal etwas ausführlicher beschrieben
unter http://sniplets.anaboe.net/cgiperl04.html.

Sieht soweit ja ganz gut aus. Nur Ifs fehlen, gibts die auch?

再见,
 克里斯蒂安

[Siechfred]

Tag Christian.

http://sniplets.anaboe.net/cgiperl04.html.
Sieht soweit ja ganz gut aus. Nur Ifs fehlen, gibts die auch?

Aber sicher, ich wollte mein Beispiel nur nicht zu ausführlich machen, da es sich eher an Nutzer richten soll, die noch nie mit Templates gearbeitet haben. Übrigens habe ich das Ganze sehr exzessiv in meinem (mittlerweile ad acta gelegten) Perl-Blog verwendet, also auch mit IF..ELSE oder UNLESS :-)

Siechfred

[Tim Tepaße]

Hallo Christian,

Stell dir vor, das CForum würde den Quelltext hardcodiert ausgeben… eine kleine Design-Änderung und man müsste es neu kompilieren.

*hust*

Haben wir uns nicht gestern noch über fo_feeds unterhalten? ;)

Tim

[Christian Kruse]

你好 Tim,

Stell dir vor, das CForum würde den Quelltext hardcodiert ausgeben…
eine kleine Design-Änderung und man müsste es neu kompilieren.

*hust*

Haben wir uns nicht gestern noch über fo_feeds unterhalten? ;)

Das ist ein klein wenig eine andere Situation ;) Die Struktur dieser
XML-Daten _darf_ nicht geändert werden, da sie eine Schnittstelle
darstellt. Wäre es ein beliebiges XML-Format, hätte ich das über ein
Template gemacht ;) Aber hier hat niemand was zu suchen, das ist Sache
eines Programmierers, die Struktur ist definiert durch entsprechende
Standards.

再见,
 克里斯蒂安

[Tim Tepaße]

Hallo Christian,

Das ist ein klein wenig eine andere Situation ;) Die Struktur dieser XML-Daten _darf_ nicht geändert werden, da sie eine Schnittstelle darstellt.

HTML ist auch nur eine Schnittstelle. ;)

Wäre es ein beliebiges XML-Format, hätte ich das über ein Template gemacht ;) Aber hier hat niemand was zu suchen, das ist Sache eines Programmierers, die Struktur ist definiert durch entsprechende Standards.

Jain. Auch diese XML-Formate kann man erweitern, insofern ist ihre Struktur nicht fest. Ein Forumsadmin könnte sich plötzlich entscheiden von RSS 2.0 auf RSS 1.0 umzustellen und zusätzlich noch RDF/FOAF-Informationen drin mit aufzunehmen. Oder Krempel, der der derzeit noch durch fo_feeds.conf definiert wird zu ändern. Auch ist die Struktur eines Feeds variabel, manche Elemente sind optional, etc. Um es im MVC-Modell auszudrücken: Ein Feed ist auch nur ein seperater View auf einen Thread, ähnlich wie die Nested- oder List-Ansicht.

Aber natürlich sollte man schon wissen, was man da tut, klar. ;)

Tim

[opi]

Hallo Struppi,

Was den Header angeht, gibt es da soviele Möglichkeiten dass ich froh bin immer ein Modul benutzen zu können das alle Möglichkeiten abdeckt.

...

und dazwischen ganz normale HTML-Ausgabe ...

print "<table class ...
print "<div class ...
print "<form class ...

einmal sieht HTML code im Skript Code nicht schön aus, außerdem vermeidest du mit Funktionen Verschachtelungsfehler und wie sieht es bei einer komplexen Struktur aus?

Wieso das?

Wenn du eine statische *.htm Datei schreibst, kannst du genauso viele
Fehler machen bei der Verschachtelung. Ansonsten schaut das für mich
sehr lesbar aus. Beispiel:

  
  
# mal schnell dahin getippt  
  
my $hash = {  
   "Struppi"   => "Hallo",  
   "Christian" => "Hi",  
   "opi"       => "Hi alter",  
};  
  
print "<table class=\"tab_options\">\n";  
print "   <tr>\n";  
print "      <th class=\"td_option_header\">Begr&uuml;&szlig;ung</th>\n";  
print "      <th class=\"td_option_header\">Name</th>\n";  
print "   </tr><tr>\n";  
  
foreach my $key (sort keys %$hash) {  
   print "      <td class=\"td_option_body\">$hash->{$key}</td>\n";  
   print "      <td class=\"td_option_body\">$key</td>\n";  
   print "   </tr><tr>\n";  
}  
  
print "      <td class=\"td_option_footer\" colspan=\"2\"></td>\n";  
print "   </tr>\n";  
print "</table>\n";  

z.b. mit einem Formular, dort ist ein Select Feld mit einer Liste IDs und den dazugehörigen Werten als Text und falls das Formular vorher schon angezeigt wurde muss der Wert ausgewählt werden, wenn nicht eine andere vorgegebene ID. Mit dem CGI Modul sieht das so aus:

print CGI::popup_menu(
-name => 'ids',
-values => [keys %$list],
-labels => $list,
-default => $id
);

  
  
# copy paste aus einem meiner skripts, pfad+name geändert  
  
print "<form action=\"/pfad/skript.cgi\">\n";  
print "<input type=\"hidden\" name=\"SESSIONID\" value=\"$arg->{SESSIONID}\">\n";  
print "<table class=\"tab_options\">\n";  
print "   <tr>\n";  
print "      <th colspan=\"2\" class=\"td_option_header\">Options</th>\n";  
print "   </tr><tr>\n";  
print "      <td style=\"width:30%;\" class=\"td_option_body\">Update rate</td>\n";  
print "      <td style=\"width:70%;\" class=\"td_option_body\">\n";  
print "         <select name=\"Rate\" size=\"1\" class=\"listfield\">\n";  
  
# mein default-wert wird hier gesetzt, wenn er nicht bei einem  
# vorherigen aufruf gesetzt wurde ...  
  
$arg->{Rate} = "inactive" unless $arg->{Rate};  
  
foreach ( "inactive", 10, 30, 60, 180, 600 ) {  
   print "            <option value=\"$_\" selected>$name</option>\n" if $_ eq $arg->{Rate};  
   print "            <option value=\"$_\">$name</option>\n" if $_ ne $arg->{Rate};  
}  
  
print "         </select>\n";  
print "      </td>\n";  
  
# normalerweise kommen hier noch ein paar andere selects+options...  
# soviel wollte ich nun doch nicht einfügen :-)  
  
print "   </tr>\n";  
print "</table>\n";  
print "</form>\n";  

Natürlich kann man das auch selber machen, aber je mehr du davon brauchst umso glücklicher bist du das das schon mal jemand gemacht hat.

Bei manchen Dingen ja, bei manchen nein. Siehe auch weiter unten.

doFooter(); # meine Fußleiste mit </body></html>

print CGI::end_html();

sieht für mich nicht schlechter aus.

naja, ausser das diese Funktion meine schön formatierte Fußleiste
nicht wieder gibt ;-)

Natürlich ist es Geschmackssache, aber warum etwas was andere die evtl. mehr Ahnung haben und x-fach erprobt ist

weil ich es privat mache und es mir einen riesen Spaß macht Struppi :-)

Greez,
opi

[Struppi]

das mit der globalen Variable hatte ich mir schon irgendwie gedacht
und habe mich dann doch für die "robuste und lange schon im Einsatz"
befindliche Funktion fatalsToBrowser entschieden :-)

Die ja erst mal nichts anderes macht als einen Fehler auch in den Browser umzuleiten.

D.h. sie ist nützlich, wenn du mal schnell einen Fehler finden willst, aber sie ist nichts für den täglichen Einsatz beim entwickeln. Da u.U. nicht genug Informationen ausgegeben werden.

Ich habe es einfach so realisiert, das ich für all meine Fehler, die
auftreten könnten und die ich auch abfange, einen Fehlercode ausgeben
lasse. Beispiel:

sysopen(FILE,$file,O_RDONLY) or die "<SOFTWARE_NAME>-ERROR-1223";

Der Fehlercode deshalb, weil es unterschiedliche Skripts gibt, die
auf gleiche Ressourcen zugreifen und ich es lästig finde für alle
Skripts die gleiche Meldung zu schreiben.

Soweit so gut (wobei hier z.b. die Information fehlt welche Datei versucht wurde zu öffnen.)

Zur Auswertung der error_log habe ich mir noch ein Skript
geschrieben, welches regelmäßig Meldungen ausliest und bei dem
Vorkommen eines Fehlers eine Mail oder WasAuchImmer auslöst.

Und ein (per cronjob?) regelmäßiges meistens sinnlose laufende Skript ist Resourcenfreundlicher als eine Modul, das nur im Fehlerfall mit require einbinden wird?

Ich glaub nicht.

Es würde doch für Fixes ausreichen, strict wieder aufzunehmen oder?

klar, aber wie Christian schon sagte, macht use strict nicht soviel als das du dadurch irgendetwas meßbares erreichen könntest.

Struppi.

[opi]

Hallo,

Funktion fatalsToBrowser

Die ja erst mal nichts anderes macht als einen Fehler auch in den Browser umzuleiten.

D.h. sie ist nützlich, wenn du mal schnell einen Fehler finden willst, aber sie ist nichts für den täglichen Einsatz beim entwickeln. Da u.U. nicht genug Informationen ausgegeben werden.

da gebe ich dir vollkommen recht. Aber meine Skripts sind meist sehr
klein und nicht länger als 300-500 Zeilen. Das ist noch sehr über-
sichtlich.

Ich habe es einfach so realisiert, das ich für all meine Fehler, die
auftreten könnten und die ich auch abfange, einen Fehlercode ausgeben
lasse. Beispiel:

sysopen(FILE,$file,O_RDONLY) or die "<SOFTWARE_NAME>-ERROR-1223";

Der Fehlercode deshalb, weil es unterschiedliche Skripts gibt, die
auf gleiche Ressourcen zugreifen und ich es lästig finde für alle
Skripts die gleiche Meldung zu schreiben.

Soweit so gut (wobei hier z.b. die Information fehlt welche Datei versucht wurde zu öffnen.)

oh nein. Es gibt zwei oder drei Hände voll mit Dateien, die geöffnet,
erstellt oder was auch immer werden. Die Fehlercodes lassen ziemlich
genau auf den Fehler hindeuten und wenn nicht, dann gebe ich die
Variable mit ... die "NAME-ERROR-1234 $var";

Zur Auswertung der error_log habe ich mir noch ein Skript
geschrieben, welches regelmäßig Meldungen ausliest und bei dem
Vorkommen eines Fehlers eine Mail oder WasAuchImmer auslöst.

Und ein (per cronjob?) regelmäßiges meistens sinnlose laufende Skript ist Resourcenfreundlicher als eine Modul, das nur im Fehlerfall mit require einbinden wird?

auch nein. Ein Job der non Stop läuft. Dieser Prozess macht noch viel
mehr als die error_log zu überwachen. Dieser Prozess überwacht auch
noch andere Prozesse und Logdateien. Und soviele Ressourcen frist der
nicht! Du kannst mir glauben, dass gerade ich darauf insbesondere
achte :-)

Ich glaub nicht.

Es würde doch für Fixes ausreichen, strict wieder aufzunehmen oder?

klar, aber wie Christian schon sagte, macht use strict nicht soviel als das du dadurch irgendetwas meßbares erreichen könntest.

is ja gut, ich lass es ja schon drin :-) war auch nur so ne Frage.

Greez,
opi

[Benne]

Hallo Christian,

Du solltest immer den -w-Switch benutzen und nie use warnings, ja. Das ist
der perldoc sogar so wichtig, dass sie es _drei_ mal wiederholen ;)

in "Effective Perl Programming" steht das genau umgekehrt drin.
-w schaltet nämlich auch Warnungen für alle eingebundenen Module an.
In der Regel möchte man aber keine Warnungen von einem fremden Modul erhalten..

Gruß,
Benne

[Christian Kruse]

你好 Benne,

Du solltest immer den -w-Switch benutzen und nie use warnings, ja. Das
ist der perldoc sogar so wichtig, dass sie es _drei_ mal wiederholen ;)
in "Effective Perl Programming" steht das genau umgekehrt drin.

Dann widerspricht Effective Perl Programming in diesem Fall der perldoc ;)
Jetzt ist es deine Aufgabe zu entscheiden, wem du folgen möchtest.

-w schaltet nämlich auch Warnungen für alle eingebundenen Module an.

… was ja auch durchaus wünschenswert ist.

In der Regel möchte man aber keine Warnungen von einem fremden Modul
erhalten..

Doch, sicher möchte man das. Es macht auf eventuelle Fehler in dem Modul
aufmerksam. Modulen, die Warnings produzieren, würde ich nicht trauen.

再见,
 克里斯蒂安

[Stefan]

Hi Christian,

wenn das Skript ausgiebig (!) getestet worden ist, sollte man dann den -w Parameter und use warnings nun deaktivieren.

Verringert denn das die CPU-Auslastung des Servers?

Bye

Stefan

[Christian Kruse]

你好 Stefan,

wenn das Skript ausgiebig (!) getestet worden ist, sollte man dann
den -w Parameter und use warnings nun deaktivieren.

Nein. Du solltest es aktiviert lassen und regelmäßig auf Warnungen prüfen.

Verringert denn das die CPU-Auslastung des Servers?

Nein, nicht wirklich.

再见,
 克里斯蒂安

[opi]

Hallo Christian,

Du solltest immer den -w-Switch benutzen und nie use warnings, ja. Das ist
der perldoc sogar so wichtig, dass sie es _drei_ mal wiederholen ;)

warum denn -w und nicht use warnings?

Greez,
opi