Einfache PHP-Shoplösung gesucht

[Pierre]

Hallo

Ich hoffe ich verstosse hier nicht gegen die Forumsregeln, wenn ich nach einer PHP-Shoplösung frage. In meinem Webprojekt möchte ich eine einfache Shoplösung integrieren. Zahlungswesen brauchts net, einfach einen Warenkorb und wenn sich die Besucher anmelden können und später wieder erkannt werden wär das auch ganz toll. Und ne einfache Adminumgebung für den Shopbetreiber mit Bildupload und freier Definition der Kategorien.
Das Wichtigste ist aber, dass ich den Shop meinem Layout anpassen, bzw. darin  integrieren kann.
Das aktuelle Layout ist css-basiert und schaut so aus:
http://http://www.per-net.ch/garage/weber/angebot/index.html

Kennt jemand ne gute Lösung, die ich für mein Projekt anpassen kann?

Besten Dank für Eure Tipps.
Pierre

[Tom]

Hello Pierre,

da bisher keine andere Antwort kommt und Du eigentlich auch schon ganz gute Ansätze gezeigt hast, lass uns doch so ein Ding hier mal planen und dann nach und nach auch programmieren. Dutzende von Folgegenarationen an Forumsbesuchern werden es uns danken...

Also, wie fangen wir an?

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[XaraX]

Hallo Pierre,

da bisher keine andere Antwort kommt und Du eigentlich auch schon ganz gute Ansätze gezeigt hast, lass uns doch so ein Ding hier mal planen und dann nach und nach auch programmieren. Dutzende von Folgegenarationen an Forumsbesuchern werden es uns danken...

Also, wie fangen wir an?

Wir fangen mit einer Vorüberlegung an, um uns einen groben Überblick zu verschaffen:

Was ist ein Online-shop (O-Shop)?

Ein O-Shop ist ein Web mit fast ausschließlich kommerziell Charakter.
   Ein solches Web muß der breitestmöglichen Masse an Browsern / Clients
   gerecht werden, um breitestmöglichen Anklang zu finden.

Anforderungen an Techniken

Die daraus erwachsenden Anforderungen an die einzusentzenden
   Techniken sind eheblich und tragen maßgeblich zum Erfolg des
   Webs bei.

- Einsatz von HTML nach Standard des W3C
    - Einsatz von CSS nach Standard des W3C
    - Bezugnahme auf Fehler verschiedener Browser
      (vgl.: CSS hack, Boxmodel, Bug)
    - Einsatz von PHP als serverseitige Technik

Anforderungen an die Gestaltung

Die Gestaltung ist der bedeutenste Teil des O-Shops. Er ist das
   Interface über dem alle Transaktionen im Hinblick auf das Zusammen-
   spiel von Client <-> Server, aber auch Kunde <-> Verkäufer ablaufen.
    Je einfacher und intuitiver es gestaltet ist, desto weniger Mühe
   wird ein User beim aufsuchen von Produkten im O-Shop haben und desto
   eher wird er kaufen.
    Bei der Umsetzung eines Layouts sind die eigenen Erfahrungen mit Web
   erheblich. Daher ist es nicht schlecht google mit allen Suchbegriffen
   der Form AAlräucherein bis Zylinderstifte zu durchsuchen, um diese
   Erfahrungen nochmals aufzufrischen.

Präsentation der Produkte

Alle Produkte sind den User so zu präsentieren, daß er einen grobum-
   fassenden Eindruck des Produktes erhält. Dieser Eindruck darf für den
   durchschnittsgebildeten User keine Fragen offenlassen und klärt ihn
   gleichfalls über alle gesetzlich vorgeschriebenen Angaben auf.
    Darüber hinaus werden dem User bei Interesse detailreichere Einblik-
   ke in Wort und Bild gewährt.
    Diese Möglichkeit der Darbietung hält sich an "Weniger ist mehr",
   der User hat also auf den ersten Blick nur die Informationen, die er
   braucht und wird nicht mit Details erschlagen; daraus erwechst
   gleichfalls der Vorteil, das man nur die Informationen serviert, die
   die wirklich benötigt werden (Traffic).

Rechtlicher Aspekt

vgl.: Impressum, Fernabsatzgesetz, Rech O-Shop

