php-resource



Zurück   PHP-Scripte PHP-Tutorials PHP-Jobs und vieles mehr > Entwicklung > PHP Developer Forum
 

Login

 
eingeloggt bleiben
star Jetzt registrieren   star Passwort vergessen
 

 

 


PHP Developer Forum Hier habt ihr die Möglichkeit, eure Skriptprobleme mit anderen Anwendern zu diskutieren. Seid so fair und beantwortet auch Fragen von anderen Anwendern. Dieses Forum ist sowohl für ANFÄNGER als auch für PHP-Profis! Fragen zu Laravel, YII oder anderen PHP-Frameworks.

Antwort
 
LinkBack Themen-Optionen Thema bewerten
  #1 (permalink)  
Alt 18-10-2010, 13:58
Hagbard-Celine
 Registrierter Benutzer
Links : Onlinestatus : Hagbard-Celine ist offline
Registriert seit: Oct 2007
Beiträge: 8
Hagbard-Celine ist zur Zeit noch ein unbeschriebenes Blatt
Standard Exceptions Verständnis/Nutzen Frage

Hallo zusammen,

ich arbeite mich gerade in Design-Pattern ein und bin jetzt auch noch mal auf das Thema Exceptions gestoßen was ich lange Zeit gemieden habe weil mir der Nutzen nicht ganz klar war.

Nun muss natürlich was dran sein wenn es anerkannter Maßen als guter Stil gilt Exceptionhandlung statt IF/ELSE Konstrukte zu nutzen.

Also der Aufbau mit Try/Catch Blöcken und dem Werfen von Exceptions habe ich verstanden und ist auch zu genüge im Internet dokumentiert. Auch das Exceptions wie der Name schon sagt nur im Ausnahmefall geworfen werden sollten ist auch klar und nicht etwa um true/false in normalen Bedingungen zu behandeln.

Jetzt aber geht es um den nutzen.

Nehmen wir mal ein einfaches Beispiel ein Query über eine Methode einer MySQL Klasse:

Fehlerbehandlung mit Exceptions
PHP-Code:
public function doQuery($query)
{
   try
   {
      
$this->_result mysql_query($query$this->_connection);
      if(!
$this->result)
      {
         throw new 
Exeption('Fehler im SQL-Query');    
      }
   }
   catch(
Exception $e)
   {
      echo 
$e->getMessage();
      
// Sonstige Fehlerbehandlung
   
}    

Fehlerbehandlung mit IF/ELSE
PHP-Code:
public function doQuery($query)
{
   
$this->_result mysql_query($query$this->_connection);
   if(!
$this->result)
   {
         echo(
'Fehler im SQL-Query');    
         
// Sonstige Fehlerbehandlung
   
}

Wie man sieht ist die IF/ELSE Methode (noch) übersichtlicher und mit weniger Code verbunden. Wieso sollte man hier trotzdem zu Exception-Lösung greifen?

Oder würdet Ihr das nur bei komplexeren Methoden machen wo viele mögliche Fehlerbehandlungen via IF/ELSE Verzweigungen sehr unübersichtlich werden könnten? Weil der nächste Vorteil die Exception Klasse erweitern zu können um so auf jeden Fehler individuell reagieren zu können habe ich natürlich bei IF/ELSE genauso.

Für mich gibt sich deshalb bis jetzt nur der, bei vielen abzufangenden Fehlern, besser zu überblickende Code. Einen sonstigen richtigen Mehrwert sehe ich noch nicht.

Eine andere Frage die ich noch hätte wäre wo man dann den Try/Catch Block aufführt in der Klasse/Methode selber wie oben im Beispiel?

Oder im Programmcode den Aufruf der Methode in Try/Catch packen?
Dann müsste ich mich darauf verlassen das die Methode immer in einem Try/Catch Blöck steht da sonst die geworfene Exception nicht behandelt wird und zu einem Scriptabbruch führt.

Aber normal sollte jeder die Klasse benutzen können ohne genau zu wissen was genau im Code gemacht wird ... also könnte auch unbekannt sein ob eine Exception geworfen wird.


Würde mich um konstruktives Feedback sehr freuen
(Und ja ich habe Google und sonstige Suchen benutzt und mir sehr viele Beiträge zu diesem Thema angesehen)

Vielen Dank!
Mit Zitat antworten
  #2 (permalink)  
Alt 18-10-2010, 14:04
TobiaZ
  Moderator
Links : Onlinestatus : TobiaZ ist offline
Registriert seit: Jan 2001
Ort: MUC und MGL, Germany
Beiträge: 34.421
Blog-Einträge: 1
TobiaZ befindet sich auf einem aufstrebenden Ast
Standard

Wie du schon richtig erkannt hast, kommen Exceptions nur in Ausnahmefällen zum tragen. In deinem Beispiel würde folglich eine MySQL-Query fehlschlagen.

Dieser Fall tritt eigentlich so gut wie nie ein, weil du ja die Werte vorher geprüft hast. Falls er nun doch eintritt, kannst du nicht mehr viel retten, höchstens Loggen. Das Ding ist fehlgeschlagen, also längst in den Brunnen gefallen, und das obwohl die Rahmenbedingungen von Seiten des Users korrekt sind.

In deinem Beispiel liefern Exceptions in der Tat keinen Vorteil. Aber geh mal davon aus, dass du die Fehlerbehandlung einem Exception Handler übergibst, dann sieht die Sache schon wieder ganz anders aus. Bei jeder fehlgeschlagenen Query wirfst du z.B. eine MySqlException. Somit brauchst du die nachfolgende Behandlung (Loggen des Fehlers, Informieren des Admins, Speichern der Degubinformationen, Neutrale Meldung an den User) nur noch einmalig zu implementieren. Und das mit all seinen Vorteilen.
__________________
ERST LESEN: Unsere Regeln. | Ich hab schon Pferde kotzen sehn!

READ THIS: Strings richtig trennen/verbinden | JOINs, das leidige Thema | Wegwerf E-Mail Adressen

Ich werde keinen privaten 1:1 Support leisten, außer ich biete ihn ausdrücklich an.

Wenn man sich selbst als "Noob" bezeichnet, sollte man die Finger davon lassen.
Wenn man gewillt ist daran etwas zu ändern, lernt man Grundlagen!

Geändert von TobiaZ (18-10-2010 um 14:08 Uhr)
Mit Zitat antworten
  #3 (permalink)  
Alt 18-10-2010, 14:06
Benutzerbild von onemorenerd onemorenerd
  Moderator
Links : Onlinestatus : onemorenerd ist offline
Registriert seit: Mar 2005
Ort: Berlin
Beiträge: 9.471
onemorenerd wird schon bald berühmt werdenonemorenerd wird schon bald berühmt werden
Standard

Dein erster Code-Abschnitt ist Käse. mysql_query() wirft keine Exceptions. Deswegen kann das try-catch weg. Übrig bleibt quasi der selbe Code wie in deinem zweiten Beispiel, nur dass eben kein echo erfolgt sondern throw.

Wenn du dir nun überlegst, wie der Fehler an der Stelle erkannt wird, wo deine Methode aufgerufen wurde, wirst du den Vorteil von Exceptions sicherlich einsehen - der Aufrufer würde vom echo und damit vom Auftreten des Fehlers gar nichts mitbekommen. Das schlägt direkt bis zum Client durch und der kann mit dieser Fehlermeldung auf deiner Webseite überhaupt nichts anfangen. ;-)
Natürlich kannst du statt echo auch return false machen. Aber dann muss jedem Aufruf von doQuery() ein Test des Rückgabewerts folgen.
Bei tiefen Callstacks ist man da mit Exceptions besser beraten. Die kann man auch einfach mal nicht fangen und es einer höheren Schicht überlassen oder man kann sie fangen und erneut werfen oder konvertieren oder oder oder.

Geändert von onemorenerd (18-10-2010 um 14:11 Uhr)
Mit Zitat antworten
  #4 (permalink)  
Alt 18-10-2010, 14:08
unset
  Moderator
Links : Onlinestatus : unset ist offline
Registriert seit: Jan 2007
Ort: Düsseldorf
Beiträge: 3.782
unset befindet sich auf einem aufstrebenden Ast
Standard

Genau dazu habe ich vor über einem Jahr schon was geschrieben: Re: Wann verwende ich Exceptions // der php hacker ? ein php blog
Mit Zitat antworten
  #5 (permalink)  
Alt 18-10-2010, 14:59
Hagbard-Celine
 Registrierter Benutzer
Links : Onlinestatus : Hagbard-Celine ist offline
Registriert seit: Oct 2007
Beiträge: 8
Hagbard-Celine ist zur Zeit noch ein unbeschriebenes Blatt
Standard

Erstmal Danke für die vielen schellen, guten Antworten.

Zitat:
Zitat von onemorenerd Beitrag anzeigen
Dein erster Code-Abschnitt ist Käse. mysql_query() wirft keine Exceptions. Deswegen kann das try-catch weg. Übrig bleibt quasi der selbe Code wie in deinem zweiten Beispiel, nur dass eben kein echo erfolgt sondern throw.

Wenn du dir nun überlegst, wie der Fehler an der Stelle erkannt wird, wo deine Methode aufgerufen wurde, wirst du den Vorteil von Exceptions sicherlich einsehen - der Aufrufer würde vom echo und damit vom Auftreten des Fehlers gar nichts mitbekommen. Das schlägt direkt bis zum Client durch und der kann mit dieser Fehlermeldung auf deiner Webseite überhaupt nichts anfangen. ;-)
Natürlich kannst du statt echo auch return false machen. Aber dann muss jedem Aufruf von doQuery() ein Test des Rückgabewerts folgen.
Bei tiefen Callstacks ist man da mit Exceptions besser beraten. Die kann man auch einfach mal nicht fangen und es einer höheren Schicht überlassen oder man kann sie fangen und erneut werfen oder konvertieren oder oder oder.
OK das mit dem überflüssigen Try/Catch Block habe ich verstanden.

