Thread: chart pie diagramm class

Hat jemand den Fehler gefunden, warum Zahlen unter 1 % nicht angezeigt werden?

Vielleicht wäre es hier sinnvoll mit allen Renderern SVG-Grafiken zu generieren und die bei Bedarf in Bilder, ImageMaps etc zu transformieren. Ist jedenfalls wohl weniger Arbeit als für jeden Ausgabetyp und jeden Diagrammtyp einen neuen Renderer zu schreiben.


Was meinst du mit "nicht angezeigt"? Taucht der komplette Wert nicht in dem Diagramm auf? Oder fehlt nur der Balken? Letzteres könnte vielleicht an einer ungünstigen Bildgröße liegen, 1% = 1 Pixel wäre. Dann wären natürlich kleinere Werte <1Pixel und würden deshalb nicht dargestellt. Man müsste also dafür den berechneten Wert aufrunden (oder so)

Es taucht nicht auf.
1,2 % werden noch deutlich dargestellt, aber 0,9 ist einfach nicht da, auch wenn ich die Bild-höhe verdoppele   

Ich hab mir nun deinen jetztigen Code angesehen und habe einige Verbesserungsvorschläge. Ich hoffe sie sind dir willkommen und du wirst diese umsetzten, denn ich glaube, dass sie sehr sinnvoll sind.
Und verstehe das bitte nicht als Kritik, sondern nimm meine Tipps an und lerne daraus. Man denkt schnell, dass man OOP programmieren kann, aber es gibt da doch mehr zu lernen als man glaubt. Und das gelerne dann richtig einzusetzten stellt auch eine Herausforderung da. Meine Verbesserungsvorschläge basieren hauptsächlich auf OOP.

Chart.php

• "scheme" direkt als Array speichern und nicht als String und dann explode() verwenden.
• In Konstruktoren NIE "return" verwenden, da der Wert von return nicht zurückgegeben wird. Meiner Meinung nach, sollte das beim Phasen einen Error geben. Da waren die php-Entwickler schlampig. Falls man tatsächlich im Konstruktor ein Fehler passieren kann, dann muss man mit Exceptions arbeiten. Aber so etwas sollte man vermeiden.
• "addSeries()" was ist das? Sollte man aus dem Kommentar herauslesen können. So, beim weiteren Code durchschauen wurde es dann klar. Wenn man auf Preformance optimieren möchte, dann könnte man direkt ein Array übergeben und auf DataSeries verzichten. Falls es "sicher" sein soll, dann schreib "addSeries( DataSeries $serie )". Dann übergibst du das ganze DataSeries Objekt und holst dir erst in der Methode das Array raus.
• "render()" falls du schon ein return false machst, dann solltest du auch ein return true machen.

*ChartRenderer.php

• "label_form" mach ein Interface "LableForm" und 2 Klassen (LableFormRound, LableFormSquare) die jenes implementieren. Und dann gibst du ihnen einfach eine Methode "render()". Dann brauchst du keinen langsamen String Vergleich und es ist leichter erweiterbar. Man muss nur einen neuen LableForm Klasse schreiben und nichts am bestehenden Code ändern.
• Eine abstract Superklasse "ChartRenderer" einführen. Denn soweit ich sehe unterscheiden sich die Klassen nur an einer Stelle um 15-30 Codezeilen. In die abstract Superclass enthält den identischen Code von den momentanen Renderern. Zusätzlich machst du eine abstract Method z.B. "renderImageForm()" (der Name ist nicht sondlerlich gut, aber mir ist auf die schnelle nichts anderes eingefallen) und rufst diese anstelle der 15-30 unterschiedlichen Codezeilen auf. In den Basisklassen (PieChartRender, BarCharRenderer) definierst du dann die abstract method.
• "render()" bitte versuche diese Methode in mehrere Methoden aufzuspalten. Denn so wie sie ist, kenne ich mich absolut nicht aus und könnte (ohne Einarbeitungszeit) keine schnellen Änderungen durchführen. Wie ich aufspalten meine: "render(){ doWork1(); doWork2(); doWordk3(); }". Denn durch sowas wird der Code viel besser lesbar und damit auch leichter Änder- und Erweiterbar

EDIT: falls es Fragen zu einem der Punkte gibt, dann einfach stellen. Ich werde dann versuchen diese zu beantworten. Vor allem Fragen wie: "Warum schlagst du vor, dass man das so macht", wird es vielleicht geben.