Ab hier finge dann alles programmiertechnische an. Ich bitte um Korrektur und Ergenzung. Einen Punkt der Kosten- und Zeitminimierung gäbe es da noch: Man gehe zu den großen Hostern und bediene sich einer ihrer Fertigsysteme im bereich von 9.99 bis 49.95 monatilich.

Gruß aus Berlin!
eddi

[Tom]

Hello eddi,

wollte hier nur vermelden, dass ich es gesehen habe und mir morgen mal reinziehen werde. Heute habe ich keine Lust mehr auf qualitative Arbeit ;-))

Ich sauf jetzt einen und schwanzel noch ein Wenig durchs Web.
Nebenbei muss ich noch einen Briefentwurf fertig stellen; das ist Quality genug für heute.

Sollte ich's verpennen, tritt mich nochmal (per mail).

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Tom]

Hello,

Ich sauf jetzt einen und schwanzel noch ein Wenig durchs Web.

*schluck* das sollte "schawenzel" heißen, was soviel wie "Surfen" bedeutet

Es ist ja schließlich noch vor 22:00

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Tom]

Hello,

Noch ein wesentliches Anliegen ist mir die die strikte Trennung von Berechnungsmodulen und Ausgabeinheit. Es wird also keine Scripte mit Spaghetticode geben dürfen, in dem Ausgaben und Berechnungen gemischt werden.

Es gibt im wesentlichen die Funktionbereiche in der Section "Main":

• Benutzeridentifikation
• "normale" Anzeigeberechnung
• Dialogberechnung
• Funktionalitätsberechnung (Buttons)
  ------------------
  HTML-Ausgabe
  ------------------
• Anzeige-Template

Einen wichtigen Punkt sollten wir noch klären:
Da es ein "einfacher" Shop werden soll, müssen wir vielleicht eine koplexe Arbeit abliefern und das Ding nicht auf einem DBMS aufsetzen, sondern auf einem Flatfile-System.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[XaraX]

Moin,

Noch ein wesentliches Anliegen ist mir die die strikte Trennung von Berechnungsmodulen und Ausgabeinheit. Es wird also keine Scripte mit Spaghetticode geben dürfen, in dem Ausgaben und Berechnungen gemischt werden.

*lach* hab mal keine Sorge ;)

Es gibt im wesentlichen die Funktionbereiche in der Section "Main":

• Benutzeridentifikation
• "normale" Anzeigeberechnung
• Dialogberechnung
• Funktionalitätsberechnung (Buttons)

---

HTML-Ausgabe

• Anzeige-Template

Gerne auch OOP :)

Einen wichtigen Punkt sollten wir noch klären:
Da es ein "einfacher" Shop werden soll, müssen wir vielleicht eine koplexe Arbeit abliefern und das Ding nicht auf einem DBMS aufsetzen, sondern auf einem Flatfile-System.

Ich denke wir wissen, wie "einfach" ein Shop ist; ob es Flatfiles (an sich) Sein müssen, weiß ich nicht, vielleicht sollten wir uns auch mal an XML orientieren. Also geklärt.

Was würdes Du unter https://forum.selfhtml.org/?t=100415&m=616080 für PHP (-Module) benötigen? Welche Module Apaches sind Dir zu viel / würdest Du zusätzlich nehmen?

Gruß aus Berlin!
eddi

[XaraX]

Hallo Pierre,

Ergänzung:

Desweiteren ist SSL für eine Verschlüsselte Übertragung von sensiblen Daten nötig.

Gruß aus Berlin!
eddi

[XaraX]

Hallo Pierre,

also fangen wir mal an den technischen Teil dieses Projekts (Arbeitsname: Self-O-Shop) zu definieren und zu unterteilen. Setzen wir uns mal als Grundlage einen eigens für den O-Shop angemieteten (V)Server, dessen einziger Zweck es ist, ein einziges (, natürlich überaus vielbesuchtes) Web zu beherbergen.
 Wir wollen einen Online-Shop (O-Shop) erstellen, der Produkte an Interessenten offeriert, eine einfache Produktverwaltung ermöglicht und eine Bestellabwicklung ermöglicht; und alles auf der Basis von PHP. Da PHP alleine diese Aufgaben schwerlich beweltigen kann, werden wir auch einen Web-Server benötigen. Dieser wird auf den allermeisten Maschinen, die als VServer / (Root)Server neben Mail-Server und SSHD bereits vorinstalliert und aller Vernunft nach mit einem GNU/Linux interagieren. Wie bereits in den Vorüberlegungen (& ff.) dargelegt, werden wir hier so einige Register ziehen, die das Forum an Kategorien zu bieten hat.
 Damit nicht in einem heillosem Durcheinander jedes Thema in einem Arm des Thread besprochen wird, halte ich es für sinnvoll eine Vorabtrennung folgender Themen vorzunehmen:

