Web 2.0

Re: Web 2.0

Am Tue, 26 Sep 2006 13:16:00 +0200 schrieb Helmut Chang:

> Martin Kaffanke schrieb:
>
>> Beispiel im anderen Thread, hier nochmal kurz:
>
> Welcher andere Thread?
>
>> Ich habe eine Datenbank mit Usern, die sich über die Webseite registriert
>> haben. Dazu wurden noch einige zusätzliche Daten aufgenommen.
>>
>> Nun möchte ich das offline administrieren.
>
> Bitte erzähl mir, wie du eine Datenbank, die auf einem entfernten Server
> läuft, offline administrierst.

Naja, eine Datenbank läuft hier schon. Sozusagen als slave, es geht vor
allem um die Ständigen Abfragen, die mein Kunde dann mit seinem Notebook
zu seinen Kunden mitnehmen möchte, ...

> Mir scheint, du mischt da munter Begriffe, etc. Du möchtest nicht
> offline administrieren, sondern du möchtest über eine
> Desktop-Applikation und nicht über eine Webapplikation administrieren.

Ich möchte beides letztlich.

> Tjo, und für eine Desktop-Applikation würde ich PHP auch nicht
> verwenden. Du vergleichst IMHO Äpfel und Birnen.

Tja, drum nehm ich eine Sprache, die beides kann.

lg,
Martin

Re: Web 2.0

Torsten Zühlsdorff schrieb:
> Martin Kaffanke schrieb:
>
> Es ist in Java z.b. unmöglich, eine Wertzuweisung innerhalb einer
> Bedingungsabfrage zu machen. Das wird als unglaublicher Fortschritt
> gewertet, obwohl man das ohne Mühe umgehen kann - in dem man mitdenkt.
> Dafür muß man in Java auf viellerleich verzichten. Referenzen.
> Funktionen als Parameter. Und vieles vieles mehr.

Wer sagt denn, dass Zuweisungen in Bedingungsabfragen in Java nicht
möglich sind?


int test;
if((test=1) == 1){

}


Eine Zuweisung hat in Java immer den Wert des r-Werts, das bedeutet,
dass in diesem Fall das if immer durchlaufen wird...

Gut, was nicht so einfach möglich ist, ist, dass man versehentlich aus
einem == ein = in einer Abfrage macht! Das liegt aber nur daran, dass
eine Zuweisung eben auch einen gewissen datentyp hat, und in einem
vergleichsausdruck nunmal boolean stehen muss! dieses hier würde wieder
gehen:

boolean test;
if(test = true){

}

jm2c Alex

Re: Web 2.0

Alex Hepp wrote:

> Ich kann bei smarty / php auch Objekte assignen, und im Template zb.
> sowas verwenden:
>
> {$martin->getPHPSkill()}

Auch wenns zur eigentlichen Diskusion wenig beiträgt. Aber hier wurde
definitiv die Aufteilung in Layout und Code missachtet.

Solche Konstrukte haben meiner Meinung nach definitiv nix in einem
Template zu suchen! Das Smarty da eigene Wege geht ist ja schon länger
bekannt. Aber besser scheints da auch nicht mehr zu werden.

MfG Ulf aka AntiSmarty

Re: Web 2.0

Alex Hepp schrieb:

>> Es ist in Java z.b. unmöglich, eine Wertzuweisung innerhalb einer
>> Bedingungsabfrage zu machen. Das wird als unglaublicher Fortschritt
>> gewertet, obwohl man das ohne Mühe umgehen kann - in dem man mitdenkt.
>> Dafür muß man in Java auf viellerleich verzichten. Referenzen.
>> Funktionen als Parameter. Und vieles vieles mehr.
>
>
> Wer sagt denn, dass Zuweisungen in Bedingungsabfragen in Java nicht
> möglich sind?
>
>
> int test;
> if((test=1) == 1){
>
> }
>
>
> Eine Zuweisung hat in Java immer den Wert des r-Werts, das bedeutet,
> dass in diesem Fall das if immer durchlaufen wird...
>
> Gut, was nicht so einfach möglich ist, ist, dass man versehentlich aus
> einem == ein = in einer Abfrage macht! Das liegt aber nur daran, dass
> eine Zuweisung eben auch einen gewissen datentyp hat, und in einem
> vergleichsausdruck nunmal boolean stehen muss!

Asche über mein Haupt für die unzureichende Erläuterung :(

Gruß,
Torsten

Re: Web 2.0

Am Tue, 26 Sep 2006 13:14:10 +0200 schrieb Torsten Zühlsdorff:

> 1. PHP ist leicht und bietet relativ viel Freiraum.
> 2. Mit Selbstdisziplin kann man sehr schnell und sehr einfach zu sehr
> guten Ergebnissen kommen
> 3. Es gibt viele populäre Sprachen, die unsauberes Programmieren
> unmöglich machen und sind dafür stark eingeschränkt.
>
> Zu Drittens ist Java ein typisches Beispiel. Es ist syntaxmäßig nur
> wenig besser als PHP, aber gilt weitläufig als viel proffessioneller.
> Es ist in Java z.b. unmöglich, eine Wertzuweisung innerhalb einer
> Bedingungsabfrage zu machen.

Naja, man versucht halt so ambivalenz von Statements zu vermeiden:

if (a = foo())

Hat die Zuweisung nicht geklappt, weil z.b. für a zu wenig Speicher zur
Verfügung steht oder aus welchem Grund auch immer, oder hat die Funktion
False zurückgegeben?

> Das wird als unglaublicher Fortschritt
> gewertet, obwohl man das ohne Mühe umgehen kann - in dem man mitdenkt.
> Dafür muß man in Java auf viellerleich verzichten. Referenzen.
> Funktionen als Parameter. Und vieles vieles mehr.
>
> Selbst in den neuen, jetzt immer populärer werdenen Sprachen wie ruby
> oder Python ist letzteres nicht möglich (hier mag ich mich irren, da ich
> kaum Zeit auf sie verwende - bisher habe ich es aber nicht finden können)

Python arbeitet normalerweise mit Referenzen, wenn nicht anders angegeben.
Funktionen als Parameter oder Rückgabewerte sind kein Problem, ...
Ebenso das Verwenden eines Objektes als 'Intelligentes Array' ist kein
Problem. (bei a['foo'] = "whatever" wird eine funktion ausgeführt, die
alles mögliche machen kann, a ist eine instanz einer klasse.)

>>
>> d = "Dach"
>> h = "Haus"
>> mystr = u"Das %s fällt vom %(b)"%d
>
> Wo ist jetzt nochmal der Unterschied zu:
> $d = "Dach";
> $h = "Haus";
> $mystr = "Das $d fällt vom $h";
> ?
> Syntaxtisch nimmt sich das nicht viel. Und in der hier von PHP-gewählten
> Variante ist es noch sehr unschön.

Vielleicht dass mein string unicode ist, und dass hier formatstring
verwendet wird und nicht einfach nur ersetzt wird.

> Mal abgesehen davon, dass Strings nichts im Code zu suchen haben.

Wie machst du es sonst? In eigentlich jeder gängigen Scriptsprache sind
statische (oder halt mit gettext übersetzte) strings bereits built in.

>> (ok, normalerweise werfe ich die beiden schreibeweisen nicht
>> durcheinander, ist hier nur ein Beispiel. Das u steht für "unicode".)
>>
>> was mir noch gut gefällt:
>>
>> parts = " hallo welt ".strip().split(" ")
>>
>> (parts ist jetzt eine liste, bestehend aus "hallo" und "welt".
>
> $parts = implode(' ', 'hallo welt');
>
> Obwohl ich noch immer Rätsel, warum man soetwas macht, soll es ja auch
> dafür Anwendungsmöglichkeiten geben.

Der strip() (entfernen von leerzeichen am Anfang und am Ende) fehlt noch.
Wenns komplizierter wird, braucht man in php am besten einen Editor mit
syntax highlighting, damit man die dazugehörige geschachtelte Klammer
findet, in python lese ich einfach von links nach rechts.

> Ohne bessere Erläuterung kann man darauf nichts erweitern. Desweiteren
> übersiehst du, dass vieles, was man in anderen Sprachen häufig macht,
> auch häufig unnötig ist. In PHP macht z.b. das Operatorenüberladen nur
> außerordentlich selten Sinn. In C dagegen schon viel häufiger.

Du willst ein Anwendungsbeispiel? Ich habe ein Objekt, hätte die
attribute aber jetzt gerne als assoziatives array, nur lesbar, damit ich
darüber einen iterator (foreach) machen kann. In python schreibe ich eine
Methode:

# exemplarisch:
def __iterator__(self, key):
if hasattr(self, key):
return (key, getattr(self, key))
raise KeyError

Schon ist mein Objekt als Dictionary lesbar verwendbar, einem foreach
steht nichts im Wege:

for k, v in myinstance:
print k, v

Wie mach ich das in php?

> Ich empfehle es dir. Dein Python wurde auch stark von LISP beeinflußt.

Was ist daran verwerflich? PHP ist auch von perl beeinflusst.

[ db schnitstelle ]

Ich kann aber die datenbankschnittstelle einfach kopieren und für den
clienten verwenden.

Martin

Re: Web 2.0

Am Tue, 26 Sep 2006 13:01:05 +0200 schrieb Ulf Kadner:

>> Naja, es gibt arrays und assoziative arrays.
>
> Assoziazive Arrays ist lediglich eine Untermenge von Arrays. Der Satz
> würde auf die Autowelt bezogen ungefähr soviel heisten wie "Es gibt PKWs
> und BMWs"

naja, in PHP wird das irgendwie durcheinandergewürfelt, ich weiß.

Martin

Re: Web 2.0

Ulf Kadner schrieb:
> Alex Hepp wrote:
>
>> Ich kann bei smarty / php auch Objekte assignen, und im Template zb.
>> sowas verwenden:
>>
>> {$martin->getPHPSkill()}
>
> Auch wenns zur eigentlichen Diskusion wenig beiträgt. Aber hier wurde
> definitiv die Aufteilung in Layout und Code missachtet.

Das sehe ich nicht ganz so! Wo ist der Unterschied, ob ich einen rein
lesenden Zugriff auf die Methode habe, oder den Wert in einer
gesonderten Variable halte? Natürlich müssen Seiteneffekte und
schreibende Zugriffe verhindert werden... Es gibt sicherlich geeignetere
Template Engines... Ich wollte damit auch nur die "Flexibilität" von
Smarty ggü Python darstellen, die Martin PHP in Abrede stellen wollte...

> Solche Konstrukte haben meiner Meinung nach definitiv nix in einem
> Template zu suchen! Das Smarty da eigene Wege geht ist ja schon länger
> bekannt. Aber besser scheints da auch nicht mehr zu werden.

Auch das sehe ich anders, denn meiner Meinung nach ist es auch für den
Designer einfacher, zu wissen, dass er ein Objekt hat, bei dem er nunmal
gewisse Methodenaufrufe, oder Felder verwenden kann, als dass er 20
verschiedene Strings oder Objekte hat, die er auseinanderhalten und
verwenden muss.

Natürlich kann man das bei smarty auch missbrauchen, was natürlich nicht
mehr Sinn der Sache ist, aber hier ist eben auch wieder Selbstdisziplin
gefragt!

Ausserdem wird in diesem Fall die benötigte Businesslogik klar im Code
gehalten... Aber Du hast schon grundsätzlich Recht, da eben auch
Missbrauch möglich ist, sollte man wohl eine andere Template Engine
einsetzen, oder eben selbst eine stricken!

> MfG Ulf aka AntiSmarty

Alex (der smarty trotzdem ab und an einsetzt!) ;)

Re: Web 2.0

Am Tue, 26 Sep 2006 13:20:33 +0200 schrieb Alex Hepp:

> Verzeih mir, dass ich nur einen "Ausschnitt" aus der Datei postete, und
> die '' Teile wegliess! Das ist für mich nunmal
> selbstverständlich, da wir hier in einer php ng sind. Aber ansonsten
> "läuft" das erste Sahne!

Das ist wahrscheinlich genau das was mich an python am meisten stört. Es
macht für mich den Eindruck, als ob php einfach nur ein HTML-Tag ist.

>> Ich habe genau das was du in diesem einen Beispiel demonstrierts auch
>> tatsächlich eingesetzt. Bin froh, dass diese Zeiten vorbei sind. Jetzt
>> mach ich einfach
>>
>> @render('template')
>> def myfunc(self, args):
>> return {'meinName': 'Alex'}
>>
>> bei gleichem Template (andere Notation) und fertig ists. ('Alex' kann
>> auch ein dict (php: assoziatives array) sein, welches untervariablen
>> enthält für das template.)
>
> Und das ist einfacher???? wie sieht denn dann das template aus?

Im Grunde wie deines. Umgangssprachlich würde ich sagen, das @render
bereitet lediglich die darauffolgende funktion vor, die läuft nämlich
innerhalb der funktion 'render' wenn sie aufgerufen wird. So eine art
wrapper, der sich um das Template kümmert.

> Ich kann bei smarty / php auch Objekte assignen, und im Template zb.
> sowas verwenden:
>
> {$martin->getPHPSkill()}

Sieht für mich auf den ersten Blick nach einer Vermischung von Template
und Code aus.

Derartige Dinge mache ich aber auch, mit properties. Hier wird bei

martin.phpskill (php: $martin->phpskill, also ein attribut keine funktion)
einfach noch eine funktion aufgerufen, die den Wert zurückgibt. Das
funktioniert dann Objektintern.

Ist wohl eine Frage der Implementation. Aber in meiner Version scheint
mir klarer zu sein, wo der code und wo das template ist.

>> Ok, du hast recht, ich werde mich dann langsam aus der Gruppe
>> zurückziehen. PHP hat für mich ausgedient, leider hab ich noch ein
>> paar alte Projekte die ich warten muss, aber ansonsten bin ich froh php
>> nicht mehr verwenden zu müssen.
>
> Tjo, schüss! ;)

;-)

cu,
Martin

Re: Web 2.0

Am Tue, 26 Sep 2006 12:48:25 +0200 schrieb Ulrich Gehauf:

> Am Tue, 26 Sep 2006 10:42:13 +0200 schrieb Martin Kaffanke:
>
>> Für mich ist eine Datei die mit endet bereits
>> ein in html eingepetteter php code.
>
> Das hat zum einen nix mit Petting zu tun, sondern schreibt sich
> "eingebettet"
>
> Und zum Anderen: Wie kommst du darauf das
> valides (oder überhaupt irgendwie) HTML ist?

Es sagt dem Server, dass hier php code zum auswerten ist. Der Server ist
genötigt, hier HTML von PHP zu trennen. Der Programmierer macht das
selbe. Anstatt das einfach in verschiedenen Dateien abzulegen.

lg,
Martin

Re: Web 2.0

Martin Kaffanke schrieb:

>>1. PHP ist leicht und bietet relativ viel Freiraum.
>>2. Mit Selbstdisziplin kann man sehr schnell und sehr einfach zu sehr
>>guten Ergebnissen kommen
>>3. Es gibt viele populäre Sprachen, die unsauberes Programmieren
>>unmöglich machen und sind dafür stark eingeschränkt.
>>
>>Zu Drittens ist Java ein typisches Beispiel. Es ist syntaxmäßig nur
>>wenig besser als PHP, aber gilt weitläufig als viel proffessioneller.
>>Es ist in Java z.b. unmöglich, eine Wertzuweisung innerhalb einer
>>Bedingungsabfrage zu machen.
>
> Naja, man versucht halt so ambivalenz von Statements zu vermeiden:

Du weißt, was Ambivalenz bedeutet?

> if (a = foo())
>
> Hat die Zuweisung nicht geklappt, weil z.b. für a zu wenig Speicher zur
> Verfügung steht oder aus welchem Grund auch immer, oder hat die Funktion
> False zurückgegeben?

Solche Ausdrücke sind zwar leicht lesbar, aber soetwas verwendet man
nicht. Wenn du deine Fragen ernst meinst, verstehst du die Syntax nicht.

>>Das wird als unglaublicher Fortschritt
>>gewertet, obwohl man das ohne Mühe umgehen kann - in dem man mitdenkt.
>>Dafür muß man in Java auf viellerleich verzichten. Referenzen.
>>Funktionen als Parameter. Und vieles vieles mehr.
>>
>>Selbst in den neuen, jetzt immer populärer werdenen Sprachen wie ruby
>>oder Python ist letzteres nicht möglich (hier mag ich mich irren, da ich
>>kaum Zeit auf sie verwende - bisher habe ich es aber nicht finden können)
>
> Python arbeitet normalerweise mit Referenzen, wenn nicht anders angegeben.

Um auf dein Beispiel zurückzukommen, müßte das bedeuten:
d = "dach"
h = d
h = "auto"

und jetzt steht in d auto? Standardmäßige Referenzen auf Variablen
machen kaum Sinn.

> Funktionen als Parameter oder Rückgabewerte sind kein Problem, ...
> Ebenso das Verwenden eines Objektes als 'Intelligentes Array' ist kein
> Problem. (bei a['foo'] = "whatever" wird eine funktion ausgeführt, die
> alles mögliche machen kann, a ist eine instanz einer klasse.)

Objekte !== Arrays. Selbst in Python.

>>>d = "Dach"
>>>h = "Haus"
>>>mystr = u"Das %s fällt vom %(b)"%d
>>
>>Wo ist jetzt nochmal der Unterschied zu:
>>$d = "Dach";
>>$h = "Haus";
>>$mystr = "Das $d fällt vom $h";
>>?
>>Syntaxtisch nimmt sich das nicht viel. Und in der hier von PHP-gewählten
>>Variante ist es noch sehr unschön.
>
> Vielleicht dass mein string unicode ist, und dass hier formatstring
> verwendet wird und nicht einfach nur ersetzt wird.

Wow. Unicode und Tokens. Ich bin begeistert. Was ist jetzt so toll daran?

>>Mal abgesehen davon, dass Strings nichts im Code zu suchen haben.
>
> Wie machst du es sonst? In eigentlich jeder gängigen Scriptsprache sind
> statische (oder halt mit gettext übersetzte) strings bereits built in.

Ist die Frage ernst gemeint? Kein vernüftiger Programmierer schreibt
irgendwelche Texte in seinen Code (es sei denn, er macht das mit Absicht
in wissen um die Konsequenzen) (Ausnahme: Dokumentation). Wenn du solche
Fragen stellst, ist es egal, welche Sprache du verwendest - das kann nur
schief gehen.

>>>(ok, normalerweise werfe ich die beiden schreibeweisen nicht
>>>durcheinander, ist hier nur ein Beispiel. Das u steht für "unicode".)
>>>
>>>was mir noch gut gefällt:
>>>
>>>parts = " hallo welt ".strip().split(" ")
>>>
>>>(parts ist jetzt eine liste, bestehend aus "hallo" und "welt".
>>
>>$parts = implode(' ', 'hallo welt');
>>
>>Obwohl ich noch immer Rätsel, warum man soetwas macht, soll es ja auch
>>dafür Anwendungsmöglichkeiten geben.
>
> Der strip() (entfernen von leerzeichen am Anfang und am Ende) fehlt noch.

$parts = explode(' ', trim('hallo welt');

Besser?

> Wenns komplizierter wird, braucht man in php am besten einen Editor mit
> syntax highlighting, damit man die dazugehörige geschachtelte Klammer
> findet, in python lese ich einfach von links nach rechts.

Du verzapfst Unsinn. Dein Beispiel:

parts = " hallo welt ".strip().split(" ")

Liest man von rechts nach links. Leider gehört auch PHP zu den Sprachen,
die man Gemischtseitig liest.

>>Ohne bessere Erläuterung kann man darauf nichts erweitern. Desweiteren
>>übersiehst du, dass vieles, was man in anderen Sprachen häufig macht,
>>auch häufig unnötig ist. In PHP macht z.b. das Operatorenüberladen nur
>>außerordentlich selten Sinn. In C dagegen schon viel häufiger.
>
> Du willst ein Anwendungsbeispiel?

Um Gotteswillen nein - mehr ertrage ich nicht :P

> Ich habe ein Objekt, hätte die
> attribute aber jetzt gerne als assoziatives array, nur lesbar, damit ich
> darüber einen iterator (foreach) machen kann. In python schreibe ich eine
> Methode:
>
> # exemplarisch:
> def __iterator__(self, key):
> if hasattr(self, key):
> return (key, getattr(self, key))
> raise KeyError
>
> Schon ist mein Objekt als Dictionary lesbar verwendbar, einem foreach
> steht nichts im Wege:
>
> for k, v in myinstance:
> print k, v
>
> Wie mach ich das in php?

mit get_object_vars() und einen foreach().

Du solltest dir nicht Beispiele aussuchen, die man auch noch leichter
lösen kann. Desweiteren sind punktelle Beispiele für Sprachvergleite
totaler Unsinn.

>>Ich empfehle es dir. Dein Python wurde auch stark von LISP beeinflußt.
>
> Was ist daran verwerflich? PHP ist auch von perl beeinflusst.

Daran ist nichts verwerflich. Ich wollte dir nur durch die Blume sagen,
dass ich Lisp für wesentlich besser als Python halte.

> [ db schnitstelle ]
>
> Ich kann aber die datenbankschnittstelle einfach kopieren und für den
> clienten verwenden.

Unsinn. Wenn die Datenbank offline ist, weil du das ganze ja offline
administrieren möchtest, kannst du genau gar nichts.

Gruß,
Torsten

Re: Web 2.0

Martin Kaffanke schrieb:
> Am Tue, 26 Sep 2006 13:01:05 +0200 schrieb Ulf Kadner:
>
>>> Naja, es gibt arrays und assoziative arrays.
>> Assoziazive Arrays ist lediglich eine Untermenge von Arrays. Der Satz
>> würde auf die Autowelt bezogen ungefähr soviel heisten wie "Es gibt PKWs
>> und BMWs"
>
> naja, in PHP wird das irgendwie durcheinandergewürfelt, ich weiß.

Ich bat Dich doch, unqualifizierte Provokationen zu unterlassen, oder ? ;)

Re: Web 2.0

Martin Kaffanke schrieb:

>>>Naja, es gibt arrays und assoziative arrays.
>>
>>Assoziazive Arrays ist lediglich eine Untermenge von Arrays. Der Satz
>>würde auf die Autowelt bezogen ungefähr soviel heisten wie "Es gibt PKWs
>>und BMWs"
>
> naja, in PHP wird das irgendwie durcheinandergewürfelt, ich weiß.

Wenn du noch häufiger solchen Unsinn erzählst, wirst du gefiltert...

Gruß,
Torsten

Re: Web 2.0

Alex Hepp wrote:

>> Solche Konstrukte haben meiner Meinung nach definitiv nix in einem
>> Template zu suchen! Das Smarty da eigene Wege geht ist ja schon länger
>> bekannt. Aber besser scheints da auch nicht mehr zu werden.
>
> Auch das sehe ich anders, denn meiner Meinung nach ist es auch für den
> Designer einfacher, zu wissen, dass er ein Objekt hat,

Verstehe ich nicht!

Im allgeminen ist es hier so, das Leute die fürs Design+Templates
zuständig sind keinen Schimmer von PHP haben. Warum auch? sonst wärens
ja nicht nur Designer geworden! ;-)

Spass beiseite.
Der Witz an der Sache ist ja eigentlich das durch ein Template genau
diese Belästigung des Designers mit "Voodoo aus der anderen Wert"
vermieden werden soll. Wenn ich ner Designabteilung erst ne PHP-API
vorlegen würde, damit die Ihr Template erstellen können wären die Lacher
definitiv nicht auf meiner Seite.

MfG, Ulf

Re: Web 2.0

Am Tue, 26 Sep 2006 14:13:03 +0200 schrieb Torsten Zühlsdorff:

> Martin Kaffanke schrieb:
>
>>>>Naja, es gibt arrays und assoziative arrays.
>>>
>>>Assoziazive Arrays ist lediglich eine Untermenge von Arrays. Der Satz
>>>würde auf die Autowelt bezogen ungefähr soviel heisten wie "Es gibt PKWs
>>>und BMWs"
>>
>> naja, in PHP wird das irgendwie durcheinandergewürfelt, ich weiß.
>
> Wenn du noch häufiger solchen Unsinn erzählst, wirst du gefiltert...

Keine Sorge, am ende dieses Threades werde ich diese Gruppe sowieso aus
meinem newsreader entfernen.

Martin

Re: Web 2.0

Am Tue, 26 Sep 2006 14:12:17 +0200 schrieb Alex Hepp:

> Martin Kaffanke schrieb:
>> Am Tue, 26 Sep 2006 13:01:05 +0200 schrieb Ulf Kadner:
>>
>>>> Naja, es gibt arrays und assoziative arrays.
>>> Assoziazive Arrays ist lediglich eine Untermenge von Arrays. Der Satz
>>> würde auf die Autowelt bezogen ungefähr soviel heisten wie "Es gibt PKWs
>>> und BMWs"
>>
>> naja, in PHP wird das irgendwie durcheinandergewürfelt, ich weiß.
>
> Ich bat Dich doch, unqualifizierte Provokationen zu unterlassen, oder ? ;)

Ist ja umgekehrt auch nicht anders. (Irgendwo gegen Ende des postings,
das du zitiert hast.)

Martin

Re: Web 2.0

Martin Kaffanke schrieb:

>>>>>Naja, es gibt arrays und assoziative arrays.
>>>>
>>>>Assoziazive Arrays ist lediglich eine Untermenge von Arrays. Der Satz
>>>>würde auf die Autowelt bezogen ungefähr soviel heisten wie "Es gibt PKWs
>>>>und BMWs"
>>>
>>>naja, in PHP wird das irgendwie durcheinandergewürfelt, ich weiß.
>>
>>Wenn du noch häufiger solchen Unsinn erzählst, wirst du gefiltert...
>
> Keine Sorge, am ende dieses Threades werde ich diese Gruppe sowieso aus
> meinem newsreader entfernen.

Damit tust du uns einen großen Gefallen. Aber irgendwie tut mir die
Python-Gruppe leid...

Gruß,
Torsten

Re: Web 2.0

Martin Kaffanke wrote:

> Keine Sorge, am ende dieses Threades werde ich diese Gruppe sowieso aus
> meinem newsreader entfernen.

Das ist die beste Idee die Du je hier geäussert hast. Danke!

MfG, Ulf

Re: Web 2.0

Am Tue, 26 Sep 2006 14:12:14 +0200 schrieb Torsten Zühlsdorff:

>> Python arbeitet normalerweise mit Referenzen, wenn nicht anders angegeben.
>
> Um auf dein Beispiel zurückzukommen, müßte das bedeuten:
> d = "dach"
> h = d
> h = "auto"
>
> und jetzt steht in d auto? Standardmäßige Referenzen auf Variablen
> machen kaum Sinn.

Du hast jetzt genau das gepostet wie man in python referenzen
explizit vermeidet.

Ich meine bei Dinge wie for i in x: (php: foreach) oder auch bei übergabe
von daten an eine funktion haben wir in python referenzen.