Gruß,
Xaron

@Xaron:
Erst einmal Danke für deinen Beitrag. Solche Beiträge sind leider in letzter Zeit selten geworden.

Ich möchte noch einmal darauf hinweisen, dass es kein Meisterwerk ist.

Für Schreibfaule, wie mich. Statt : hätte ich jedes Mal ',' schreiben müssen. Ich glaube kaum, das hier die Performance merklich sich verbessert. Achja hier der Nachtrag für andere Farbschemen.
Wird gemacht.So beraube ich jeden Programmier, der die Klasse benutzt um die Möglichkeit, eigene Methoden hinzuzufügen:

• function getDurchschnitt
• function getMax
• function countValues

Meine Antwort:Information hiding. Hier wäre meine Frage:
Warum schlägst du vor, dass man das so macht

Zeit! Die Klasse ist nur ein netter Nebeneffekt. Natürlich habe ich über eine Abstrakt Klasse nachgedacht. Es ist nur so, dass ich die Klasse von klasse7dark einfach per copy-and-paste übernommen habe.

Ich möchte jetzt nicht undankbar für Tipps herübergekommen sein. Bei mir ist einfach die Zeit der begrenzte Faktor. Für Nebeneffekte, wie runde Diagramme steckte ich nicht viel Arbeit hinein.

Wenn ich mal viel Zeit haben werde, werde ich es umsetzen. Ich sehe es nur als Codesnippet, dass ich gerne mit der Community teilen möchte. Für alle anderen:
http://www.aditus.nu/jpgraph/


Gute Nacht. Oder Guten Morgen je nachdem.

Naja. Vielleicht kann man sich ja bei einem cDc-Remake (Code-DB oder was auch immer) mal richtig Gedanken über soetwas machen. zB gleich auf PHP5.3 aufzusetzen und sämtliche Skripte direkt in einem Namespace zu verpacken und damit quasi eine Art Framework oder Klassensammlung für andere Programmierer bereitzustellen.

Ich glaube ich hab auch schon angemerkt, dass es nicht perfekt ist, aber dennoch als Beispielcode recht gut gelungen und auf den meisten Rechnern direkt einsetzbar ist. (Bei mir fehlte leider die Möglichkeit jpeg zu erzeugen, also hab ich kurzerhand den Kram in png geändert). Ich persönlich hätte das Scheme vermutlich auch noch in einer Klasse gekapselt, weil man damit auch noch "Random-Schemes" hätte implementieren können. Und vielleicht wäre es auch sinnvoller erst eine einfache SVG-Grafik zu erzeugen und die anschließend in das gewünschte Format zu transformieren, weil umgekehrt ist schwierig und für jede Art von Diagramm mehrere Möglichkeiten zu schreiben halte ich für sinnfrei.
Genauso die Sache mit den Legenden: Man hätte eine komplette Klasse nutzen können um die Legende zu generieren, eine für den Graphen selbst und in der übergeordneten Klasse den ganzen Spaß zusammensetzen können. Generell könnte man überlegen, ob man nicht noch ein paar Hilfsklassen für die Bildverarbeitung oder Bildbearbeitung schreibt.
Wie auch immer: Ich halte recht viel von solchen Quick-and-Dirty Klassen. Immerhin kann man dadurch die Anforderungen an das (Teil)projekt genauer spezifizieren und anschließend eine gute Implementierung erreichen.

Was ich allerdings sehr interessant finde: Die Pro-Version von JpGraph kostet 85€ für eine Single-License und satte 650€ für eine Bulk-Lizenz. Wenn man überlegt, dass man zumindest die Pie-Diagramme in kaum mehr als 30 Zeilen Code (ohne das drum herum) schreiben kann... Naja. Leistet zwar wohl noch "etwas" mehr, aber dennoch halte ich den Preis für Wucher.

Ich habe mal versucht die Class produktiv einzusetzen.... - Sieht nur nicht wirklich schön aus   

Füge gleich noch ein Bild davon an.

----------------------------------------------------

Ja ok,
sieht wirklich scheiße aus.

Ich weiß jetzt aber nicht, wie man das besser machen kann, bin für konstruktive Kritik offen.

Zweispaltige Anzeige der Farben / Prozentanzeige fällt mir da so ein. Dann ist es nach unten nicht mehr so überstehend.