Web-SERVER  (apache)
  PHP
  HTML/XHTML
  CSS
  JavaScript
  RECHT

(Ich beginne mal den Server etwas zu beleuchten ;)

Gruß aus Berlin!
eddi

[XaraX]

Hallo Pierre,

nehmen wir mal den weitverbreitesten Web-Server, den apachen, zur Basis unseres O-Shops. Günstig ist es immer den Server so schmal wie möglich zu halten und nach Möglichkeiten auch selbst zu kompilieren. Warum steht hier.
 Den apachen gibt es derzeit in zwei grundlegenden Versionen: 2.0.52 und 1.3.33. Der wesentliche Unterschied zwischen den beiden besteht in der frei wählbaren Handhabungen von Threads vs. Kindprozessen in der Version 2.x zu einem Prefroken in Prozessen in Version 1.x.

Da wir ja einen überaus populären O-Shop mit genialen Produkten haben werden, werden wir PHP als Modul einbinden. In der Ausgabe von ./configue --help der PHP-Sourcen heißt es dazu:

--with-apxs2[=FILE]  EXPERIMENTAL: Build shared Apache 2.0 module. FILE is the optional pathname to the Apache apxs tool; defaults to apxs.

Persönlich arbeite ich seit einem halben Jahr mit PHP 5.0.x und apache 2.0.x und konnte noch keine Probleme feststellen. Aber solang es noch als experimentell bezeichnet wird, sollten wir lieber die Hände davon lassen. Daher gehe ich mal vom apachen 1.3.x aus.
 Der apache bringt insgesamt 43 Module mit, die wir nie im Leben brauchen werden. Ein Modul brauchen wir neben PHP noch zusätzlich mod_ssl. Aber schauen wir uns mal an, welche module der apache ohne weitere Angaben mitbringt:

http_core.c
  mod_env.c
  mod_log_config.c
  mod_mime.c
  mod_negotiation.c
  mod_status.c
  mod_include.c
  mod_autoindex.c
  mod_dir.c
  mod_cgi.c
  mod_asis.c
  mod_imap.c
  mod_actions.c
  mod_userdir.c
  mod_alias.c
  mod_access.c
  mod_auth.c
  mod_setenvif.c

Neben PHP halte ich folgende Module für ausreichend:

http_core.c
     Um core kommen wir nun mal nicht herum ;)

mod_access.c
     Man sollte sich die Möglichkeit offen lassen IP-Adressen
     auszusperren, wenn von ihnen Gefahren (DoS) ausgehen.

mod_auth.c
     Ein Web, insbesondere ein O-Shop ist immer eine Baustell,
     die natürlich auch abgesperrt werden will ;)

mod_dir.c
     Da wir mit PHP arbeiten, wollen wir natürlich auch Da-
     tein, wie "index.php" als Verzeichnis haben.

mod_expires.c
     Dieses Modul werden wir einsetzen, um statische Inhalte
     nur einmalig servieren zu müssen.

mod_headers.c
     Dieses Modul werden wir einsetzen, um statische Inhalte
     nur einmalig servieren zu müssen.

mod_log_config.c
     (Nicht wirklich benötigt, aber interessant ;)

mod_mime.c
     Wird benötigt für Content Negatiation.

mod_negotiation.c
     Das macht den Inhalt felxibler nach den Browsereinstel-
     lungen des Accept.

mod_rewrite.c
     Dieses Modul bevorzuge ich gegenüber mod_alias.

mod_so.c
     Versorgt den Server mit der Fähigkeit Module zu akzep-
     tieren. (Genaugenommen aber auch entbehrlich.)

mod_ssl.c
     Sorgt für Verschlüsselung sensibler Daten.