also
def foo(a):
a = "Maus"

a = "Hallo"
foo(a)

print a
# gibt "Maus" aus.

Um das zu vermeiden:
a = "Hallo"
b = a
foo(b)

Aber das ist eher selten, sagen wir mal so, ich habe das noch fast nie
gebraucht.

>> Funktionen als Parameter oder Rückgabewerte sind kein Problem, ...
>> Ebenso das Verwenden eines Objektes als 'Intelligentes Array' ist kein
>> Problem. (bei a['foo'] = "whatever" wird eine funktion ausgeführt, die
>> alles mögliche machen kann, a ist eine instanz einer klasse.)
>
> Objekte !== Arrays. Selbst in Python.

Nein, aber umgekehrt ists in python schon:
a = ['eins', 'zwei']
isinstance(a, object)
# returns True

isinstance(a, array)
ist natürlich auch True, weil array eine erweiterung von objekt ist.

Und deshalb habe ich in python auch die Möglichkeit, jedem x-belibigen
objekt die Funktionalität zu verleihen, sich bei einer Notation
wie in foreach wie eine Liste (array) zu verhalten. Das brauche ich
hingegen viel häufiger, als eine Kopie von Daten (vgl. Referenzen oben).

>>>Mal abgesehen davon, dass Strings nichts im Code zu suchen haben.
>>
>> Wie machst du es sonst? In eigentlich jeder gängigen Scriptsprache sind
>> statische (oder halt mit gettext übersetzte) strings bereits built in.
>
> Ist die Frage ernst gemeint? Kein vernüftiger Programmierer schreibt
> irgendwelche Texte in seinen Code (es sei denn, er macht das mit Absicht
> in wissen um die Konsequenzen) (Ausnahme: Dokumentation). Wenn du solche
> Fragen stellst, ist es egal, welche Sprache du verwendest - das kann nur
> schief gehen

Zeit mir also ein Paket, das ganz ohne statische Strings (meist
Fehlermeldungen) auskommt.

> Du verzapfst Unsinn. Dein Beispiel:
>
> parts = " hallo welt ".strip().split(" ")
>
> Liest man von rechts nach links. Leider gehört auch PHP zu den Sprachen,
> die man Gemischtseitig liest.

Lies wie du willst. Ich lese: Da gibts einen string, der heißt " hallo
welt ". Dieser wird dann gestrippt, danach gesplittet.

Nichts für ungut.

Martin

Re: Web 2.0

Ulf Kadner schrieb:
> Alex Hepp wrote:
>
>>> Solche Konstrukte haben meiner Meinung nach definitiv nix in einem
>>> Template zu suchen! Das Smarty da eigene Wege geht ist ja schon
>>> länger bekannt. Aber besser scheints da auch nicht mehr zu werden.
>>
>> Auch das sehe ich anders, denn meiner Meinung nach ist es auch für den
>> Designer einfacher, zu wissen, dass er ein Objekt hat,
>
> Verstehe ich nicht!
>
> Im allgeminen ist es hier so, das Leute die fürs Design+Templates
> zuständig sind keinen Schimmer von PHP haben. Warum auch? sonst wärens
> ja nicht nur Designer geworden! ;-)

Hehe! ;)

> Spass beiseite.
> Der Witz an der Sache ist ja eigentlich das durch ein Template genau
> diese Belästigung des Designers mit "Voodoo aus der anderen Wert"
> vermieden werden soll. Wenn ich ner Designabteilung erst ne PHP-API
> vorlegen würde, damit die Ihr Template erstellen können wären die Lacher
> definitiv nicht auf meiner Seite.

In meinen Augen ist viel wesentlicher, als Layout von Code zu trennen,
Businesslogik von Präsentationslogik zu trennen. Denn auch als reiner
Templatedesigner benötige ich eine gewisse Logik...

Aber davon abgesehen, folgendes sei gegeben:
---------------
1. (vereinfacht)
im php: $smarty->assign('var1',$obj->method());
im template:

{$var1}
---------------
2. im php:
$smarty->assign('obj',$obj);

im template:
{$obj->method()}
---------------

Smarty erlaubt keinen schreibenden Zugriff auf die Objekte, sprich, ich
kann das Objekt im Template nicht verändern (es sei denn ich nutze das
{assign} tag.

Noch dazu habe ich den Vorteil, dass, sollte sich ein Wert der zur
Berechnung von method() (was immer es auch liefert) benötigt wird,
_nach_ dem assign ändern, dann eben auch der Wert ändert, im anderen
Fall müsste ich immer wieder nach Änderungen, die ein bestimmte Variable
für das Template verändern, entweder neu berechnen, oder eben neu zuweisen!

Wenn man nun eben verschiedene Modelle nutzt, sprich, einmal Modelle,
die man intern verwendet, um eben die Businesslogik durchzuführen, und
einmal Modelle, die zur Zuweisung für die Templates verwendet werden,
und demnach natürlich keine Methoden enthalten mit Seiteneffekten, und
verändernden Zugriffen, ist man a.) auf der sicheren Seite, und hat b.)
eine dennoch gegebene Trennung.

Für den Designer ist es doch vollkommen egal, ob Du ihm beibringen
musst, dass er eine Variable verwenden kann, die einen bestimmten Wert
hat, zb. $warenkorb_gesamtpreis, oder ob es ein Objekt gibt, mit einer
lesenden Methode, oder einem Attribut:

zb. $warenkorb->getGesamtpreis, oder: $warenkorb->gesamtpreis.

Wenn ich viele Werte im Template brauche, muss man sich schon eine
geeignete Namenskonvention einfallen lassen, um das Durchsichtig zu machen!

Wenn ich dann noch eine geeignete IDE einsetze, kann der Designer sogar
mit Codevervollständigung arbeiten, und sieht sofort die entsprechenden
Variablenattribute / -methoden!

Puh, jetzt brauch ich ne Zigarette! ;)

Alex

Re: Web 2.0

Am Tue, 26 Sep 2006 14:26:02 +0200 schrieb Torsten Zühlsdorff:

> Damit tust du uns einen großen Gefallen. Aber irgendwie tut mir die
> Python-Gruppe leid...

Dort bin ich auch nicht. In Python fallen die Lösungen irgendwie
leichter.

lg,
Martin

Re: Web 2.0

Martin Kaffanke schrieb:
> Vielleicht dass mein string unicode ist, und dass hier formatstring
> verwendet wird und nicht einfach nur ersetzt wird.

php: sprintf().

>> Obwohl ich noch immer Rätsel, warum man soetwas macht, soll es ja auch
>> dafür Anwendungsmöglichkeiten geben.
>
> Der strip() (entfernen von leerzeichen am Anfang und am Ende) fehlt noch.
> Wenns komplizierter wird, braucht man in php am besten einen Editor mit
> syntax highlighting, damit man die dazugehörige geschachtelte Klammer
> findet, in python lese ich einfach von links nach rechts.

php: trim();

ja, und in lisp braucht man den klammerblick ;) aber wer sagt denn, dass
man Methodenstapelungen nicht auftrennen darf, um die Lesbarkeit zu
erhöhen? Wie ist das denn in Python (kenn mich da nich aus), liefern
_alle_ Methoden ein "Objekt" zurück, auf dem weitergearbeitet werden
kann, oder gibt es auch Methoden, die auf dem "Objekt" selbst arbeiten,
und zb. nur false od. true zurückliefern?

> Du willst ein Anwendungsbeispiel? Ich habe ein Objekt, hätte die
> attribute aber jetzt gerne als assoziatives array, nur lesbar, damit ich
> darüber einen iterator (foreach) machen kann. In python schreibe ich eine
> Methode:
>
> # exemplarisch:
> def __iterator__(self, key):
> if hasattr(self, key):
> return (key, getattr(self, key))
> raise KeyError
>
> Schon ist mein Objekt als Dictionary lesbar verwendbar, einem foreach
> steht nichts im Wege:
>
> for k, v in myinstance:
> print k, v
>
> Wie mach ich das in php?

Wer macht sowas??? Was ist der Sinn ausser zu debuggen? Thorsten hats
dir ja erklärt!

> [ db schnitstelle ]
>
> Ich kann aber die datenbankschnittstelle einfach kopieren und für den
> clienten verwenden.

Bitte???? erstmal, was genau meinst Du damit, die Schnittstelle zu
kopieren?

Du kannst auch 10 Seiten text kopieren, und dadrauf rumkritzeln, und das
dann in einen Ordner einheften, da hast Du in Etwa das gleiche, als wenn
Du offline eine DB administrierst, die Du aus Daten erstellt hast, die
auf einem Server gehalten wird, und wo sich die Daten ständig ändern.
Sei mal ehrlich: Du hast grundsätzlich überhaupt keine Ahnung, und
wolltest nur einfach mal Blödsinn verzapfen? Kann das sein?

lg Alex

Re: Web 2.0

Am Tue, 26 Sep 2006 14:36:09 +0200 schrieb Alex Hepp:

> zb. $warenkorb->getGesamtpreis, oder: $warenkorb->gesamtpreis.

Ich finde, dass eines der beiden für den Designer auf jedenfall genügt.

Sonst kommt noch die Frage: Warum geht denn dieses ->getID nicht, ->id
hingegen schon? Ich würde nur eines verwenden, einfach ums einfacher
für den designer zu halten. Auf Entwicklerebene ists ohnehin dasgleiche.
(Wenn man einfach mit properties arbeitet, schreibt man zwar die set_ und
get_ Methoden, später reicht es aber aus die attribute zu setzen und
lesen, indem man sie wie attribute behandelt. Ich finde methoden bei
objekten die nur zum setzen und lesen von attributen sind etwas seltsam.
Außer man setzt oder liest mehrere Attribute gemeinsam.)

Martin

Re: Web 2.0

Martin Kaffanke schrieb:

>>>Python arbeitet normalerweise mit Referenzen, wenn nicht anders angegeben.
>>
>>Um auf dein Beispiel zurückzukommen, müßte das bedeuten:
>>d = "dach"
>>h = d
>>h = "auto"
>>
>>und jetzt steht in d auto? Standardmäßige Referenzen auf Variablen
>>machen kaum Sinn.
>
> Du hast jetzt genau das gepostet wie man in python referenzen
> explizit vermeidet.

Nein - ich habe genau das gepostet, was du gesagt hast. Standardmäßige
Verwendung von Referenzen für Variablen.
Man sollte das Programmier-Vokabular schon beherrschen.

>>>Funktionen als Parameter oder Rückgabewerte sind kein Problem, ...
>>>Ebenso das Verwenden eines Objektes als 'Intelligentes Array' ist kein
>>>Problem. (bei a['foo'] = "whatever" wird eine funktion ausgeführt, die
>>>alles mögliche machen kann, a ist eine instanz einer klasse.)
>>
>>Objekte !== Arrays. Selbst in Python.
>
> Nein, aber umgekehrt ists in python schon:
> a = ['eins', 'zwei']
> isinstance(a, object)
> # returns True
>
> isinstance(a, array)
> ist natürlich auch True, weil array eine erweiterung von objekt ist.

Nein, in dem Fall wäre Array ein Object. Genauso wie in Java
Zeichenketten ein Objekt vom Typ String sind.

>>>>Mal abgesehen davon, dass Strings nichts im Code zu suchen haben.
>>>
>>>Wie machst du es sonst? In eigentlich jeder gängigen Scriptsprache sind
>>>statische (oder halt mit gettext übersetzte) strings bereits built in.
>>
>>Ist die Frage ernst gemeint? Kein vernüftiger Programmierer schreibt
>>irgendwelche Texte in seinen Code (es sei denn, er macht das mit Absicht
>>in wissen um die Konsequenzen) (Ausnahme: Dokumentation). Wenn du solche
>>Fragen stellst, ist es egal, welche Sprache du verwendest - das kann nur
>>schief gehen
>
> Zeit mir also ein Paket, das ganz ohne statische Strings (meist
> Fehlermeldungen) auskommt.

Ungefähr alles was ich im letztes Jahr geschrieben haben.
Ja, da gibt es auch Fehlermeldungen.
Nein, die stehen nicht im Code.

>>Du verzapfst Unsinn. Dein Beispiel:
>>
>>parts = " hallo welt ".strip().split(" ")
>>
>>Liest man von rechts nach links. Leider gehört auch PHP zu den Sprachen,
>>die man Gemischtseitig liest.
>
> Lies wie du willst. Ich lese: Da gibts einen string, der heißt " hallo
> welt ". Dieser wird dann gestrippt, danach gesplittet.

Du liest Unsinn. Solcherlei grundlegende Dinge sollte man beherrschen.
Schließlich wird deine Aktion zu erst ausgeführt und dann ihr Ergebnis
der Variable "parts" zugewiesen. Und jetzt darfst du gerne sagen, ob die
Variable links oder rechts steht und ob ihr erst der Wert zugewiesen
wird oder erst die Operation ausgeführt wird.

> Nichts für ungut.

Nichts für ungut selber.

Gruß,
Torsten

Re: Web 2.0

Alex Hepp schrieb:

> Wer macht sowas??? Was ist der Sinn ausser zu debuggen? Thorsten hats
> dir ja erklärt!

Ich bestehe darauf, dass Torsten das geschrieben hat und nicht Thorsten :P
Torsten schreibst sowieso viel zu viel....

> Sei mal ehrlich: Du hast grundsätzlich überhaupt keine Ahnung, und
> wolltest nur einfach mal Blödsinn verzapfen? Kann das sein?

Bestimmt möchte er lieb gehabt werden.

Gruß,
Torsten

Re: Web 2.0

Ulrich Gehauf schrieb:

> Wie kommst du auf Java? Ich dachte, die Zukunft liegt in Perl. Oder war=
's
> doch Python? Ne quatsch. .NET...

Forth, was sonst...

SCNR
Niels

--=20
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------

Re: Web 2.0

Martin Kaffanke schrieb:

> Ich finde methoden bei
> objekten die nur zum setzen und lesen von attributen sind etwas seltsam.

Jetzt vergreife dich nicht auch noch an der OOP. Das ist standard. Das
ist die absolute Grundlage von OOP.

Gruß,
Torsten

Re: Web 2.0

Martin Kaffanke schrieb:
> Am Tue, 26 Sep 2006 14:36:09 +0200 schrieb Alex Hepp:
>
>> zb. $warenkorb->getGesamtpreis, oder: $warenkorb->gesamtpreis.
>
> Ich finde, dass eines der beiden für den Designer auf jedenfall genügt.
>
> Sonst kommt noch die Frage: Warum geht denn dieses ->getID nicht, ->id
> hingegen schon? Ich würde nur eines verwenden, einfach ums einfacher
> für den designer zu halten. Auf Entwicklerebene ists ohnehin dasgleiche.
> (Wenn man einfach mit properties arbeitet, schreibt man zwar die set_ und
> get_ Methoden, später reicht es aber aus die attribute zu setzen und
> lesen, indem man sie wie attribute behandelt. Ich finde methoden bei
> objekten die nur zum setzen und lesen von attributen sind etwas seltsam.
> Außer man setzt oder liest mehrere Attribute gemeinsam.)

Oh mann, jetzt hör aber auf!

1. war das ein Beispiel, und ich wollte nur demonstrieren, dass eben
beides möglich ist!

also, ich versuche jetzt nicht, Dir sämtliche Paradigmen zu erläutern,
nur soviel: 1. Der Vorteil von getter Methoden ist, dass man noch
Berechnungen, oder was weiss ich was einbauen kann, was aber für den
"Benutzer", sprich in diesem Fall den Designer vollkommen transparent
ist! Gerade aber bei setter Methoden macht das Ganze sehr viel Sinn,
weil die Logik zum Setzen der Attribute vollkommen gekapselt wird, aber
davon hast Du scheinbar nicht die geringste Ahnung...

Tipp: Wikipedia. Les Dir dort mal die Artikel zu Programmierparadigmen,
Objektorientierung etc. durch... Danach kannst Du Dir ein gutes Buch
nehmen, und dann nochmal posten! Bitte!

Gruß Alex

Re: Web 2.0

Niels Braczek schrieb:

>>Wie kommst du auf Java? Ich dachte, die Zukunft liegt in Perl. Oder war's
>>doch Python? Ne quatsch. .NET...
>
> Forth, was sonst...

Ihr alle wollt doch nur COBOL totschweigen! Verschwörung!

Gruß,
Torsten

Re: Web 2.0

Torsten Zühlsdorff schrieb:
> Alex Hepp schrieb:
>
>> Wer macht sowas??? Was ist der Sinn ausser zu debuggen? Thorsten hats
>> dir ja erklärt!
>
> Ich bestehe darauf, dass Torsten das geschrieben hat und nicht Thorsten :P
> Torsten schreibst sowieso viel zu viel....

*duck* Sorry... ;)

>> Sei mal ehrlich: Du hast grundsätzlich überhaupt keine Ahnung, und
>> wolltest nur einfach mal Blödsinn verzapfen? Kann das sein?
>
> Bestimmt möchte er lieb gehabt werden.

Ich weiss es ja auch nicht, aber es zeigt sich mal wieder, dass wir die
Dummen sind, weil wir nicht schon lange einen Filter haben, der mal
grundsätzlich diese unqualifizierten Versuche der Provokation nicht nur
in die Tonne kloppt, sondern auch noch automatisch die
Programmiererpolizei und das FBI (Federal Bastard Incrementation) auf
die Fährte schickt!

m2c.
alex

Re: Web 2.0

Alex Hepp schrieb:

>>> Wer macht sowas??? Was ist der Sinn ausser zu debuggen? Thorsten hats
>>> dir ja erklärt!
>>
>> Ich bestehe darauf, dass Torsten das geschrieben hat und nicht
>> Thorsten :P
>> Torsten schreibst sowieso viel zu viel....
>
> *duck* Sorry... ;)

Mittlerweilen bin ich daran gewöhnt. Unsere Technik hier hat 2 Jahre
benötigt, um meinen Namen im Mailsystem zu korrigieren. Vermutlich bist
du schneller :P

>>> Sei mal ehrlich: Du hast grundsätzlich überhaupt keine Ahnung, und
>>> wolltest nur einfach mal Blödsinn verzapfen? Kann das sein?
>>
>> Bestimmt möchte er lieb gehabt werden.
>
> Ich weiss es ja auch nicht, aber es zeigt sich mal wieder, dass wir die
> Dummen sind, weil wir nicht schon lange einen Filter haben, der mal
> grundsätzlich diese unqualifizierten Versuche der Provokation nicht nur
> in die Tonne kloppt, sondern auch noch automatisch die
> Programmiererpolizei und das FBI (Federal Bastard Incrementation) auf
> die Fährte schickt!

Jetzt weiß ich nicht, ob ich Amen oder ACK schreiben soll *grübel*

Gruß,
Torsten

Re: Web 2.0

Alex Hepp wrote:

> In meinen Augen ist viel wesentlicher, als Layout von Code zu trennen,
> Businesslogik von Präsentationslogik zu trennen. Denn auch als reiner
> Templatedesigner benötige ich eine gewisse Logik...

Ich stimme Dir zwar im Bezug des Wesentlichen zu, nur ist das sehr oft
eine unüberwindbare Schwelle einen "Designer" dazu zu bewegen sowas auch
umsetzen zu wollen.

Hier ist ein wahrhaft grosser Unterschied zwischen der reinen Le(e|h)re
und dem was man im täglichen Alltag so antrifft.

> Aber davon abgesehen, folgendes sei gegeben:
> ---------------
> 1. (vereinfacht)
> im php: $smarty->assign('var1',$obj->method());
> im template:
>
> {$var1}
> ---------------
> 2. im php:
> $smarty->assign('obj',$obj);
>
> im template:
> {$obj->method()}
> ---------------
>
> Smarty erlaubt keinen schreibenden Zugriff auf die Objekte, sprich, ich
> kann das Objekt im Template nicht verändern (es sei denn ich nutze das
> {assign} tag.

Du meinst damit keinen direkten Schreibzugriff! Wenn $obj->method()
diesen bereits implementiert kann Smarty daran auch nix ändern.
Um sowas einen Grafikheini beizubringen (nicht die falschen Methoden zu
nutzen ist schon mehr als reiner guter Wille notwendig.

Da nutz dann zwar eine strikte Trennung von Bussiness und Präsentation
was, aber je nach Projektgrösse ist auch irgendwo Schluss mit Lustig da
der Speicherverbrauch bei derartigen Trennungen nicht einfach steigt
sondern sich proportial Verdoppelt. (GoF)

PHP ist nunmal kein Performancezauberer.

> Puh, jetzt brauch ich ne Zigarette! ;)

Unpassender Moment :-)

MfG, Ulf

Re: Web 2.0

Ulf Kadner schrieb:
> Alex Hepp wrote:
>
>> In meinen Augen ist viel wesentlicher, als Layout von Code zu trennen,
>> Businesslogik von Präsentationslogik zu trennen. Denn auch als reiner
>> Templatedesigner benötige ich eine gewisse Logik...
>
> Ich stimme Dir zwar im Bezug des Wesentlichen zu, nur ist das sehr oft
> eine unüberwindbare Schwelle einen "Designer" dazu zu bewegen sowas auch
> umsetzen zu wollen.

Gut, das ist dann Dein Problem ;) Ich hab mir mal angewöhnt, einfach so
viel zu schwätzen, dass die Jungs nich mehr wissen, was ich will, und
dann haben die gemacht, was ich wollte ;)

> Hier ist ein wahrhaft grosser Unterschied zwischen der reinen Le(e|h)re
> und dem was man im täglichen Alltag so antrifft.

ACK! Leider!

>> Aber davon abgesehen, folgendes sei gegeben:
>> ---------------
>> 1. (vereinfacht)
>> im php: $smarty->assign('var1',$obj->method());
>> im template:
>>
>> {$var1}
>> ---------------
>> 2. im php:
>> $smarty->assign('obj',$obj);
>>
>> im template:
>> {$obj->method()}
>> ---------------
>>
>> Smarty erlaubt keinen schreibenden Zugriff auf die Objekte, sprich,
>> ich kann das Objekt im Template nicht verändern (es sei denn ich nutze
>> das {assign} tag.
>
> Du meinst damit keinen direkten Schreibzugriff! Wenn $obj->method()
> diesen bereits implementiert kann Smarty daran auch nix ändern.
> Um sowas einen Grafikheini beizubringen (nicht die falschen Methoden zu
> nutzen ist schon mehr als reiner guter Wille notwendig.

Richtig, ich schrieb deshalb auch, dass es in diesem Fall am besten ist,
eine 2geteilte Modellarchitektur einzuführen, wobei das eine Modell eben
NUR für die Verwendung im Template verwendet wird, während das 2. eben
in der Businesslogik eingesetzt wird, sprich eben auch "schreibende"
Methoden hat!

> Da nutz dann zwar eine strikte Trennung von Bussiness und Präsentation
> was, aber je nach Projektgrösse ist auch irgendwo Schluss mit Lustig da
> der Speicherverbrauch bei derartigen Trennungen nicht einfach steigt
> sondern sich proportial Verdoppelt. (GoF)

Wie kann sich denn was proportional verdoppeln? Nur so als Frage!
Natürlich steigt der Speicherverbrauch leicht an, aber in meinen Augen
eben nicht unangemessen zum Nutzen den man durch die Trennung hat!

> PHP ist nunmal kein Performancezauberer.

ACK, aber wer ist das schon! Wie war das noch mit dem goldenen Viereck?
performance, wartbarkeit, qualität (im sinne von bugfreiheit),
entwicklungsaufwand. Hab ich was vergessen?

>> Puh, jetzt brauch ich ne Zigarette! ;)
>
> Unpassender Moment :-)

Warum? Hörst Du grade auf??? ;)

Alex

Re: Web 2.0

Post removed (X-No-Archive: yes)

Re: Web 2.0

Thomas Barth schrieb:
> Hallo!
>
> * CMS Systeme: Joomla 1.0, Mambo 4.5
> * Foren: phpBB 2.0, ThWBoard 3.0
> * Newsletter: PHPlist 2.1
> * Publishing Systeme: WordPress 2.0
> * Blog-Software: Serendipity 1.0
> * Voting: PHP Voting
> * Galerie: Gallery 2.1.2, Coppermine 1.4
> * Web-Shop: osCommerce 2.2
> * Formmailer: Formmailer 1.0
> * Kalender: ExtCalendar 2.0
> * Wiki: DokuWiki
> * Sonstiges: Vanilla 1.0.1
>
> Wird der PHP-Entwickler überflüssig werden?

Der PHP-Entwickler wird sich immer auf dem neuesten Stand der
PHP-Entwicklung/Technik mit neuen Versionen halten und seinen Kunden
Individualität anpreisen müssen.

HTML ist auch nicht tot, sondern wurde XHTML.
C ebenso wenig, sondern es kam C++/C#.
Und auch JavaScript erstand von neu durch Ajax.

mfg,
Ricardo

Re: Web 2.0

Ricardo Wickel wrote:

> HTML ist auch nicht tot, sondern wurde XHTML.
> C ebenso wenig, sondern es kam C++/C#.

C# hat mit C bitte was zu tun?

Aber fang jetzt nicht damit an das in beiden der Buchstabe C vorkommt. ;-)

MfG, Ulf

Re: Web 2.0

Am Tue, 26 Sep 2006 14:48:06 +0200 schrieb Torsten Zühlsdorff:

>> Nein, aber umgekehrt ists in python schon:
>> a = ['eins', 'zwei']
>> isinstance(a, object)
>> # returns True
>>
>> isinstance(a, array)
>> ist natürlich auch True, weil array eine erweiterung von objekt ist.
>
> Nein, in dem Fall wäre Array ein Object. Genauso wie in Java
> Zeichenketten ein Objekt vom Typ String sind.

Ok, ich denke hier haben wir aneinander vorbeigeredet. In (new style)
python definiert man neue klassen am besten immer indem man vom build in
object ableitet:

class foo(object):

natürlich kann man das "(object)" weglassen, dafür sollte man aber dann
spezielle Gründe haben.

offensichtlich ist eine Liste (kann man nicht so richtig mit einem Array
vergleichen, aber naja, in der Anwendung ists häufig ähnlich) vom typ
object abgeleitet.

Anders ausgedrückt:

wenn isinstance(foo, array) True ist, so ist isinstance(foo, object) immer
True, während umgekehrt, wenn isinstance(bar, object) True ist, kann
isinstance(bar, array) true oder false sein.

Strings in python sind auch immer objekte, ebenso integers, floats, etc.
etc. Python ist halt extrem objektorientiert.

>> Zeit mir also ein Paket, das ganz ohne statische Strings (meist
>> Fehlermeldungen) auskommt.
>
> Ungefähr alles was ich im letztes Jahr geschrieben haben.
> Ja, da gibt es auch Fehlermeldungen.
> Nein, die stehen nicht im Code.

Jetzt machst du mich neugierig. Wo schreibst du die strings denn hin?

