Beiträge von SinnlosS

Zitat von The User

Das, was Synaptic sagte, und die Konfiguration hängt nicht von der internen Datenhaltung im Programm ab (ob die Daten mit der Konfiguration jetzt in irgendeiner globalen Variable, in Objekt xy oder sonstwo landen oder vllt. direkt verarbeitet werden) ebenso wenig wie von der Programmiersprache. Zudem ist sie einfacher zu lesen.

Zum ersten Punkt (Sicherheit) habe ich meinen Standpunkt bereits zweimal dargelegt. Zum zweiten, die Klasse von Tobse parst aus einer Config-Datei ein Array, bei meinem Beispiel steht das Array direkt in einer Datei. Und diese Datei mit dem PHP-Array kann ich genauso an jeder beliebigen Stelle einbinden, an der ich auch die Config-Datei parsen lassen kann. Das macht nun wirklich keinen Unterschied.

Zitat von Tobse

- Winamp Themes nur XMLs und Bilder
- PhpMyadmin Themes auch nur inis und Stylesheets
- WinRAR Themes haben auch nur ne ini und Bilder

Fällt dir was auf? ini, xml? Das sind standardisierte Formate, und gegen die Verwendung selbiger hab auch ich persönlich gar nichts. (Und für niemand anderen als mich persönlich argumentiere ich hier noch, wie bereits gesagt. Ich maße mir nicht an für die Allgemeinheit zu sprechen)

Zitat von The User

... Eine solche beschränkte Konfigurationsdatei kann man auch mit einem Programm bearbeiten.

Mit einem Programm das extra für diese Datei geschrieben werden muss, da es eine eigene Syntax nutzt.

Zitat von The User

... und die Konfigurationsdatei muss nicht wissen, wo im Script die Daten hinsollen...

Ich verstehe nicht was du damit meinst, bzw. wo der Unterschied zu einem PHP-Daten-Array in einer Datei sein soll.

Zitat von The User

Ich seh da kein Problem, wenn man nen eigenes config-file Format haben will, warum auch nicht… Und natürlich hat es Mehrwert, nur das Wort INI gehört da nicht rein.

Ok, ich habe mich vielleicht etwas zu sehr an INI aufgehangen. Kein Mehrwert bezog sich auf die Alternative eine PHP-Datei zu schreiben in der die Daten direkt als Array stehen, statt ein eigenes Format zu nutzen das dann erst noch geparst werden muß und auf eine bestimmte PHP-Klasse angewiesen ist.
Ein Greifen des Arguments, das Config-Dateien von Personen angelegt werden sollen, denen nicht genug vertraut wird um sie direkt php-Dateien anlegen zu lassen, ist mir halt noch nie untergekommen und halte ich, zumindest bei mir, auch für die Zukunft für so unwahrscheinlich, dass ich mir darum keine Gedanken mache.

Trotzdem kamen meine Postings vielleicht etwas zu negativ rüber. Wem die Klasse hilft, und sei es nur zeitweise, der soll sie selbstverständlich verwenden, ich will das niemandem aus- oder schlechtreden. Es ging mir wohl mehr darum warum ich für mich persönlich keinen großen Nutzen darin sehe. Andere können das natürlich anders sehen.

Poste den Code mal bitte ordentlich eingerückt und in den [ php ] [ /php ] code-Tags, damit es vernünftig leserlich ist.

Natürlich musst du dich nicht rechtfertigen, und meine Kritik ist auch keineswegs böse, sondern konstruktiv gemeint.