Das mit dem Echo war nur ein Beispiel und sollte nicht die tatsächliche Fehlerbehandlung darstellen, ich wollte das Beispiel nur möglichst kompakt halten.

Aber statt einem Try/Catch beim Aufrufen hätte ich, wie Du schon richtig sagst, auch false benutzen können. Ob ich jetzt jedes mal auf den Rückgabewert teste oder jedesmal ein Try/Catch Block erzeuge dürfte kaum einen unterschied machen (vom Aufwand).
Mit Zitat antworten
  #6 (permalink)  
Alt 18-10-2010, 15:03
h3ll
 Registrierter Benutzer
Links : Onlinestatus : h3ll ist offline
Registriert seit: Mar 2008
Beiträge: 3.578
h3ll befindet sich auf einem aufstrebenden Ast
Standard

Zitat:
Zitat von Hagbard-Celine Beitrag anzeigen
Aber statt einem Try/Catch beim Aufrufen hätte ich, wie Du schon richtig sagst, auch false benutzen können. Ob ich jetzt jedes mal auf den Rückgabewert teste oder jedesmal ein Try/Catch Block erzeuge dürfte kaum einen unterschied machen (vom Aufwand).
Eine Funktion sollte nur einen Datentyp liefern. Also wenn du einen Boolean-Wert erwartest und TRUE oder FALSE lieferst, ist das in Ordnung. Wenn du allerdings einen String oder ein Array erwartest, aber plötzlich FALSE daher kommt, ist das nicht wirklich sauber.
Mit Zitat antworten
  #7 (permalink)  
Alt 18-10-2010, 15:14
Benutzerbild von fireweasel fireweasel
 Registrierter Benutzer
Links : Onlinestatus : fireweasel ist offline
Registriert seit: Sep 2008
Ort: At home
Beiträge: 851
fireweasel wird schon bald berühmt werdenfireweasel wird schon bald berühmt werden
fireweasel eine Nachricht über AIM schicken fireweasel eine Nachricht über Yahoo! schicken
Standard

Zitat:
Zitat von Hagbard-Celine Beitrag anzeigen
Hallo zusammen,

ich arbeite mich gerade in Design-Pattern ein und bin jetzt auch noch mal auf das Thema Exceptions gestoßen was ich lange Zeit gemieden habe weil mir der Nutzen nicht ganz klar war.
Exceptions und Design-Patterns existieren unabhängig voneinander.

Zitat:
Nun muss natürlich was dran sein wenn es anerkannter Maßen als guter Stil gilt Exceptionhandlung statt IF/ELSE Konstrukte zu nutzen.
Wer sagt, dass es als guter Stil gilt?

Zitat:
Also der Aufbau mit Try/Catch Blöcken und dem Werfen von Exceptions habe ich verstanden ...
Offensichtlich noch nicht, wie dein Code-Beispiel zeigt. Sagen wir mal so: Dein Verständnis von Exceptions erscheint mir in etwa so gut wie meine Kenntnisse in Schach. Ich weiß, wie man die Figuren rückt ... ;-)

Wozu dienen Exceptions?

