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.
Gast
#2808148
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? :-)
Hi, ich hab die Dateien nochmal angehängt. Die Datei einfach in den tools Ordner entpacken.
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.
Welchen Browser benutzt du? Ich habs bisher nur mit Firefox 14 getestet.
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?
Bei mir läuft die neue Version unter FF 14.0.1 (openSUSE 12.1) mit der Revision 517. Ich werde sie daher in meine übernehmen :)
Gast
#2811296
Hi, so die DemoDB wird jetzt wieder einmal am tag upgedated um 11:00. mfg
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...
Gast
#2811749
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.
Nimm statt Samba NFS für die Freigabe.
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 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
50 | |
51 | |
52 | |
53 | |
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 | |
2 | |
3 | |
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.
Gast
#2813490
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
Gast
#2813502
b.r schrieb: > 1. Es wäre mal an der Zeit einen neuen Thread aufzumachen. Zwecks > besserer Ladezeiten und vielleicht auch einem aussagekräftigeren > Threadtitel? Da mach ich mal die Ingrid. Hier geht's (hoffentlich) weiter: Beitrag "Lagerverwaltung Part-DB V0.2.2" Also nochmal, für alle die es erst beim zweiten Mal gelesen haben: Neue Beiträge zum Thema bitte hier abliefern: Beitrag "Lagerverwaltung Part-DB V0.2.2" Grüße b.r P.S.: Habt Ihr schonmal hier reingeschaut?!? Beitrag "Lagerverwaltung Part-DB V0.2.2"
Antwort siehe neuen Thread Beitrag "Lagerverwaltung Part-DB V0.2.2"
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?
Gast
#2883807
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
Wo findet man denn das aktuelle Installationspaket?
Uhu Uhuhu schrieb: > Wo findet man denn das aktuelle Installationspaket? Bitte nicht mehr diesen Thread hier benutzen. Die Antwort habe ich hier gepostet: Beitrag "Re: Lagerverwaltung Part-DB V0.2.2"
Dann sollte man diesen Thread vielleicht mit einem Vorhängeschloß versehen.
Getan.