Ich spreche mal nur von mir persönlich: Ich habe sicherlich über 90% meiner Klassen/Libraries die ich mir im Lauf der Jahre geschrieben habe mittlerweile verworfen und kann über das meiste davon nur noch den Kopf schütteln. Und so wird es dir auch mit deinem ini-Parser früher oder später gehen. Deine Klasse bietet nicht den geringsten Mehrwert gegenüber ini-Files die sich an die gängigen Konventionen halten, dafür aber mindestens einen enormen Nachteil, nämlich das diese ini-Files völlig auf deine PHP-Klasse angewiesen sind. Moderne professionelle Softwareentwicklung setzt aber voll auf Entkoppelung und Wiederverwendbarkeit der verschiedenen Elemente. Und da wird deine Klasse ein No-Go.
Mach einen txt-Parser draus, dann kommen wenigstens keine Mißverständnisse auf. ini-Files haben nunmal (aus gutem Grund) Syntax-Konventionen. Und die über Bord zu werfen und somit jegliche Möglichkeit der Wiederverwendbarkeit zu eliminieren, einzig und allein aus dem Grund, weil dir persönlich eine andere Schreibweise besser gefällt, ist nichts was für die Allgemeinheit sonderlich interessant ist.

Wie gesagt, das ist nicht böse sondern konstruktiv gemeint. Ich weiß deine Bereitschaft deine Codes der Allgemeinheit zur Verfügung zu stellen durchaus zu schätzen. Aber wer etwas veröffentlich muss auch das Feedback akzeptieren.

ini-Dateien sind nach meiner Auffassung für Settings gedacht, nicht für Datenhaltung. Und ich lasse in meinen Systemen niemanden Settings festlegen und ini-Dateien anlegen, dem ich nicht auch weit genug vertraue um ihn php-Dateien anlegen zu lassen.
Wenn es um Daten geht die von Außenstehenden eingepflegt werden, dann kriegen sie eine Web-Oberfläche über die sie das machen können, und ich entscheide in welcher Form ich die Daten ablege.

Guck dir mal an wofür hier die ini-Datei verwendet wird:
http://samuelsjoberg.com/archive/2007/01/url-dispatcher
In so einer Form macht das schon wesentlich mehr Sinn für mich.

Ich verstehe nicht ganz, wieso ich ein ini-File schreiben sollte, dass sich an Konventionen halten muss, die von einer spezifischen PHP-Klasse vorgegeben werden. Durch deine eigenen Konventionen geht die eventuelle Wiederverwendbarkeit in anderen Sprachen flöten. Also welchen Mehrwert bietet es mir ein ini-File zu schreiben, dass auf deine PHP-Klasse angewiesen ist und nichts weiter macht als mir ein assoziatives Array zu erstellen, statt einfach eine PHP-Datei zu erstellen in die ich direkt mein Array schreibe?

Gerade bei Login-Systemen gilt für mich bei Usern die Cookies deaktiviert haben oder nicht annehmen: "Dukummsthiernichrein!"
Ich lasse nicht die Sicherheit für den Großteil der Benutzer sausen, nur weil einige wenige Benutzer schlecht/falsch informiert sind. Für einen entsprechenden Hinweis an solche Leute sollte natürlich gesorgt sein.
Schöner Artikel zum Thema Session-Sicherheit:
http://phpforum.de/forum/showthread.php?t=216531

Meine Glaskugel sagt: Du hast irgendwas übersehen oder nicht beachtet.

session_regenerate_id macht bei dir genau das gleiche wie bei jedem anderen auch. Und auch das Verhalten von Variablen ist bei dir nicht anders als bei anderen. Also solange du keinen Code zeigst kann man dir auch nicht sagen wo dein Fehler liegt.

Ich habe den Test jetzt nochmal auf einem anderen Server mit zwei anderen Tabellen durchgeführt. Erste Tabelle mit 5,5 Millionen Datensätzen, gejointe Tabelle mit knapp über 100.000 Datensätzen. Mysql-Version 5.1.49.
Kein Geschwindigkeitsunterschied zwischen den beiden Abfragen.