Ob man diese Statisch einkompiliert oder nicht, ist Geschmackssache, persönlich baue ich essentielle Module immer statisch ein.

Gruß aus Berlin!
eddi

[XaraX]

Hallo Pierre,

laut dem Konfigurationsvorschlag in der Datei "httpd.conf.default", die sich im Verzeichnis "conf" des kompilierten apachen standardisiert befindet, wird für den lieben IE natürlich wieder eine Extrawurst von Nöten sein. Der Server mekerte mich gerade an:

$ ./httpd -f /self-o-shop/conf/httpd.conf.default -D SSL
Syntax error on line 1186 of /sv/self-o-shop/conf/httpd.conf.default:
Invalid command 'SetEnvIf', perhaps mis-spelled or defined by a module not included in the server configuration

In Zeile 1186 heist es dazu:

SetEnvIf User-Agent ".*MSIE.*" \          nokeepalive ssl-unclean-shutdown \          downgrade-1.0 force-response-1.0

Gibt es andere Möglichkeiten mit den bestehenden Modulen auszukommen?

Es bleibt uns vorerst einmal nichts anderes übrig, als unseren Indianer noch ein Modul unter den Arm zu klemmen, sodaß ich ihn wie folgt kompiliert habe:

$ ./configure \ --prefix=/self-o-shop \ --disable-module=actions \ --disable-module=alias \ --disable-module=asis \ --disable-module=autoindex \ --disable-module=cgi \ --disable-module=env \ --disable-module=imap \ --disable-module=include \ --disable-module=status \ --disable-module=userdir \ --enable-module=expires \ --enable-module=headers \ --enable-module=rewrite \ --enable-module=so \ --enable-module=ssl

$ make
$ make certificate TYPE=...
$ make install

(Zu Fragen zum installieren von mod_ssl ist die Datei "INSTALL" als Beschreibung ausreichend.)

Nun schwirrt der httpd ohne Murren ab und liefert das Manual (wahlweise auch verschlüsselt mit einem selbstsigniertem Zertifikat). Somit kann man sich nun PHP zuwenden.

Gruß aus Berlin!
eddi

[XaraX]

Bei den Konfigurationen beschränke ich mich auf die wesentlichen Teile, die nur das Projekt PHP-O-Shop direkt betreffen

LoadModule php5_module        libexec/libphp5.so

VERZEICHNISSE

DirectoryIndex  index

<Files ~ "^.ht">
 Order   allow,deny
 Deny    from all
 Satisfy All
</Files>

<Directory />
 Options       FollowSymLinks
 AllowOverride None
</Directory>

<Directory "/self-o-shop/htdocs">
 AllowOverride All
 Options       All +MultiViews

Order         allow,deny
 Allow         from all

RewriteEngine on
 RewriteRule   shop$ http://%{HTTP_HOST}/shop/ [R]

<Files "shop">
  ForceType    application/x-httpd-php
 </Files>
</Directory>

<Directory "/self-o-shop/admin">
 AllowOverride  All
 DirectoryIndex index.php
 Options        All

Require       valid-user

php_value post_max_size       1M
 php_value upload_max_filesize 1M
</Directory>

PHP

php_flag allow_call_time_pass_reference 0
php_flag magic_quotes_gpc               0
php_flag register_argc_argv             0
php_flag register_long_arrays           0

php_value arg_separator.input           "&amp;"
php_value default_charset               "iso-8859-1"
php_value include_path                  ".:/self-o-shop/php/include"
php_value post_max_size                 102400
php_value upload_max_filesize           10
php_value user_agent                    "Self-O-Shop"
php_value variables_order               "GPC"

VHOSTS

NameVirtualHost 192.168.0.9
<VirtualHost self-o-shop>
 DocumentRoot /self-o-shop/htdocs

<Directory "/self-o-shop/htdocs/img">
  ExpiresActive  On
  ExpiresDefault A2419200
  Header         append Cache-Control "public"
 </Directory>

<Directory "/self-o-shop/htdocs/add">
  ExpiresActive  On
  ExpiresDefault A2419200
  Header         append Cache-Control "public"
 </Directory>
</VirtualHost>

<VirtualHost admin>
 DocumentRoot /self-o-shop/admin
</VirtualHost>

