kirk disen schrieb:> bei der r514 fällt mir auf dass es in der Artikelauflistung nicht mehr> möglich ist die Unterkategorien auszublenden.
Bist du dir da ganz sicher? Ich konnte dies bei mir nicht
nachvollziehen. Und auch in der Online-Demo
(http://partdb.grautier.com/) funktioniert es (Ich weiss zwar nicht
welche SVN Revision dort läuft, aber es müsste eigentlich die jeweils
aktuellste sein).
Zur Sicherheit kannst du ja mal noch die neuste showparts.php holen:
https://part-db.googlecode.com/svn/trunk/showparts.php
Ansonsten müsste man vielleicht mal schauen, ob Apache irgendwelche
Fehlermeldungen liefert.
Hi, die Demo ist momentan nicht die aktuellste hab den Server neu
aufsetzen müssen die ist ca. 20 tage alt bin noch nicht dazu gekommen
das autoupdaten wieder einzurichten.
Hi,
ich find es Klasse, dass das Projekt so aktiv entwickelt wird, weiter
so.
Ich hab meinen Widerstandsrechner auch etwas erweitert. Man kann jetzt
den besten Widerstand aus einer E-Reihe suchen und die besten
Widerstände für Spannungsteiler.
Anbei ein diff-File und die drei Bilder müssen in den Ordner
tools/rechner/
Ob die Bestimmung der Widerstände die optimalste ist weis ich nicht,
wäre nett wenn das ein paar Leute testen könnten.
Geplant ist noch ein Rechner für dem LM317.
André Althaus schrieb:> ich find es Klasse, dass das Projekt so aktiv entwickelt wird, weiter> so.
Wir geben uns Mühe ;-)
> Ich hab meinen Widerstandsrechner auch etwas erweitert. Man kann jetzt> den besten Widerstand aus einer E-Reihe suchen und die besten> Widerstände für Spannungsteiler.>> Anbei ein diff-File und die drei Bilder müssen in den Ordner> tools/rechner/
Hmm entweder bin ich zu dumm um den Patch zu übernehmen (gut möglich,
weiss nicht wie es geht^^), oder irgendwas stimmt mit dem Patch nicht
;-) Die JavaScript-Sachen funktionieren nach dem patchen irgendwie nicht
mehr...Könntest du vielleicht einfach die ganzen Dateien hochladen, die
überschrieben werden müssen? :-)
André Althaus schrieb:> Hi,> ich hab die Dateien nochmal angehängt. Die Datei einfach in den tools> Ordner entpacken.
Danke, aber bei mir funktionieren die neuen zwei Funktionen nicht. Da
tut sich JavaScriptmässig einfach nichts. Ich habe die Dateien trotzdem
mal ins SVN geladen (r517), dann können die anderen auch mal schauen obs
bei ihnen funktioniert.
André Althaus schrieb:> Welchen Browser benutzt du? Ich habs bisher nur mit Firefox 14 getestet.
Ebenfalls FF14, auf Linux Ubuntu. Die Farbringtabelle funktioniert, nur
die neuen beiden Funktionen nicht.
Du kannst ja mal die aktuelle SVN Version beziehen und schauen ob die
bei dir läuft. Dann reden wir auch sicher von den gleichen Dateien. Ich
kann nicht ausschliessen dass ich irgendwas falsch gemacht habe ;-)
Oder wenn die Online-Demo bald wieder richtig funktioniert könnten wir
es dort testen :-) (@K.J. soll nicht heissen dass du stressen sollst xD)
Ach übrigens @all:
Die Semesterprüfungen sind fast vorbei (nur noch eine), heisst also ich
kann langsam wieder mit dem Programmieren anfangen :-) @Udo, wie weit
bist du mit den Templates?
Leider nicht viel weiter. Hatte andere Arbeiten vorzuziehen :( Ich hoffe
doch sehr, das ich diese Woche mal ein paar Stunden wieder daran
arbeiten werde. Soviel Rückstand ist ja nicht, dass ich es nicht
schaffen könnte.
K. J. schrieb:> Hi, so die DemoDB wird jetzt wieder einmal am tag upgedated um 11:00.>> mfg
Wunderbar!
Jetzt sehe ich auch dass der Widerstandsrechner funktioniert. Da muss
wohl irgendwas an meiner Installation faul sein... Neuerdings liegen bei
mir die Skripte auf einer Samba Freigabe, die dann nach /var/www
gemountet werden. Vielleicht ist da ja nun irgendwo der Hund begraben...
Urban B. schrieb:> K. J. schrieb:>> Hi, so die DemoDB wird jetzt wieder einmal am tag upgedated um 11:00.>>>> mfg>> Wunderbar!> Jetzt sehe ich auch dass der Widerstandsrechner funktioniert. Da muss> wohl irgendwas an meiner Installation faul sein... Neuerdings liegen bei> mir die Skripte auf einer Samba Freigabe, die dann nach /var/www> gemountet werden. Vielleicht ist da ja nun irgendwo der Hund begraben...
Ahm WTF du mountest ne SAMBA Freigabe in nen Webordner ? mal abgesehen
von den Rechteproblemen, gibt es da noch diverse andere.
K. J. schrieb:> Ahm WTF du mountest ne SAMBA Freigabe in nen Webordner ? mal abgesehen> von den Rechteproblemen, gibt es da noch diverse andere.
xD ja ich weiss es ist komisch aber eigentlich scheint alles zu
funktionieren. Dass es sicherheitstechnisch vielleicht nicht optimal ist
ist mir wurscht, läuft ja alles in meinem privaten LAN.
Der Hintergrund ist folgender:
Ich möchte den Webserver (momentan) am liebsten in einer VM laufen
lassen, denn ich lagere gerne Software in VMs aus um mein System
"sauber" zu halten. Die Webseiten an sich (also die Dateien) möchte ich
aber auf meiner lokalen Festplatte haben, nicht in einer VM (1. möchte
ich keine Dateien verlieren wenn eine VM kaputt geht (meine lokalen
Dateien werden täglich gesichert) und 2. ist das Programmieren
angenehmer wenn sich die Dateien auf meinem eigenen System befinden). Da
die Webseiten sowieso Teil einer Samba Freigabe sind, dachte ich, ich
könnte ja den freigegebenen Ordner "www" in der VM einfach per fstab
nach "var/www" mounten. Dazu noch in der fstab "uid=33,gid=33" setzen
damit "www-data" Zugriff auf die Dateien hat.
Wie gesagt, eigentlich funktioniert es :-) Ob das Javascript-Problem
wirklich durch meine komische Konstellation entstanden ist, weiss ich
nicht. Andere JavaScript Teile funktionieren wunderbar.
Udo Neist schrieb:> Nimm statt Samba NFS für die Freigabe.
Für all meine Freigaben NFS zu verwenden geht nicht, es gibt noch einen
Windows PC der auf die Freigaben zugreifen muss. Und Samba und NFS
parallel zu nutzen finde ich irgendwie blöd ;-)
Urban B. schrieb:> Für all meine Freigaben NFS zu verwenden geht nicht, es gibt noch einen> Windows PC der auf die Freigaben zugreifen muss. Und Samba und NFS> parallel zu nutzen finde ich irgendwie blöd ;-)
Nutze ich hier schon seit Jahren. Was soll daran blöd sein? Man muss ja
kein YP-Server parallel aufbauen g NFS v4 ist performanter, braucht
auch nicht unbedingt Kerberos.
Udo Neist schrieb:> Nutze ich hier schon seit Jahren. Was soll daran blöd sein?
Naja dann ist mein PC irgendwann mehr Server als Workstation^^ Ne ich
mag es einfach nicht wenn mein Arbeits-PC vollgestopft ist mit Software.
Daher auch die VMs (ich könnte ja auch Apache auf meinem PC laufen
lassen, will ich aber nicht). Ich bin auch einfach zu faul all das Zeug
wieder zu installieren wenn ich mal mein System neu aufsetze. Lieber die
weniger häufig verwendeten Programme in einer VM installieren, dann
brauche ich nach einer Neuinstallation des Systems nur noch Virtualbox
zu installieren.
Aber wenn wirklich Samba an dem JavaScript Problem schuld sein sollte,
werde ich da natürlich schon noch was unternehmen :-) Momentan hat das
aber keine Priorität, sonst läuft ja alles so wie es soll.
Übrigens arbeite ich gerade an der ganzen Update-Geschichte von Part-DB.
Vor allem auch zu den Versionsbezeichnungen habe ich mir Gedanken
gemacht. Mein Vorschlag wäre, dass ein User zwischen drei Varianten
wählen können soll: "stable", "unstable" und "svn".
Bei "stable" soll das System nur Updates anzeigen, die als stabil
gekennzeichnet sind. Bei "unstable" dachte ich, das sollen einfach die
Release Candidates von der nächsten stabilen Version sein, und bei "svn"
immer die jeweils aktuelle SVN Revision. Letzteres funktioniert
vermutlich halt auf vielen Webspaces nicht, ist aber ja auch nicht
weiter schlimm.
(es gibt aber sogar spezielle PHP-Funktionen um SVN-Sachen erledigen zu
können [scheinen aber noch experimentell zu sein]. Vielleicht ist auf
einigen Webservern ja sogar das entsprechende Plugin installiert, dann
könnte man ein checkout machen ohne ein exec(). )
Eine stabile Version soll aus drei Ziffen bestehen, z.B: "0.2.3".
Eine unstabile Version mit dem Vermerk des RC: "0.2.4 RC3".
Und eine SVN Revision "r567".
Um diese drei Versionsbezeichnungen auch untereinander vergleichen zu
können (zum entscheiden, welche neuer/älter ist), würde sich anbieten,
dass die stabilen und unstabilen Versionen auch immer den Vermerk zur
jeweiligen SVN Revision beinhalten. Also dass z.B. die Version "0.2.3"
damals die Revision "r456" hatte.
Die Revisionsnummer wäre programmiertechnisch dann eigentlich die
relevante Information, um Versionen untereinander vergleichen zu können.
Wenn wir nur mit den "0.2.3"-Bezeichnungen arbeiten würden, könnte es
sonst mal zu einem Durcheinander kommen. Man stelle sich vor, dass
jemand von "svn" auf "stable" wechseln möchte. Wie kann dann Part-DB
entscheiden, welche Updates es runterladen/installieren muss? Es weiss
ja nichtmal, ob die neuste stabile Version überhaupt neuer ist als die
aktuell installierte SVN Revision. Arbeiten wir mit den Revisionszahlen,
ist es für das System kein Problem zu erkennen, ob ein Update verfügbar
ist oder nicht.
Das würde dann natürlich bedeuten, dass bei jedem Update, das angeboten
wird, auch die jeweilige Revisionsnummer hinterlegt sein muss. Aber das
sollte ja nicht weiter stören.
Urban B. schrieb:>> Nutze ich hier schon seit Jahren. Was soll daran blöd sein?>> Naja dann ist mein PC irgendwann mehr Server als Workstation^^ Ne ich> mag es einfach nicht wenn mein Arbeits-PC vollgestopft ist mit Software.> Daher auch die VMs (ich könnte ja auch Apache auf meinem PC laufen> lassen, will ich aber nicht). Ich bin auch einfach zu faul all das Zeug> wieder zu installieren wenn ich mal mein System neu aufsetze. Lieber die> weniger häufig verwendeten Programme in einer VM installieren, dann> brauche ich nach einer Neuinstallation des Systems nur noch Virtualbox> zu installieren.
Ich hab ein eigenes Netzwerk hier laufen. Mein Server stellt mir alles
wichtige für die Webprogrammierung zur Verfügung. Wenn schon, dann teste
ich es in einer realen Umgebung. Eine VM hätte nur den Vorteil, dass man
fatale Fehler einfach schnell ungeschehen machen kann. Aber wofür hat
man ja ein tägliches Backup oder kopiert mal schnell die betreffenden
Dateien unter einen neuen Namen? Aber jeder arbeitet ja anders ;-)
Revision 518:
- showdevices.php auf Templates umgestellt
- Anstelle von $currency wird money_format() verwendet und Darstellung
in der Tabelle angepasst
Mir ist per Zufall die PHP-Funktion money_format() aufgefallen, als ich
die Zahlendarstellung der Preise vereinheitlichen wollte. Diese Funktion
kann die Währung anhand von der Umgebungsvariable LC_MONETARY und einem
Formatstring darstellen. Somit kann auf die Variable $currency
verzichtet werden.
ToDo: Formatstring anhand von LC_MONETARY aus einem Array entnehmen.
Bei meiner Umstellung auf Templates sind mir die doch sehr
unterschiedliche Formatierungen aufgefallen. Ich habe mir mal ein paar
Gedanken über ein gemeinsamen Styleguid gemacht. Er sollte so einfach
wie möglich sein, damit Einsteiger recht schnell damit zurecht kommen.
1
Styleguide --- 28.08.2012 Udo Neist (weinbauer73@gmail.com)
2
3
*** Sprache ***
4
5
- Alle Kommentare sind in Englisch zu verfassen.
6
- Deutsche Kommentare sind entsprechend zu kennzeichnen und möglichst rasch ins englische zu übersetzen.
7
- Kommentare sind nicht überflüssig, sondern notwendig!
8
9
*** Dokumentation ***
10
11
- Einleitende Kommentare für die Funktionsbeschreibung sollten nicht vergessen werden.
12
- Dokumentationssystem wird noch gesucht.
13
- Offizielles Wiki nutzen.
14
15
*** Entwicklung ***
16
17
- PHP 4 ist veraltet und sollte nicht mehr genutzt werden.
18
- Alle neuen Funktionen werden in den Branches zuerst getestet und dann in die offizielle Version übernommen.
19
- Kennzeichnung von stable, unstable und non public (oder ähnlich)-Versionen.
20
21
*** PHP-Script ***
22
23
- Einleitung mit Lizenz
24
- darunter Initiator der Datei mit Datum und Email
25
- darunter Auflistung der Änderungen im folgenden Format:
26
- Jahr Email
27
- neue Zeile
28
- Tabulator und "-"
29
- Kurze Beschreibung der Änderung
30
- möglichst eine Auflistung aller Funktionen
31
- Ausgabe von HTML nicht in das Script übernehmen, dazu Templates (vlibTemplate) nutzen.
32
- Eine zentrale Library bindet die
33
34
*** Einrückungen ***
35
36
- 1 Tabulatorschritt umfasst 5 Spaces.
37
- Öffnende und schliessende geschweifte Klammern in einer eigenen Zeile.
38
- Jeder Block innerhalb geschweifter Klammern um einen Tab einrücken.
39
- Ausnahmen für einzeilige Blöcke. Auf Klammern sollte der Lesbarkeit wegen nicht verzichtet werden.
40
- IF-THEN-ELSE als ternärer Operator ist erlaubt, sollte möglichst aber nur bei der Zuweisung von Werten verwendet werden.
41
- Arrays oder längere Strings so formatieren, das eine gute Lesbarkeit gewährleistet ist.
42
43
*** Benennungen ***
44
45
- Funktionen werden klein geschrieben und müssen selbst beschreibende Namen tragen.
46
- Trennung der einzelnen Wörter erfolgt mit dem Unterstrich ("_").
47
48
*** Klassen und Funktionen ***
49
50
- Sich wiederholende Funktionen bitte in Klassen auslagern.
51
- Namespaces sind möglich.
52
- Klassen mit dem Konstruktur __construct() für die Prüfung auf Abhängigkeiten der Klasse und eventuell fehlenden Funktionen versehen.
53
- Debug-Funktionen ermöglichen.
Wenn es keine größeren Widersprüche gibt, stelle ich das am Wochenende
ins PartDB-Wiki.
Udo Neist schrieb:> Bei meiner Umstellung auf Templates sind mir die doch sehr> unterschiedliche Formatierungen aufgefallen. Ich habe mir mal ein paar> Gedanken über ein gemeinsamen Styleguid gemacht.
Gute Idee!
> *** Entwicklung ***>> - PHP 4 ist veraltet und sollte nicht mehr genutzt werden.
Spätestens wenn wir unsere Branches in den Trunk übernehmen, ist Part-DB
auch gar nicht mehr lauffähig mit PHP 4, vor allem wegen dem PDO und den
Klassen (die sich seit PHP 4 stark verändert haben und eine
Kompatibilität sehr aufwändig machen würde). Daher ist dann "sollte
nicht mehr genutzt werden" zu ungenau - es kann gar nicht mehr genutzt
werden.
> - Alle neuen Funktionen werden in den Branches zuerst getestet und dann> in die offizielle Version übernommen.
Hmm ich weiss nicht ob das wirklich notwendig ist. Wenn die User ihre
Part-DB Installationen über die Updatefunktion ganz einfach aktuell
halten können, wird (hoffentlich) keiner mehr die SVN-Version im Einsatz
haben (ausser natürlich für die Entwicklung). Daher darf im Trunk
durchaus auch mal eine Version drin sein, die noch offensichtliche
Fehler enthält. Ich denke, das ist doch bei SVN eigentlich auch "so
gedacht", oder?
> - Kennzeichnung von stable, unstable und non public (oder> ähnlich)-Versionen.
Ich weiss jetzt nicht genau wie du das meinst. Ich würde mir das so
vorstellen:
- Die Hauptentwicklung geschieht im Trunk
- Nur grössere Änderungen, die lange dauern, oder irgendwelche Tests
werden in Branches durchgeführt (so wi wir beiden es momentan halt
machen)
- Von Zeit zu Zeit schauen wir, dass die Version im Trunk möglichst
stabil läuft. Dann erstellen wir vom Trunk ein Release Candidate und
geben dieses frei für diejenigen, die bei sich die "unstable" Updates
installieren.
- Wenn wir der Meinung sind, die aktuelle Version im Trunk ist nun
stabil, erstellen wir ein Update-Paket und geben dieses als "stable"
frei.
Zwischen der Herausgabe des ersten Release Candidate bis zur jeweiligen
stabilen Version sollten natürlich keine grösseren Änderungen mehr
durchgeführt werden (neue Funktionen usw.). Die behält man besser
erstmal entweder bei sich auf dem PC oder halt in einem Branch. Nach der
Herausgabe der stabilen Version kann man dann wieder im Trunk
herumwerkeln wie man will.
> - Eine zentrale Library bindet die
das verstehe ich nicht :-)
> - 1 Tabulatorschritt umfasst 5 Spaces.
5 Spaces ist aber ziemlich unüblich, oder? 4 wären doch viel
verbreiteter würde ich meinen.
> - Klassen mit dem Konstruktur __construct() für die Prüfung auf> Abhängigkeiten der Klasse und eventuell fehlenden Funktionen versehen.
Hmm das verstehe ich auch nicht :-)
> - Debug-Funktionen ermöglichen.
Gute Idee, nur wie macht man das bei PHP am besten? Hat sich da irgend
ein System eingebürgert? Einfach mit "print" irgendwelche Meldungen
ausgeben funktioniert ja nicht immer (wenn z.B. eine Meldung innerhalb
von einem html-<select> ausgegeben wird, wäre sie teilweise gar nicht
ersichtlich).
Ansonsten bin ich mit dem Styleguide einverstanden.
Urban B. schrieb:>> *** Entwicklung ***>>>> - PHP 4 ist veraltet und sollte nicht mehr genutzt werden.>> Spätestens wenn wir unsere Branches in den Trunk übernehmen, ist Part-DB> auch gar nicht mehr lauffähig mit PHP 4, vor allem wegen dem PDO und den> Klassen (die sich seit PHP 4 stark verändert haben und eine> Kompatibilität sehr aufwändig machen würde). Daher ist dann "sollte> nicht mehr genutzt werden" zu ungenau - es kann gar nicht mehr genutzt> werden.
Für uns ist es klar, aber vielleicht gibt es noch Neueinsteiger, die
auch PHP 4 wollen? Ist nur eine Klarstellung.
>> - Alle neuen Funktionen werden in den Branches zuerst getestet und dann>> in die offizielle Version übernommen.>> Hmm ich weiss nicht ob das wirklich notwendig ist. Wenn die User ihre> Part-DB Installationen über die Updatefunktion ganz einfach aktuell> halten können, wird (hoffentlich) keiner mehr die SVN-Version im Einsatz> haben (ausser natürlich für die Entwicklung). Daher darf im Trunk> durchaus auch mal eine Version drin sein, die noch offensichtliche> Fehler enthält. Ich denke, das ist doch bei SVN eigentlich auch "so> gedacht", oder?
Ich habe die Styleguides bewusst so geschrieben, denn es spiegelt die
aktuelle Situation dar. Wenn später die Update-Funktion auch klappt und
wir eine neue offzielle Version haben, würde dieser Punkt wegfallen.
>> - Kennzeichnung von stable, unstable und non public (oder>> ähnlich)-Versionen.>> Ich weiss jetzt nicht genau wie du das meinst. Ich würde mir das so> vorstellen:> - Die Hauptentwicklung geschieht im Trunk> - Nur grössere Änderungen, die lange dauern, oder irgendwelche Tests> werden in Branches durchgeführt (so wi wir beiden es momentan halt> machen)> - Von Zeit zu Zeit schauen wir, dass die Version im Trunk möglichst> stabil läuft. Dann erstellen wir vom Trunk ein Release Candidate und> geben dieses frei für diejenigen, die bei sich die "unstable" Updates> installieren.> - Wenn wir der Meinung sind, die aktuelle Version im Trunk ist nun> stabil, erstellen wir ein Update-Paket und geben dieses als "stable"> frei.
Sagt das obige was anderes aus? Nicht das ich wüsste. Uns dürfte es klar
sein, nur ob alle den Unterschied verstehen? "stable" ist der offizielle
Teil, "unstable" die vor der Freigabe stehende und "non public" sind
halt unsere beiden Branches. Oder wie würdest du es nennen? Release
Candidates würde ich zu den "unstable"-Versionen zählen.
>> - Eine zentrale Library bindet die>> das verstehe ich nicht :-)
Na, das nicht jedes Script jede Library und Klasse selbst einbinden
muss. Derzeit läuft das ja über die lib.php bzw. config.php und erfüllt
damit die Bedingung.
>> - 1 Tabulatorschritt umfasst 5 Spaces.>> 5 Spaces ist aber ziemlich unüblich, oder? 4 wären doch viel> verbreiteter würde ich meinen.
Bei den meisten Programmen die ich verwende sind 5 voreingestellt. Ich
hab auch mit 4 keine Probleme. Hauptsache sauber getrennt :-)
>> - Klassen mit dem Konstruktur __construct() für die Prüfung auf>> Abhängigkeiten der Klasse und eventuell fehlenden Funktionen versehen.>> Hmm das verstehe ich auch nicht :-)
Ganz einfach. Die einzelnen Klassen haben untereinander Abhängigkeiten.
Fehlt eine Funktion, sei eine fehlende Datei im System oder eine falsche
PHP-Version, so läuft das Script nicht. Genauso ist das mit den Rechten
im Dateisystem (hatten wir ja schon mit get_svn_revision()), kann man
dort auch prüfen. Ich meine, wir sollten das schon nutzen.
>> - Debug-Funktionen ermöglichen.>> Gute Idee, nur wie macht man das bei PHP am besten? Hat sich da irgend> ein System eingebürgert? Einfach mit "print" irgendwelche Meldungen> ausgeben funktioniert ja nicht immer (wenn z.B. eine Meldung innerhalb> von einem html-<select> ausgegeben wird, wäre sie teilweise gar nicht> ersichtlich).
Man könnte in den Templates ein Debug-Block hinzufügen, der dort gewisse
Daten darstellt oder in ein "Logfile" schreibt, welches in einem eigenen
Fenster regelmäßig per Ajax geladen werden kann.
> Ansonsten bin ich mit dem Styleguide einverstanden.
Gut :-)
Der Styleguide soll Neueinsteigern ein paar kleine Regeln für das
Projekt aufzeigen, wie wir das ganze Handhaben wollen. Für uns ist das
meiste selbstverständlich. Ich will euch ja auch nicht bevormunden, nur
weil ich seit Anfang/Mitte der 1980er programmiere und für meine eigenen
Projekte entsprechende Regeln versuche einzuhalten, auch wenn sie
nirgendwo stehen. Es macht aber die Arbeit erträglicher, wenn man nach
einiger Abwesenheit wieder am Code arbeiten "muss". Sind ja alles nur
Vorschläge :-)
>>> - Alle neuen Funktionen werden in den Branches zuerst getestet und dann>>> in die offizielle Version übernommen.>>>> Hmm ich weiss nicht ob das wirklich notwendig ist. Wenn die User ihre>> Part-DB Installationen über die Updatefunktion ganz einfach aktuell>> halten können, wird (hoffentlich) keiner mehr die SVN-Version im Einsatz>> haben (ausser natürlich für die Entwicklung). Daher darf im Trunk>> durchaus auch mal eine Version drin sein, die noch offensichtliche>> Fehler enthält. Ich denke, das ist doch bei SVN eigentlich auch "so>> gedacht", oder?>> Ich habe die Styleguides bewusst so geschrieben, denn es spiegelt die> aktuelle Situation dar. Wenn später die Update-Funktion auch klappt und> wir eine neue offzielle Version haben, würde dieser Punkt wegfallen.
Ach so, ja klar, beim aktuellen Stand passt das natürlich. Irgendwie
denke ich einfach immer schon an den Moment, wo unsere Branches zur
stabilen Version werden^^
>>> - Kennzeichnung von stable, unstable und non public (oder>>> ähnlich)-Versionen.>>>> Ich weiss jetzt nicht genau wie du das meinst. Ich würde mir das so>> vorstellen:>> - Die Hauptentwicklung geschieht im Trunk>> - Nur grössere Änderungen, die lange dauern, oder irgendwelche Tests>> werden in Branches durchgeführt (so wi wir beiden es momentan halt>> machen)>> - Von Zeit zu Zeit schauen wir, dass die Version im Trunk möglichst>> stabil läuft. Dann erstellen wir vom Trunk ein Release Candidate und>> geben dieses frei für diejenigen, die bei sich die "unstable" Updates>> installieren.>> - Wenn wir der Meinung sind, die aktuelle Version im Trunk ist nun>> stabil, erstellen wir ein Update-Paket und geben dieses als "stable">> frei.>> Sagt das obige was anderes aus? Nicht das ich wüsste. Uns dürfte es klar> sein, nur ob alle den Unterschied verstehen? "stable" ist der offizielle> Teil, "unstable" die vor der Freigabe stehende und "non public" sind> halt unsere beiden Branches. Oder wie würdest du es nennen? Release> Candidates würde ich zu den "unstable"-Versionen zählen.
OK dann hast du es so gemeint wie ich. Deshalb habe ich ja geschrieben
"Ich weiss jetzt nicht genau wie du das meinst". Dein Wort
"kennzeichnen" hat mich verwirrt, ich wusste nicht ob du damit irgendwie
eine explizite Kennzeichnung der Revisionen meinst oder so. Die
eigentliche "Kennzeichnung" wird aber ja erst beim Bereitstellen von
Updates durchgeführt, nicht vorher und nicht nachher. Also haben
schlussendlich nur die Updatepakete eine solche Kennzeichnung, in den
branches und im trunk gibts sowas nicht. Aber ich glaube jetzt wir
meinen beide dasselbe, wollte nur sichergehen :-)
>>> - Eine zentrale Library bindet die>>>> das verstehe ich nicht :-)>> Na, das nicht jedes Script jede Library und Klasse selbst einbinden> muss. Derzeit läuft das ja über die lib.php bzw. config.php und erfüllt> damit die Bedingung.
Warum soll nicht jedes Skript jede benötigte Library und Klasse selber
einbinden? Das ist doch die einzig "saubere" Lösung. Nur das Includen,
was auch wirklich benötigt wird, nicht mehr und nicht weniger. Aber
natürlich alles hierarchisch, man included nur die Klasse die man auch
benötigt, die Abhängigkeiten dieser Klasse werden dann natürlich durch
diese Klasse selber eingebunden.
>>> - 1 Tabulatorschritt umfasst 5 Spaces.>>>> 5 Spaces ist aber ziemlich unüblich, oder? 4 wären doch viel>> verbreiteter würde ich meinen.>> Bei den meisten Programmen die ich verwende sind 5 voreingestellt. Ich> hab auch mit 4 keine Probleme. Hauptsache sauber getrennt :-)
Interessant, habe noch nie 5 Spaces gesehen, darum war ich so "verwirrt"
:-)
>>> - Klassen mit dem Konstruktur __construct() für die Prüfung auf>>> Abhängigkeiten der Klasse und eventuell fehlenden Funktionen versehen.>>>> Hmm das verstehe ich auch nicht :-)>> Ganz einfach. Die einzelnen Klassen haben untereinander Abhängigkeiten.> Fehlt eine Funktion, sei eine fehlende Datei im System oder eine falsche> PHP-Version, so läuft das Script nicht. Genauso ist das mit den Rechten> im Dateisystem (hatten wir ja schon mit get_svn_revision()), kann man> dort auch prüfen. Ich meine, wir sollten das schon nutzen.
Ah jetzt habe ich verstanden was du meinst. Ob es Sinn macht, diese
Sachen in den Konstruktor aufzunehmen, darüber lässt sich diskutieren.
Steht wirklich irgend eine Funktion nicht zur Verfügung, wäre die ganze
Klasse dann ja nicht mehr funktionsfähig. Wird die Überprüfung erst
durchgeführt wenn eine solche Funktion gebraucht wird (oder gar nicht
überprüft...) dann fehlt nur diese eine Funktionalität der Klasse, der
Rest davon kann weiterhin funktionieren.
>>> - Debug-Funktionen ermöglichen.>>>> Gute Idee, nur wie macht man das bei PHP am besten? Hat sich da irgend>> ein System eingebürgert? Einfach mit "print" irgendwelche Meldungen>> ausgeben funktioniert ja nicht immer (wenn z.B. eine Meldung innerhalb>> von einem html-<select> ausgegeben wird, wäre sie teilweise gar nicht>> ersichtlich).>> Man könnte in den Templates ein Debug-Block hinzufügen, der dort gewisse> Daten darstellt oder in ein "Logfile" schreibt, welches in einem eigenen> Fenster regelmäßig per Ajax geladen werden kann.
Ah ja das wäre genial! Und wie würdest du dann die Debug-Meldungen an
diese Seite übermitteln? Irgendwie mit einer globalen Variable? Mit
$_SESSION?
> Ich will euch ja auch nicht bevormunden, nur> weil ich seit Anfang/Mitte der 1980er programmiere und für meine eigenen> Projekte entsprechende Regeln versuche einzuhalten, auch wenn sie> nirgendwo stehen. Es macht aber die Arbeit erträglicher, wenn man nach> einiger Abwesenheit wieder am Code arbeiten "muss". Sind ja alles nur> Vorschläge :-)
Ja klar, solche Styleguides sind immer eine gute Sache, gerade bei
OpenSource Projekten. Sofern es nicht gerade ein völlig schräger Style
ist, bin ich dafür :-)
Urban B. schrieb:> Ach so, ja klar, beim aktuellen Stand passt das natürlich. Irgendwie> denke ich einfach immer schon an den Moment, wo unsere Branches zur> stabilen Version werden^^
Das habe ich bemerkt :-) Es ist ein Ziel, aber noch nicht mal im Ansatz
sind wir beide so weit.
> OK dann hast du es so gemeint wie ich. Deshalb habe ich ja geschrieben> "Ich weiss jetzt nicht genau wie du das meinst". Dein Wort> "kennzeichnen" hat mich verwirrt, ich wusste nicht ob du damit irgendwie> eine explizite Kennzeichnung der Revisionen meinst oder so. Die> eigentliche "Kennzeichnung" wird aber ja erst beim Bereitstellen von> Updates durchgeführt, nicht vorher und nicht nachher. Also haben> schlussendlich nur die Updatepakete eine solche Kennzeichnung, in den> branches und im trunk gibts sowas nicht. Aber ich glaube jetzt wir> meinen beide dasselbe, wollte nur sichergehen :-)
Im SVN müssen wir das nicht, nur nach aussen sollte es irgendwie klar
sein :-)
> Warum soll nicht jedes Skript jede benötigte Library und Klasse selber> einbinden? Das ist doch die einzig "saubere" Lösung. Nur das Includen,> was auch wirklich benötigt wird, nicht mehr und nicht weniger. Aber> natürlich alles hierarchisch, man included nur die Klasse die man auch> benötigt, die Abhängigkeiten dieser Klasse werden dann natürlich durch> diese Klasse selber eingebunden.
Dann wirst du über kurz oder lang das Problem bekommen, jede
Abhängigkeit in den einzelnen Scripten selbst zu verwalten. Durch den
Autoloader, den ich bereits in der lib.php drin habe, werden die Klassen
selbstständig beim ersten Aufruf geladen. So ist das Problem weg.
Ansonsten gibt es ja fast keine weiteren Dateien mehr, die eingebunden
werden müssten.
>>>> - 1 Tabulatorschritt umfasst 5 Spaces.>>>>>> 5 Spaces ist aber ziemlich unüblich, oder? 4 wären doch viel>>> verbreiteter würde ich meinen.>>>> Bei den meisten Programmen die ich verwende sind 5 voreingestellt. Ich>> hab auch mit 4 keine Probleme. Hauptsache sauber getrennt :-)>> Interessant, habe noch nie 5 Spaces gesehen, darum war ich so "verwirrt"> :-)
In meinem Editor ist nur ein Tab eingestellt. Ob ein Tab 3, 4 oder 5
Leerzeichen umfasst, ist da nur eine Darstellungssache. Ich denke, wir
sollten da 3 bis 5 Leerzeichen reinschreiben. Weniger oder mehr macht
die Sache dann zu unübersichtlich (hab auch mal was von 8 Leerzeichen
pro Einrückung gelesen).
> Ah jetzt habe ich verstanden was du meinst. Ob es Sinn macht, diese> Sachen in den Konstruktor aufzunehmen, darüber lässt sich diskutieren.> Steht wirklich irgend eine Funktion nicht zur Verfügung, wäre die ganze> Klasse dann ja nicht mehr funktionsfähig. Wird die Überprüfung erst> durchgeführt wenn eine solche Funktion gebraucht wird (oder gar nicht> überprüft...) dann fehlt nur diese eine Funktionalität der Klasse, der> Rest davon kann weiterhin funktionieren.
Es gibt aber auch Abhängigkeiten, die man an x Stellen benötigt. Eine
zentrale Überprüfung lohnt sich dann schon. Man kann sich aber streiten,
ob man das will. Ich werde es zumindest in meinen Klassen einbauen, denn
ich benötige vlibTemplate und eine Fehlerbehandlungsklasse. Ich erzeuge
nicht schon am Anfang ein Objekt dieser Klassen, sondern kurz bevor ich
es brauche. Fehlt die Klasse/Funktion schon am Anfang, brauche ich alles
weitere gar nicht auszuführen. Somit gäbe es auch keine Probleme mit
fehlerhaften Daten. Meine Meinung ist halt, dass das System nicht an
fehlenden Funktionen hängen bleiben darf, sondern nur bei echten Fehlern
im System. Nichts ist peinlicher, wenn man eine Abhängigkeit vergisst.
Oder kennst du jede PHP-Installation auf Erden? Ich nicht ;-)
> Ah ja das wäre genial! Und wie würdest du dann die Debug-Meldungen an> diese Seite übermitteln? Irgendwie mit einer globalen Variable?
Landet alles in der Datenbank. Das "Logfile" wird alle x Sekunden von
einem Javascript per XMLHttpRequest geladen und angezeigt. Im Prinzip
habe ich das schon in einem ganz einfach Chatsystem so gemacht :D
> Ja klar, solche Styleguides sind immer eine gute Sache, gerade bei> OpenSource Projekten. Sofern es nicht gerade ein völlig schräger Style> ist, bin ich dafür :-)
Keine Sorge, sowas mag ich auch nicht :-) Zudem sollen ja alle was davon
haben, nicht ein durchgeknallter Freak allein lach
Udo Neist schrieb:> Dann wirst du über kurz oder lang das Problem bekommen, jede> Abhängigkeit in den einzelnen Scripten selbst zu verwalten. Durch den> Autoloader, den ich bereits in der lib.php drin habe, werden die Klassen> selbstständig beim ersten Aufruf geladen. So ist das Problem weg.> Ansonsten gibt es ja fast keine weiteren Dateien mehr, die eingebunden> werden müssten.
Ich sehe momentan aber den Vorteil der Autoload-Funktion nicht. Sieht
man in deinem Code auch irgendwo ein Aufruf dieser Funktion? Konnte beim
Durchstöbern gerade keiner finden. Aber schlussendlich schreibst du dann
einfach ein "__autoload('error')" statt einem
"include_once('error.php')", wo ist da der Vorteil?
Also ich finde, es gehört "zum guten Ton", dass man am Anfang jeder
Datei genau diejenigen includes einfügt, die gebraucht werden. Nicht
mehr und nicht weniger, und auch nicht mitten in einer Datei drin. Halt
so wie in C/C++, das ist ein ganz simples aber sauberes System.
Udo Neist schrieb:> In meinem Editor ist nur ein Tab eingestellt. Ob ein Tab 3, 4 oder 5> Leerzeichen umfasst, ist da nur eine Darstellungssache. Ich denke, wir> sollten da 3 bis 5 Leerzeichen reinschreiben. Weniger oder mehr macht> die Sache dann zu unübersichtlich (hab auch mal was von 8 Leerzeichen> pro Einrückung gelesen).
Also wir verwenden ja Leerzeichen und nicht Tabs, dann ist es ja nicht
mehr nur eine Darstellungssache. Ja, 8 Leereichen werden glaube ich im
Linux Kernel verwendet :-) Ich würde vorschlagen wir nehmen 4 Zeichen,
das ist nicht nur optisch ansprechend sondern auch ein weit verbreiteter
"Standard" (zumindest habe ich den Eindruck, dass es weit verbreitet
ist).
Udo Neist schrieb:> Es gibt aber auch Abhängigkeiten, die man an x Stellen benötigt. Eine> zentrale Überprüfung lohnt sich dann schon. Man kann sich aber streiten,> ob man das will. Ich werde es zumindest in meinen Klassen einbauen, denn> ich benötige vlibTemplate und eine Fehlerbehandlungsklasse. Ich erzeuge> nicht schon am Anfang ein Objekt dieser Klassen, sondern kurz bevor ich> es brauche. Fehlt die Klasse/Funktion schon am Anfang, brauche ich alles> weitere gar nicht auszuführen. Somit gäbe es auch keine Probleme mit> fehlerhaften Daten. Meine Meinung ist halt, dass das System nicht an> fehlenden Funktionen hängen bleiben darf, sondern nur bei echten Fehlern> im System. Nichts ist peinlicher, wenn man eine Abhängigkeit vergisst.> Oder kennst du jede PHP-Installation auf Erden? Ich nicht ;-)
Theoretisch könnten wir das dann auch mit ein Admin-Tool erledigen. Dann
muss es nicht jedesmal beim Anlegen eines Objektes geprüft werden. Dort
bekommt man dann direkt einen Überblick, welche Funktionen nicht zur
Verfügung stehen, und was die Konsequenzen davon sind. Ist z.B. kein
Modul für Zip-Archive vorhanden, funktioniert das System trotzdem, nur
die Updatefunktion läuft dann halt nicht, und das könnte dann das
Admin-Tool dem Benutzer mitteilen.
Ich dachte auch schon an ein Admin-Tool, bei dem man die Dateirechte der
Systemdateien überprüfen kann (falsche Rechte stellen ja ein
Sicherheitsrisiko dar). z.B. bei CMS Systemen gibts ja häufig nach dem
Installieren eine Warnung wenn irgendwelche Zugriffsrechte nicht
stimmen.
Dieses Admin-Tool könnte man vielleicht auch gleich nach jedem Update
anzeigen lassen, um gleich überprüfen zu können ob alles notwendige
vorhanden ist und die Dateirechte stimen.
Udo Neist schrieb:> Landet alles in der Datenbank. Das "Logfile" wird alle x Sekunden von> einem Javascript per XMLHttpRequest geladen und angezeigt. Im Prinzip> habe ich das schon in einem ganz einfach Chatsystem so gemacht :D
Ah, ja, also eine Tabelle "debug_logs" o.ä. anlegen, in der dann alle
debug Meldungen landen? Das wäre genial!
Ach ja, als ich an meinen Klassen weiterarbeiten wollte, ist mir in den
Sinn gekommen dass ja noch das Datenbankupdate für das neue
Preis/Lieferantensystem fehlt, weisst du noch? :-)
Urban B. schrieb:> Ah, ja, also eine Tabelle "debug_logs" o.ä. anlegen, in der dann alle> debug Meldungen landen? Das wäre genial!
Das habe ich nun bei mir bereits eingebaut, da ich dieses Feature extrem
gut gebrauchen kann beim programmieren der Klassen. Ist zwar erstmal nur
mit HTML gebaut, aber das kann man auch später noch durch JavaScript
ersetzen. Funktionieren tuts mit HTML auch einwandfrei.
Ich wollte dir das nur schnell schreiben, nicht dass du auch noch sowas
baust.
Jetzt brauche ich nur noch einen dritten Bildschirm um dort die
Debug-Meldungen anzuzeigen :-)
Urban B. schrieb:> Ich sehe momentan aber den Vorteil der Autoload-Funktion nicht. Sieht> man in deinem Code auch irgendwo ein Aufruf dieser Funktion? Konnte beim> Durchstöbern gerade keiner finden. Aber schlussendlich schreibst du dann> einfach ein "__autoload('error')" statt einem> "include_once('error.php')", wo ist da der Vorteil?
Aus der lib.php:
1
function __autoload($classname) {
2
if ( $classname == '_exception' ) $classname = 'error';
3
include_once(strtolower($classname).".php");
4
}
Es wird kein Aufruf benötigt, es ist eine "magische" Funktion.
__autoload() wird durch new() automatisch aufgerufen und lädt die
entsprechende Klasse. Diese Funktion muss ich irgendwann auf
spl_autoload_register() umschreiben, denn __autoload() soll irgendwann
verschwinden.
http://php.net/manual/de/language.oop5.autoload.php> Also ich finde, es gehört "zum guten Ton", dass man am Anfang jeder> Datei genau diejenigen includes einfügt, die gebraucht werden. Nicht> mehr und nicht weniger, und auch nicht mitten in einer Datei drin. Halt> so wie in C/C++, das ist ein ganz simples aber sauberes System.
Was ist das anderes, als wenn ganz oben eine einzelne Library
eingebunden wird, in dem alle Includes stattfinden? Wenn du in jede
Datei die ganzen Includes schreibst, dann nimm include_once() bzw.
require_once(), sonst bekommst du u.U. Probleme mit doppelt
eingebundenen Dateien!
Ich hab in deinem Branch noch nicht gesehen, wieviele Includes/Requires
du machen musst. __autoload() reduziert zumindest die vielen Includes
der Klassen.
> Udo Neist schrieb:> Also wir verwenden ja Leerzeichen und nicht Tabs, dann ist es ja nicht> mehr nur eine Darstellungssache. Ja, 8 Leereichen werden glaube ich im> Linux Kernel verwendet :-) Ich würde vorschlagen wir nehmen 4 Zeichen,> das ist nicht nur optisch ansprechend sondern auch ein weit verbreiteter> "Standard" (zumindest habe ich den Eindruck, dass es weit verbreitet> ist).
Ob ich nun Tab mit 5 oder 4 Leerzeichen in der Darstellung oder vom
Editor direkt in Leerzeichen umgewandelt werden, das stört doch
niemanden. Ich bin aber nicht päpstlicher als der Papst und habs auf 4
Leerzeichen umgestellt :)
> Theoretisch könnten wir das dann auch mit ein Admin-Tool erledigen. Dann> muss es nicht jedesmal beim Anlegen eines Objektes geprüft werden. Dort> bekommt man dann direkt einen Überblick, welche Funktionen nicht zur> Verfügung stehen, und was die Konsequenzen davon sind. Ist z.B. kein> Modul für Zip-Archive vorhanden, funktioniert das System trotzdem, nur> die Updatefunktion läuft dann halt nicht, und das könnte dann das> Admin-Tool dem Benutzer mitteilen.
Du hast es nicht ganz verstanden. Jedes Update des zu Grunde liegenden
Systems kann zu einer Fehlfunktion führen. Kein Script der Welt prüft
vorher nach und blockiert fehlende Funktionen. Sowas wird in einem
try-catch-Block gemacht oder mit function_exists(), wenn diese Funktion
noch nicht offiziell existiert. Man weiß ja schliesslich nicht, welche
Version auf dem Server genau installiert ist.
PHP ist deutlich anders als C/C++, auch wenn es ähnliche Konzepte
mitbringt. Was bei C/C++ üblich ist, ist nicht unbedingt auch die
richtige Vorgehensweise bei PHP. In C/C++ ist der Sprach- und
Funktionsumfang genormt. Einige Funktionen sind nicht in PHP selbst,
sondern per PEAR eingebunden oder sind noch als experimentell
gekennzeichnet und daher fraglich. So verhält es sich derzeit mit
money_format(), welches ich benutze. Fehlt es, so bilde ich es nach. Es
ist hilfreich, auch mal bei php.net die Kommentare zu lesen ;-)
> Ich dachte auch schon an ein Admin-Tool, bei dem man die Dateirechte der> Systemdateien überprüfen kann (falsche Rechte stellen ja ein> Sicherheitsrisiko dar). z.B. bei CMS Systemen gibts ja häufig nach dem> Installieren eine Warnung wenn irgendwelche Zugriffsrechte nicht> stimmen.
Das hatte ich als repair.ups-Script in meinem Updatesystem bereits
vorgesehen :-)
Urban B. schrieb:> Das habe ich nun bei mir bereits eingebaut, da ich dieses Feature extrem> gut gebrauchen kann beim programmieren der Klassen. Ist zwar erstmal nur> mit HTML gebaut, aber das kann man auch später noch durch JavaScript> ersetzen. Funktionieren tuts mit HTML auch einwandfrei.
Das du das "Logfile" bereits umgesetzt hast, das ist löblich :-) Erspart
mir zumindest eine weitere Baustelle. Wenn du es hochgeladen hast, kann
ich das ja auch bei mir schon einbauen. Das xhr-Teil schreibe ich dann.
Hallo an alle Mitentwickler!
1. Es wäre mal an der Zeit einen neuen Thread aufzumachen. Zwecks
besserer Ladezeiten und vielleicht auch einem aussagekräftigeren
Threadtitel?
2. Das mit den 4 Leerzeichen scheint ja nun Konsens zu sein und findet
meine vollste Zustimmung. Gibt es schon einen guten Platz/Link für die
Coding Guidelines?
3. Debuglog bzw. SQL-Transaction-Log finde ich eine tolle Sache, hatte
ich auch schonmal im Hinterkopf.
4. (@kami) die leeren Tabellen bei den Preisen waren wirklich für
Preisstaffeln und mehrere Lieferanten gedacht. Kann also gerne noch
richtig umgesetzt werden.
5. Momentan haben wir - so wie ich das sehe - zwei Entwicklungen:
Templates und OOP. Jedes neue Feature macht daher doppelt Arbeit
(entweder für den Einpfleger, oder für den Entwickler). Wir sollten uns
vielleicht erstmal auf eine Sache konzentrieren.
6. SVN-Nutzung:
Die zwei Entwicklungsrichtungen spiegeln sich ja in den beiden
User-Branches wieder.
Ich würde mal folgenden Vorschlag machen:
Im TRUNK liegt die Stable-Version, auf der nur kleine Bug-fixes gemacht
werden. Neue Sachen werden in einem testing-Branch ausprobiert.
Ungefähr alle drei Monate wird unstable zu stable gemacht und ein
hübsches Download-Paket geschnürt.
7. Bei größeren Versionssprüngen, wenn z.B. Version 0.3 mit templates &
oop fertig ist, wird die Datenbankversion auf 100 gesetzt und alle
Datenbankupdates aus dem Code entfernt bzw. in ein manuelles Skript
verschoben.
So. Das wars erstmal.
Grüße
b.r
b.r schrieb:> Es wäre mal an der Zeit einen neuen Thread aufzumachen.Und Udo Neist schrieb:> Antwort siehe neuen Thread Beitrag "Lagerverwaltung Part-DB V0.2.2"
Wenn das Konsens ist, schlage ich vor, diesen Thread von einem Admin
schließen zu lassen, sonst wird's noch unübersichtlicher. Nach dem
Thread Beitrag "Teile-Verwaltung für elektronische Bauteile" zur
"Part-db Lagerverwaltung" ist das nämlich mindestens schon der
dritte Thread.
Soll im Artikel Part-DB RW - Lagerverwaltung unter "Wünsche /
Verbesserungsvorschläge / Bugreports" der Link auf den neuen Thread Nr.
269289 angepaßt werden?
Hallo,
ich bin nach der Suche nach einer Installations Anleitung für PART-DB
2.2.
Ich selber habe danach gesucht leider aber für mich, als Anfänger
ernüchternde Anleitungen gefunden und nicht weitergekommen.
Gib es ausführliche Anleitung ? wenn nicht besteht vielleicht eine
Möglichkeit eine ausführliche Anleitung für PART-DB 2.2 zu erstellen
(Schritt bei Schritt) bin wahrscheinlich nicht der erste der danach
sucht!
Grüße
Mamim
Thread beobachten
Seitenaufteilung abschalten