Das waren nur wenige Test-Datensätze, 20 Bilder, 40 User. MySQL-Version kann ich dir grad nicht sagen, bin erst Sonntag wieder zuhause, dann kann ich mal nachschauen. Ich teste das nächste Woche auch nochmal auf unserem Produktiv-Server in der Firma, da kann ich auf Tabellen mit ein paar Millionen Datensätzen testen. Interessiert mich schon, da meines Wissens beide Versionen von MySQL intern identisch verarbeitet werden (EXPLAIN schmeißt wie gesagt bei beiden Abfragen auch das identische Ergebnis).
Ich kann mir aber eigentlich nicht vorstellen, dass die Performance bei vielen Datensätzen auf einmal unverhältnismäßig auseinanderdriftet.
Generell muss ich sagen, ich habe sehr lange auch bei jedem "Kleinscheiß" auf Performance geachtet und allen möglichen Kram getestet. Davon bin ich aber völlig abgekommen, ich halte mich mittlerweile an den Leitsatz, dass als erste ausschließlich darauf hin entwickelt wird die Testcases ans Laufen zu kriegen und den Code übersichtlich und wartbar zu halten. Von Beginn an auf Performance zu achten ist nach meinen Erfahrungen absolut kontraproduktiv und sorgt nur für unnötige Verzögerungen in der Entwicklung. Performance-Optimierungen stehen an wenn das System fertig ist und läuft, und sich dann eben Performance-Probleme zeigen. Und da liegen die Flaschenhälse dann i.d.R. in ganz anderen Bereichen, als solchen Kleinigkeiten. Vielleicht revidiere ich da meine Meinung bezüglich unseres Falles hier nochmal, sollten sich tatsächlich bei großen Datenmengen stark spürbare Divergenzen ergeben. Kann ich mir aber wie gesagt bei den bisherigen Ergebnissen nicht vorstellen und habe ich auch vorher noch nie gehört.
Bezüglich der Übersichtlichkeit/Lesbarkeit: Klar, bei so einer simplen Abfrage wie hier ist das ziemlich latte, trotzdem präferiere ich auchda schon JOINs, weil da eben das zusammensteht, was auch logisch zusammengehört, und nicht zerstückelt und über die Abfrage verteilt wird.