Des weiteren kehre ich mit dem eisernen Besen durch die mime.types und entferne alles, was nicht hundertprozentig gebraucht wird. Dmit ich PHP-Unteerstüzung erhalte, trage ich noch folgendes ein:

application/x-httpd-php  php

Gruß aus Berlin!
eddi

[XaraX]

Prompt was vergessen:

[...]

PHP

[...]

php_flag zlib.output_compression        1
php_value zlib.output_compression_level 9

Gruß aus Berlin!
eddi

[XaraX]

Hallo Pierre,

da der O-Shop als serverseitige Technik PHP verwenden soll, liegt hierauf natürlich der besondere Augenmerk. PHP bringt in der Version 5.0.3 von Hause aus satte 80 Erweiterungen mit. Man könnte spötteln, daß es für so ziemlich jede jemanls erdacht Datenbank auch eigens dafür eine Erweiterung mitbringt. Aber da es ein einfacher O-Shop sein soll werden wir darauf verzichten müssen.

PHP bringt ohne weitere Auswahl folgende Erweiterungen gleich mit:

ctype
  DOM
  iconv
  libXML
  PCNTL
  POSIX
  Session
  SimpleXML
  SPL
  SQLite
  Tokenizer
  XML

Das Modul libphp5.so des apachen erreicht in dieser Grundeinstellung und mit den Standardeinstellung "CFLAGS_CLEAN = -g -O2" für den Compiler satte 9,5 MB. Persönlich setze ich auf diesem Rechner (von dem ich gerade schreibe), der auch mein vorwiegender Arbeitsplatz ist, meine eingenen Flags

$ CFLAGS="-O3 -march=athlon -fomit-frame-pointer" make

Ohne an den Erweiterungen herumgebastelt zu haben, ist das PHP-Modul auf 2,3 MB zusammengeschrumpft. Näheres zu diesem kleinen Nettigkeiten findet sich für gewöhnlich unter http://gcc.gnu.org/; leider beobachte ich seit einigen Tagen, das der Server nicht mehr zu erreichen ist :( also müssen wir uns mit  "man gcc" bescheiden.

Aber zurück zu den Erweiterungen: Auch wenn es naheliegend klingt Sessions zu verwenden, würde ich auf alle(!) Erweiterungen verzichten wollen. Aber hierbei ist sehr wichtig zu wissen, was man alles mit PHP machen möchte und wie man was machen möchte. Die meisten werden zu den bereist erwähnten passenden Datenbankerweiterungen greifen wollen. Manche, werden vielleicht mit XML als Datenspeicher arbeiten wollen. Wieder andere werden PHP nicht nur als Modul des apachen nutzen wollen, sondern auch als Command Line Interface und völlig andere Erweiterungen benötigen.

Selbst setze ich auf die Fähigkeit der Modularisierung PHPs, um nur das zu laden, was man wirklich gebraucht wird. Da wir einen O-Shop haben wollen, der mit der imensen Nachfrage nach den genialen Produkten, auf die die Welt nur gewartete hat, zurecht kommen muß, halte ich zur Sicherung der Bandbreite zlib für unumgänglich.

Sollten weitere Erweiterungen benötigt werden, bitte ich kurz um Einspruch.

Gruß aus Berlin!
eddi

[XaraX]

Hallo Pierre,

$ CFLAGS="-O3 -march=athlon -fomit-frame-pointer" make

Korrektur:

$ CFLAGS="-O3 -march=athlon -fomit-frame-pointer" ./configure

Sollten weitere Erweiterungen benötigt werden, bitte ich kurz um Einspruch.

Keine? Gut (Notfalls lassen diese sich nachträglich als Modul noch einbinden).

CFLAGS="-O3 -march=athlon -fomit-frame-pointer" ./configure --prefix=/self-o-shop/php --with-zlib --with-apxs=/self-o-shop/bin/apxs --disable-all --disable-cli --disable-cgi
$ make
$ make install

somit hat der apache ein 1,4 MB großes Modul, mit dem er nun arbeiten soll. Als nächstes sollte bedacht werden, wie das Projekt in Verzeichnisse angelegt wird.

Gruß aus Berlin!
eddi

[XaraX]

Hallo Pierre,

nun läuft der apache mit PHP.