> Du liest Unsinn. Solcherlei grundlegende Dinge sollte man beherrschen.
> Schließlich wird deine Aktion zu erst ausgeführt und dann ihr Ergebnis
> der Variable "parts" zugewiesen. Und jetzt darfst du gerne sagen, ob die
> Variable links oder rechts steht und ob ihr erst der Wert zugewiesen
> wird oder erst die Operation ausgeführt wird.

Immer dies i-tüpfchen reiterei....

Martin

Re: Web 2.0

Am Tue, 26 Sep 2006 14:53:16 +0200 schrieb Alex Hepp:

> also, ich versuche jetzt nicht, Dir sämtliche Paradigmen zu erläutern,
> nur soviel: 1. Der Vorteil von getter Methoden ist, dass man noch
> Berechnungen, oder was weiss ich was einbauen kann, was aber für den
> "Benutzer", sprich in diesem Fall den Designer vollkommen transparent
> ist!

Naja, wenn man das möchte... das ist bei mir eher selten, dass ich das
explizit brauche.

Mir gefällt das so auch ziemlich gut:

def foo(object):
def _set_myvar(self, value):
# hier werden die berechnungen durchgeführt.
# z.B. verwendete ich das zuletzt um ein x-belibiges datum
# in eine einheitsform zu verwandeln.
self._myvar = value
def _get_myvar(self):
# auch hier kann ich berechnungen etc. durchführen
return self._myvar

myvar = property(_get_myvar, set_myvar)

Fertig.

bar = foo()
bar.myvar = "hallo"
# führt also jetzt _set_myvar() mit value="hallo" aus.

usw. usf.

Martin

Re: Web 2.0

Martin Kaffanke schrieb:
> Am Tue, 26 Sep 2006 14:53:16 +0200 schrieb Alex Hepp:
> bar = foo()
> bar.myvar = "hallo"
> # führt also jetzt _set_myvar() mit value="hallo" aus.

und wo ist nun der Unterschied zu

$obj->myvar = 'foo';

> usw. usf.

Ich hab mir alles durchgelesen und mir schwant, daß du keinen blassen
Dunst von PHP hast. Warum du dich dann zu solchen Trollpostings, wie man
sie eigentlich nur aus dem Heise.de-Forum kennt, hergibst verstehe wer will.

gruß, Frank

Re: Web 2.0

Am Tue, 26 Sep 2006 14:38:13 +0200 schrieb Alex Hepp:

> Wie ist das denn in Python (kenn mich da nich aus), liefern
> _alle_ Methoden ein "Objekt" zurück, auf dem weitergearbeitet werden
> kann, oder gibt es auch Methoden, die auf dem "Objekt" selbst arbeiten,
> und zb. nur false od. true zurückliefern?

Natürlich gibts auch inline methoden z.B. bei einer Liste mylist.sort()
usw. Ich habs aber gerade getestet, auch ein Boolean ist ein Objekt. Kann
daher auch einfach nach int umgewandelt werden.

b = True
print int(b)
# liefert 1
print str(b)
# liefert 'True' (als string natürlich)

> Wer macht sowas??? Was ist der Sinn ausser zu debuggen? Thorsten hats
> dir ja erklärt!

Och, das kommt hier immer wieder mal vor.

Ich mag auch:

b = [dict(i['id'], i['name']) for i in a]

in php sprache macht aus a:

$a[0]['id'] = 2
$a[0]['name'] = "Walter"
$a[1]['id'] = 5
$a[1]['name'] = "Hubert"

das Dictionary:

$b[2] = "Walter"
$b[5] = "Hubert"

in nur einem Statement. Hab ich in php noch nicht so kurz hingekriegt.
Aber vielleicht geht das ja auch irgendwie? Anwendungsfall ist bei mir,
wenn ich eine DB habe, in der ich ID's zu Aufzählungen zuordnen möchte.

> Sei mal ehrlich: Du hast grundsätzlich überhaupt keine Ahnung, und
> wolltest nur einfach mal Blödsinn verzapfen? Kann das sein?

*gg* Nein. Ich habe nur vergessen die PHP group abzumelden, und
blöderweise mal wieder reingefallen.

Die diskussion ist doch eigentlich die Selbe wie zwischen Religionen (ist
ja e grad recht aktuell). Jeder meint das seine wäre besser. ;-)

Und ... mir machts grad Spaß.

lg,
Martin

Re: Web 2.0

On Tue, 26 Sep 2006 19:24:25 +0200, Ulf Kadner wrote:

> Ricardo Wickel wrote:
>
>> HTML ist auch nicht tot, sondern wurde XHTML.
>> C ebenso wenig, sondern es kam C++/C#.
>
> C# hat mit C bitte was zu tun?
>
> Aber fang jetzt nicht damit an das in beiden der Buchstabe C vorkommt. ;-)

Dann gälte nämlich auch COBOL.

Gruß,
Matthias

Re: Web 2.0

On Tue, 26 Sep 2006 20:45:08 +0200 Martin Kaffanke wrote:
> b = [dict(i['id'], i['name']) for i in a]

> Hab ich in php noch nicht so kurz hingekriegt. Aber vielleicht geht
> das ja auch irgendwie?

Entspricht in Laenge und Funktionalitaet ganz gut

| foreach($a as $v) $b[$v['id']] = $v['name'];

Rein persoenlich halte ich letzteres fuer lesbarer, aber das hat
wohl mehr mit der Erfahrung in einer bestimmten Sprache zu tun,
als mit sonstwas.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich

Sinnen mit Stefan - massgeblich werden mit Lachen.
(Sloganizer)

Re: Web 2.0

Martin Kaffanke schrieb:
> Am Tue, 26 Sep 2006 14:53:16 +0200 schrieb Alex Hepp:
>
>> also, ich versuche jetzt nicht, Dir sämtliche Paradigmen zu erläutern,
>> nur soviel: 1. Der Vorteil von getter Methoden ist, dass man noch
>> Berechnungen, oder was weiss ich was einbauen kann, was aber für den
>> "Benutzer", sprich in diesem Fall den Designer vollkommen transparent
>> ist!

> Mir gefällt das so auch ziemlich gut:

> def foo(object):
> def _set_myvar(self, value):
> # hier werden die berechnungen durchgeführt.
> # z.B. verwendete ich das zuletzt um ein x-belibiges datum
> # in eine einheitsform zu verwandeln.
> self._myvar = value
> def _get_myvar(self):
> # auch hier kann ich berechnungen etc. durchführen
> return self._myvar
>
> myvar = property(_get_myvar, set_myvar)

Ja, Getter und Setter kennt PHP seit Version 5.0 auch, nur das sie etwas
anders implementiert sind.

class foo {
public function __get($property) {
return @$this->properties[$property];
}

public function __set($property, $value) {
$this->properties[$property] = $value;
}
}

Das funktioniert allerdings nur mit Einschränkungen. Das Verhalten, das
du von Python kennst kannst du auch simulieren, wenn du die __get() und
__set() Methoden entsprechend modifizierst.

class foo {
private $myvar;

public function __get($property) {
if(!method_exists($this, 'get' . $property)) {
throw new Exception('No such method.');
}

return call_user_func(array($this, 'get' . $property));
}

public function __set($property, $value) {
if(!method_exists($this, 'set' . $property)) {
throw new Exception('No such method.');
}

call_user_func(array($this, 'set' . $property), $value);
}

public function getMyVar() {
return $this->myvar;
}

public function setMyVar($value) {
$this->myvar = $value;
}
}

> bar = foo()
> bar.myvar = "hallo"

$bar = new foo;
$bar->myvar = "hallo";

Re: Web 2.0

Martin Kaffanke schrieb:
> Am Tue, 26 Sep 2006 12:09:28 +0200 schrieb Torsten Zühlsdorff:

>> Und deinen letzten Satz verstehe ich nicht. Tippfehler?

> In python kann ich verschieden klassen definieren. Diese dann
> instanziieren, also objekte. In den klassen kann ich definieren was
> passieren soll, wenn z.b. zwei objekte einer klasse gegeneinander getestet
> werden, oder werte zugewiesen werden, ...

> class Foo:
> whatever...

> a = Foo()
> b = Foo()
> a['ein'] = "string" # in python kenne ich diese schreibeweise nur
> # bei assoziativen arrays, nicht bei objekten.

Meinst du in deinem Kommentar PHP statt Python? Du kannst in PHP5 die
Schnittstelle ArrayAccess implementieren und dann dein Objekt wie ein
normales Array verwenden.

class MyArray implements ArrayAccess {
private $array = array();

public function offsetExists($offset) {
return array_key_exists($this->array, $offset);
}

public function offsetGet($offset) {
return $this->array[$offset];
}

public function offsetSet($offset, $value) {
if (is_null($offset)) {
$this->array[] = $value;
} else {
$this->array[$offset] = $value;
}
}

public function offsetUnset($offset) {
unset($this->array[$offset]);
}
}

$test = new MyArray;

$test['a'] = 'Hello';
$test['b'] = ' World!';

print $test['a'] . $test['b'];

> if a == b:
> dosomething

Eine Möglichkeit Operatoren zu Überladen wird es in PHP vorerst nicht
geben. Auch eine __equals()-Methode oder ähnliches nicht.



> for i in b: # python: foreach()
> print i

Du kannst dafür die IteratorAggregate Schnittstelle implementieren:

class StringIterator implements Iterator {
private $string;
private $position;

public function __construct($string) {
$this->string = explode(' ', $string);
}

public function rewind() {
$this->position = 0;
}

public function valid() {
return $this->position < sizeof($this->string);
}

public function key() {
return $this->position;
}

public function current() {
return $this->string[$this->position];
}

public function next() {
$this->position++;
}
}

class String implements IteratorAggregate {
private $string;

public function __construct($string = '') {
$this->string = $string;
}

public function getIterator() {
return new StringIterator($this->string);
}
}

$string = new String('Dies ist ein String.');

foreach ($string as $key => $value) {
print $value . ' ';
}
?>

Alternativ kannst du (je nach Komplexität des Objektes) auch einfach das
Objekt zu einem Array casten und dann über das Array iterieren.

$obj = new stdClass;
$obj->a = "foo";
$obj->b = "bar";

foreach((array) $obj as $k => $v) {
print "$k => $v\n";
}
?>

> Naja, vielleicht geht das ja auch bereits in php, ich habe die 5.0er
> Entwicklung nicht mehr mitgemacht, habe bereits in python entwickelt.

Wie du siehst, geht da eine ganze Menge.

>> Natürlich kann man sogar MP3-Player damit erstellen, aber das ist nicht
>> sinnvoll.

> Angenommen ich habe eine Webseite, bei der Sich user anmelden können.
> Diese möchte ich dann gerne offline Administrieren, ... ist das dann eine
> Webapplikation oder nicht? PHP sinnvoll?

Nein, PHP nicht sinnvoll. Du kannst zwar mit PHP-GTK theoretisch GUIs
basteln, aber das ist eher Spielerei. Dein Szenario spricht aber nicht
gegen PHP auf dem Webserver.

> Schneller ists ohnehin, weil die Verbindung
> zwischen den Seiten nicht geschlossen wird.

Von welchen Seiten sprichst du? Wenn du Datenbankverbindungen zwischen
verschiedenen Requests meinst: bei MySQL spielt das kaum eine Rolle und
für andere RDBMS gibt es Proxies, die die Verbindung zum Server aufrecht
erhalten.

Re: Web 2.0

Matthias Esken schrieb:
> On Tue, 26 Sep 2006 19:24:25 +0200, Ulf Kadner wrote:
>> Ricardo Wickel wrote:
>>
>>> HTML ist auch nicht tot, sondern wurde XHTML.
>>> C ebenso wenig, sondern es kam C++/C#.
>>
>> C# hat mit C bitte was zu tun?
>>
>> Aber fang jetzt nicht damit an das in beiden der Buchstabe C vorkommt.=
;-)
>=20
> Dann gälte nämlich auch COBOL.

Und BASI_C_!

SCNR
Niels, der tatsächlich in 'B' programmiert hat

--=20
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------

Re: Web 2.0

Martin Kaffanke schrieb:
> Am Tue, 26 Sep 2006 14:38:13 +0200 schrieb Alex Hepp:

> Die diskussion ist doch eigentlich die Selbe wie zwischen Religionen (ist
> ja e grad recht aktuell). Jeder meint das seine wäre besser. ;-)

Die Selbe Diskussion zwischen Religionen und Programmiersprachen? das
würde mich mit den doch _leicht_ unterschiedlichen Argumentationen stark
verwundern. Es sei denn, man "betet" einfach argumentfrei sein "Meine
ist besser" runter! Es könnte vielleicht eine ähnliche Diskussion sein,
vielleicht noch die Gleiche, aber die Selbe sicher nicht! Soviel zu den
Korinthen für heute! ;)

Weiterhin versucht hier keiner, php als bessere Sprache zu verkaufen,
sondern nur Deine Argumente für "PHP hat ausgedient!" zu entkräften...

Ich hab mir python noch nie angeschaut, daher maße ich mir nicht an, das
diskutieren zu können, mir scheint einfach nur, dass Du Dich ebensowenig
mit PHP beschäftigt hast, um das tun zu können!

Ausserdem glaube ich auch, dass Dir Grundlegendes fehlt, wie zb. das
Wissen um tatsächliche Objektorientierung! Aber gut, das führt jetzt zu
weit!

> Und ... mir machts grad Spaß.

Freut mich! ;)

gruß Alex

Re: Web 2.0

Frank Schenk schrieb:
> Martin Kaffanke schrieb:
>> Am Tue, 26 Sep 2006 14:53:16 +0200 schrieb Alex Hepp:
>> bar = foo()
>> bar.myvar = "hallo"
>> # führt also jetzt _set_myvar() mit value="hallo" aus.

Aber python ist strikt objektorientiert??? Ich verstehe ;) Mir ist
allerdings lieber, wenn ich tatsächlich sehe, dass eine setter Methode
ausgeführt wird, als dass es so aussieht, als hätte ich ein public
attribut, auf dass ich direkt zugreife! Automatische Wandlungen von
Zuweisungen in Methodenaufrufe gefällt mir generell nicht sonderlich gut!

> und wo ist nun der Unterschied zu
>
> $obj->myvar = 'foo';
>
>> usw. usf.
>
> Ich hab mir alles durchgelesen und mir schwant, daß du keinen blassen
> Dunst von PHP hast. Warum du dich dann zu solchen Trollpostings, wie man
> sie eigentlich nur aus dem Heise.de-Forum kennt, hergibst verstehe wer
> will.

Mir schwant noch ganz anderes ;)

gruß Alex

Re: Web 2.0

Niels Braczek schrieb:
> Matthias Esken schrieb:
>> On Tue, 26 Sep 2006 19:24:25 +0200, Ulf Kadner wrote:
>>> Ricardo Wickel wrote:
>>>
>>>> HTML ist auch nicht tot, sondern wurde XHTML.
>>>> C ebenso wenig, sondern es kam C++/C#.
>>> C# hat mit C bitte was zu tun?
>>>
>>> Aber fang jetzt nicht damit an das in beiden der Buchstabe C vorkommt. ;-)
>> Dann gälte nämlich auch COBOL.
>
> Und BASI_C_!
>
> SCNR
> Niels, der tatsächlich in 'B' programmiert hat
>
und PAS_C_AL

Alex, der ebenso tatsächlich mal in Basic, als auch in Pascal
programmiert hat ;)

Re: Web 2.0

Martin Kaffanke schrieb:

> Strings in python sind auch immer objekte, ebenso integers, floats, etc.
> etc. Python ist halt extrem objektorientiert.

Das nervt schon an Java. Es gibt mehr als OOP. Das schöne an PHP ist,
dass man nicht auf ein Paradigmum beschränkt ist.

>>>Zeit mir also ein Paket, das ganz ohne statische Strings (meist
>>>Fehlermeldungen) auskommt.
>>
>>Ungefähr alles was ich im letztes Jahr geschrieben haben.
>>Ja, da gibt es auch Fehlermeldungen.
>>Nein, die stehen nicht im Code.
>
> Jetzt machst du mich neugierig. Wo schreibst du die strings denn hin?

In eine Datei, die keinen Code enthält?
Genauso wie Konfigurationen?

>>Du liest Unsinn. Solcherlei grundlegende Dinge sollte man beherrschen.
>>Schließlich wird deine Aktion zu erst ausgeführt und dann ihr Ergebnis
>>der Variable "parts" zugewiesen. Und jetzt darfst du gerne sagen, ob die
>>Variable links oder rechts steht und ob ihr erst der Wert zugewiesen
>>wird oder erst die Operation ausgeführt wird.
>
> Immer dies i-tüpfchen reiterei....

Du redest Unsinn. Soetwas ist von entscheidender Bedeutung. Wenn du mal
C programmiert hast, wirst du das spätestens feststellen, wenn plötzlich
ein * auf ein & trifft und auf aufgrund ihrer Wertung und der
Leserichtung weitere Entscheidungen treffen mußt. Bei Scriptsprachen mit
dieses Gemischlese wirkt sich das äußert ungünstig auf die Lesbarkeit
aus, aber natürlich kann man sich daran gewöhnen...

Gruß,
Torsten

Re: Web 2.0

Alex Hepp schrieb:

>>>>> HTML ist auch nicht tot, sondern wurde XHTML.
>>>>> C ebenso wenig, sondern es kam C++/C#.
>>>>
>>>> C# hat mit C bitte was zu tun?
>>>>
>>>> Aber fang jetzt nicht damit an das in beiden der Buchstabe C
>>>> vorkommt. ;-)
>>>
>>> Dann gälte nämlich auch COBOL.
>>
>>
>> Und BASI_C_!
>>
>> SCNR
>> Niels, der tatsächlich in 'B' programmiert hat
>>
> und PAS_C_AL
>
> Alex, der ebenso tatsächlich mal in Basic, als auch in Pascal
> programmiert hat ;)

Denk doch mal einer an _C_ecil :P

Gruß,
Torsten

Re: Web 2.0

On Wed, 27 Sep 2006 09:56:17 +0200 Torsten Zühlsdorff wrote:
> >>Ja, da gibt es auch Fehlermeldungen.
> >>Nein, die stehen nicht im Code.

> > Jetzt machst du mich neugierig. Wo schreibst du die strings
> > denn hin?

> In eine Datei, die keinen Code enthält?
> Genauso wie Konfigurationen?

Und wie bewaehrt sich das in der Praxis? Ich habe da gerade ein
System in Arbeit, das rund 4.000 unterschiedliche Fehlermeldungen
verwendet. Zur Zeit stehen die jeweils an Ort und Stelle im Code,
was unangenehm ist. Ein Auslagern in getrennte Dateien fuehrt
allerdings zu einer Flut von Konstanten, was dann zwar eleganter,
aber IMHO noch unuebersichtlicher fuer den Autor ist.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich

Rollen ist unser gemeinsamer Traum. Stefan, so stramm wie die Welt.
(Sloganizer)

Re: Web 2.0

"Torsten Zühlsdorff" schrieb im Newsbeitrag
news:451a2fc4$0$5144$9b4e6d93@newsspool1.arcor-online.net...
> Alex Hepp schrieb:
>
>>>>>> HTML ist auch nicht tot, sondern wurde XHTML.
>>>>>> C ebenso wenig, sondern es kam C++/C#.
>>>>>
>>>>> C# hat mit C bitte was zu tun?
>>>>>
>>>>> Aber fang jetzt nicht damit an das in beiden der Buchstabe C
>>>>> vorkommt. ;-)
>>>>
>>>> Dann gälte nämlich auch COBOL.
>>>
>>>
>>> Und BASI_C_!
>>>
>>> SCNR
>>> Niels, der tatsächlich in 'B' programmiert hat
>>>
>> und PAS_C_AL
>>
>> Alex, der ebenso tatsächlich mal in Basic, als auch in Pascal
>> programmiert hat ;)
>
> Denk doch mal einer an _C_ecil :P

Hallo? Ihr habt die wichtigste wiedereinmal einfach vergessen:
PHP: Hypertext Prepro_c_essor

Gott zum Gruße
Bas

Re: Web 2.0

Torsten Zühlsdorff schrieb:

> Das nervt schon an Java. Es gibt mehr als OOP. Das schöne an PHP ist,
> dass man nicht auf ein Paradigmum beschränkt ist.

Paradigmum?

Paradigma - Paradigmen

Paradigmum - Paradigmumien?

In Java hat man Paradigmen, in PHP Paradigmusen. Wer mit Paradigmen
programmieren will, der darf nicht PHP nehmen.

Grüße, Matthias

Re: Web 2.0

Stefan Froehlich schrieb:

>>>>Ja, da gibt es auch Fehlermeldungen.
>>>>Nein, die stehen nicht im Code.
>
>>>Jetzt machst du mich neugierig. Wo schreibst du die strings
>>>denn hin?
>
>>In eine Datei, die keinen Code enthält?
>>Genauso wie Konfigurationen?
>
> Und wie bewaehrt sich das in der Praxis?

Sehr gut.

> Ich habe da gerade ein
> System in Arbeit, das rund 4.000 unterschiedliche Fehlermeldungen
> verwendet. Zur Zeit stehen die jeweils an Ort und Stelle im Code,
> was unangenehm ist. Ein Auslagern in getrennte Dateien fuehrt
> allerdings zu einer Flut von Konstanten, was dann zwar eleganter,
> aber IMHO noch unuebersichtlicher fuer den Autor ist.

Warum soll das unübersichtlicher sein?

Wie gibst du wo die Fehlermeldungen aus? Was sind das für
Fehlermeldungen? Kann man diese Fehlermeldungen z.b. automatisiert aus
dem Programmfluß ableiten? Helfen Konstrukte wie personalisierte
Exceptions oder Observer?

Gruß,
Torsten

Re: Web 2.0

Stefan Froehlich wrote:

> System in Arbeit, das rund 4.000 unterschiedliche Fehlermeldungen
> verwendet. Zur Zeit stehen die jeweils an Ort und Stelle im Code,
> was unangenehm ist.

Mehr als das. Es ist schlecht wartbar!

> Ein Auslagern in getrennte Dateien fuehrt
> allerdings zu einer Flut von Konstanten, was dann zwar eleganter,
> aber IMHO noch unuebersichtlicher fuer den Autor ist.

Das ist Deine subjektive Wahrnehmung!
Aber es gibt zum Glück auch Alternativen. Schreib Dir ne Konfigklasse
als Singleton, die bei Initialisierung Daten aus z.B. einer INI-Datei
einliest in intern behandelt. Das macht wenig Arbeit und ist flexibel
und schnell.

MfG, Ulf

Re: Web 2.0

Matthias P. Wuerfl schrieb:

>> Das nervt schon an Java. Es gibt mehr als OOP. Das schöne an PHP ist,
>> dass man nicht auf ein Paradigmum beschränkt ist.
>
> Paradigmum?
>
> Paradigma - Paradigmen
>
> Paradigmum - Paradigmumien?
>
> In Java hat man Paradigmen, in PHP Paradigmusen. Wer mit Paradigmen
> programmieren will, der darf nicht PHP nehmen.

Man darf sich auch gar nicht mehr vertippen, ohne das irgendein
Scherzkeks seine lustigen Kommentare dazu abgibt.

Desweiteren ist die Aufzählung des korrekten Plurals unvollständig. Es
fehlt "Paradigmata".

Gruß,
Torsten

Re: Web 2.0

Sebastian Moderlak schrieb:

> Hallo? Ihr habt die wichtigste wiedereinmal einfach vergessen:
> PHP: Hypertext Prepro_c_essor

Ist das damit wieder OnTopic? ;-)

MfG
Niels

--=20
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------

Trennung von Programmlogik und Texten (was: Web 2.0)

Ich antworte einmal hierauf, aber das schliesst natuerlich auch die
Anmerkungen von Torsten mit ein.

On Wed, 27 Sep 2006 12:05:05 +0200 Ulf Kadner wrote:
> > System in Arbeit, das rund 4.000 unterschiedliche
> > Fehlermeldungen verwendet. Zur Zeit stehen die jeweils an Ort
> > und Stelle im Code, was unangenehm ist.

> Mehr als das. Es ist schlecht wartbar!

Jein. Es hat zweifellos den Nachteil, dass (programmlogisch) weit
entfernte, aber textlich idente Fehlermeldungen (typisch "Datei
nicht gefunden" oder aehnliches) nicht immer und nicht erzwungen den
gleichen Text verwenden.

Es ist aber insofern besser wartbar, weil bei unmittelbar bei der
Abfrage auch klar ist, womit darauf reagiert wird. Oder umgekehrt,
noch wichtiger, direkt bei Text auch der Kontext steht, fuer den er
gedacht ist.

Verwende ich ein Konstrukt wie:

| if ($testA) $errors[] = error_const_1;
| elseif ($testB) $errors[] = error_const_2;
|
| if ($testC) $errors[] = error_const_3;
| elseif ($testD) $errors[] = error_const_4;

....laesst das im Lauf der Zeit eine Menge Moeglichkeiten fuer
Inkonsistenzen. Programme veraendern sich bzw. wachsen, ich habe
nirgendwo eine abgeschlossene Liste mit Meldungen, sondern es kommen
laufend neue hinzu, bzw. aendern sich gelegentlich bestehende.

> > Ein Auslagern in getrennte Dateien fuehrt allerdings zu einer
> > Flut von Konstanten, was dann zwar eleganter, aber IMHO noch
> > unuebersichtlicher fuer den Autor ist.

> Das ist Deine subjektive Wahrnehmung!

Da ich - und nur ich - der Autor bin, ist diese aber bezueglich der
Unuebersichtlichkeit entscheidend :-). Mein Leidensdruck ist auch
nicht besonders gross, lediglich die oben erwaehnten, gelegentlichen
sprachlichen Inkonsistenzen der Meldungen stoeren mich etwas.

> Schreib Dir ne Konfigklasse als Singleton, die bei Initialisierung
> Daten aus z.B. einer INI-Datei einliest in intern behandelt. Das
> macht wenig Arbeit und ist flexibel und schnell.

So etwas habe ich fuer die Programmkonfiguration, das ist
quadratisch, praktisch und gut. Da handelt es sich aber auch nur
um einige Dutzend Werte, die alle mit Konstanten sinnvoll und
systematisch benennbar sind.

Ad Torsten: der Grossteil der Meldungen stammt entweder aus
$_REQUEST, oder aus der Bearbeitung externer Datentraeger (primaer
CSV, XML). Der erste Typ wird je Programm in einer eigenen
Pruefroutine erzeugt, der zweite Typ ergibt sich sehr
unterschiedlich im Lauf der Dateibearbeitung. Natuerlich liesse sich
das eine oder andere davon automatisiert erstellen (wird bei
Gelegenheit auch immer wieder gemacht), dennoch bleiben mir
zu viele Faelle, wo das nicht geht. Z.B.

| $errors['DateOpen'] = _('Das Öffnungsdatum darf nicht vor dem Ende der Anbotsfrist liegen.');

....taucht halt genau dort und genau einmal auf, nirgendwo sonst.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich

Stefan - das zerrissenste Geschenk, welches es je geben wird.
(Sloganizer)

Re: Web 2.0

Niels Braczek schrieb:

> Ist das damit wieder OnTopic? ;-)

Klar: OnTopi_C_

Grüße, Matthias

--
http://www.trullala.de
--
Der Trend geht ganz eindeutig zur Zweitsignatur.

Re: Web 2.0

Ulf Kadner schrieb:
> Ricardo Wickel wrote:
>
>> HTML ist auch nicht tot, sondern wurde XHTML.
>> C ebenso wenig, sondern es kam C++/C#.
>
> C# hat mit C bitte was zu tun?
>
> Aber fang jetzt nicht damit an das in beiden der Buchstabe C vorkommt. ;-)
>
> MfG, Ulf

"C# baut auf C++ auf, daher wird sich jeder C++-Programmierer schnell in
dieser Sprache wohl fühlen." [1]

mfg,
Ricardo

--
[1] : http://www.galileocomputing.de/openbook/csharp/intro.htm#t2t 35

Re: Trennung von Programmlogik und Texten

Stefan Froehlich schrieb:
> Ich antworte einmal hierauf, aber das schliesst natuerlich auch die
> Anmerkungen von Torsten mit ein.
>
> On Wed, 27 Sep 2006 12:05:05 +0200 Ulf Kadner wrote:
>
>>>System in Arbeit, das rund 4.000 unterschiedliche
>>>Fehlermeldungen verwendet. Zur Zeit stehen die jeweils an Ort
>>>und Stelle im Code, was unangenehm ist.
>
>>Mehr als das. Es ist schlecht wartbar!
>
> Jein. Es hat zweifellos den Nachteil, dass (programmlogisch) weit
> entfernte, aber textlich idente Fehlermeldungen (typisch "Datei
> nicht gefunden" oder aehnliches) nicht immer und nicht erzwungen den
> gleichen Text verwenden.
>
> Es ist aber insofern besser wartbar, weil bei unmittelbar bei der
> Abfrage auch klar ist, womit darauf reagiert wird. Oder umgekehrt,
> noch wichtiger, direkt bei Text auch der Kontext steht, fuer den er
> gedacht ist.

Da verfolgst du einen falschen Ansatz: Aus der Bedingungsabfrage muß
eindeutig hervorgehen, was passiert und erwartet wird. Dabei wird aber
häufig falsch formuliert. Gängig (und ungünstig) ist die Überprüfung, ob
der Fehlerfall eingetreten ist. Besser, wartbarer und korrekter ist aber
die Überprüfung, ob der Erfolgsfall nicht eingetreten ist.

Einfache Beispiele:

$resDir = opendir('directory');

Falsch:
if(!$resDir)

Richtig:
if(!is_resource($resDir))

Erklärung:
1. Du kannst an der Variable $resDir bereits ablesen, dass erwartet
wird, dass sie eine Resource als Wert erhält. Daher das 'res'.
Nomenklaturen sind außerordentlich wichtig.
2. Im falschen Beispiel überprüfst du, ob $resDir 'false' ist, da
opendir im Fehlerfall ein 'false' zurückliefert. Würdest du aber
zusätzlich noch auf die Nomenklatur verzichten, müßtest du erst im
Handbuch nachschlagen, welcher Wert im korrekten Fall erwartet wird.
Unter 'Richtig' wird überprüft, ob der Wert der Variable keine Resource
ist. Daraus geht hervor, dass eine Resource verlangt wird und das es
keine gibt.
Fehler werfen. Fertig.

Desweiteren vergißt du, dass Fehlermeldung durchaus mehrsprachig sein
können müssen oder Fehler zwar auftreten können, aber nicht den
Programmfluß beenden, so dass andere Teile der Applikation auf den
Fehler reagieren können. Bei mir ist es daher häufig so, dass ich
schlicht einen Fehlercode (setzt sich nach einem Schema zusammen) an die
Fehlerbehandlung übergebe und die macht den Rest. Richtige Datei parsen,
Sprachunterscheidung, andere Programmteile benachrichtigen,
Fehlermeldung ausgeben und gut.

>>>Ein Auslagern in getrennte Dateien fuehrt allerdings zu einer
>>>Flut von Konstanten, was dann zwar eleganter, aber IMHO noch
>>>unuebersichtlicher fuer den Autor ist.
>
>>Das ist Deine subjektive Wahrnehmung!
>
> Da ich - und nur ich - der Autor bin, ist diese aber bezueglich der
> Unuebersichtlichkeit entscheidend :-). Mein Leidensdruck ist auch
> nicht besonders gross, lediglich die oben erwaehnten, gelegentlichen
> sprachlichen Inkonsistenzen der Meldungen stoeren mich etwas.

Egoist :P

> Ad Torsten: der Grossteil der Meldungen stammt entweder aus
> $_REQUEST, oder aus der Bearbeitung externer Datentraeger (primaer
> CSV, XML).

Anstelle von $_REQUEST sollte man die korrekten Superglobalen verwenden.

> | $errors['DateOpen'] = _('Das Öffnungsdatum darf nicht vor dem Ende der Anbotsfrist liegen.');

Ich hoffe für dich, dass $errors nicht global ist!

Gruß,
Torsten

Re: [OT]Web 2.0

Ricardo Wickel wrote:

> "C# baut auf C++ auf, daher wird sich jeder C++-Programmierer schnell in
> dieser Sprache wohl fühlen." [1]

Das ist falsch! C# baut auf dem Net-Framework von MS auf, welches
wiederum größtenteils auf der WindowsAPI arbeitet. Diese ist zwar in C
und C++ geschrieben aber das wars auch schon.
C# unterscheidet sich bereits drastisch in seiner Arbeitsweise von C++

Nur ein Bsp. Ohne dotNET-Framework ist C# unmöglich nutzbar. C++ braucht
das nicht.

Ansonsten muestest Du auch sagen, das die neueren VB, J# usw. versionen
auch auf C++ aufbauen und einem C++ Programmierer z schnellen wohlfühlen
in der Sprache bewegen. Das wage ich ernsthaft zu bezweifeln.

Auch Delphi arbeitet in vielen Bereichen mit der Windows-Api. Auch hier
gilt Deine These nicht!

C++ hat wirklich nix mit C# gemein was C# nicht auch mit anderen
Sprachen gemein hat.

> [1] : http://www.galileocomputing.de/openbook/csharp/intro.htm#t2t 35

Diese Aussage wurde im Web schon zu genüge diskutiert und als falsch
definiert.

C# ist eine von Grund auf neu gestaltet Sprache mit Modernen
Eigenschaften. Selbiges kann man z.B. nicht immer von C++ sagen. C++
unterscheidet sich Syntaktisch sehr stark von C#.
Es sei denn Du redest von der MS C++ Version die man im VS bearbeiten
kann. Aber die hat mit dem eigentlichen C++ nicht mehr viel zu tun bzw
die eigentliche C++ Version ist nur ein kleine Teilmenge dessen.

MfG, Ulf

Re: [OT]Web 2.0

Ulf Kadner schrieb:

> C# ist eine von Grund auf neu gestaltet Sprache mit Modernen
> Eigenschaften.

Könntest du mir eine Liste der modernen Eigenschaften zukommen lassen?
Ich überlege schon seid langen, mit welcher Sprache ich mich bald mal
wieder beschäftigen sollte oder ob ich nicht lieber selbst eine
entwerfen sollte.

Gruß,
Torsten

Re: [OT]Web 2.0

Torsten Zuehlsdorff wrote:

>>C# ist eine von Grund auf neu gestaltet Sprache mit Modernen
>>Eigenschaften.
>
> Könntest du mir eine Liste der modernen Eigenschaften zukommen lassen?

Hallo Thorsten!
^:-)

Hast Du wohl das Smiley zu Deiner Frage vergessen?

Wenn nicht... Es gibt genügend Dokumentationen zu C# Warum sollte ich
mir die Arbeit machen die alle abzutippen bzw. darüber nachzusinnen? :-)
Ic hab hier einige freie Bücher zu C# als PDF, die kann ich Dir gerne
schicken.

> Ich überlege schon seid langen, mit welcher Sprache ich mich bald mal
> wieder beschäftigen sollte oder ob ich nicht lieber selbst eine
> entwerfen sollte.

Na letzteres kann man wohl nur in ein paar Jahrzehnten umsetzen wenn
mans allein oder zu zweit angeht.

MfG, Ulf

Re: [OT]Web 2.0

Ulf Kadner schrieb:

>>> C# ist eine von Grund auf neu gestaltet Sprache mit Modernen
>>> Eigenschaften.
>>
>> Könntest du mir eine Liste der modernen Eigenschaften zukommen lassen?
>
> Hallo Thorsten!
> ^:-)

:P

> Hast Du wohl das Smiley zu Deiner Frage vergessen?

Nein ;) Aber nachdem heute morgen mein Usenetzugang spontan gesperrt war
und ich die Geschichten des "Bastard Operators of Hell" gelesen habe,
dachte ich mir, dass ich keine Zeit mehr zum Googlen habe :P

> Wenn nicht... Es gibt genügend Dokumentationen zu C# Warum sollte ich
> mir die Arbeit machen die alle abzutippen bzw. darüber nachzusinnen? :-)
> Ic hab hier einige freie Bücher zu C# als PDF, die kann ich Dir gerne
> schicken.

Ein Buch mit kurzen Überblick würde mir reichen - vielen herzlichen Dank :)

>> Ich überlege schon seid langen, mit welcher Sprache ich mich bald mal
>> wieder beschäftigen sollte oder ob ich nicht lieber selbst eine
>> entwerfen sollte.
>
> Na letzteres kann man wohl nur in ein paar Jahrzehnten umsetzen wenn
> mans allein oder zu zweit angeht.

Warum? Yacc und Bison ermöglichen die grundlegende Arbeit in relativ
kurzer Zeit. Möglich wären auch Sprachen wie LISP oder ähnliche zu
verwenden und so die Portierung abzukürzen.
Ich habe auch schon Sprachimplementierungen in 500 Zeilen gesehen. :)

Gruß,
Torsten

Re: [OT]Web 2.0

Torsten Zuehlsdorff wrote:

> Ulf Kadner schrieb:
>>Hast Du wohl das Smiley zu Deiner Frage vergessen?
>
> Nein ;)

Du verwirrst mich! :-)

> Aber nachdem heute morgen mein Usenetzugang spontan gesperrt war
> und ich die Geschichten des "Bastard Operators of Hell" gelesen habe,
> dachte ich mir, dass ich keine Zeit mehr zum Googlen habe :P

Hehe. Ich kenn die Geschichte nicht. Aber wenn keine Zeit mehr zum
Googlen ist werd ich wohl dumm sterben ;-)

> Ein Buch mit kurzen Überblick würde mir reichen - vielen herzlichen Dank :)

Sie haben Post... :-)

> Warum? Yacc und Bison ermöglichen die grundlegende Arbeit in relativ
> kurzer Zeit.

Ja aber... :-x Haste recht.

> Ich habe auch schon Sprachimplementierungen in 500 Zeilen gesehen. :)

Ich hab schon mal ne Katze aufm Surfbrett in 20-Fuss Wellen gesehen...

MfG, Ulf

Re: [OT]Web 2.0

Torsten Zuehlsdorff schrieb:
> Ulf Kadner schrieb:

>>> Ich überlege schon seid langen, mit welcher Sprache ich mich bald m=
al
>>> wieder beschäftigen sollte oder ob ich nicht lieber selbst eine
>>> entwerfen sollte.
>>=20
>> Na letzteres kann man wohl nur in ein paar Jahrzehnten umsetzen wenn
>> mans allein oder zu zweit angeht.

Hast du http://de.wikipedia.org/wiki/Brainfuck schon vergessen?

MfG
Niels

--=20
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------

Re: [OT]Web 2.0

Niels Braczek schrieb:
>>>>Ich überlege schon seid langen, mit welcher Sprache ich mich bald mal
>>>>wieder beschäftigen sollte oder ob ich nicht lieber selbst eine
>>>>entwerfen sollte.
>>>
>>>Na letzteres kann man wohl nur in ein paar Jahrzehnten umsetzen wenn
>>>mans allein oder zu zweit angeht.
>
> Hast du http://de.wikipedia.org/wiki/Brainfuck schon vergessen?

Ich dachte daher eher an:

http://ebiquity.umbc.edu/blogger/2005/10/30/lisp-in-500-line s-of-c/

Gruß,
Torsten

Re: Trennung von Programmlogik und Texten

On Thu, 28 Sep 2006 10:42:07 +0200 Torsten Zuehlsdorff wrote:
> > [Fehlermeldungen im Programmcode sind] insofern besser wartbar,
> > weil bei unmittelbar bei der Abfrage auch klar ist, womit darauf
> > reagiert wird. Oder umgekehrt, noch wichtiger, direkt bei Text
> > auch der Kontext steht, fuer den er gedacht ist.

> Da verfolgst du einen falschen Ansatz: Aus der Bedingungsabfrage
> muß eindeutig hervorgehen, was passiert und erwartet wird. Dabei
> wird aber häufig falsch formuliert. Gängig (und ungünstig) ist die
> Überprüfung, ob der Fehlerfall eingetreten ist. Besser, wartbarer
> und korrekter ist aber die Überprüfung, ob der Erfolgsfall nicht
> eingetreten ist.
>
> Einfache Beispiele:
>
> $resDir = opendir('directory');
>
> Falsch:
> if(!$resDir)
>
> Richtig:
> if(!is_resource($resDir))

Der Unterschied ist in meinen Augen zwar nicht uninteressant, aber
eher marginal, und hat vor allem mit dem Ort der Textmeldungen nicht
viel zu tun. Im wesentlichen mache ich das ohnehin so aehnlich, z.B.

| if (!is_readable($path_prefix . $_REQUEST['mediafile'])) {
| $errors['mediafile'] = _('Die Katalogdatei wurde nicht gefunden.');
| }
| else {
| [...weitere Pruefungen der Datei...]]
| }

Nun steht aber der Text immer noch beim Programm - und ein Auslagern
in eine externe Datei via unzaehliger Konstanten wird IMHO eben
unuebersichtlich. Man _koennte_ natuerlich einige Tests und Texte
auch vereinheitlichen, hier z.B. zu "Datei nicht gefunden", diese
etwas groessere Ausfuehrlichkeit in den Rueckmeldungen finde ich
aber angenehm fuer den Anwender.

> Desweiteren vergißt du, dass Fehlermeldung durchaus mehrsprachig
> sein können müssen

Die _sind_ mehrsprachig, dafuer habe ich ja gettext!

> oder Fehler zwar auftreten können, aber nicht den Programmfluß
> beenden, so dass andere Teile der Applikation auf den Fehler
> reagieren können.

Auch das ist hier der Fall. $errors wird typischerweise durch die
gesamte Pruefroutine geschleppt, danach geparkt, bis das Programm
getan hat, was es tun sollte und dann entweder ausgegeben oder in
einer Session zwischengeparkt (um nach einem Redirect angezeigt zu
werden).

> Bei mir ist es daher häufig so, dass ich schlicht einen Fehlercode
> (setzt sich nach einem Schema zusammen) an die Fehlerbehandlung
> übergebe und die macht den Rest. Richtige Datei parsen,
> Sprachunterscheidung, andere Programmteile benachrichtigen,
> Fehlermeldung ausgeben und gut.

Dann haettest Du oben also an der entscheidenen Stelle stehen:

| $errors['mediafile'] = err_file_notfound_media;

Hm. Damit bin ich wieder am Anfang meiner Ueberlegungen, genau das
gefaellt mir in der Menge eben nicht.

> > Ad Torsten: der Grossteil der Meldungen stammt entweder aus
> > $_REQUEST, oder aus der Bearbeitung externer Datentraeger
> > (primaer CSV, XML).

> Anstelle von $_REQUEST sollte man die korrekten Superglobalen
> verwenden.

Darueber setze ich mich bei $_PUT und $_GET grosszuegig hinweg.
Geprueft werden muessen die Inhalte ohnehin, und jedes Formular
verwendet bei korrekter Anwendung nur _entweder_ PUT _oder_ GET.
Macht der Anwender vorsaetzlich Unsinn und fliegt bei der Pruefung
auf die Nase, ist das nun wirklich sein Problem. Fuer mich bleibt so
die Chance, gelegentlich einen POST-Request einfach im Browser ueber
die URL nachbauen zu koennen.

> > | $errors['DateOpen'] = _('Das Öffnungsdatum darf nicht vor dem Ende der Anbotsfrist liegen.');

> Ich hoffe für dich, dass $errors nicht global ist!

Noe, ist es nicht, keine Angst :-)

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich

Stefan muß mehr als Happy machen!
(Sloganizer)

Re: [OT]Web 2.0

Ulf Kadner writes:

> Das ist falsch! C# baut auf dem Net-Framework von MS auf, welches
> wiederum größtenteils auf der WindowsAPI arbeitet. Diese ist zwar in C
> und C++ geschrieben aber das wars auch schon.
> C# unterscheidet sich bereits drastisch in seiner Arbeitsweise von C++
>
> Nur ein Bsp. Ohne dotNET-Framework ist C# unmöglich nutzbar. C++
> braucht das nicht.

http://mono-project.com/Main_Page

das .NET-zeugs kann sich nicht sonderlich stark auf das Windows-Api
verlassen, wenn sowas wie GTK# unter Linux funktioniert.

--
frobnicate foo

Re: Trennung von Programmlogik und Texten

Stefan Froehlich schrieb:
> On Thu, 28 Sep 2006 10:42:07 +0200 Torsten Zuehlsdorff wrote:

> Nun steht aber der Text immer noch beim Programm - und ein Auslagern
> in eine externe Datei via unzaehliger Konstanten wird IMHO eben
> unuebersichtlich. Man _koennte_ natuerlich einige Tests und Texte
> auch vereinheitlichen, hier z.B. zu "Datei nicht gefunden", diese
> etwas groessere Ausfuehrlichkeit in den Rueckmeldungen finde ich
> aber angenehm fuer den Anwender.
>

Also ich mache das grundsätzlich etwas anders... Und zwar habe ich
resource Files, in denen eben keine Konstanten, sondern Arrays definiert
werden, ist aber im Grunde dasselbe. Der Vorteil ist allerdings, dass
ich diese in meiner get_res_string methode erstmal mit dynamischen
Anpassungen belege, sprich diese methode nimmt nicht nur einen
parameter(den namen der resource), sondern eben noch beliebig viele
(abhängig von der Anzahl Platzhalte im resource String) Parameter als
Array entgegennimmt. Diese ersetzen eben dann die Platzhalter in der
Reihenfolge. So ist eine Anpassung (dadurch Ausführlichkeit) der Strings
möglich, ohne dafür gleich 10 Strings zu verwenden.

das sieht dann so aus:
$langManager->get_res_string('file_not_found',array('media_c atalog'));

In diesem Fall wird dann auch wieder abhängig von der Sprache der
entsprechende Wert für media_catalog eingesetzt.

Gut, das mag recht umständlich oder unübersichtlich klingen, ist aber
imho sehr flexibel, vor allem, wenn man eine zusätzliche Sprache
hinzufügen muss.


>> Anstelle von $_REQUEST sollte man die korrekten Superglobalen
>> verwenden.
>
> Darueber setze ich mich bei $_PUT und $_GET grosszuegig hinweg.
> Geprueft werden muessen die Inhalte ohnehin, und jedes Formular
> verwendet bei korrekter Anwendung nur _entweder_ PUT _oder_ GET.
> Macht der Anwender vorsaetzlich Unsinn und fliegt bei der Pruefung
> auf die Nase, ist das nun wirklich sein Problem. Fuer mich bleibt so
> die Chance, gelegentlich einen POST-Request einfach im Browser ueber
> die URL nachbauen zu koennen.
>

$_PUT? Ich schätze mal, Du meinst $_POST. Ich mache das allerdings auch
_teilweise_ so, um eben, wie Du sagst, POSTS mal mit URLS abzubilden,
oder umgekehrt. Man könnte natürlich auch grundsätzlich auch die
Formulare per GET abschicken, aber dann käme ich ab und an über die
Grenze einer URL Länge...

m2c.

Gruß Alex

Re: Trennung von Programmlogik und Texten

On Fri, 29 Sep 2006 08:32:49 +0200 Alex Hepp wrote:
> Und zwar habe ich resource Files, in denen eben keine Konstanten,
> sondern Arrays definiert werden, ist aber im Grunde dasselbe. Der
> Vorteil ist allerdings, dass ich diese in meiner get_res_string
> methode erstmal mit dynamischen Anpassungen belege, sprich diese
> methode nimmt nicht nur einen parameter(den namen der resource),
> sondern eben noch beliebig viele (abhängig von der Anzahl
> Platzhalte im resource String) Parameter als Array entgegennimmt.

Gut, das ist dann eine zusaetzliche Abkuerzung - an der Grundidee
der Konstanten aendert sie nichts. D.h. ich muesste einmal alle
Quelltexte durchforsten, wieviele unterschiedliche Meldungen da
tatsaechlich enthalten sind, ggf. gemeinsame ausfiltern und das
ganze dann in eine externe Datei zusammenfassen. Naja, mal sehen.

> So ist eine Anpassung (dadurch Ausführlichkeit) der Strings
> möglich, ohne dafür gleich 10 Strings zu verwenden.

> das sieht dann so aus:
> $langManager->get_res_string('file_not_found',array('media_c atalog'));

> In diesem Fall wird dann auch wieder abhängig von der Sprache der
> entsprechende Wert für media_catalog eingesetzt.

Ich habe sehr schlechte Erfahrungen mit mehrsprachigen Texten
gemacht, bei denen Parameter verwendet werden. Das klappt lange Zeit
gut, bis dann irgendwo (an der falschen Stelle) Pluralformen oder
Geschlechter auftauchen, die man mit gettext nicht mehr in den Griff
bekommt. Deshalb lasse ich Texte inzwischen am liebsten komplett.

> >> Anstelle von $_REQUEST sollte man die korrekten Superglobalen
> >> verwenden.

> > Darueber setze ich mich bei $_PUT und $_GET grosszuegig hinweg.
> > [...]

> $_PUT? Ich schätze mal, Du meinst $_POST.

*huestel*

Naja, von den bisher zwei bemerkten Tippfehlern gestern Abend war
das der entschieden weniger peinliche. Der Tag war offenbar zu lang.

> Ich mache das allerdings auch _teilweise_ so, um eben, wie Du
> sagst, POSTS mal mit URLS abzubilden, oder umgekehrt. Man könnte
> natürlich auch grundsätzlich auch die Formulare per GET
> abschicken,

Das halte ich fuer keine so gute Idee, da die Leute dann Formulare
durch Reload mehrfach abschicken koennen, was nicht immer im Sinn
des Erfinders ist. GET fuer Abfragen, POST fuer Aktionen ist (fuer
den normalen Anwender) schon sinnvoll.

> aber dann käme ich ab und an über die Grenze einer URL Länge...

Dieses Problem hat mich letztendlich dazu bewogen, an manchen
Stellen doch auf $_SESSION zurueckzugreifen.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich

Wolke Nummer sieben zum verlieben. Mit Stefan. Ein kultiviertes Vergnügen!
(Sloganizer)

Re: Trennung von Programmlogik und Texten

Stefan Froehlich schrieb:

>>>[Fehlermeldungen im Programmcode sind] insofern besser wartbar,
>>>weil bei unmittelbar bei der Abfrage auch klar ist, womit darauf
>>>reagiert wird. Oder umgekehrt, noch wichtiger, direkt bei Text
>>>auch der Kontext steht, fuer den er gedacht ist.
>
>>Da verfolgst du einen falschen Ansatz: Aus der Bedingungsabfrage
>>muß eindeutig hervorgehen, was passiert und erwartet wird. Dabei
>>wird aber häufig falsch formuliert. Gängig (und ungünstig) ist die
>>Überprüfung, ob der Fehlerfall eingetreten ist. Besser, wartbarer
>>und korrekter ist aber die Überprüfung, ob der Erfolgsfall nicht
>>eingetreten ist.
>>
>>Einfache Beispiele:
>>
>>$resDir = opendir('directory');
>>
>>Falsch:
>>if(!$resDir)
>>
>>Richtig:
>>if(!is_resource($resDir))
>
> Der Unterschied ist in meinen Augen zwar nicht uninteressant, aber
> eher marginal, und hat vor allem mit dem Ort der Textmeldungen nicht
> viel zu tun. Im wesentlichen mache ich das ohnehin so aehnlich, z.B.

Doch - den wenn du Code liest, möchtest du den Programmfluß nicht an
Hand irgendwelcher Fehlermeldungen ablesen. Wenn der Code lesbar ist,
benötigst du auch gar keine Fehlermeldungen innerhalb des Codes.

> | if (!is_readable($path_prefix . $_REQUEST['mediafile'])) {
> | $errors['mediafile'] = _('Die Katalogdatei wurde nicht gefunden.');
> | }
> | else {
> | [...weitere Pruefungen der Datei...]]
> | }

Hm - weißt du was Wächter sind?

> Nun steht aber der Text immer noch beim Programm - und ein Auslagern
> in eine externe Datei via unzaehliger Konstanten wird IMHO eben
> unuebersichtlich. Man _koennte_ natuerlich einige Tests und Texte
> auch vereinheitlichen, hier z.B. zu "Datei nicht gefunden", diese
> etwas groessere Ausfuehrlichkeit in den Rueckmeldungen finde ich
> aber angenehm fuer den Anwender.

Genau Rückmeldungen sind natürlich wünschenswert. Das heißt aber nicht,
sie auch gleich im Code plazieren zu müssen.
Wenn dich die vernüftige Logik schon nicht überzeugt:
Stelle dir vor, du möchtest eine Fehlermeldung ändern und vertippst dich
dabei: Dann ist dein Programm auf einmal kaputt. Auf Grund einer
lausigen Ausgabe wird deine komplette Programmlogik zerstört. Mit ein
wenig Glück liegt es an einem kaum zu sehenden Escapezeichen und
beschäftigt dich ein paar Stunden. Wenn man Text dort hin packt, wo er
hingehört, hat sich das Problem erledigt.
Im übrigen ist es auch _der_ typische Anfängerfehler bei
Konfigurationsdateien. Text, Konfigurationen und einiges mehr dürfen
nicht ausführbar sein!

>>Desweiteren vergißt du, dass Fehlermeldung durchaus mehrsprachig
>>sein können müssen
>
> Die _sind_ mehrsprachig, dafuer habe ich ja gettext!

Ach - ein gettexter :P

>>Bei mir ist es daher häufig so, dass ich schlicht einen Fehlercode
>>(setzt sich nach einem Schema zusammen) an die Fehlerbehandlung
>>übergebe und die macht den Rest. Richtige Datei parsen,
>>Sprachunterscheidung, andere Programmteile benachrichtigen,
>>Fehlermeldung ausgeben und gut.
>
> Dann haettest Du oben also an der entscheidenen Stelle stehen:
>
> | $errors['mediafile'] = err_file_notfound_media;