1.) In so komisch designeten Sprachen wie PHP sind sie eine Krücke, mit der eine Funktion zusätzliche Rückgabewerte an ihren Aufrufer senden kann. Für PHP ist das ganz wichtig, denn hier können bspw. Konstruktur-Funktionen überhaupt nichts zurückgeben. Wenn man jetzt ein Objekt "instanziiert", hat man keine Möglichkeit, einen Fehler zu melden, außer man benutzt Exceptions. Dies wird zwar gemeinhin als schlechter Stil betrachtet, aber wir haben ja nichts besseres ... ;-)

2.) Der Quellcode lässt sich einfacher gestalten, weil der Ablauf im Normalfall einfacher ersichtlich ist. Ein Beispiel: Wir schreiben Text in ein Logfile ...

PHP-Code:
function write_to_log($path$log_txt) {
    
$file file_object::open($path'a');
    
$file->write($log_txt);
    
$file->close();
    return 
TRUE;

In der Praxis könnte das Probleme bereiten, weil Dateien nicht immer vorhanden sind, nicht an jedem Pfad-Ende eine Datei sitzt (es gibt auch Verzeichnisse), man nicht immer Schreibrechte besitzt und Festplattenspeicher endlich ist. All diese Eventualitäten sollte man abfangen. Das geht mit "IFs":

PHP-Code:
function write_to_log($path$log_txt) {
    if (!
is_object($file file_object::open($path'a')) {
        return 
FALSE;
    }
    if (
        
is_int($bytes_written $file->write($log_txt)) &&
        
$bytes_written === strlen($log_txt)
    ) {
        
$file->close();
        return 
FALSE;
    }
    
$file->close();
    return 
TRUE;

Aber hier kann man den ursprünglichen Programmablauf nicht mehr so gut erkennen.

Mit Exceptions dagegen, bleibt fast alles beim alten, wenn man mal vom catch-Block absieht:
PHP-Code:
function write_to_log($path$log_txt) {
    try {
        
$file file_object::open($path'a');
        
$file->write($log_txt);
        
$succes TRUE;
    }
    catch (
file_object_exception $ex) {
        
// handling $ex if needed
        
$succes FALSE;
    }

    
$file->close();
    return 
$succes
Selbstverständlich müssen die aufgerufenen Funktionen (oder Objekt-Methoden) auch die richtigen Exceptions werfen. Auch deswegen ist dein Beispiel nicht besonders praxisnah. Es gibt aber diverse Datenbank-Extensions, mit denen man Exception-Handling schön üben kann (bsp. das übersichtliche SQLite3).


Zitat:
Oder würdet Ihr das nur bei komplexeren Methoden machen wo viele mögliche Fehlerbehandlungen via IF/ELSE Verzweigungen sehr unübersichtlich werden könnten?
In selbstgeschriebenen Funktionen verzichte ich nach Möglichkeit darauf Exceptions zu werfen.

Zitat:
Für mich gibt sich deshalb bis jetzt nur der, bei vielen abzufangenden Fehlern, besser zu überblickende Code. Einen sonstigen richtigen Mehrwert sehe ich noch nicht.
Exceptions sind in PHP die einzige Möglichkeit aus einem Objekt-Konstruktor heraus einen Fehler zu melden. Da gibts nichts mit IF-ELSE.

Zitat:
...

Dann müsste ich mich darauf verlassen das die Methode immer in einem Try/Catch Blöck steht da sonst die geworfene Exception nicht behandelt wird und zu einem Scriptabbruch führt.
Das ist das Prinzip dahinter: Fange alle Exceptions ab, die deine Kind-Funktionen werfen, wenn du sie behandeln kannst. Wenn nicht, reiche sie an deinen Aufrufer weiter. Das führt dann letzten Endes oft zu lustigen Trace-Back-Debugging-Sessions ... ;-)

Zitat:
Aber normal sollte jeder die Klasse benutzen können ohne genau zu wissen was genau im Code gemacht wird ... also könnte auch unbekannt sein ob eine Exception geworfen wird.
Das Werfen von Exceptions gehört zur Schnittstelle (Signatur, oder wie auch immer man das nennt) einer Funktion (wie bspw. die Rückgabewerte und die Aufruf-Parameter). Wer die Funktion nutzt, muss auch damit rechnen, das Exceptions geworfen werden. In vernünftig designeten Sprachen muss man dies auch angeben (bspw. mit dem Keyword "throws" in Java).

Geändert von fireweasel (18-10-2010 um 22:13 Uhr)
Mit Zitat antworten
  #8 (permalink)  
Alt 18-10-2010, 16:13
Hagbard-Celine
 Registrierter Benutzer
Links : Onlinestatus : Hagbard-Celine ist offline
Registriert seit: Oct 2007
Beiträge: 8
Hagbard-Celine ist zur Zeit noch ein unbeschriebenes Blatt
Standard

Hallo Fireweasel,

danke für deine ausführliche Erklärung.
Mit Zitat antworten
  #9 (permalink)  
Alt 18-10-2010, 16:17
Benutzerbild von onemorenerd onemorenerd
  Moderator
Links : Onlinestatus : onemorenerd ist offline
Registriert seit: Mar 2005
Ort: Berlin
Beiträge: 9.471
onemorenerd wird schon bald berühmt werdenonemorenerd wird schon bald berühmt werden
Standard

Das Schöne an Exceptions im Vergleich mit Rückgabewerten ist nicht nur die bereits erwähnte Typenstringenz, sondern dass Exceptions einen anderen Code Flow ermöglichen. Return false führt zurück zum caller und der muss darauf reagieren. Sonst knallts. Throw springt ebenfalls aus dem aktuellen Scope, aber wenn der übergeordnete kein catch implementiert, nibbelt die Exception weiter nach oben. Man muss also nicht überall Fehlerbehandlung einbauen und kann dabei sicher sein, das trotzdem kein Code ausgeführt wird, der mit dem Fehler nicht umgehen kann.
Mit Zitat antworten
  #10 (permalink)  
Alt 22-10-2010, 12:53
Hagbard-Celine
 Registrierter Benutzer
Links : Onlinestatus : Hagbard-Celine ist offline
Registriert seit: Oct 2007
Beiträge: 8
Hagbard-Celine ist zur Zeit noch ein unbeschriebenes Blatt
Standard

Hallo zusammen,

entschuldigt das ich den Thread wieder nach oben hole ich wollte aber keinen neuen erstellen weil sich meine neue Frage auch auf Exceptions bezieht.
Also ich habe mich jetzt noch weiter eingelesen und wollte für die verschiedenen Arten von Fehlern die meine Klasse werfen kann eigene Exceptions erstellen damit ich die Fehler besser individuell behandeln kann.

Nun ist dies ja recht einfach mit möglich:

Code:
class MyException extends Exception
{
/* CODE */
}
Meine Frage ist nun jedoch wohin würde man diesen Code packen?
In eine eigene myexception.php Datei und diese in der benötigen Klasse includieren? Oder packt man den Code einfach in die selbe Klassen-Datei in der Sie auch benötigt wird?

Oder ist das Fall abhängig?

Momentan würde ich wie folgt vorgehen:

1)
Eigene Exception wird in 2 Klassen gebraucht. Ich erstelle eine eigene PHP-Datei mit dem Code der eigenen Exception und binde diese in beiden Klassen per require ein.

2)
Eigene Exception wird nur in einer Klasse benötigt. Ich schreibe den Code der eigenen Exception in die PHP-Datei der Klasse mit rein.


Ist das so korrekt oder was ist dort Best Practise/empfohlen?


Besten Dank
Mit Zitat antworten
  #11 (permalink)  
Alt 22-10-2010, 12:56
h3ll
 Registrierter Benutzer
Links : Onlinestatus : h3ll ist offline
Registriert seit: Mar 2008
Beiträge: 3.578
h3ll befindet sich auf einem aufstrebenden Ast
Standard

Üblicherweise ist eine Klasse eine Datei.
Mit Zitat antworten
  #12 (permalink)  
Alt 22-10-2010, 13:01
Benutzerbild von onemorenerd onemorenerd
  Moderator
Links : Onlinestatus : onemorenerd ist offline
Registriert seit: Mar 2005
Ort: Berlin
Beiträge: 9.471
onemorenerd wird schon bald berühmt werdenonemorenerd wird schon bald berühmt werden
Standard

Autoload statt require.
Mit Zitat antworten
  #13 (permalink)  
Alt 22-10-2010, 13:05
TobiaZ
  Moderator
Links : Onlinestatus : TobiaZ ist offline
Registriert seit: Jan 2001
Ort: MUC und MGL, Germany
Beiträge: 34.421
Blog-Einträge: 1
TobiaZ befindet sich auf einem aufstrebenden Ast
Standard

Zitat:
entschuldigt das ich den Thread wieder nach oben hole ich wollte aber keinen neuen erstellen weil sich meine neue Frage auch auf Exceptions bezieht.
Dafür ist er ja da!

Zitat:
Momentan würde ich wie folgt vorgehen:
1) Eigene Exception wird in 2 Klassen gebraucht. Ich erstelle eine eigene PHP-Datei mit dem Code der eigenen Exception und binde diese in beiden Klassen per require ein.
2) Eigene Exception wird nur in einer Klasse benötigt. Ich schreibe den Code der eigenen Exception in die PHP-Datei der Klasse mit rein.
Du kannst ja vorher nie wissen, was vielleicht noch kommt.