Verschiedene Aufgaben des Server verlangen verschiedene Konfigurationen, so nimmt der ständige Bezug von notwendigen Bildern der einzelnen Produkte über  die Browser dem O-Shop die Bandbreite. Sie sind statisch und unterliegen, einmal serviert, keiner Änderung seites des Betreibers. Mit PHP generierte Dokumente dagegen werden sich jedes mal verändern.

Für unser Web wurde bereis per Configure Command das oberste Verzeichnis "self-o-shop" angelegt und ich würde nun wie folgt

/self-o-shop
    |
    |-[... andere Verzeichnisse ...]
    |
    |-admin                 1. Administrationsweb
    |
    |-php
    |   |
    |   -include           2. Includeverzeichnis     |       |     |       -templ         3. Verzeichnis für HTML-Schablonen
    |
    |-waren                 4. Datenverzeichnis der Waren
    |
    -htdocs         |         |-add               5. Verzeichnis für additionelles         |         |-bestellung        6. (Selbstredend)         |         |-img               7. Bilderverzeichnis         |         |-info              8. Verzeichnis für statisches         |         |-index.html        [Datei]         |         |-robots.txt        [Datei]         |         -shop              [Datei]

1. Administration

Von hier aus wird der O-Shop administriert. Scripte zur einpflege
   von Produktdaten, statistischer Auswertungen und Bestellungsver-
   waltung werden von diesem Web gesteuert.

2. Include verzeichnis

Hier werden alle Klassen und Funktionen eingelagert, die von PHP
   dynamisch hinzugeladen werden. Somit werden sie auserhalb des Webs
   gehalten, was für die Sicherheit wichtig ist; insbesondere beim
   Arbeiten mit Passwörtern.

3. Templates

Aus diesem Verzeichnis bezieht PHP seine HTML-Konstrukte zur Gene-
   rierung von Dokumenten.

4. Datenverzeichnis der Waren

Dieses Verzeichnis wird das Herzstück werden. Alle Informationen
   über Produkte werden in dieses Verzeichnis eingelagert werden.

5. Verzeichnis für additionelles

Separate JavaScripte und Stylesheets und Layoutbilder werden hier
   bereit gehalten.

6. Bestellung

Scripte zur Bestellabwicklung aber auch den Warenkob und das Er-
   fassen der User betreffend finden hier platz.

7. Bilder

Aus diesem Verzeichnis werden die Produktbilder serviert.

8. Statisches

Dokumente wie "Wir über uns", "AGB" oder "Impressum", die keiner-
   lei Dynamik benötigen, werden hier eingelagert.

Damit können wir nun den Server konfigurieren.

Gruß aus Berlin!
eddi

[XaraX]

Hallo Pierre,

sammeln wir doch einmal, was wir alles brauchen und im include_path ablegen:

E-Mail-Adresserkennung

########## email_pruef.inc #################################

function email_pruef($a)
    {

Zerlegen der Adresse in USER @ HOST als Kleinschreibung

$a=explode('@',strtolower($a));

gibt es genau ein Zeichen @

if(count($a)==2)
        {

# Zerlegen des HOST in Subdomains und Anhaengen des USER $a[0]

$b=explode('.',$a[1]);

# HOST hat [SUB.]DOMAI.TLD

if(($c=count($b))>1)
            {
            $b[]=$a[0];
            $c++;

# Durchlaufen und abpruefen aller Zeichen

for($i=0;$i<$c;$i++)
                {

# auf Zeichenkettenlaenge pruefen

$a=strlen($b[$i]);

# Zeichenkette ist mindestens 2 Zeichen lang und wird durchlaufen

if($a>1)
                    for($j=0;$j<$a;$j++)
                        {

# Speichern des ASCII-Wert des Zeichens $b[$i]{$j}

$d=ord($b[$i]{$j});

# [0-9a-z]

if(($d>47 && $d<58) || ($d>97 && $d<123));

# Zeichen ist das erste Zeichen von $b[$i]

elseif($j==0) return FALSE;

# +[ -_ ]

elseif($d==45 || $d==95);

# Zeichenkette ist USER +[ . ]

elseif($i==(count($b)-1) && $d==46);
                        else           return FALSE;
                        }
                else    return FALSE;
                }
            }
        else    return FALSE;
        }
    else    return FALSE;

return TRUE;
    }

Gruß aus Berlin!
eddi