Nicht zwangsweise. Ich habe versucht anzudeuten, dass die
Fehlerbehandlungsreichweite groß ist. Ich kann einem Observer
bescheidsagen, dass etwas schief gelaufen ist. Ich kann auch PHP
Warnings, Notices und Erros ausgeben. Ich kann das Programm sofort
terminieren. Oder aber ich sage "geb mal eine Fehlermeldung aus. Du
findest sie unter Code xxx". Oder aber wiederrum "Hier hast du eine
Exception - werte sie aus und gebe die passende Fehlermeldung aus".

> Hm. Damit bin ich wieder am Anfang meiner Ueberlegungen, genau das
> gefaellt mir in der Menge eben nicht.

Wo siehst du da die Menge? Fehlercodes sind wesentlich kürzer als Text :P
Desweiteren ist es ganz angenehm, einfach eine ausgedrücke Liste aller
möglichen Fehler zu haben. Wenn du sie nach einem definierten Schema
erstellst, kannst du sie dir auch automatisiert ausgeben lassen - für
jede Sprache von mir aus.

>>>Ad Torsten: der Grossteil der Meldungen stammt entweder aus
>>>$_REQUEST, oder aus der Bearbeitung externer Datentraeger
>>>(primaer CSV, XML).
>
>>Anstelle von $_REQUEST sollte man die korrekten Superglobalen
>>verwenden.
>
> Darueber setze ich mich bei $_PUT und $_GET grosszuegig hinweg.
> Geprueft werden muessen die Inhalte ohnehin, und jedes Formular
> verwendet bei korrekter Anwendung nur _entweder_ PUT _oder_ GET.
> Macht der Anwender vorsaetzlich Unsinn und fliegt bei der Pruefung
> auf die Nase, ist das nun wirklich sein Problem.

Wie kommst du auf das schmale Brett, dass deine Formular angewendet
werden? Sobald ich auch nur 5 Minuten Zeit habe, ist es genau das, was
ich _nicht_ mache. Wenn ich erwarte, dass man mir Formulardaten per
$_POST übergibt und die kommen auf einmal per $_GET, dann habe ich doch
schon den ersten Anhaltspunkt für einen Angriff.
Post und Get sind zwar problemlos zu simulieren, aber so verhindert man
z.b. eine ungewollte Datenkombination oder kann sicherstellen, dass das
Formular korrekt verwendet wird.

> Fuer mich bleibt so
> die Chance, gelegentlich einen POST-Request einfach im Browser ueber
> die URL nachbauen zu koennen.

Oder ein GET über den Post.

>>>| $errors['DateOpen'] = _('Das Öffnungsdatum darf nicht vor dem Ende der Anbotsfrist liegen.');
>
>>Ich hoffe für dich, dass $errors nicht global ist!
>
> Noe, ist es nicht, keine Angst :-)

Macht der Gewohnheit :P

Gruß,
Torsten

Re: Trennung von Programmlogik und Texten

Alex Hepp schrieb:

> $_PUT? Ich schätze mal, Du meinst $_POST. Ich mache das allerdings auch
> _teilweise_ so, um eben, wie Du sagst, POSTS mal mit URLS abzubilden,
> oder umgekehrt. Man könnte natürlich auch grundsätzlich auch die
> Formulare per GET abschicken, aber dann käme ich ab und an über die
> Grenze einer URL Länge...

Du würdest Dateien per URL verschicken? :P

Gruß,
Torsten

Re: Trennung von Programmlogik und Texten

Stefan Froehlich schrieb:
> Gut, das ist dann eine zusaetzliche Abkuerzung - an der Grundidee
> der Konstanten aendert sie nichts. D.h. ich muesste einmal alle
> Quelltexte durchforsten, wieviele unterschiedliche Meldungen da
> tatsaechlich enthalten sind, ggf. gemeinsame ausfiltern und das
> ganze dann in eine externe Datei zusammenfassen. Naja, mal sehen.

Naja, das die Arbeit an bestehenden Projekten recht aufwendig ist, ist
klar... Allerdings lohnt imho der Aufwand absolut! Frage ist eben nur,
ob Zeit dafür ist ;)

>> So ist eine Anpassung (dadurch Ausführlichkeit) der Strings
>> möglich, ohne dafür gleich 10 Strings zu verwenden.
>
>> das sieht dann so aus:
>> $langManager->get_res_string('file_not_found',array('media_c atalog'));
>
>> In diesem Fall wird dann auch wieder abhängig von der Sprache der
>> entsprechende Wert für media_catalog eingesetzt.
>
> Ich habe sehr schlechte Erfahrungen mit mehrsprachigen Texten
> gemacht, bei denen Parameter verwendet werden. Das klappt lange Zeit
> gut, bis dann irgendwo (an der falschen Stelle) Pluralformen oder
> Geschlechter auftauchen, die man mit gettext nicht mehr in den Griff
> bekommt. Deshalb lasse ich Texte inzwischen am liebsten komplett.
>

Das ist ja auch nur für relativ allgemeine Meldungen gedacht, wenn ich
merke, dass irgendwo eben doch 2 unterschiedliche Varianten angewandt
werden müssen, führe ich eine neue Resource ein! Über eine simples
Suchen geht das meist ruck zuck!

>> $_PUT? Ich schätze mal, Du meinst $_POST.
>
> *huestel*
>
> Naja, von den bisher zwei bemerkten Tippfehlern gestern Abend war
> das der entschieden weniger peinliche. Der Tag war offenbar zu lang.

Ich hab nen Tippfehler übersehen??? Wo?? ;)

>> Ich mache das allerdings auch _teilweise_ so, um eben, wie Du
>> sagst, POSTS mal mit URLS abzubilden, oder umgekehrt. Man könnte
>> natürlich auch grundsätzlich auch die Formulare per GET
>> abschicken,
>
> Das halte ich fuer keine so gute Idee, da die Leute dann Formulare
> durch Reload mehrfach abschicken koennen, was nicht immer im Sinn
> des Erfinders ist. GET fuer Abfragen, POST fuer Aktionen ist (fuer
> den normalen Anwender) schon sinnvoll.
>

Das Affenformular kennst Du, oder? Davon abgesehen, war das eh nur ein
Hirngespinst ;) Allerdings sehe ich gerade im Bezug auf Deine
Argumentation keinen Unterschied zwischen GET und POST, ok, bei den
meisten Browsern kommt mittlerweile eine Warnmeldung, dass man
POST-Daten erneut abschicken möchte. Aber aus eigener Erfahrung weiss
ich, dass die meisten User hier einfach auf OK klicken ;)

>> aber dann käme ich ab und an über die Grenze einer URL Länge...
>
> Dieses Problem hat mich letztendlich dazu bewogen, an manchen
> Stellen doch auf $_SESSION zurueckzugreifen.

Wie das denn? Ach so, Du meinst, um benötigte Werte nicht in hidden
fields zu speichern, sondern in der Session? das mach ich sowieso so ;)
Mir gehts nur um Werte, die der Benutzer verändern kann, bzw. die
abhängig von Interaktion teilweise per javascript angepasst werden müssen!

Gruß Alex

Re: Trennung von Programmlogik und Texten

Stefan Froehlich schrieb:

>>Ich mache das allerdings auch _teilweise_ so, um eben, wie Du
>>sagst, POSTS mal mit URLS abzubilden, oder umgekehrt. Man könnte
>>natürlich auch grundsätzlich auch die Formulare per GET
>>abschicken,
>
> Das halte ich fuer keine so gute Idee, da die Leute dann Formulare
> durch Reload mehrfach abschicken koennen, was nicht immer im Sinn
> des Erfinders ist. GET fuer Abfragen, POST fuer Aktionen ist (fuer
> den normalen Anwender) schon sinnvoll.

Du vergißt, dass Nutzer dann gerne das abgeschickte Formular bookmarken
und immer wieder aufrufen.
Ein Reload wird aber durch den üblichen Zufallswert in einem Formular
verhindert.

Gruß,
Torsten

Re: Trennung von Programmlogik und Texten

Torsten Zuehlsdorff schrieb:
> Alex Hepp schrieb:
>
>> $_PUT? Ich schätze mal, Du meinst $_POST. Ich mache das allerdings auch
>> _teilweise_ so, um eben, wie Du sagst, POSTS mal mit URLS abzubilden,
>> oder umgekehrt. Man könnte natürlich auch grundsätzlich auch die
>> Formulare per GET abschicken, aber dann käme ich ab und an über die
>> Grenze einer URL Länge...
>
> Du würdest Dateien per URL verschicken? :P

Sicher würde ich, wenn es ginge ;) Das ist natürlich ein Fall, wo man
auf POST angewiesen ist, was man spätestens dann merkt, wenn man es nich
auf die Reihe bekommt, eine Datei upzuloaden ;)

lg. alex

Re: [OT]Web 2.0

Ulf Kadner schrieb:

>>> Hast Du wohl das Smiley zu Deiner Frage vergessen?
>>
>>
>> Nein ;)
>
> Du verwirrst mich! :-)

Gerne ;)

>> Warum? Yacc und Bison ermöglichen die grundlegende Arbeit in relativ
>> kurzer Zeit.
>
> Ja aber... :-x Haste recht.

Du hättest jetzt immerhin einwenden können, dass die Auswertung von
Sprachkonstrukten zwar die grundlegende Arbeit darstellt, aber die
Funktionalität, sowie Anbindungen und Portierbarkeit _wirklich_ Arbeit
darstellen. Abgesehen von Konzeption, Wartung und Sicherheit natürlich.
*seufz*

>> Ich habe auch schon Sprachimplementierungen in 500 Zeilen gesehen. :)
>
> Ich hab schon mal ne Katze aufm Surfbrett in 20-Fuss Wellen gesehen...

Send Pix!

Gruß,
Torsten

Re: [OT]Web 2.0

Torsten Zuehlsdorff schrieb:
> Ulf Kadner schrieb:
>
>>> Ich habe auch schon Sprachimplementierungen in 500 Zeilen gesehen. :)
>> Ich hab schon mal ne Katze aufm Surfbrett in 20-Fuss Wellen gesehen...
>
> Send Pix!

Ich will auch !!! ;)

alex

Re: Trennung von Programmlogik und Texten

Alex Hepp schrieb:

>>> $_PUT? Ich schätze mal, Du meinst $_POST. Ich mache das allerdings auch
>>> _teilweise_ so, um eben, wie Du sagst, POSTS mal mit URLS abzubilden,
>>> oder umgekehrt. Man könnte natürlich auch grundsätzlich auch die
>>> Formulare per GET abschicken, aber dann käme ich ab und an über die
>>> Grenze einer URL Länge...
>>
>> Du würdest Dateien per URL verschicken? :P
>
> Sicher würde ich, wenn es ginge ;)

base64_encode() existiert ;)

Gruß,
Torsten

Re: Trennung von Programmlogik und Texten

Torsten Zuehlsdorff schrieb:
> Alex Hepp schrieb:
>
>>>> $_PUT? Ich schätze mal, Du meinst $_POST. Ich mache das allerdings auch
>>>> _teilweise_ so, um eben, wie Du sagst, POSTS mal mit URLS abzubilden,
>>>> oder umgekehrt. Man könnte natürlich auch grundsätzlich auch die
>>>> Formulare per GET abschicken, aber dann käme ich ab und an über die
>>>> Grenze einer URL Länge...
>>> Du würdest Dateien per URL verschicken? :P
>> Sicher würde ich, wenn es ginge ;)
>
> base64_encode() existiert ;)

Das wird aber wohl kaum wirklich funktionieren ==> 2048 (2083) Zeichen
max. URL länge... Auch wenn es nicht im HTTP Protokoll spezifiziert ist,
aber eben aufgrund vom IE praktisch so ist! Oder gilt das nur für den
Pfadanteil, und nicht für Parameter, das würde allerdings einiges ändern ;)

Re: Trennung von Programmlogik und Texten

Alex Hepp schrieb:

>>>>> $_PUT? Ich schätze mal, Du meinst $_POST. Ich mache das allerdings
>>>>> auch
>>>>> _teilweise_ so, um eben, wie Du sagst, POSTS mal mit URLS abzubilden,
>>>>> oder umgekehrt. Man könnte natürlich auch grundsätzlich auch die
>>>>> Formulare per GET abschicken, aber dann käme ich ab und an über die
>>>>> Grenze einer URL Länge...
>>>>
>>>> Du würdest Dateien per URL verschicken? :P
>>>
>>> Sicher würde ich, wenn es ginge ;)
>>
>>
>> base64_encode() existiert ;)
>
> Das wird aber wohl kaum wirklich funktionieren ==> 2048 (2083) Zeichen
> max. URL länge... Auch wenn es nicht im HTTP Protokoll spezifiziert ist,
> aber eben aufgrund vom IE praktisch so ist! Oder gilt das nur für den
> Pfadanteil, und nicht für Parameter, das würde allerdings einiges ändern ;)

Nein, wie du sagst: Diese Einschränkung ist nicht spezifiziert, sondern
wird meist nur durch Browser und Server gesetzt. Aber kleinere Dateien
lassen sich damit schon mal per URL übertragen. -.-

Gruß,
Torsten

Re: [OT]Web 2.0

Torsten Zuehlsdorff wrote:

> Du hättest jetzt immerhin einwenden können, dass die Auswertung von
> Sprachkonstrukten zwar die grundlegende Arbeit darstellt, aber die
> Funktionalität, sowie Anbindungen und Portierbarkeit _wirklich_ Arbeit
> darstellen. Abgesehen von Konzeption, Wartung und Sicherheit natürlich.
> *seufz*

Frag nicht warum, aber ich hatte es irgendwie geahnt das Du mir die
Argumentation abnimmst! ;-)

>>Ich hab schon mal ne Katze aufm Surfbrett in 20-Fuss Wellen gesehen...
>
> Send Pix!

Das wird kompliziert! Da muss ich erst eins malen. Aber das Ergebnis wär
wohl ne starke Zumutung und ich bezweifle das ichs so hinbekomme, das
man auch erkennt das es ne Katze sein soll. :-)

Ich gebe zu es war gelogen ;-)
Inspiriert hat mich wohl die "Fellelse" (Hund vom Kumpel) der ist
wirklich schon mitgesurft aber auch nicht bei 20Fuss Wellen. Da bleib
ich lieber an Land und bestaune die Gewalt dessen.

MfG, Ulf

Re: [OT]Web 2.0

Ulf Kadner schrieb:
> Torsten Zuehlsdorff wrote:
>
>> Du hättest jetzt immerhin einwenden können, dass die Auswertung von
>> Sprachkonstrukten zwar die grundlegende Arbeit darstellt, aber die
>> Funktionalität, sowie Anbindungen und Portierbarkeit _wirklich_ Arbeit
>> darstellen. Abgesehen von Konzeption, Wartung und Sicherheit natürlich.
>> *seufz*
>
> Frag nicht warum, aber ich hatte es irgendwie geahnt das Du mir die
> Argumentation abnimmst! ;-)
>
>>> Ich hab schon mal ne Katze aufm Surfbrett in 20-Fuss Wellen gesehen...
>>
>> Send Pix!
>
> Das wird kompliziert! Da muss ich erst eins malen. Aber das Ergebnis wär
> wohl ne starke Zumutung und ich bezweifle das ichs so hinbekomme, das
> man auch erkennt das es ne Katze sein soll. :-)

Na, dann mach doch Asciiart ;)

> Ich gebe zu es war gelogen ;-)
> Inspiriert hat mich wohl die "Fellelse" (Hund vom Kumpel) der ist
> wirklich schon mitgesurft aber auch nicht bei 20Fuss Wellen. Da bleib
> ich lieber an Land und bestaune die Gewalt dessen.

Wer bitte nennt denn seinen Hund Fellelse???? ;) Bei 20 Fuss hohen
wellen schnapp ich mir mein Bodyboard und begehe den Surferselbstmord ;)

gruß Alex

Re: [OT]Web 2.0

Ulf Kadner schrieb:

>> Du hättest jetzt immerhin einwenden können, dass die Auswertung von
>> Sprachkonstrukten zwar die grundlegende Arbeit darstellt, aber die
>> Funktionalität, sowie Anbindungen und Portierbarkeit _wirklich_ Arbeit
>> darstellen. Abgesehen von Konzeption, Wartung und Sicherheit natürlich.
>> *seufz*
>
> Frag nicht warum, aber ich hatte es irgendwie geahnt das Du mir die
> Argumentation abnimmst! ;-)

Das liegt daran, dass ich eigentlich ein recht gutes Auge für Fehler
habe. ;)
Funktioniert aber nur selten auf den Inhaber bezogen ^^

Daher wäre mein Gedanke auch einfach eine bestehende, portierte Sprache
zu verwenden und damit Sprachkonstrukte zu entwicklen, mit welcher man
wiederrum die Sprache entwickelt. Es ist ja gar nicht so selten, dass
man Sprachen zum Teil mit sich selbst schreibt :P

>>> Ich hab schon mal ne Katze aufm Surfbrett in 20-Fuss Wellen gesehen...
>>
>> Send Pix!
>
> Das wird kompliziert! Da muss ich erst eins malen. Aber das Ergebnis wär
> wohl ne starke Zumutung und ich bezweifle das ichs so hinbekomme, das
> man auch erkennt das es ne Katze sein soll. :-)

Moderne Grafikbearbeitung sollte das möglich machen. Meine Freundin
erzeugt auch gerne Chimären aus verschiedenen Menschen und Tieren :P

So - und jetzt suche das Wortspiel, dass sich auf deine Katze und die
Wellen bezieht ^^

Gruß,
Torsten

Re: [OT]Web 2.0

Alex Hepp wrote:

> Wer bitte nennt denn seinen Hund Fellelse???? ;)

Nicht gut? :-) Den Hund störts scheinbar nicht.

> Bei 20 Fuss hohen
> wellen schnapp ich mir mein Bodyboard und begehe den Surferselbstmord ;)

Ich kann höchstens 100 meter hohen wellen bieten, die aber leider aus
Sand sind.

http://gallerie.downto.de/main.php?g2_itemId=177

MfG, Ulf

Re: [OT]Web 2.0

Torsten Zuehlsdorff wrote:

> Das liegt daran, dass ich eigentlich ein recht gutes Auge für Fehler
> habe. ;)

:-)

> Daher wäre mein Gedanke auch einfach eine bestehende, portierte Sprache
> zu verwenden und damit Sprachkonstrukte zu entwicklen, mit welcher man
> wiederrum die Sprache entwickelt. Es ist ja gar nicht so selten, dass
> man Sprachen zum Teil mit sich selbst schreibt :P

Also ich will das nicht! Glaub mir. Um entscheiden zu koennen ob es eine
Notwendigkeit gibt sich derartiges anzutun muss man wohl erst mal
recherchieren ob da bereits ein Anderer die selbe Idee hatte.

> Moderne Grafikbearbeitung sollte das möglich machen.

Auch davon hab ich keinen blassen schimmer. Fotografieren ist ja noch OK
aber mehr auch nicht.

> Meine Freundin
> erzeugt auch gerne Chimären aus verschiedenen Menschen und Tieren :P

:-)

> So - und jetzt suche das Wortspiel, dass sich auf deine Katze und die
> Wellen bezieht ^^

Gibts da Finderlohn?

MfG, Ulf

Re: [OT]Web 2.0

Ulf Kadner schrieb:
> Alex Hepp wrote:
>
> Ich kann höchstens 100 meter hohen wellen bieten, die aber leider aus
> Sand sind.
>
> http://gallerie.downto.de/main.php?g2_itemId=177

Sehr cool, kennst Du die Dûne du Pyla? In der Nähe von Archachon in
Südwestfrankreich, das ist auch unglaublich.. Wenn ich heut abend zu
Hause bin, post ich mal nen link!

gruß Alex

Re: [OT]Web 2.0

Alex Hepp wrote:

> Sehr cool, kennst Du die Dûne du Pyla?

Klar, die höchste Düne von Europa. Noch dazu am Atlantik gelegen.
Das haben wir uns nen ganzen Tag mit Snowboards die Kante gegeben. :-)

In Namibia war das sehr anstrengend (45°C + Sturm + Hardboots) dort is
jeder nur einmal gefahren.

> Südwestfrankreich, das ist auch unglaublich.. Wenn ich heut abend zu
> Hause bin, post ich mal nen link!

OK :-)

MfG, Ulf

Re: [OT]Web 2.0

Ulf Kadner schrieb:

>> Daher wäre mein Gedanke auch einfach eine bestehende, portierte Sprache
>> zu verwenden und damit Sprachkonstrukte zu entwicklen, mit welcher man
>> wiederrum die Sprache entwickelt. Es ist ja gar nicht so selten, dass
>> man Sprachen zum Teil mit sich selbst schreibt :P
>
> Also ich will das nicht! Glaub mir. Um entscheiden zu koennen ob es eine
> Notwendigkeit gibt sich derartiges anzutun muss man wohl erst mal
> recherchieren ob da bereits ein Anderer die selbe Idee hatte.

Da hast du natürlich recht. Aber solange mich keine Sprache wirklich
befriedigt, gibt es immerhin diese Notwendigkeit für mich.

>> So - und jetzt suche das Wortspiel, dass sich auf deine Katze und die
>> Wellen bezieht ^^
>
> Gibts da Finderlohn?

Ruhm und Ehre für dein ausgeprägtes Allgemeinwissen über unbedeutende
Dinge :P

Gruß,
Torsten

Re: Trennung von Programmlogik und Texten

Torsten Zuehlsdorff schrieb:

>>Darueber setze ich mich bei $_PUT und $_GET grosszuegig hinweg.
>>Geprueft werden muessen die Inhalte ohnehin, und jedes Formular
>>verwendet bei korrekter Anwendung nur _entweder_ PUT _oder_ GET.
>>Macht der Anwender vorsaetzlich Unsinn und fliegt bei der Pruefung
>>auf die Nase, ist das nun wirklich sein Problem.
>
> Wie kommst du auf das schmale Brett, dass deine Formular angewendet
> werden?

Kleiner Nachtrag: Dieser Satz macht nur Sinn, wenn man ihn wie folgt liest:
"Wie kommst du auf das schmale Brett, dass deine Formulare korrekt
angewendet werden?"

Gruß,
Torsten

Re: Trennung von Programmlogik und Texten

On Fri, 29 Sep 2006 09:32:17 +0200 Torsten Zuehlsdorff wrote:
> > | if (!is_readable($path_prefix . $_REQUEST['mediafile'])) {
> > | $errors['mediafile'] = _('Die Katalogdatei wurde nicht gefunden.');
> > | }
> > | else {
> > | [...weitere Pruefungen der Datei...]]
> > | }

> Hm - weißt du was Wächter sind?

Oehm, irgendwoanders ging es gerade um Englisch als Fachsprache - meinst
Du Exceptions? Mit "Waechter" fange ich so rein gar nichts an :-)

Falls ja: weiss ich schon, aber zu Beginn des Projekts gab es zum einen
noch keine Exceptions in PHP (ja, das ganze ist von der Struktur her
schon etwas aelter), und zum anderen sehe ich gerade in solchen Faellen
auch nicht die zwingende Notwendigkeit dafuer. Eine Aneinanderkettung
von max. einem halben Dutzend if-else oder if-elseif-else Pruefungen ist
nicht gar so unuebersichtlich.

> > Man _koennte_ natuerlich einige Tests und Texte auch
> > vereinheitlichen, hier z.B. zu "Datei nicht gefunden", diese etwas
> > groessere Ausfuehrlichkeit in den Rueckmeldungen finde ich aber
> > angenehm fuer den Anwender.

> Genau Rückmeldungen sind natürlich wünschenswert. Das heißt aber
> nicht, sie auch gleich im Code plazieren zu müssen.

Das nicht, nein - aber dann waere der Gewinn durch eine Auslagerung
ganz offensichtlich :)

> Wenn dich die vernüftige Logik schon nicht überzeugt:

Ich sage gar nicht, dass mich das nicht ueberzeugt. Bloss wenn ich
jetzt "klar, so soll es sein und nicht anders" schreibe, ist die
Diskussion vorbei. Da eine Umsetzung sowieso eher eine Frage von
Monaten ist, kann ich ruhig noch ein paar Aspekte durchkauen und
hinterher abwaegen.

> Stelle dir vor, du möchtest eine Fehlermeldung ändern und
> vertippst dich dabei: Dann ist dein Programm auf einmal kaputt.
> Auf Grund einer lausigen Ausgabe wird deine komplette
> Programmlogik zerstört. Mit ein wenig Glück liegt es an einem kaum
> zu sehenden Escapezeichen und beschäftigt dich ein paar Stunden.
> Wenn man Text dort hin packt, wo er hingehört, hat sich das
> Problem erledigt.

Hm. Solange die Datei mit den Fehlermeldungen ein require ist, macht
es keinen echten Unterschied: PHP-Anweisungen hier wie dort mit dem
gleichen Potential fuer derartige Fehlermeldungen (die bislang noch
kein echtes Problem waren). Also braucht es noch eine
Abstraktionsebene mehr, ein eigener Handler, der sich um das
Einlesen kuemmert.

> > Die _sind_ mehrsprachig, dafuer habe ich ja gettext!

> Ach - ein gettexter :P

Gibt es denn etwas anderes?

Im Ernst: ich kenne sonst kein System, das mir meine Texte aus
PHP- und C-Code, aus Templates, Datenbanken und Excel-Vorlagen
extrahiert. Ausserdem kenne ich sonst kein System, mit dem man
vernuenftig das Problem des Duals in diversen slawischen Sprachen
loesen kann.

Der nette Editor zum Uebersetzen ist ein Plus, auch wenn er bei
professionellen Uebersetzungsdiensten meist erst einmal arge
Irritationen verursacht.

> > | $errors['mediafile'] = err_file_notfound_media;

> Nicht zwangsweise. Ich habe versucht anzudeuten, dass die
> Fehlerbehandlungsreichweite groß ist. Ich kann einem Observer
> bescheidsagen, dass etwas schief gelaufen ist. Ich kann auch PHP
> Warnings, Notices und Erros ausgeben. Ich kann das Programm sofort
> terminieren.

Die letzten Dinge versuche ich eigentlich konsequent zu vermeiden.
Eine PHP-Meldung im Error-Log deutet hier stets auf _meinen_ Fehler
hin, nicht auf einen zu erwarteten Programmzustand.

> Oder aber ich sage "geb mal eine Fehlermeldung aus. Du findest sie
> unter Code xxx". Oder aber wiederrum "Hier hast du eine Exception
> - werte sie aus und gebe die passende Fehlermeldung aus".

Ich weiss noch nicht recht, ob diese grosse Flexibilitaet wirklich
notwendig ist. Bislang werden Fehlermeldungen, die der Anwender zu
Gesicht bekommt, immer nur auf der auessersten (d.h. der Formular-)
Ebene erzeugt. Liegt die Ursache eingekapselt weiter innen, kommen
ohnehin schon Codes zum Einsatz - das sind dann aber ueberschaubar
viele.