Daher: Je Klasse eine Datei. Und Autoloading verwenden.
__________________
ERST LESEN: Unsere Regeln. | Ich hab schon Pferde kotzen sehn!

READ THIS: Strings richtig trennen/verbinden | JOINs, das leidige Thema | Wegwerf E-Mail Adressen

Ich werde keinen privaten 1:1 Support leisten, außer ich biete ihn ausdrücklich an.

Wenn man sich selbst als "Noob" bezeichnet, sollte man die Finger davon lassen.
Wenn man gewillt ist daran etwas zu ändern, lernt man Grundlagen!
Mit Zitat antworten
  #14 (permalink)  
Alt 22-10-2010, 13:44
Hagbard-Celine
 Registrierter Benutzer
Links : Onlinestatus : Hagbard-Celine ist offline
Registriert seit: Oct 2007
Beiträge: 8
Hagbard-Celine ist zur Zeit noch ein unbeschriebenes Blatt
Standard

Hi Leute,

wow das ging mal fix.
Vielen Dank für die vielen Antworten.

Dann werde ich es mit einer eigenen Datei + Autoloading machen.
Mit Zitat antworten
Antwort

Lesezeichen

Stichworte
exception, fehler, fehlerbehandlung, if-else, php


Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)
 

Ähnliche Themen
Thema Autor Forum Antworten Letzter Beitrag
Cookie- Verständnis Frage Lexus_Ks PHP Developer Forum 3 07-06-2006 17:07
verständnis frage club-basic PHP Developer Forum 2 18-06-2005 11:05
verständnis frage zu oop und classen bpieper PHP Developer Forum 5 16-03-2005 19:49
verständnis frage maschli PHP Developer Forum 3 22-09-2004 22:15
verständnis frage bei klassen Trashar PHP Developer Forum 8 15-11-2003 18:02