Ich verwende JQuery und mache kaum etwas über reines JavaScript, für Ajax-Calls nutze ich da $.post() ( http://api.jquery.com/jQuery.post/ )

Für Tabs gibt es da auch ein Extra Widget und in der Demo auch genau deinen Anwendungsfall, nämlich Tab-Inhalte via Ajax laden:
http://jqueryui.com/demos/tabs/#ajax

Ich nehme an du sprichst von Javascript?
Dann lässt sich das meines Wissens mit gleichen Variablennamen nicht realisieren.
Ich sehe spontan zwei Möglichkeiten:
1. Du numerierst deine Tabs durch, verwendest deine bisherigen gleichen Variablennamen als Array und schreibst die jeweiligen Variableninhalte in den Index mit der entsprechenden Tabnummer. Dann brauchst du bei einem Funktionsaufruf nur prüfen welcher Tab gerade aktiv ist.
2. Du lädst beim Seitenaufruf nur dein Starttab, und bei einem Tabwechsel tauschst du den Inhalt per Ajax aus.

Was da sinnvoller ist hängt ganz vom konkreten Anwendungsfall ab.

CREATE TABLE IF NOT EXISTS `user` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(50) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=41 ;


CREATE TABLE IF NOT EXISTS `image` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `filename` varchar(30) NOT NULL,
  `user_id` int(10) unsigned NOT NULL,
  `addDate` datetime NOT NULL,
  `isPublished` tinyint(1) unsigned NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`),
  KEY `user_id` (`user_id`,`isPublished`),
  KEY `user_id_2` (`user_id`),
  KEY `isPublished` (`isPublished`)
) ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=21 ;

EXPLAINs bringen bei beiden Abfragen ein identisches Ergebnis.

Zeitmessung:

<?php
$db = new mysqli("localhost","root","","jointest");
$sql = "
SELECT 
	i.id, i.filename, u.name
FROM 
	image i, user u
WHERE 
	i.isPublished =1
	AND 
	u.id=i.user_id
ORDER BY 
	i.addDate DESC 
LIMIT 6";
$res = $db->prepare($sql);
$start = microtime(true);
for($i=0;$i<10000;$i++) {
	$res->execute();
}
$stop = microtime(true);
$time = $stop-$start;
echo "<pre>WHERE:\t{$time}\n";
unset($res);
$sql = "
SELECT 
	i.id,i.filename,u.name
FROM 
	image i
		INNER JOIN 
		user u 
			ON 
			u.id=i.user_id
WHERE 
	i.isPublished=1
ORDER BY 
	i.addDate DESC 
LIMIT 6";
$res = $db->prepare($sql);
$start = microtime(true);
for($i=0;$i<10000;$i++) {
	$res->execute();
}
$stop = microtime(true);
$time = $stop-$start;
echo "JOIN:\t{$time}</pre>";
?>

5 Beispieldurchläufe:

WHERE:	3.526524066925
JOIN:	3.4969871044159


WHERE:	3.7058770656586
JOIN:	3.4664239883423


WHERE:	3.4749619960785
JOIN:	3.3867881298065


WHERE:	3.4011709690094
JOIN:	3.4289638996124


WHERE:	3.5800061225891
JOIN:	3.5392849445343

Ja klar, das wollte ich auch nicht bestreiten. Sein Beispiel funktioniert für deinen Fall genauso einwandfrei und ich kenne einige Leute denen diese Schreibweise besser gefällt.
Ich bevorzuge für mich persönlich halt einfach aus Prinzip JOINs

Intern macht es von der Geschwindigkeit keinen wirklichen Unterschied. Ich habe allerdings in größeren Projekten häufiger mal JOINs über 5+ Tabellen, und da ist es ohne JOIN-Klausel sehr mühselig wenn man nach mehreren Wochen nochmal an so eine Abfrage ran muß um Anpassungen vorzunehmen. Daher verwende ich prinzipiell nur noch JOINs.
Mal abgesehen davon, dass das Beispiel von threadi nur eine Alternative für INNER JOINs bietet, nicht für OUTER JOINs.

Ich persönlich präferiere JOINs, aus Gründen einer übersichtlicheren Strukturierung. Die Bedingungen für die Tabellenverknüpfungen haben nach meiner Auffassung nichts in der WHERE-Klausel verloren. Die WHERE-Klausel ist dazu da die Ergebnismenge einzuschränken.

Vorausgesetzt du möchtest für einen Gewinn eine Chance von 1% haben, für einen anderen eine Chance von 10%, die Gesamtchance überhaupt irgendetwas zu gewinnen soll genau 10% sein (höchste Chance bei einem Gewinn). Dann kannst du nicht mit % rechnen ohne das Ergebnis zu verfälschen, also nicht mit einer Zufallszahl zwischen 1-100.
Du musst eine "Reichweite von-bis" für jeden Gewinn bilden und 100 mit dem sich hieraus ergebenden "Überhang" faktorisieren. Dann eine Zufallszahl zwischen 1 und dem neuen Maxwert bilden und schauen ob die ermittelte Zahl in einer Gewinn-Range liegt.

So in etwa (ungetestet eben runtergehackt):

Table prizes


id | prize     | chance
---+-----------+-------
 1 | Auto      |      1
 2 | Teddy     |     10
 3 | Gutschein |     20

$sql = "SELECT prize,chance FROM prizes ORDER BY chance ASC";
$res = $db->prepare($sql);
$res->bind_result($prize,$chance);
$res->execute();
$rangedChances = array();
$chanceSum = 1;
while($res->fetch()) {
	$min = $chanceSum;
	$max = $chanceSum + $chance - 1;
	$rangedChances[] = array( "prize"=>$prize , "min"=>$min , "max"=>$max );
	$chanceSum+= $chance;
}
$rndMax = round( 100 * ( $chanceSum / $chance ) );
$myChance = random(1,$rndMax);
$myPrize  = null;
if($myChance<=$chanceSum) {
	foreach($rangedChances as $curChance) {
		if($myChance>=$curChance['min'] && $myChance<=$curChance['max']) {
			$myPrize = $curChance['prize'];
			break;
		}
	}
}
if($myPrize===null) {
	echo "Leider nicht gewonnen.";
}
else {
	echo "Herzlichen Glückwunsch, Sie haben gewonnen! Ihr Preis: {$myPrize}";
}

Das wollte ich auch nicht unterstellen.

Ich habe nur festgestellt, dass viele Entwickler sich der von mir angesprochenen Punkte nicht wirklich bewußt sind. Da steckt in den seltensten Fällen böse Absicht hinter.