> > Hm. Damit bin ich wieder am Anfang meiner Ueberlegungen, genau
> > das gefaellt mir in der Menge eben nicht.

> Wo siehst du da die Menge? Fehlercodes sind wesentlich kürzer als
> Text :P

Ich befuerchte zunaechst Probleme bei der konsequenten Benennung,
insbesondere im Zug von Programmerweiterungen. Im weiteren
befuerchte ich dann allgemeines Chaos eben durch inkonsequente
Namensgebung.

> > Geprueft werden muessen die Inhalte ohnehin, und jedes Formular
> > verwendet bei korrekter Anwendung nur _entweder_ PUT _oder_ GET.
> > Macht der Anwender vorsaetzlich Unsinn und fliegt bei der Pruefung
> > auf die Nase, ist das nun wirklich sein Problem.

> Wie kommst du auf das schmale Brett, dass deine Formular [korrekt]
> angewendet werden? Sobald ich auch nur 5 Minuten Zeit habe, ist es
> genau das, was ich _nicht_ mache.

Selber schuld, dann gebuehrt Dir kein Mitleid :)

Ganz im Ernst: wenn jemand bereits vorsaetzlich eigene GET- oder
POST-Werte an meine Software verfuettert, dann hat er auch die
Faehigkeit, sich das eine oder andere auszusuchen, ergo ist die
Unterscheidung dazwischen erst recht _vollkommen_ egal.

Und dann: alles, was ankommt, wird abgefragt und ggf. die weitere
Ausfuehrung mangels Berechtigung verweigert. Ueberlagert jemand
einen sinnvollen POST-Wert durch einen sinnlosen GET-Wert, bekommt
er schlimmstenfalls eine sinnlose (aber unkritische) Ausgabe. _Mir_
ist das gleichgueltig, und der Anwender weiss ja wohl, woher es
kommt.

> Wenn ich erwarte, dass man mir Formulardaten per $_POST übergibt
> und die kommen auf einmal per $_GET, dann habe ich doch schon den
> ersten Anhaltspunkt für einen Angriff.

Und was tust Du dann mit diesem Wissen? :-)

> so verhindert man z.b. eine ungewollte Datenkombination oder kann
> sicherstellen, dass das Formular korrekt verwendet wird.

Auch nicht leichter, da man die "richtigen" Variablen genau den
gleichen Pruefungen unterziehen muss.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich

Stefan, mit dem verwundeten Formblatt der Liebeslust.
(Sloganizer)

Re: Trennung von Programmlogik und Texten

On Fri, 29 Sep 2006 09:35:25 +0200 Alex Hepp wrote:
> > D.h. ich muesste einmal alle Quelltexte durchforsten, wieviele
> > unterschiedliche Meldungen da tatsaechlich enthalten sind, ggf.
> > gemeinsame ausfiltern und das ganze dann in eine externe Datei
> > zusammenfassen. Naja, mal sehen.

> Naja, das die Arbeit an bestehenden Projekten recht aufwendig ist,
> ist klar... Allerdings lohnt imho der Aufwand absolut! Frage ist
> eben nur, ob Zeit dafür ist ;)

Das sowieso. Witzigerweise war das Projekt urspruenglich so
gestrickt, dass die Texte alle in einem grossen Array standen.
Im Zug der dritten Fremdsprache wurde dann alles auf gettext()
umgestellt, und bei der Gelegenheit sind dann auch die Bezeichner
gegen die Originaltexte ersetzt worden, was das Programmieren
ungleich einfacher gemacht hat (und dafuer das Aendern einzelner
Texte einen Tick schwieriger).

> > Ich habe sehr schlechte Erfahrungen mit mehrsprachigen Texten
> > gemacht, bei denen Parameter verwendet werden. Das klappt lange
> > Zeit gut, bis dann irgendwo (an der falschen Stelle)
> > Pluralformen oder Geschlechter auftauchen, die man mit gettext
> > nicht mehr in den Griff bekommt. Deshalb lasse ich Texte
> > inzwischen am liebsten komplett.

> Das ist ja auch nur für relativ allgemeine Meldungen gedacht, wenn
> ich merke, dass irgendwo eben doch 2 unterschiedliche Varianten
> angewandt werden müssen, führe ich eine neue Resource ein! Über
> eine simples Suchen geht das meist ruck zuck!

Die Suche laesst sich noch halbwegs rasch erledigen, ja. Aber
gettext() plus Orignalmeldung im Quellcode fasst mir beispielsweise
auch uebergreifend zwischen C- und PHP-Code zusammen (und ja, das
ist hier tatsaechlich relevant). Bei einer Auslagerung in eine
Textdatei erhoeht das den Aufwand schon wieder deutlich.

> >> $_PUT? Ich schätze mal, Du meinst $_POST.
>
> > Naja, von den bisher zwei bemerkten Tippfehlern gestern Abend
> > war das der entschieden weniger peinliche. Der Tag war offenbar
> > zu lang.

> Ich hab nen Tippfehler übersehen??? Wo?? ;)

Noe, der war in einer privaten Mail knapp vor dem Posting. An den
Auswirkungen repariere ich heute noch :-/

> >> Man könnte natürlich auch grundsätzlich auch die Formulare per
> >> GET abschicken,

> > GET fuer Abfragen, POST fuer Aktionen ist (fuer den normalen
> > Anwender) schon sinnvoll.

> Allerdings sehe ich gerade im Bezug auf Deine Argumentation keinen
> Unterschied zwischen GET und POST, ok, bei den meisten Browsern
> kommt mittlerweile eine Warnmeldung, dass man POST-Daten erneut
> abschicken möchte. Aber aus eigener Erfahrung weiss ich, dass die
> meisten User hier einfach auf OK klicken ;)

Auch wieder wahr. Deshalb bekommen die Leute als Antwort auf einen
POST-Request auch einen Statuscode 303 mit Verweis auf die
Folgeseite geliefert. Das bewaehrt sich soweit recht gut.

> >> aber dann käme ich ab und an über die Grenze einer URL Länge...
> >
> > Dieses Problem hat mich letztendlich dazu bewogen, an manchen
> > Stellen doch auf $_SESSION zurueckzugreifen.
>
> Wie das denn? Ach so, Du meinst, um benötigte Werte nicht in hidden
> fields zu speichern, sondern in der Session? das mach ich sowieso so ;)

Ich habe gerne recht viel in der URL stehen, weil das beispielsweise
fuer Bookmarks praktisch ist, oder auch fuer den Betrieb in mehreren
Browserfenstern.

Bei Fehlermeldungen, die durch den 303er durchgeschleift werden,
hoert sich das dann allerdings definitiv auf.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich

Stefan: ein entschlossenes Team!
(Sloganizer)

Re: Trennung von Programmlogik und Texten

Stefan Froehlich schrieb am 30.09.2006 13:04:

>> Ich hab nen Tippfehler übersehen??? Wo?? ;)

> Noe, der war in einer privaten Mail knapp vor dem Posting. An den
> Auswirkungen repariere ich heute noch :-/

Verstehe, gutes Gelingen ;)

> Auch wieder wahr. Deshalb bekommen die Leute als Antwort auf einen
> POST-Request auch einen Statuscode 303 mit Verweis auf die
> Folgeseite geliefert. Das bewaehrt sich soweit recht gut.

Du meinst auf einen wiederholten POST Request oder wie?

>>>> aber dann käme ich ab und an über die Grenze einer URL Länge...
>>> Dieses Problem hat mich letztendlich dazu bewogen, an manchen
>>> Stellen doch auf $_SESSION zurueckzugreifen.
>> Wie das denn? Ach so, Du meinst, um benötigte Werte nicht in hidden
>> fields zu speichern, sondern in der Session? das mach ich sowieso so ;)
>
> Ich habe gerne recht viel in der URL stehen, weil das beispielsweise
> fuer Bookmarks praktisch ist, oder auch fuer den Betrieb in mehreren
> Browserfenstern.

Widerspricht sich das jetzt gerade, oder hatte ich gestern ein Bier zuviel???
Oder meinst Du mit den mehreren Browserfenstern bspwse das Aufrufen eines links
in einem extra Fenster? Aber das funktioniert doch auch über die Session, vom
Client sollten eigentlich immer nur Daten übertragen werden, die sich aufgrund
von Interaktion ändern können! Und eben diese frage ich meist halt mit $_REQUEST
ab, damit ich sowohl ein Form posten kann, als auch den Aufruf per URL
nachbilden kann (Bookmarks, simple Links, später Erweiterung zu "Sprechenden
URLS" mit mod_rewrite usw)...

CU Alex

Re: Trennung von Programmlogik und Texten

On 30 Sep 2006 10:56:02 GMT, Stefan Froehlich wrote:

>> > | if (!is_readable($path_prefix . $_REQUEST['mediafile'])) {
>> > | $errors['mediafile'] = _('Die Katalogdatei wurde nicht gefunden.');
>> > | }
>> > | else {
>> > | [...weitere Pruefungen der Datei...]]
>> > | }
>> Hm - weißt du was Wächter sind?
> Oehm, irgendwoanders ging es gerade um Englisch als Fachsprache - meinst
> Du Exceptions? Mit "Waechter" fange ich so rein gar nichts an :-)

27.1. Halte Code links. Verwende Wächter statt Schachtel-if
http://www.php-faq.de/q/q-stil-waechter.html


gregor
--
.''`. http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4
: :' : debian: the universal operating system - http://www.debian.org/
`. `' member of https://www.vibe.at/ | how to reply: http://got.to/quote/
`-

Re: Web 2.0

Martin Kaffanke schrieb:
> Ich habe php an
> den Nagel gehängt, vor allem deshalb weil es schon eine Kunst ist, hier
> ordentlich Source von Design auseinanderzuhalten.

Ich weiss nicht, wo Dein Problem ist:
http://pear.php.net/manual/de/package.html.html-template-fle xy.php
http://pear.php.net/manual/de/package.html.html-template-it. php

Re: Trennung von Programmlogik und Texten

On Sun, 1 Oct 2006 00:53:16 +0200 gregor herrmann wrote:
> >> > | if (!is_readable($path_prefix . $_REQUEST['mediafile'])) {
> >> > | $errors['mediafile'] = _('Die Katalogdatei wurde nicht gefunden.');
> >> > | }
> >> > | else {
> >> > | [...weitere Pruefungen der Datei...]]
> >> > | }

> 27.1. Halte Code links. Verwende Wächter statt Schachtel-if
> http://www.php-faq.de/q/q-stil-waechter.html

Ah, ok. Dass es dafuer auch noch einen eigenen Fachbegriff gibt, war mir
neu :)

Im grossen und ganzen mache ich das ohnehin so aehnlich, aber ich goenne
mir auch ganz bewusst Ausnahmen davon. Nimm beispielsweise die Pruefung
von zwei Datumsfeldern:

| if (!gueltig($datum1)) {
| $errors = ...
| }
|
| if (!gueltig($datum2)) {
| $errors = ...
| }
| elseif ($datum1 < $datum2) {
| $errors = ...
| }

Hier ist das noch relativ trivial, aber es gibt auch komplexere
Abhaengigkeiten mit mehr beteiligten Feldern. Mehr als zwei
verschachtelte Ebenen treten auch nach diesem Schema kaum jemals auf.

Darueberhinaus existiert bei mir kein Code der Form doit() aus der
obigen URL, da alle Vorbedingungen gemeinsam in einer eigenen Funktion
geprueft werden. Im Hauptprogramm steht dann nur noch etwas in der Art

| if (!check()) return;
| [...doit...]

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich

Stefan - Für die Kennerin von Welt: Krachen bis es riecht!
(Sloganizer)

Re: Trennung von Programmlogik und Texten

On Sat, 30 Sep 2006 14:50:48 +0200 Alex Hepp wrote:
> > Deshalb bekommen die Leute als Antwort auf einen POST-Request
> > auch einen Statuscode 303 mit Verweis auf die Folgeseite
> > geliefert. Das bewaehrt sich soweit recht gut.

> Du meinst auf einen wiederholten POST Request oder wie?

Jedes Formular, das dazu in der Lage ist, Daten in der Applikation
zu aendern, wird mit POST abgeschickt. Als Antwort darauf kommt dann
grundsaetzlich ein Statuscode 303, typischerweise mit
Location-Header auf sich selbst (es gibt einzelne Ausnahmen davon).
Diese Seite besitzt dann wiederum sinnvollen Inhalt, unabhaengig
davon, ob sie durch die Umleitung oder z.B. durch Reloads oder
Bookmars aufgerufen wurde.

Beispiel: nach dem Anlegen eines Objekts wird auf die Seite "Objekt
darstellen" umgeleitet, verbunden mit einer (ueber Session
kommunizierten) Statusmeldung "Objekt wurde neu angelegt". Kommt
jemand spaeter wieder auf diese Seite, erhaelt er die Objektanzeige
ohne die Statusmeldung.

> >>> Dieses Problem hat mich letztendlich dazu bewogen, an manchen
> >>> Stellen doch auf $_SESSION zurueckzugreifen.
>
> > Ich habe gerne recht viel in der URL stehen, weil das
> > beispielsweise fuer Bookmarks praktisch ist, oder auch fuer den
> > Betrieb in mehreren Browserfenstern.

> Widerspricht sich das jetzt gerade, oder hatte ich gestern ein Bier zuviel???

Das eine schliesst das andere nicht unbedingt aus :-)

> Oder meinst Du mit den mehreren Browserfenstern bspwse das
> Aufrufen eines links in einem extra Fenster? Aber das funktioniert
> doch auch über die Session,

Es gibt bei hierarchischen Darstellungen oft Sitzungsdaten, die fuer
die laufende Anzeige wichtig sind - bei kaskadierter Darstellung
beispielsweise die Reihenfolge der einzelnen Ebenen. Teilen sich
mehrere Browserinstanzen $_SESSION, bekommt man nach einem Reload
unter Umstaenden eine voellig andere Seite, wenn man zuvor in einem
anderen Fenster navigiert hat.

> vom Client sollten eigentlich immer nur Daten übertragen werden,
> die sich aufgrund von Interaktion ändern können!

Darueber gehe ich wohl ein wenig hinaus. Ich habe eine zusaetzliche
Variable, in der Statusinformation ueber den augenblicklichen
"Standort" im Programm uebertragen wird.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich

Stefan - Komfort kennt keine Grenzen: Spüren weil es jubiliert!
(Sloganizer)

Re: Web 2.0

Thomas Richter schrieb:
> Martin Kaffanke schrieb:
>> Ich habe php an
>> den Nagel gehängt, vor allem deshalb weil es schon eine Kunst ist, hier
>> ordentlich Source von Design auseinanderzuhalten.
>
> Ich weiss nicht, wo Dein Problem ist:
> http://pear.php.net/manual/de/package.html.html-template-fle xy.php
> http://pear.php.net/manual/de/package.html.html-template-it. php

Alternativ: Smarty

Re: Trennung von Programmlogik und Texten

Stefan Froehlich schrieb:

Hallo - mit ein wenig Verzögerung dank Urlaub meine Antwort:

>>>| if (!is_readable($path_prefix . $_REQUEST['mediafile'])) {
>>>| $errors['mediafile'] = _('Die Katalogdatei wurde nicht gefunden.');
>>>| }
>>>| else {
>>>| [...weitere Pruefungen der Datei...]]
>>>| }
>
>>Hm - weißt du was Wächter sind?
>
> Oehm, irgendwoanders ging es gerade um Englisch als Fachsprache - meinst
> Du Exceptions? Mit "Waechter" fange ich so rein gar nichts an :-)

Im englischen wäre es "Guaridan". ;) Aber ich sehe, dass es dir bereits
erklärt wurde.

>>Wenn dich die vernüftige Logik schon nicht überzeugt:
>
> Ich sage gar nicht, dass mich das nicht ueberzeugt. Bloss wenn ich
> jetzt "klar, so soll es sein und nicht anders" schreibe, ist die
> Diskussion vorbei. Da eine Umsetzung sowieso eher eine Frage von
> Monaten ist, kann ich ruhig noch ein paar Aspekte durchkauen und
> hinterher abwaegen.

Nur weil du sagst "so soll es sein [..]" bedeutet es nicht das Ende des
Diskurses. Abgesehend davon, dass man diesen auch privat weiterführen
kann ;)

>>Stelle dir vor, du möchtest eine Fehlermeldung ändern und
>>vertippst dich dabei: Dann ist dein Programm auf einmal kaputt.
>>Auf Grund einer lausigen Ausgabe wird deine komplette
>>Programmlogik zerstört. Mit ein wenig Glück liegt es an einem kaum
>>zu sehenden Escapezeichen und beschäftigt dich ein paar Stunden.
>>Wenn man Text dort hin packt, wo er hingehört, hat sich das
>>Problem erledigt.
>
> Hm. Solange die Datei mit den Fehlermeldungen ein require ist, macht
> es keinen echten Unterschied:

Seid wann gehört Text in eine ausführbare Datei? Es heißt nicht umsonst
_Text_datei. ;)

>>>Die _sind_ mehrsprachig, dafuer habe ich ja gettext!
>
>>Ach - ein gettexter :P
>
> Gibt es denn etwas anderes?

Klar - die Frage ist natürlich wie sinnvoll was ist. Bei wenigen
Sprachen reichen häufig einfache Textdateien mit den jeweiligen
Übersetzungen.

Bei mir trat/tritt nur häufig der Fall auf, dass ich keine sinnvolle
Anwendung für gettext finde.

> Im Ernst: ich kenne sonst kein System, das mir meine Texte aus
> PHP- und C-Code, aus Templates, Datenbanken und Excel-Vorlagen
> extrahiert.

Wie gesagt: Text hat nichts im Code zu suchen.
>>>| $errors['mediafile'] = err_file_notfound_media;
>
>>Nicht zwangsweise. Ich habe versucht anzudeuten, dass die
>>Fehlerbehandlungsreichweite groß ist. Ich kann einem Observer
>>bescheidsagen, dass etwas schief gelaufen ist. Ich kann auch PHP
>>Warnings, Notices und Erros ausgeben. Ich kann das Programm sofort
>>terminieren.
>
> Die letzten Dinge versuche ich eigentlich konsequent zu vermeiden.
> Eine PHP-Meldung im Error-Log deutet hier stets auf _meinen_ Fehler
> hin, nicht auf einen zu erwarteten Programmzustand.

Richtig: Aber es ist sinnvoll eigene Fehler einzuplanen und abzufangen.
So kann eine nicht korrekt erkannte fehlerhafte Konfiguration abgefangen
werden und ein Vertipper in einem völlig anderen Applikations"ende"
aufgedeckt werden. Mal ganz zu schweigen, dass im Super-Gau des RCE die
Applikation nicht beliebig zweckentfremdet werden kann. Obwohl man dann
sicherlich andere sorgen haben sollte :P

>>>Hm. Damit bin ich wieder am Anfang meiner Ueberlegungen, genau
>>>das gefaellt mir in der Menge eben nicht.
>
>>Wo siehst du da die Menge? Fehlercodes sind wesentlich kürzer als
>>Text :P
>
> Ich befuerchte zunaechst Probleme bei der konsequenten Benennung,
> insbesondere im Zug von Programmerweiterungen. Im weiteren
> befuerchte ich dann allgemeines Chaos eben durch inkonsequente
> Namensgebung.

Das klingt nach fauler Ausrede. Es ist nun wirklich einfach eine
konsequente Benennung durchzuführen. Klassendefinitionen,
Funktionsbibliotheken, Funktionen usw. sind nicht unendlich groß,
sondern haben für gewöhnlich eine Größe, die das ganze wartbar hält.
Heutzutage sagt man pro Klasse ca. 600 Zeilen und pro Funktion/Methode
ca. 40 Zeilen. Du kannst dir also ausrechnen, wieviel Fehlermeldungen
eine Klasse/Methode maximal werfen kann und so für entsprechende
numerische Räume sorgen.

>>>Geprueft werden muessen die Inhalte ohnehin, und jedes Formular
>>>verwendet bei korrekter Anwendung nur _entweder_ PUT _oder_ GET.
>>>Macht der Anwender vorsaetzlich Unsinn und fliegt bei der Pruefung
>>>auf die Nase, ist das nun wirklich sein Problem.
>
>>Wie kommst du auf das schmale Brett, dass deine Formular [korrekt]
>>angewendet werden? Sobald ich auch nur 5 Minuten Zeit habe, ist es
>>genau das, was ich _nicht_ mache.
>
> Selber schuld, dann gebuehrt Dir kein Mitleid :)

Bisher tut es immer den Entwicklern leid. Besonders jenen, die JS als
Validierung verwenden *hust*

> Ganz im Ernst: wenn jemand bereits vorsaetzlich eigene GET- oder
> POST-Werte an meine Software verfuettert, dann hat er auch die
> Faehigkeit, sich das eine oder andere auszusuchen, ergo ist die
> Unterscheidung dazwischen erst recht _vollkommen_ egal.

Ja und Nein.

> Und dann: alles, was ankommt, wird abgefragt und ggf. die weitere
> Ausfuehrung mangels Berechtigung verweigert. Ueberlagert jemand
> einen sinnvollen POST-Wert durch einen sinnlosen GET-Wert, bekommt
> er schlimmstenfalls eine sinnlose (aber unkritische) Ausgabe. _Mir_
> ist das gleichgueltig, und der Anwender weiss ja wohl, woher es
> kommt.

Seltsame Konfiguration hast du. Die am häufigsten verwende Registrierung
ist doch (vermutlich) "EGPCS".Das heißt, dass dein Get durch einen Post
überlagert wird. Was allerdings nicht passiert, wenn du Get und Post
getrennt verwendest.

>>Wenn ich erwarte, dass man mir Formulardaten per $_POST übergibt
>>und die kommen auf einmal per $_GET, dann habe ich doch schon den
>>ersten Anhaltspunkt für einen Angriff.
>
> Und was tust Du dann mit diesem Wissen? :-)

Eine weitere Ausführung unterbinden.
Soetwas verlangt ein restriktiven Sicherheitssystem.
Man bereinigt/verwendet nicht Daten, von denen man weiß, dass sie nicht
aus der gewünschten Quelle stammen.

>>so verhindert man z.b. eine ungewollte Datenkombination oder kann
>>sicherstellen, dass das Formular korrekt verwendet wird.
>
> Auch nicht leichter, da man die "richtigen" Variablen genau den
> gleichen Pruefungen unterziehen muss.

Richtig. Aber eine Prüfung sollte auch die Quelle umfassen. Falsche
Quelle -> falsche Daten. Ausführung Ende. Irgendwelche Behandlungen mit
überschriebenen und ungewollten Datenkombinationen gleicht ja schon fast
einer "Bereinigung" fehlerhafter Daten.

Gruß,
Torsten

Re: Trennung von Programmlogik und Texten

On Mon, 09 Oct 2006 12:17:04 +0200 Torsten Zuehlsdorff wrote:
> > Ich sage gar nicht, dass mich das nicht ueberzeugt. Bloss wenn
> > ich jetzt "klar, so soll es sein und nicht anders" schreibe, ist
> > die Diskussion vorbei. Da eine Umsetzung sowieso eher eine Frage
> > von Monaten ist, kann ich ruhig noch ein paar Aspekte durchkauen
> > und hinterher abwaegen.

> Nur weil du sagst "so soll es sein [..]" bedeutet es nicht das
> Ende des Diskurses. Abgesehend davon, dass man diesen auch privat
> weiterführen kann ;)

News haben den Vorteil, dass ich einen gewissen zeitlichen Druck
zum Antworten habe. Per Mail dauert das mitunter gleich ein paar
Wochen :-/. Aber noch sind wir ja halbwegs beim Thema.

> >>Stelle dir vor, du möchtest eine Fehlermeldung ändern und
> >>vertippst dich dabei: Dann ist dein Programm auf einmal kaputt.
> >>Auf Grund einer lausigen Ausgabe wird deine komplette
> >>Programmlogik zerstört.

> > Hm. Solange die Datei mit den Fehlermeldungen ein require ist,
> > macht es keinen echten Unterschied:

> Seid wann gehört Text in eine ausführbare Datei? Es heißt nicht
> umsonst _Text_datei. ;)

Bei einer Skriptsprache ist das Programm auch Text. Aber ok, ja, man
kann das ganze natuerlich auch noch deutlich eleganter verpacken.
Hilft aber eh alles nichts, da ich von gettext alleine schon wegen
des Plural-Handlings nicht abgehen werde.

> Bei mir trat/tritt nur häufig der Fall auf, dass ich keine
> sinnvolle Anwendung für gettext finde.

Gibst Du nirgendwo an Zahlen angepasste Meldungen aus? Fast jede
Liste mit Ueberschrift hat bei mir so etwas ("Der folgende Fehler
ist aufgetreten" vs. "Die folgenden Fehler sind aufgetreten").

> >>Ich habe versucht anzudeuten, dass die
> >>Fehlerbehandlungsreichweite groß ist. Ich kann einem Observer
> >>bescheidsagen, dass etwas schief gelaufen ist. Ich kann auch PHP
> >>Warnings, Notices und Erros ausgeben. Ich kann das Programm
> >>sofort terminieren.

> > Die letzten Dinge versuche ich eigentlich konsequent zu
> > vermeiden. Eine PHP-Meldung im Error-Log deutet hier stets auf
> > _meinen_ Fehler hin, nicht auf einen zu erwarteten
> > Programmzustand.

> Richtig: Aber es ist sinnvoll eigene Fehler einzuplanen und
> abzufangen.

Ein klassischer "interner" Fehler sind beispielsweise Dateien, die
sich nicht oeffnen lassen (weil z.B. der Name der $_FILES Variable
falsch geschrieben ist, oder aehnliches). Hole ich mir da eine
Meldung von ganz innen, hilft die dem Anwender auch nicht weiter,
denn der hat ja alles richtig gemacht. Selbst finde ich das dann
schon relativ schnell.

Oder, vergleichbar haeufig, der Aufruf einer Methode von etwas, das
kein Objekt ist (weil die Initialisierung vergessen wurde). Da habe
ich dann sogar schon die Zeilennummer im errorlog, trotzdem moechte
ich das nicht ueber das programminterne Fehlersystem laufen lassen,
weil es dort einfach nicht dazupasst. Da kommt bestenfalls noch ein
"sorry, hier ist etwas faul"-Bildschirm.

Moegliche Fehler in der Programmlogik fange ich hingegen fast immer
ab, aber die decken sich auch sehr haeufig mit dem, was man durch
boeswillige Eingaben erreichen kann.

> Mal ganz zu schweigen, dass im Super-Gau des RCE die Applikation
> nicht beliebig zweckentfremdet werden kann.

Vielleicht sollte ich dazu sagen, dass sich meine Anwender
vertraglich dazu verpflichten, genau das nicht zu tun *g*

> >>Fehlercodes sind wesentlich kürzer als Text :P

> > Ich befuerchte zunaechst Probleme bei der konsequenten
> > Benennung, insbesondere im Zug von Programmerweiterungen. Im
> > weiteren befuerchte ich dann allgemeines Chaos eben durch
> > inkonsequente Namensgebung.

> Das klingt nach fauler Ausrede.

Mag sein, aber ich kenne mich...

> Es ist nun wirklich einfach eine konsequente Benennung
> durchzuführen. Klassendefinitionen, Funktionsbibliotheken,
> Funktionen usw. sind nicht unendlich groß, sondern haben für
> gewöhnlich eine Größe, die das ganze wartbar hält.

Das ufert mitunter aus. Da ist der XML-Parser, der im Lauf der Jahre
gewachsen ist und inzwischen fuer sich alleine schon 800
unterschiedliche Fehlermeldungen auswerfen kann (ist halt keine ganz
triviale DTD). Und das ist nur ein Datenformat unter mehreren, und
das wiederum nur ein Teilaspekt der Gesamtapplikation.

> Heutzutage sagt man pro Klasse ca. 600 Zeilen und pro Funktion/Methode
> ca. 40 Zeilen.

*seufz*

Da sage ich lieber nichts dazu :)