Themen-Optionen
Thema bewerten
Thema bewerten:

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are an


PHP News

ebiz-trader 7.5.0 mit PHP7 Unterstützung veröffentlicht
ebiz-trader 7.5.0 mit PHP7 Unterstützung veröffentlichtDie bekannte Marktplatzsoftware ebiz-trader ist in der Version 7.5.0 veröffentlicht worden.

28.05.2018 | Berni

Wissensbestand in Unternehmen
Wissensbestand in UnternehmenLebenslanges Lernen und Weiterbilden sichert Wissensbestand in Unternehmen

25.05.2018 | Berni


 

Aktuelle PHP Scripte

PHP Server Monitor

PHP Server Monitor ist ein Skript, das prüft, ob Ihre Websites und Server betriebsbereit sind.

11.09.2018 Berni | Kategorie: PHP/ Security
PHP WEB STATISTIK ansehen PHP WEB STATISTIK

Die PHP Web Statistik bietet Ihnen ein einfach zu konfigurierendes Script zur Aufzeichnung und grafischen und textuellen Auswertung der Besuchern Ihrer Webseite. Folgende zeitlichen Module sind verfügbar: Jahr, Monat, Tag, Wochentag, Stunde Folgende son

28.08.2018 phpwebstat | Kategorie: PHP/ Counter
Affilinator - Affilinet XML Produktlisten Skript

Die Affilinator Affilinet XML Edition ist ein vollautomatisches Skript zum einlesen und darstellen der Affili.net (Partnerprogramm Netzwerk) Produktlisten und Produktdaten. Im Grunde gibt der Webmaster seine Affilinet PartnerID ein und hat dann unmittelb

27.08.2018 freefrank@ | Kategorie: PHP/ Partnerprogramme
 Alle PHP Scripte anzeigen

Alle Zeitangaben in WEZ +2. Es ist jetzt 10:31 Uhr.