Numerische Raeume empfinde ich jedenfalls als grausam beim Arbeiten.
Ich habe so etwas fuer ein Berechtigungsschema verwendet -
wesentlich weniger Codes, als Fehlermeldungen, aber trotzdem spiesst
es sich immer wieder einmal wo mit der Systematik. Und dann den
gesamten Quelltext zu durchforsten und zu aendern, ist auch nicht so
toll. Bei Berechtigungen ist es kaum vermeidbar, bei Texten halt
eben schon.

> >>Wie kommst du auf das schmale Brett, dass deine Formular
> >>[korrekt] angewendet werden? Sobald ich auch nur 5 Minuten Zeit
> >>habe, ist es genau das, was ich _nicht_ mache.

> > Selber schuld, dann gebuehrt Dir kein Mitleid :)

> Bisher tut es immer den Entwicklern leid. Besonders jenen, die JS
> als Validierung verwenden *hust*

Wuerde mir nicht leid tun, jeder gefundene Fehler ist ein behobener
Fehler :). Die realen Anwender haben allerdings schlicht keine Zeit
fuer solche Spielereien - wenn ich da nicht irgendwo aus Versehen
einen Link falsch getippt habe, laufen alle Aufrufe strikt nach
Vorgabe (was im Sinn von "Betatest durch den User" gar nicht so toll
ist, aber das kann man denen natuerlich auch nicht gut sagen).

> > Und dann: alles, was ankommt, wird abgefragt und ggf. die
> > weitere Ausfuehrung mangels Berechtigung verweigert. Ueberlagert
> > jemand einen sinnvollen POST-Wert durch einen sinnlosen
> > GET-Wert, bekommt er schlimmstenfalls eine sinnlose (aber
> > unkritische) Ausgabe.

> Seltsame Konfiguration hast du. Die am häufigsten verwende
> Registrierung ist doch (vermutlich) "EGPCS".

Deswegen "schlimmstenfalls". Zwar habe ich bislang immer die Hoheit
ueber die ausfuehrenden Server, aber wer weiss, was noch kommt.

> >>Wenn ich erwarte, dass man mir Formulardaten per $_POST übergibt
> >>und die kommen auf einmal per $_GET, dann habe ich doch schon
> >>den ersten Anhaltspunkt für einen Angriff.

> > Und was tust Du dann mit diesem Wissen? :-)

> Eine weitere Ausführung unterbinden.
> Soetwas verlangt ein restriktiven Sicherheitssystem.

Ich bleibe skeptisch. Ein realer Angreifer wird das gar nicht erst
tun, sondern (viel naheliegender) gleich die "richtigen" Werte
ueberschreiben. Es ist es zwar nicht, aber es hat in etwas den
Effekt von security by obscurity, bzw. sogar noch etwas weniger.

> Aber eine Prüfung sollte auch die Quelle umfassen. Falsche Quelle
> -> falsche Daten. Ausführung Ende.

Ich betrachte $_GET und $_POST beinahe als synonym, abgesehen davon,
dass die verursachenden Aufrufe unterschiedliche Auswirkungen auf
den Browser haben. Cookies haben ja wenigstens noch ein paar
zusaetzliche Attribute, die man sinnvoll einsetzen kann.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich

Stefan wird mehr als Spaß machen!
(Sloganizer)

Re: Trennung von Programmlogik und Texten

Stefan Froehlich schrieb:

> News haben den Vorteil, dass ich einen gewissen zeitlichen Druck
> zum Antworten habe. Per Mail dauert das mitunter gleich ein paar
> Wochen :-/. Aber noch sind wir ja halbwegs beim Thema.

Tut mir leid? :P

>>>>Stelle dir vor, du möchtest eine Fehlermeldung ändern und
>>>>vertippst dich dabei: Dann ist dein Programm auf einmal kaputt.
>>>>Auf Grund einer lausigen Ausgabe wird deine komplette
>>>>Programmlogik zerstört.
>
>>>Hm. Solange die Datei mit den Fehlermeldungen ein require ist,
>>>macht es keinen echten Unterschied:
>
>>Seid wann gehört Text in eine ausführbare Datei? Es heißt nicht
>>umsonst _Text_datei. ;)
>
> Bei einer Skriptsprache ist das Programm auch Text.

Das ist Unsinn. Ansonsten könntest du ja auch behaupten, dass eigentlich
alles irgendwie Text ist.
Bei Skriptsprachen markierst du für gewöhnlich, was ausgewertet werden
soll und was nicht. Du beginnst ja deinen Code mit einen beendest ihn mit ?>. Führst du diese Markierung nicht durch, werden die
übergebenen Daten (auch Texte) nicht ausgewertet. Daher ist es auch
nicht möglich, dass du einen Fehler verursachst, der Auswirkungen auf
dein Programm hat, denn es gehört ja nicht dazu.

>>Bei mir trat/tritt nur häufig der Fall auf, dass ich keine
>>sinnvolle Anwendung für gettext finde.
>
> Gibst Du nirgendwo an Zahlen angepasste Meldungen aus? Fast jede
> Liste mit Ueberschrift hat bei mir so etwas ("Der folgende Fehler
> ist aufgetreten" vs. "Die folgenden Fehler sind aufgetreten").

Doch. Wie behandelt man soetwas mit gettext?

>>>>Ich habe versucht anzudeuten, dass die
>>>>Fehlerbehandlungsreichweite groß ist. Ich kann einem Observer
>>>>bescheidsagen, dass etwas schief gelaufen ist. Ich kann auch PHP
>>>>Warnings, Notices und Erros ausgeben. Ich kann das Programm
>>>>sofort terminieren.
>
>>>Die letzten Dinge versuche ich eigentlich konsequent zu
>>>vermeiden. Eine PHP-Meldung im Error-Log deutet hier stets auf
>>>_meinen_ Fehler hin, nicht auf einen zu erwarteten
>>>Programmzustand.
>
>>Richtig: Aber es ist sinnvoll eigene Fehler einzuplanen und
>>abzufangen.
>
> Ein klassischer "interner" Fehler sind beispielsweise Dateien, die
> sich nicht oeffnen lassen (weil z.B. der Name der $_FILES Variable
> falsch geschrieben ist, oder aehnliches). Hole ich mir da eine
> Meldung von ganz innen, hilft die dem Anwender auch nicht weiter,
> denn der hat ja alles richtig gemacht. Selbst finde ich das dann
> schon relativ schnell.

Dann sind deine Applikationen vielleicht reicht einfach aufgebaut. Bei
meinem aktuellen (Langzeit)Projekt, welches zwar nur ca. 2,5 KLOC
aufweist, ist das genau anders. Wenn ich eine Warnung/Notice/Fehler
bekomme, dann ist die angegebene Zeile _niemals_ die, wo der Fehler auf
auftritt. Aufgrund des komplexeren Designs und den vielen Interaktionen,
muß ich Fehler da abfangen, wo sie herkommen - ansonsten verursachen sie
Fehler in völlig anderen Teilen. Und das kann sehr schwer zu finden sein.

> Oder, vergleichbar haeufig, der Aufruf einer Methode von etwas, das
> kein Objekt ist (weil die Initialisierung vergessen wurde). Da habe
> ich dann sogar schon die Zeilennummer im errorlog, trotzdem moechte
> ich das nicht ueber das programminterne Fehlersystem laufen lassen,
> weil es dort einfach nicht dazupasst. Da kommt bestenfalls noch ein
> "sorry, hier ist etwas faul"-Bildschirm.

Gut, soetwas paßt da wirklich nicht rein. Aber soetwas betrachte ich gar
nicht mehr als "Fehler" in einer fertigen Applikation. Das sind
Vertipper, mehr nicht. Hier gilt der Erfahrungswert:
"Gute (und erfahrene) Programmierer benötigt nur ein Viertel der Zeit
zum finden eines Fehlers [in Relation zu nicht erfahrenen
Programmierern] und machen um den selben Faktor weniger Fehler".

Das selbe gilt für Syntax-Fehler. Mittlerweilen mache ich auf 600 Zeilen
ca. 2 Vertipper, die mir trotz Highlighting nicht auffallen. Das ist
ziemlich wenig, aber leider eine Folge der vielen syntaxtischen
"Symbole" in PHP wie auch in vielen anderen Sprachen. Aber mit ein wenig
Zeit werde ich das für mich persönlich ändern :P

>>Mal ganz zu schweigen, dass im Super-Gau des RCE die Applikation
>>nicht beliebig zweckentfremdet werden kann.
>
> Vielleicht sollte ich dazu sagen, dass sich meine Anwender
> vertraglich dazu verpflichten, genau das nicht zu tun *g*

Ein guter Schritt, aber wie findest du heraus, wer es war? ;)

>>>>Fehlercodes sind wesentlich kürzer als Text :P
>
>>>Ich befuerchte zunaechst Probleme bei der konsequenten
>>>Benennung, insbesondere im Zug von Programmerweiterungen. Im
>>>weiteren befuerchte ich dann allgemeines Chaos eben durch
>>>inkonsequente Namensgebung.
>
>>Das klingt nach fauler Ausrede.
>
> Mag sein, aber ich kenne mich...

Betrachte es als Möglichkeit an dir selbst zu arbeiten. An PHP-Code kann
man wunderbar ablesen, wie dizipliniert und gut ein Programmierer
arbeitet. Im Gegensatz zu vielen anderen Sprachen läßt PHP viel
Spielraum in der Codeerstellung und der Anwendung verschiedener
Konzepte. Und ein Programmierer weiß soetwas auszunutzen :)

>>Es ist nun wirklich einfach eine konsequente Benennung
>>durchzuführen. Klassendefinitionen, Funktionsbibliotheken,
>>Funktionen usw. sind nicht unendlich groß, sondern haben für
>>gewöhnlich eine Größe, die das ganze wartbar hält.
>
> Das ufert mitunter aus. Da ist der XML-Parser, der im Lauf der Jahre
> gewachsen ist und inzwischen fuer sich alleine schon 800
> unterschiedliche Fehlermeldungen auswerfen kann (ist halt keine ganz
> triviale DTD). Und das ist nur ein Datenformat unter mehreren, und
> das wiederum nur ein Teilaspekt der Gesamtapplikation.

Schon mal über eine Re-Implementation nachgedacht?

>>Heutzutage sagt man pro Klasse ca. 600 Zeilen und pro Funktion/Methode
>>ca. 40 Zeilen.
>
> *seufz*
>
> Da sage ich lieber nichts dazu :)

Schon mal über eine Re-Implementation nachgedacht? ;)
Wobei ich mit Re-Implementation eigentlich eine Neudesign meine. Ein
häufiger Fehler von Programmierern ist der Hand zum "alles neumachen".
Aber in Code steckt Erfahrung und diese muß man Nutzen.
Wenn Code aber ausufert, dann sagt die Erfahrung, dass das nicht gut
ist. Viele meiner alten Projekte, die stark gewachsen sind, liessen sich
durch ein Neudesign stark verschlanken und vereinfachen und sind nun
wesentlich besser wartbar.

> Numerische Raeume empfinde ich jedenfalls als grausam beim Arbeiten.
> Ich habe so etwas fuer ein Berechtigungsschema verwendet -
> wesentlich weniger Codes, als Fehlermeldungen, aber trotzdem spiesst
> es sich immer wieder einmal wo mit der Systematik. Und dann den
> gesamten Quelltext zu durchforsten und zu aendern, ist auch nicht so
> toll.

Du kannst in mehreren Dateien suchen und ersetzen? :P

>>>>Wie kommst du auf das schmale Brett, dass deine Formular
>>>>[korrekt] angewendet werden? Sobald ich auch nur 5 Minuten Zeit
>>>>habe, ist es genau das, was ich _nicht_ mache.
>
>>>Selber schuld, dann gebuehrt Dir kein Mitleid :)
>
>>Bisher tut es immer den Entwicklern leid. Besonders jenen, die JS
>>als Validierung verwenden *hust*
>
>
> Wuerde mir nicht leid tun, jeder gefundene Fehler ist ein behobener
> Fehler :).

Was vorraussetzt, dass ich dir das auch noch mitteilen würde. ;)

> Die realen Anwender haben allerdings schlicht keine Zeit
> fuer solche Spielereien - wenn ich da nicht irgendwo aus Versehen
> einen Link falsch getippt habe, laufen alle Aufrufe strikt nach
> Vorgabe (was im Sinn von "Betatest durch den User" gar nicht so toll
> ist, aber das kann man denen natuerlich auch nicht gut sagen).

Das stimmt. Erfahrungsgemäß sagt man auch, dass 99,99% der Anwender das
Formular vernüftig verwenden - aber die 0,01% sind jene, die den Schaden
anrichten (können).

>>>>Wenn ich erwarte, dass man mir Formulardaten per $_POST übergibt
>>>>und die kommen auf einmal per $_GET, dann habe ich doch schon
>>>>den ersten Anhaltspunkt für einen Angriff.
>
>>>Und was tust Du dann mit diesem Wissen? :-)
>
>>Eine weitere Ausführung unterbinden.
>>Soetwas verlangt ein restriktiven Sicherheitssystem.
>
> Ich bleibe skeptisch. Ein realer Angreifer wird das gar nicht erst
> tun, sondern (viel naheliegender) gleich die "richtigen" Werte
> ueberschreiben. Es ist es zwar nicht, aber es hat in etwas den
> Effekt von security by obscurity, bzw. sogar noch etwas weniger.

Auch unter den Angreifern gibt es Abstufungen. Die meisten schaffen es
z.b. URL-Parameter zu manipulieren, wissen aber nicht, wie man ein
POST-Request absendet. Einfach gesagt: Je größer das nötige Fachwissen
zum Umgehen des Schutzes sein muß, desto weniger Menschen gibt es, die
das können. Wenn man Post und Get restriktiv behandelt, hält man sich
wirklich _viele_ Angreifer vom Hals.

>>Aber eine Prüfung sollte auch die Quelle umfassen. Falsche Quelle
>>-> falsche Daten. Ausführung Ende.
>
> Ich betrachte $_GET und $_POST beinahe als synonym, abgesehen davon,
> dass die verursachenden Aufrufe unterschiedliche Auswirkungen auf
> den Browser haben.

Und genau das sind sie nicht - im HTTP wird ja nicht umsonst zwischen
Post und Get unterschieden. Und wie gesagt: Sie sind die erste Hürde für
ein Haufen von kleinen Hacker-Kiddies, die herausgefunden haben, dass
man URLs auch selbst ändern kann ;)

Gruß,
Torsten

Re: Trennung von Programmlogik und Texten

Stefan Froehlich schrieb:

> News haben den Vorteil, dass ich einen gewissen zeitlichen Druck
> zum Antworten habe. Per Mail dauert das mitunter gleich ein paar
> Wochen :-/. Aber noch sind wir ja halbwegs beim Thema.

Tut mir leid? :P

>>>>Stelle dir vor, du möchtest eine Fehlermeldung ändern und
>>>>vertippst dich dabei: Dann ist dein Programm auf einmal kaputt.
>>>>Auf Grund einer lausigen Ausgabe wird deine komplette
>>>>Programmlogik zerstört.
>
>>>Hm. Solange die Datei mit den Fehlermeldungen ein require ist,
>>>macht es keinen echten Unterschied:
>
>>Seid wann gehört Text in eine ausführbare Datei? Es heißt nicht
>>umsonst _Text_datei. ;)
>
> Bei einer Skriptsprache ist das Programm auch Text.

Das ist Unsinn. Ansonsten könntest du ja auch behaupten, dass eigentlich
jeder Code irgendwie Text ist.
Bei Skriptsprachen markierst du für gewöhnlich, was ausgewertet werden
soll und was nicht. Du beginnst ja deinen PHP-Code mit einen beendest ihn mit ?>. Führst du diese Markierung nicht durch, werden die
übergebenen Daten (auch Texte) nicht ausgewertet. Daher ist es auch
nicht möglich, dass du einen Fehler verursachst, der Auswirkungen auf
dein Programm hat, denn es gehört ja nicht dazu.

>>Bei mir trat/tritt nur häufig der Fall auf, dass ich keine
>>sinnvolle Anwendung für gettext finde.
>
> Gibst Du nirgendwo an Zahlen angepasste Meldungen aus? Fast jede
> Liste mit Ueberschrift hat bei mir so etwas ("Der folgende Fehler
> ist aufgetreten" vs. "Die folgenden Fehler sind aufgetreten").

Doch. Wie behandelt man soetwas mit gettext?

>>>>Ich habe versucht anzudeuten, dass die
>>>>Fehlerbehandlungsreichweite groß ist. Ich kann einem Observer
>>>>bescheidsagen, dass etwas schief gelaufen ist. Ich kann auch PHP
>>>>Warnings, Notices und Erros ausgeben. Ich kann das Programm
>>>>sofort terminieren.
>
>>>Die letzten Dinge versuche ich eigentlich konsequent zu
>>>vermeiden. Eine PHP-Meldung im Error-Log deutet hier stets auf
>>>_meinen_ Fehler hin, nicht auf einen zu erwarteten
>>>Programmzustand.
>
>>Richtig: Aber es ist sinnvoll eigene Fehler einzuplanen und
>>abzufangen.
>
> Ein klassischer "interner" Fehler sind beispielsweise Dateien, die
> sich nicht oeffnen lassen (weil z.B. der Name der $_FILES Variable
> falsch geschrieben ist, oder aehnliches). Hole ich mir da eine
> Meldung von ganz innen, hilft die dem Anwender auch nicht weiter,
> denn der hat ja alles richtig gemacht. Selbst finde ich das dann
> schon relativ schnell.

Dann sind deine Applikationen vielleicht reicht einfach aufgebaut. Bei
meinem aktuellen (Langzeit)Projekt, welches zwar nur ca. 2,5 KLOC
aufweist, ist das genau anders. Wenn ich eine Warnung/Notice/Fehler
bekomme, dann ist die angegebene Zeile _niemals_ die, wo der Fehler auf
auftritt. Aufgrund des komplexeren Designs und den vielen Interaktionen,
muß ich Fehler da abfangen, wo sie herkommen - ansonsten verursachen sie
Fehler in völlig anderen Teilen. Und der kann selbst mit Stack-Trace
sehr schwer zu finden sein.

> Oder, vergleichbar haeufig, der Aufruf einer Methode von etwas, das
> kein Objekt ist (weil die Initialisierung vergessen wurde). Da habe
> ich dann sogar schon die Zeilennummer im errorlog, trotzdem moechte
> ich das nicht ueber das programminterne Fehlersystem laufen lassen,
> weil es dort einfach nicht dazupasst. Da kommt bestenfalls noch ein
> "sorry, hier ist etwas faul"-Bildschirm.

Gut, soetwas paßt da wirklich nicht rein. Aber soetwas betrachte ich gar
nicht mehr als "Fehler" in einer fertigen Applikation. Das sind
Vertipper, mehr nicht. Hier gilt der Erfahrungswert:
"Gute (und erfahrene) Programmierer benötigt nur ein Viertel der Zeit
zum finden eines Fehlers [in Relation zu nicht erfahrenen
Programmierern] und machen um den selben Faktor weniger Fehler".

Das selbe gilt für Syntax-Fehler. Mittlerweilen mache ich auf 600 Zeilen
ca. 2 Vertipper, die mir trotz Highlighting nicht auffallen. Das ist
ziemlich wenig, aber leider eine Folge der vielen syntaxtischen
"Symbole" in PHP wie auch in vielen anderen Sprachen. Aber mit ein wenig
Zeit werde ich das für mich persönlich ändern :P

>>Mal ganz zu schweigen, dass im Super-Gau des RCE die Applikation
>>nicht beliebig zweckentfremdet werden kann.
>
> Vielleicht sollte ich dazu sagen, dass sich meine Anwender
> vertraglich dazu verpflichten, genau das nicht zu tun *g*

Ein guter Schritt, aber wie findest du heraus, wer es war? ;)

>>>>Fehlercodes sind wesentlich kürzer als Text :P
>
>>>Ich befuerchte zunaechst Probleme bei der konsequenten
>>>Benennung, insbesondere im Zug von Programmerweiterungen. Im
>>>weiteren befuerchte ich dann allgemeines Chaos eben durch
>>>inkonsequente Namensgebung.
>
>>Das klingt nach fauler Ausrede.
>
> Mag sein, aber ich kenne mich...

Betrachte es als Möglichkeit an dir selbst zu arbeiten. An PHP-Code kann
man wunderbar ablesen, wie dizipliniert und gut ein Programmierer
arbeitet. Im Gegensatz zu vielen anderen Sprachen läßt PHP viel
Spielraum in der Codeerstellung und der Anwendung verschiedener
Konzepte. Und ein Programmierer weiß soetwas auszunutzen :)

>>Es ist nun wirklich einfach eine konsequente Benennung
>>durchzuführen. Klassendefinitionen, Funktionsbibliotheken,
>>Funktionen usw. sind nicht unendlich groß, sondern haben für
>>gewöhnlich eine Größe, die das ganze wartbar hält.
>
> Das ufert mitunter aus. Da ist der XML-Parser, der im Lauf der Jahre
> gewachsen ist und inzwischen fuer sich alleine schon 800
> unterschiedliche Fehlermeldungen auswerfen kann (ist halt keine ganz
> triviale DTD). Und das ist nur ein Datenformat unter mehreren, und
> das wiederum nur ein Teilaspekt der Gesamtapplikation.

Schon mal über eine Re-Implementation nachgedacht?

>>Heutzutage sagt man pro Klasse ca. 600 Zeilen und pro Funktion/Methode
>>ca. 40 Zeilen.
>
> *seufz*
>
> Da sage ich lieber nichts dazu :)

Schon mal über eine Re-Implementation nachgedacht? ;)

Wobei ich mit Re-Implementation eigentlich eine Neudesign meine. Ein
häufiger Fehler von Programmierern ist der Hang zum "alles neu machen".
Aber in Code steckt Erfahrung und diese muß man nutzen.
Wenn Code aber ausufert, dann sagt die Erfahrung, dass das nicht gut
ist. Viele meiner alten Projekte, die stark gewachsen sind, liessen sich
durch ein Neudesign stark verschlanken und vereinfachen und sind nun
wesentlich besser wartbar.

> Numerische Raeume empfinde ich jedenfalls als grausam beim Arbeiten.
> Ich habe so etwas fuer ein Berechtigungsschema verwendet -
> wesentlich weniger Codes, als Fehlermeldungen, aber trotzdem spiesst
> es sich immer wieder einmal wo mit der Systematik. Und dann den
> gesamten Quelltext zu durchforsten und zu aendern, ist auch nicht so
> toll.

Du kannst in mehreren Dateien suchen und ersetzen? :P

>>>>Wie kommst du auf das schmale Brett, dass deine Formular
>>>>[korrekt] angewendet werden? Sobald ich auch nur 5 Minuten Zeit
>>>>habe, ist es genau das, was ich _nicht_ mache.
>
>>>Selber schuld, dann gebuehrt Dir kein Mitleid :)
>
>>Bisher tut es immer den Entwicklern leid. Besonders jenen, die JS
>>als Validierung verwenden *hust*
>
> Wuerde mir nicht leid tun, jeder gefundene Fehler ist ein behobener
> Fehler :).

Was vorraussetzt, dass ich dir das auch noch mitteilen würde. ;)

> Die realen Anwender haben allerdings schlicht keine Zeit
> fuer solche Spielereien - wenn ich da nicht irgendwo aus Versehen
> einen Link falsch getippt habe, laufen alle Aufrufe strikt nach
> Vorgabe (was im Sinn von "Betatest durch den User" gar nicht so toll
> ist, aber das kann man denen natuerlich auch nicht gut sagen).

Das stimmt. Erfahrungsgemäß sagt man aber auch, dass 99,99% der Anwender
das Formular vernüftig verwenden - aber die 0,01% sind jene, die den
Schaden anrichten (können).

>>>>Wenn ich erwarte, dass man mir Formulardaten per $_POST übergibt
>>>>und die kommen auf einmal per $_GET, dann habe ich doch schon
>>>>den ersten Anhaltspunkt für einen Angriff.
>
>>>Und was tust Du dann mit diesem Wissen? :-)
>
>>Eine weitere Ausführung unterbinden.
>>Soetwas verlangt ein restriktiven Sicherheitssystem.
>
> Ich bleibe skeptisch. Ein realer Angreifer wird das gar nicht erst
> tun, sondern (viel naheliegender) gleich die "richtigen" Werte
> ueberschreiben. Es ist es zwar nicht, aber es hat in etwas den
> Effekt von security by obscurity, bzw. sogar noch etwas weniger.

Auch unter den Angreifern gibt es Abstufungen. Die meisten schaffen es
z.b. URL-Parameter zu manipulieren, wissen aber nicht, wie man ein
POST-Request absendet. Einfach gesagt: Je größer das nötige Fachwissen
zum Umgehen des Schutzes sein muß, desto weniger Menschen gibt es, die
das können. Wenn man Post und Get restriktiv behandelt, hält man sich
wirklich _viele_ Angreifer vom Hals.
Wie hoch der Schutz sein soll, ist letztlich eine einfache
Kosten-Nutzen-Rechnung.

>>Aber eine Prüfung sollte auch die Quelle umfassen. Falsche Quelle
>>-> falsche Daten. Ausführung Ende.
>
> Ich betrachte $_GET und $_POST beinahe als synonym, abgesehen davon,
> dass die verursachenden Aufrufe unterschiedliche Auswirkungen auf
> den Browser haben.

Und genau das sind sie nicht - im HTTP wird ja nicht umsonst zwischen
Post und Get unterschieden. Und wie gesagt: Sie sind die erste Hürde für
ein Haufen von kleinen Hacker-Kiddies, die herausgefunden haben, dass
man URLs auch selbst ändern kann ;)

Gruß,
Torsten

Re: Trennung von Programmlogik und Texten

On Fri, 13 Oct 2006 10:29:50 +0200 Torsten Zuehlsdorff wrote:
> >>Seid wann gehört Text in eine ausführbare Datei? Es heißt nicht
> >>umsonst _Text_datei. ;)

> > Bei einer Skriptsprache ist das Programm auch Text.

> Das ist Unsinn. Ansonsten könntest du ja auch behaupten, dass
> eigentlich jeder Code irgendwie Text ist.

Naja, C-Objektcode ist definitv kein Text mehr (selbst wenn Du dort
mit dem Hexeditor die Zeichenfolgen aenderst, klappt das nur bei
gleichen Stringlaengen). Es gibt also schon Unterschiede.

> Du beginnst ja deinen PHP-Code mit einen > mit ?>.

IMHO hat das rein historische Gruende wegen der Einbettung in HTML.
Andere Skriptsprachen kommen bestens ohne derartige Tags aus.

> > Gibst Du nirgendwo an Zahlen angepasste Meldungen aus? Fast jede
> > Liste mit Ueberschrift hat bei mir so etwas ("Der folgende
> > Fehler ist aufgetreten" vs. "Die folgenden Fehler sind
> > aufgetreten").

> Doch. Wie behandelt man soetwas mit gettext?

Einmal ganz ohne jeden Schnickschnack:

| echo ngettext(
| "Der folgende Fehler ist aufgetreten:",
| "Die folgenden Fehler sind aufgetreten",
| sizeof($errors)
| );
| echo "

";
| foreach ($errors as $error) echo "
• $error
";
| echo "

Re: Trennung von Programmlogik und Texten

Stefan Froehlich schrieb:

>>>>Seid wann gehört Text in eine ausführbare Datei? Es heißt nicht
>>>>umsonst _Text_datei. ;)
>
>>>Bei einer Skriptsprache ist das Programm auch Text.
>
>>Das ist Unsinn. Ansonsten könntest du ja auch behaupten, dass
>>eigentlich jeder Code irgendwie Text ist.
>
> Naja, C-Objektcode ist definitv kein Text mehr (selbst wenn Du dort
> mit dem Hexeditor die Zeichenfolgen aenderst, klappt das nur bei
> gleichen Stringlaengen). Es gibt also schon Unterschiede.

Da mißverstehen wir uns. Ich habe auf den Quellcode an sich angespielt -
dieser ist immer "irgendwie" Text. Desweiteren ist er das Mittel unserer
Arbeit und muß daher auch vernüftig designt sein.
Desweiteren: Wenn du PHP mal vorkompilierst, wirst du auch keinen Text
mehr finden. Darauf wollte ich hinaus.
Der Text steht im Quellcode. Quellcode wird ausgeführt. Daher ist Text
dort fehl am Platz. ;)

>>>Gibst Du nirgendwo an Zahlen angepasste Meldungen aus? Fast jede
>>>Liste mit Ueberschrift hat bei mir so etwas ("Der folgende
>>>Fehler ist aufgetreten" vs. "Die folgenden Fehler sind
>>>aufgetreten").
>
>>Doch. Wie behandelt man soetwas mit gettext?
>
> Einmal ganz ohne jeden Schnickschnack:
>
> | echo ngettext(
> | "Der folgende Fehler ist aufgetreten:",
> | "Die folgenden Fehler sind aufgetreten",
> | sizeof($errors)
> | );
> | echo "

";
> | foreach ($errors as $error) echo "
• $error
";
> | echo "

Re: Trennung von Programmlogik und Texten

On Mon, 16 Oct 2006 16:03:13 +0200 Torsten Zuehlsdorff wrote:
> >>>>Seid wann gehört Text in eine ausführbare Datei? Es heißt nicht
> >>>>umsonst _Text_datei. ;)

> >>>Bei einer Skriptsprache ist das Programm auch Text.
[...]

> Ich habe auf den Quellcode an sich angespielt - dieser ist immer
> "irgendwie" Text.

Ok, das hatte ich anders verstanden.

> Der Text steht im Quellcode. Quellcode wird ausgeführt. Daher ist
> Text dort fehl am Platz. ;)

Text im Text kann ja schon per Definition kein Problem sein :-)

> >>Wie behandelt man soetwas mit gettext?

> > Einmal ganz ohne jeden Schnickschnack:
> >
> > | echo ngettext(
> > | "Der folgende Fehler ist aufgetreten:",
> > | "Die folgenden Fehler sind aufgetreten",
> > | sizeof($errors)
> > | );
> > | echo "

";
> > | foreach ($errors as $error) echo "
• $error
";
> > | echo "

Re: Trennung von Programmlogik und Texten

Stefan Froehlich schrieb:

>>Der Text steht im Quellcode. Quellcode wird ausgeführt. Daher ist
>>Text dort fehl am Platz. ;)
>
> Text im Text kann ja schon per Definition kein Problem sein :-)

*lach* Eiskalt erwischt :P
ABER: Text !== Code. Code enthält Anweisungen die ausgeführt werden.
Text nicht. Schlägt diese Trennung einmal fehl, wird aufeinmal der Text
ausgeführt. Das ist des Pudels-Kern.

>>>>Wie behandelt man soetwas mit gettext?
>
>>>Einmal ganz ohne jeden Schnickschnack:
>>>
>>>| echo ngettext(
>>>| "Der folgende Fehler ist aufgetreten:",
>>>| "Die folgenden Fehler sind aufgetreten",
>>>| sizeof($errors)
>>>| );
>>>| echo "

";
>>>| foreach ($errors as $error) echo "
• $error
";
>>>| echo "

Re: Trennung von Programmlogik und Texten

On Fri, 20 Oct 2006 10:48:19 +0200 Torsten Zuehlsdorff wrote:
> >>>>Wie behandelt man soetwas mit gettext?
> >>[...] dann hätten wir wieder "Text" im Code. Das kann es nicht
> >>sein.

> > den Rest (i.e. die Mechanismen der Pluralbildung, die einfache
> > Uebersetzbarkeit via poedit und die einheitliche Verwaltung
> > diverser Texte in unterschiedlichsten Projekten) kann man immer
> > noch gut nuetzen.

> Nagut - dann hat sich die Sache für mich erledigt, da sie keine
> Vorteile gegenüber dem normalen Vorgehen bietet.

Solange Du im westeuropaeischen Sprachraum bleibst, stimmt das wohl.

> >>Und es gibt durchaus Fehler, an denen man mehrere Tage sitzt.

> > Das sind dann (bei mir jedenfalls) immer Fehler im Konzept, aber
> > nichts mehr, was sprachbedingt waere.

> Das wäre schade. Konzepte wechseln bei mir (d.h. Privatprojekten)
> häufiger als mir lieb ist, da ich ein gnadenloser Perfektionist
> bin, Träumer, Größenwahnsinniger usw. Find ich auch nur den
> kleinsten Fehler im Konzept ist es dran :P

Das hatte ich im Privatbereich auch so, mit dem Erfolg, kaum eines
meiner Projekte jemals bis zur Einsatzreife gebracht zu haben
(dafuer waren sie sehr elegant, jedenfalls nach meinen damaligen
Massstaeben). Das aktuelle Projekt hat ein paar bekannte Schwaechen,
dafuer wird es gegen Bezahlung eingesetzt :-)

> Fehler die mir Tagelang den Kopf zerbrechen, hängen meist mit
> nicht im Editor dargestellten Sonderzeichen oder interen
> Libary-Problemen von PHP zusammen, die sich nicht vernüftig
> Debuggen lassen.

Ueber letzteres bin ich noch nie gestolpert. Das ekligste waren
bisher UTF-8 Zeichen in Excel-Sheets via Pear, die sich bis dato
nicht loesen liessen. Dort bin ich dann in eine ganz andere Richtung
gegangen.

Ansonsten bemuehe ich mich, kritische (i.e. junge) Teile der Sprache
zu vermeiden.

> >>>Trotzdem ueberlebt so etwas leider hin und wieder bis ins
> >>>Produktivsystem, was nicht wirklich toll ist :-/

> >>Damit mußt du leben ;)

> > Jo. Zumindestens kenne ich noch kein wirksames Gegenmittel dafuer
> > (ausser das Engagement von 1 Mio. Affen, die wahllos auf meine
> > Applikation einhaemmern, aber die bezahlt dann wieder keiner).

> Hm: Test?
> Wenn das für dich ein so großes Problem darstellt, solltest du
> über Unittests nachdenken. Wenn du die hinter dich gebracht hast,
> solltest du Integrationstests durchführen.

Das hilft bis zu einem gewissen Grad. Die Natur der Software
verlangt allerdings sehr hohe Konfigurierbarkeit - es gibt zwei
Dutzend fundamentale Schalter, mit denen man einiges anstellen kann.
Dadurch wird das Testen, selbst auf unterster Ebene, nicht unbedingt
erleichtert. Von speziellen Bosheiten, wie Funktionen, die
ueberhaupt erst nach Erfuellung umfangreicher Vorbedingungen zur
Verfuegung stehen, einmal ganz abgesehen.

> Ich bin zwar kein allzu großer Freund von Unittests, ABER sie
> helfen ungemein, die Qualität zu steigern.

Das steht auch immer noch als TODO am Programm, ja.

> > einen Code-Generator habe ich als Dissertation verfasst, das
> > reicht fuer's Leben).

> *lach* Kann ich nicht ganz, aber zum Teil nachvollziehen. Ich sehe
> jetzt einfach die Vorteile, die soetwas hätte: Korrigierte
> Interfaces, vereinfachte Syntax, bessere Les- und Wartbarkeit (da
> Befehle frei wählbar - aus fnmatch kann FILENAME-MATCH werden
> usw.) und die Simulation fehlender Features wie Namespaces,
> Überlagerung, Überladen, Erben von mehreren Objekten gleichzeitig
> (letzte 3 im gewissen Rahmen).

Dafuer dann halt wieder subtile Fehler, die man im Codegenerator
machen kann...

> Die Ironie ist, dass man PHP verwendet, um PHP das beizubringen,
> was fehlt.

Nach eigenem Ermessen "fehlt". Anderen Entwicklern koennte das in
weiterer Folge, die Arbeit ordentlich erschweren, und zB das
Syntax-Highlighting und dergleichen muesste ich mir auch selbst
definieren. Maessig lustig.

> > Wenn, dann mache ich so etwas sicherlich auch nur zum Spass. Und
> > zwar deshalb, weil ich gerade in diesem Fall das Konzept
> > sicherlich 10x ueberarbeite, bis ich auch nur annaehernd etwas
> > produktives erreicht habe. Gerade derartige Dinge tendieren
> > dazu, ein sehr intensives Eigenleben zu entwickeln.

> Ich gehe meist wie folgt vor:
> 1. Ideen sammeln
> 2. Ideen codetechnisch ausprobieren
> 3. Konzept erarbeiten

Das ist schon, aber: wie lange brauchst Du fuer die drei Schritte
(die greifen ja auch sicherlich ineinander)? Ich sehe hier vor allem
ein zeitliches Problem. PHP ist gerade deshalb so interessant, weil
man relativ rasch entwickeln kann ("fast alles" ist schon irgendwo
als Befehl vorhanden). Durch Aufbau eines eigenen Codegenerators
macht man diesen Zeitvorteil ja wieder zunichte.

> > Dabei setzt Perl obiges Paradigma noch viel besser um - auch
> > dort _kann_ man schoene Programme schreiben, allerdings kenne
> > ich bestenfalls drei Leute, die das auch tun :)

> Gut, damit kennst du mehr als ich, aber das ist nicht das Problem
> ;) Ich halte es schlichtweg für zu beschränkt.

Inzwischen, ja. 99/00 haben die Diskussionen noch einen ganz anderen
Verlauf genommen.

> Lisp hat mich da noch immer beeindruckt - auch wenn ich nicht
> alles gut heißen kann - und die einzige Sprache, die ich neben
> Lisp noch außerordentlich respektiere ist Forth

Lisp ist fuer mich persoenlich schlicht unlesbar, Forth hingegen
habe ich heiss geliebt - wobei meine Forth-Programme eher write-only
waren.

> Genau genommen ist es zu tiefst deprimierent, wenn man sieht wo
> wir heute sind und wo wir vor ein paar Jahr(en)/(zehnten) waren...

Jein. Man kann die Verflachung der Programmiersprachen auch als
Fortschritt der Hardwareseite betrachten. Jetzt _koennen_ wir uns
das erlauben.

[Normenumsetzung in langem Code vs. einzelnen Klassen]
> Das ändert aber nichts an der leichteren Wartbarkeit. Und wo ich
> es noch mal lese: Fabrik und Zustands-Pattern kombinieren und
> schon hättest du deine kleinen schönen Klassen und das ganze wäre
> wartbarer und lesbarer - so behaupte ich jetzt ganz unverfroren ;)

Ein Praxistest waere natuerlich interessant. Ob Du nur dafuer 2
Wochen lang angegraute Normen studieren moechtest, weiss ich
allerdings nicht :-)

> >>>Synonym nicht, was ihre Bedeutung im Protokoll betrifft,
> >>>sondern was die Vertrauenswuerdigkeit (und damit die
> >>>Zulaessigkeit) der Datenquellen betrifft.

> >>Wozu? Alles von außen ist böse. Punkt.

> > Nein, alles was schaden anrichten kann, ist boese.

> Und woher weißt du, was Schaden anrichten kann und was nicht?

Zumindestens kann alles, was per PUT statt GET (oder umgekehrt)
hereinkommt, genau den gleichen Schaden anrichten, wie das, was
mittels der erwarteten Methode hereinkommt: nicht mehr, aber auch
nicht weniger. Also verdient es auch die gleiche Behandlung :)

Uebersehen kann ich dabei natuerlich immer noch etwas, aber das gilt
dann ohnehin im anderen Fall auch.

> >>Du solltest nicht mal $_SERVER trauen, da ich User-Agent und was
> >>weiß ich nicht alles auch einfach ändern kann ;)

> > Ich wuesste ohnehin nicht, was ich mit dem User-Agent anfangen
> > wollte...

> Es ist doch Mode, zu wissen, mit welchen Browser die eigene,
> geliebte Seite aufgerufen wurde.

Nicht nur bei der Kleidung ist mir die Mode relativ egal...

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich

Stefan. Für unerhörte Hacker, ein Märchen für Pärchen!
(Sloganizer)

Re: Trennung von Programmlogik und Texten

Stefan Froehlich schrieb:

>>>>>>Wie behandelt man soetwas mit gettext?
>>>>
>>>>[...] dann hätten wir wieder "Text" im Code. Das kann es nicht
>>>>sein.
>
>>>den Rest (i.e. die Mechanismen der Pluralbildung, die einfache
>>>Uebersetzbarkeit via poedit und die einheitliche Verwaltung
>>>diverser Texte in unterschiedlichsten Projekten) kann man immer
>>>noch gut nuetzen.
>
>>Nagut - dann hat sich die Sache für mich erledigt, da sie keine
>>Vorteile gegenüber dem normalen Vorgehen bietet.
>
> Solange Du im westeuropaeischen Sprachraum bleibst, stimmt das wohl.

Wo siehst du das Problem für andere Sprachräume?

>>>>Und es gibt durchaus Fehler, an denen man mehrere Tage sitzt.
>
>>>Das sind dann (bei mir jedenfalls) immer Fehler im Konzept, aber
>>>nichts mehr, was sprachbedingt waere.
>
>>Das wäre schade. Konzepte wechseln bei mir (d.h. Privatprojekten)
>>häufiger als mir lieb ist, da ich ein gnadenloser Perfektionist
>>bin, Träumer, Größenwahnsinniger usw. Find ich auch nur den
>>kleinsten Fehler im Konzept ist es dran :P
>
> Das hatte ich im Privatbereich auch so, mit dem Erfolg, kaum eines
> meiner Projekte jemals bis zur Einsatzreife gebracht zu haben
> (dafuer waren sie sehr elegant, jedenfalls nach meinen damaligen
> Massstaeben). Das aktuelle Projekt hat ein paar bekannte Schwaechen,
> dafuer wird es gegen Bezahlung eingesetzt :-)

Das ist bei mir ähnlich und gewollt. Es kann durchaus passieren, dass
ich 3 Jahre an ein paar tausend Zeilen werkel - aber daran kann ich dann
auch wirklich nichts mehr aussetzen.

> Ansonsten bemuehe ich mich, kritische (i.e. junge) Teile der Sprache
> zu vermeiden.

Das ist nicht hilfreich. Es gibt in PHP genügend alte Teile, die bis
heute als "CVS Only" gepflegt und dennoch produktiv eingesetzt werden.
Siehe z.b. SOAP. Anderseits gibt es auch etablierte, gewartete, aber
schlecht wartbare Teile der Sprache: siehe z.b. DomDocument.

> [Vorschlag: Unittest]
>
> Das hilft bis zu einem gewissen Grad. Die Natur der Software
> verlangt allerdings sehr hohe Konfigurierbarkeit - es gibt zwei
> Dutzend fundamentale Schalter, mit denen man einiges anstellen kann.
> Dadurch wird das Testen, selbst auf unterster Ebene, nicht unbedingt
> erleichtert. Von speziellen Bosheiten, wie Funktionen, die
> ueberhaupt erst nach Erfuellung umfangreicher Vorbedingungen zur
> Verfuegung stehen, einmal ganz abgesehen.

Darin sehe ich jetzt ehrlich gesagt kein Problem - eher Fleißarbeit.

>>>einen Code-Generator habe ich als Dissertation verfasst, das
>>>reicht fuer's Leben).
>
>>*lach* Kann ich nicht ganz, aber zum Teil nachvollziehen. Ich sehe
>>jetzt einfach die Vorteile, die soetwas hätte: Korrigierte
>>Interfaces, vereinfachte Syntax, bessere Les- und Wartbarkeit (da
>>Befehle frei wählbar - aus fnmatch kann FILENAME-MATCH werden
>>usw.) und die Simulation fehlender Features wie Namespaces,
>>Überlagerung, Überladen, Erben von mehreren Objekten gleichzeitig
>>(letzte 3 im gewissen Rahmen).
>
> Dafuer dann halt wieder subtile Fehler, die man im Codegenerator
> machen kann...

Die wären?

>>Die Ironie ist, dass man PHP verwendet, um PHP das beizubringen,
>>was fehlt.
>
> Nach eigenem Ermessen "fehlt". Anderen Entwicklern koennte das in
> weiterer Folge, die Arbeit ordentlich erschweren, und zB das
> Syntax-Highlighting und dergleichen muesste ich mir auch selbst
> definieren. Maessig lustig.

Das Highlighting hängt von deinem Editor ab. Ist dieser vernünftig
gewählt, werde ich dir eigenhändig das dazu notwendige PlugIn erstellen ;)

>>>Wenn, dann mache ich so etwas sicherlich auch nur zum Spass. Und
>>>zwar deshalb, weil ich gerade in diesem Fall das Konzept
>>>sicherlich 10x ueberarbeite, bis ich auch nur annaehernd etwas
>>>produktives erreicht habe. Gerade derartige Dinge tendieren
>>>dazu, ein sehr intensives Eigenleben zu entwickeln.
>
>>Ich gehe meist wie folgt vor:
>>1. Ideen sammeln
>>2. Ideen codetechnisch ausprobieren
>>3. Konzept erarbeiten
>
> Das ist schon, aber: wie lange brauchst Du fuer die drei Schritte
> (die greifen ja auch sicherlich ineinander)? Ich sehe hier vor allem
> ein zeitliches Problem.

Zeit ist heutzutage scheinbar immer ein Problem. In der Zeit vor der
Arbeit, war Zeit quasi bedeutungslos für mich (soweit es ebend ging -
diverse Schnittstellen zur Aussenwelt wie z.b. familäre Nahrungsaufnahme
usw. ausgenommen).
Zeit und Diskurs sind für gewöhnlich die Grundlagen jeder
Errungenschaft. Solange man nicht unter Zeitdruck steht, ist das
bedeutungslos.
Eine absolute Zeit läßt sich dafür natürlich nicht benennen, da es stark
von Projekt zu Projekt bzw. auch von der Erfahrung abhängig ist. So ist
es durchaus möglich, nach 5 Minuten ein 10KLOC Programm im Angriff zu
nehmen, ohne auch nur die geringsten Notizen, Konzepte oder Proben zu
haben. Anderseits kann man auch an 100 Zeilen ein paar Tage sitzen.

> PHP ist gerade deshalb so interessant, weil
> man relativ rasch entwickeln kann ("fast alles" ist schon irgendwo
> als Befehl vorhanden). Durch Aufbau eines eigenen Codegenerators
> macht man diesen Zeitvorteil ja wieder zunichte.

Das sehe ich nicht so. Der Codegenerator ist dazu da, noch mehr Zeit zu
sparen. Durch z.b.:
1. Einfach Syntax - statt ([{}]);=>-:> nur ():
2. Eigene Befehle: FILENAME-MATCH lesbarer/wartbarer als fnmatch
3. Verbessertes Interface - also kein Wechseln der Parameter wie z.b.
bei den Stringfunktionen in PHP üblich. Ebendso ist die Wahl generischer
Namen effektiver. So kann ein FOREACH auch auf ein FOR gemappt werden.
Bzw. besser: FOREACH unabhängig vom Datentyp (vor ein paar Wochen gab es
mal ein Beispiel, wie man Strings für Foreach-Benutzung behandelt).
Dafür habe ich zwar viele Ideen, aber noch kein wirklich befriedigendes
Konzept.
4. Nutzerdefinierte Befehlswahl - Der Benutzer kann statt FILENAME-MATCH
auch einen beliebigen Befehl darauf mappen. Genauso kann er komplette
Abkürzung für häufig verwendete Codeblöcke verwenden. Statt also ständig
nicht kürzbare Codeblöcke zu verwenden, kann er auch einfach ANWEISUNG
schreiben und spart mehrere Zeilen. Was in PHP auf Grund der
Befehlsfunktionalität nicht möglich ist, ist für einen Generator kein
Problem, da dort nichts ausgeführt wird. Genauso gut kann er die
Anweisungen auch in eine Sprache seiner Wahl übersetzen. Oder oder oder.
5. Optimierungen: Würde z.b. irgendwelche Datenbankabfragen
durchgeführt, könnte der Generator je nach PHP Version und DB Typ
zwischen PDO, einem DB-Framework oder den db-spezifischen Befehlen
wählen. Man müßte den Code nicht ändern. Ähnliches zum Beispiel für
XML-Funktionen. Oder Funktionen, die von Konfigurationen abhängig sind usw.
6. Sicherheit: Ein Generator läßt sich z.b. so einrichten, dass er z.b.
immer erst prüft, ob der Index eines Arrays existiert. Genauso gut
könnte man Typensicherheit auf Wunsch erzwingen. PHP unterstützt ja
leider nur array und Objektnamen für Parameter deklarationen. Das könnte
man um die fehlenden Typen erweitern.
7. Framework: Ein Generator hätte desweiteren die Möglichkeit, ein
Framework zur Verfügung zu stellen. Gerade damit hat Java ja seinen
Durchbruch geschafft ;)

Dazu kommen halt nachempfundene Features (die in PHP nicht möglich
sind), wie z.b. Namespaces. Auch kann mit einem Generator das Erben von
mehreren Klassen simuliert werden. Alles was in PHP fehlt und sich in
einen statischen Rahmen bewegt, ist damit abbildbar.

Die Möglichkeiten eines Generators sind weit gefaßt - so kann man von
mir aus auch Dokumentation erzwingen - die Kunst daran ist, dass ganze
irgendwie sinnvoll zu machen.

>>Lisp hat mich da noch immer beeindruckt - auch wenn ich nicht
>>alles gut heißen kann - und die einzige Sprache, die ich neben
>>Lisp noch außerordentlich respektiere ist Forth
>
> Lisp ist fuer mich persoenlich schlicht unlesbar, Forth hingegen
> habe ich heiss geliebt - wobei meine Forth-Programme eher write-only
> waren.

Bei mir ist es umgekehrt. Forth ist schlecht lesbar, weswegen auch die
meisten Programme write-only waren.
Lisp hingegen ist - natürlich in vernüftiger Formatierung - hervorragend
les- und wartbar.

>>Genau genommen ist es zu tiefst deprimierent, wenn man sieht wo
>>wir heute sind und wo wir vor ein paar Jahr(en)/(zehnten) waren...
>
> Jein. Man kann die Verflachung der Programmiersprachen auch als
> Fortschritt der Hardwareseite betrachten. Jetzt _koennen_ wir uns
> das erlauben.

Nein. Die Verflachung der Sprachen hat nicht vollständig etwas mit der
Hardware zu tun. Die Entwicklung zu immer höhere, bzw. höher
abstrahierenden Sprachen ist durchaus nicht schlecht, nur fehlen in
vielen neuen Sprachen grundsätzliche Konstrukte, die einem die Gewalt
über das Programmierte geben.
Leider hängt das auch mit der immer schlechter werdenden Ausbildung in
der Programmierung zu sammen, wie ich am eigenen Leib spüre. Nach 3
Jahren hat man ein paar Zeilen C programmiert (ohne nähere Erklärung),
ein wenig OOP Wortschatz errungen, sowie ein wenig Java und SQL
geschrieben. Wobei die Sprachen ja nach Firmensponsor varrieren können.
Was z.b. Streams sind, wie Referenzen oder Pointer funktionieren, was
Lesrichtungen in Sprachen bewirken, was gültigkeitsbereiche für
Variablen sind oder oder oder fehlt vollständig. Was zu letzt nicht
daran liegt, dass Programmierung - egal ob Konzept oder Praxis - in der
Ausbildung Fachinformatiker in Anwendungsentwicklung, genau wie eine
historische Betrachtung - fast vollständig fehlen. Letzt sind wir
Marketingmaschinen, Buchhalter, Kaufleute, PR-Menschen und Firmengründer.

> [Normenumsetzung in langem Code vs. einzelnen Klassen]
>
>>Das ändert aber nichts an der leichteren Wartbarkeit. Und wo ich
>>es noch mal lese: Fabrik und Zustands-Pattern kombinieren und
>>schon hättest du deine kleinen schönen Klassen und das ganze wäre
>>wartbarer und lesbarer - so behaupte ich jetzt ganz unverfroren ;)
>
> Ein Praxistest waere natuerlich interessant. Ob Du nur dafuer 2
> Wochen lang angegraute Normen studieren moechtest, weiss ich
> allerdings nicht :-)

Wenn du sie bezahlst ;)

>>>>Du solltest nicht mal $_SERVER trauen, da ich User-Agent und was
>>>>weiß ich nicht alles auch einfach ändern kann ;)
>
>>>Ich wuesste ohnehin nicht, was ich mit dem User-Agent anfangen
>>>wollte...
>
>>Es ist doch Mode, zu wissen, mit welchen Browser die eigene,
>>geliebte Seite aufgerufen wurde.
>
> Nicht nur bei der Kleidung ist mir die Mode relativ egal...

Schade nur, wenn die Vorgesetzen das anders bewerten. Dann kommt man
nicht drum herum :(

Gruß,
Torsten