b.r schrieb:> 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?
Stimme ich zu :-)
> 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?
Ich habe die Coding Guidelines schon angepasst. Wenn gewünscht, stelle
ich sie bei Google Code ins Wiki.
> 3. Debuglog bzw. SQL-Transaction-Log finde ich eine tolle Sache, hatte> ich auch schonmal im Hinterkopf.
Hatte ich auch schon auf meiner Liste. Wie gut, das ich das streichen
kann.
> 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.
Sobald ich die Templates fertig habe, werden wir beide Zweige
zusammenbauen. Es wäre ein durcheinander, wenn wir das recht früh
gemacht hätten.
> 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.
Das beide Branches wieder zusammen kommen müssen, das ist uns klar. Ich
denke, sobald ich die Templates fertig habe, kann ich die OOP-Sachen von
Urban einbinden. Ich beführchte allerdings, da wird es noch einiges an
Diskussionsbedarf geben. Im Moment sehe ich eine 1:1-Übersetzung der
lib.php in Klassen. Es wäre in meinem Augen sinnvoller, einige Klassen
nur mit Basis-Funktionen zu versehen, die dann von anderen Funktionen
aufgerufen wird. Die Anzahl der Dateien steigt zwar damit, aber die
Übersichtlichkeit ist besser.
> 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.
Ist schon geplant. Das Update-System wird komplett erneuert. Nur welche
Variante, das ist noch nicht klar. Ich habe ein Interpreter für
Update-Scripts geschrieben, der auch für Installationen und Reparatueren
taugt. Urban geht einen anderen Ansatz und will für jedes Update ein
neues PHP-Script schreiben.
b.r schrieb:> P.S.:> Habt Ihr schonmal hier reingeschaut?!?> Beitrag "Lagerverwaltung Part-DB V0.2.2"
Wow, nett hier! Irgendwie so leer, der Thread :-)
b.r schrieb:> 3. Debuglog bzw. SQL-Transaction-Log finde ich eine tolle Sache, hatte> ich auch schonmal im Hinterkopf.
Ja, ich denke es wird schlussendlich verschiedene Logs geben. Sicher ein
Debug Log, und dann vermutlich (irgendwann mal) ein Log um Buchungen
usw. nachvollziehen zu können. Halt alles was die Benutzer so in der
Datenbank rumfummeln (am besten gleich mit einer Möglichkeit, Buchungen
rückgängig zu machen).
b.r schrieb:> 4. (@kami) die leeren Tabellen bei den Preisen waren wirklich für> Preisstaffeln und mehrere Lieferanten gedacht. Kann also gerne noch> richtig umgesetzt werden.
Gut, danke für die Info. Habe mich schon gewundert dass die existieren,
aber leer sind.
b.r schrieb:> 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.
Naja Klassen und Templates sind ansich ja zwei komplett verschiedene
(unabhängige) Dinge, da kann man relativ gut parallel arbeiten. Das
Zusammenführen nachher gibt dann natürlich etwas Arbeit, das ist klar.
Aber die kann ich gerne übernehmen (ich bin ja der Einzige, der weiss
wie man die Klassen "anspricht" und richtig einsetzt).
Aber bis zum Zusammenführen werden meine Klassen nur mal so grob
funktionieren. Um alles richtig austesten zu können brauche ich auch
Seiten, die die Klassen richtig verwenden (z.B. in der editpartinfo.php
usw.). Damit wir die nicht doppelt machen müssen (einmal ich zum testen
und einmal Udo für die Templates) warte ich auf die Templates und fange
erst danach richtig an die Klassen zu testen.
b.r schrieb:> 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.
Momentan macht das Sinn, ja. Aber sobald die Benutzer kein SVN mehr
brauchen, um ihre Installationen aktuell zu halten, können wir die
Entwicklung auch direkt im Trunk machen. Ausser halt grad ganz grosse
Veränderungen oder irgendwelche Tests.
Udo Neist schrieb:> 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
Aaah, ich glaube jetzt habe ich es kapiert :-) OK dann ist es natürlich
eine nützliche Sache. Heisst aber, dass ich die Dateinamen der Klassen
noch umschreiben muss, oder? Die Dateinamen müssen dann wohl den
gleichen Namen haben wie die darin enthaltene Klasse.
Udo Neist schrieb:> 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.
Also ob wir Tabs oder Leerzeichen verwenden, das macht durchaus einen
Unterschied und darauf wollte ich eigentlich hinaus. Einige
Programmierer verwenden ja Tabs, dann ist die Darstellung vom Editor
abhängig, und andere verwenden Leerzeichen, dann ist die Darstellung
fest vorgegeben.
Udo Neist schrieb:> 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.
Ja da hast du recht. Die Frage ist nur, wo man solche Sachen prüfen
soll. Bei "nicht-lebenswichtigen" Funktionen wäre es eher besser wenn
die Überprüfung erst dann geschieht, wenn sie auch gebraucht wird, damit
wenigstens der Rest des Systems lauffähig ist. Nur bei sehr wichtigen
Funktionen, ohne die Part-DB nicht wirklich nutzbar ist, sollte man die
Überprüfung schon möglichst "am Anfang" machen (z.B. im Konstruktor wie
von dir vorgeschlagen).
Udo Neist schrieb:> 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.
Ich aktualisiere nachher gleich mal meinen Branch, dann kannst du es dir
anschauen. In "db_update_steps.php" siehst du wie die Tabelle aussieht
(case-Nr. 20). Falls du noch Vorschläge hast, was man zusätzlich noch
für Spalten gebrauchen könnte, gib Bescheid. Dann habe ich noch die
beiden Klassen "debug_log.php" und "debug_log_element.php" erstellt. In
"debug.php" siehst du wie die Klasse eingesetzt wird, und wie die
Ausgabe des Logs aussieht.
Vieles ist aber noch sehr provisorisch. Fehlerbehandlungen gibts bisher
noch praktisch keine in eigentlich all meinen Klassen. Das rüste ich
dann erst später nach (mit exceptions).
Udo Neist schrieb:> Im Moment sehe ich eine 1:1-Übersetzung der> lib.php in Klassen. Es wäre in meinem Augen sinnvoller, einige Klassen> nur mit Basis-Funktionen zu versehen, die dann von anderen Funktionen> aufgerufen wird. Die Anzahl der Dateien steigt zwar damit, aber die> Übersichtlichkeit ist besser.
Eine 1:1 Übersetzung ist es natürlich nicht, sonst würde OOP nicht viel
Sinn machen. Funktionen, die direkt Antworten auf SQL-Querys
durchführen, gibt es nicht mehr. SQL Querys werden allgemein viel
weniger verwendet, das meiste wird direkt durch "ein geschicktes
OOP-Design" erledigt. Nur noch "auf unterster Ebene" werden noch SQL
Querys eingesetzt.
Udo Neist schrieb:> http://code.google.com/p/part-db/wiki/Coding_Guidelines
Sehr schön!
Mein Branch ist nun aktuell, da kannst du mal das Debug-Zeugs anschauen.
Den Debug-Log verwenden wir aber schon nur für Fehlermeldungen oder?
Also nicht für irgendwelche "Bestätigungs-Meldungen" wie z.B.
"__construct(): Objekt erfolgreich angelegt" usw.
Ansonsten könnte man auch noch ein Logging-Level einbauen, dann kann man
auch solche unwichtigen Bestätigungen mitloggen, aber mit tiefer
Priorität. Beim Betrachten der Logs kann man dann wählen welche Logs
überhaupt ausgegeben werden, damit man solche unwichtigen Meldungen
unterdrücken kann.
Ich denke das würde Sinn machen. Vielleicht ein Level von 0 bis 5
definieren oder so? 0 = "total unwichtig", 5 = "ultraschlimmer fehler,
fast wäre der server abgeraucht"
Oder aber mit Strings, so wie ich es jetzt gemacht habe. Also z.B.
"warning", "error", "info". Und dann beim Viewer für jedes Attribut eine
Checkbox die man einzeln an-/abwählen kann.
Was meint ihr?
Urban B. schrieb:> Naja Klassen und Templates sind ansich ja zwei komplett verschiedene> (unabhängige) Dinge, da kann man relativ gut parallel arbeiten. Das> Zusammenführen nachher gibt dann natürlich etwas Arbeit, das ist klar.> Aber die kann ich gerne übernehmen (ich bin ja der Einzige, der weiss> wie man die Klassen "anspricht" und richtig einsetzt).> Aber bis zum Zusammenführen werden meine Klassen nur mal so grob> funktionieren. Um alles richtig austesten zu können brauche ich auch> Seiten, die die Klassen richtig verwenden (z.B. in der editpartinfo.php> usw.). Damit wir die nicht doppelt machen müssen (einmal ich zum testen> und einmal Udo für die Templates) warte ich auf die Templates und fange> erst danach richtig an die Klassen zu testen.
Du musst nicht alles übernehmen. Wir können uns auch die Arbeit teilen.
Dazu sollten wir aber erstmal mit unseren Arbeiten fertig werden und
dann anschauen, was der andere gemacht hat. Vielleicht gibt es ja auch
noch ein paar Änderungen, die dann in die neue Version einfliessen
werden.
> Udo Neist schrieb:>> http://php.net/manual/de/language.oop5.autoload.php>> Aaah, ich glaube jetzt habe ich es kapiert :-) OK dann ist es natürlich> eine nützliche Sache. Heisst aber, dass ich die Dateinamen der Klassen> noch umschreiben muss, oder? Die Dateinamen müssen dann wohl den> gleichen Namen haben wie die darin enthaltene Klasse.
Normalerweise ja, wäre sinnvoll. Du siehst aber auch, das ich ein
Klassenname umschreibe, da sie absichtlich nicht mit dem Dateinamen
übereinstimmt.
> Udo Neist schrieb:>> 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.>> Also ob wir Tabs oder Leerzeichen verwenden, das macht durchaus einen> Unterschied und darauf wollte ich eigentlich hinaus. Einige> Programmierer verwenden ja Tabs, dann ist die Darstellung vom Editor> abhängig, und andere verwenden Leerzeichen, dann ist die Darstellung> fest vorgegeben.
Bei mir werden Tabs mit einem kleinen Punkt gekennzeichnet, was die
einzelnen Ebenen der Einrückung schneller erkenntlich macht. Ich muss
mich nur etwas umgewöhnen.
Im übrigen gibt es unter Linux den Befehl expand, der Tabs nach
Leerzeichen wandeln kann. Ich kann somit weiter Tabs verwenden und
brauch halt nur einen zusätzlichen Schritt vor dem Commit :-)
tab2spaces.sh (aufzurufen im Arbeitsverzeichnis)
1
#! /bin/bash
2
FILES=`find .-type f -name"*php"-o-name"*tmpl"`
3
4
for FILE in$FILES
5
do
6
echo"bearbeite $FILE..."
7
mv"$FILE""$FILE".bak
8
expand-t4"$FILE".bak >"$FILE"
9
rm-f"$FILE".bak
10
done
> Ja da hast du recht. Die Frage ist nur, wo man solche Sachen prüfen> soll. Bei "nicht-lebenswichtigen" Funktionen wäre es eher besser wenn> die Überprüfung erst dann geschieht, wenn sie auch gebraucht wird, damit> wenigstens der Rest des Systems lauffähig ist. Nur bei sehr wichtigen> Funktionen, ohne die Part-DB nicht wirklich nutzbar ist, sollte man die> Überprüfung schon möglichst "am Anfang" machen (z.B. im Konstruktor wie> von dir vorgeschlagen).
Genau :-) Im ersten Falle kann man ein "Würgaround" einbauen, im anderen
Fall wäre es existenziell und damit ein Abbruch wert.
> Udo Neist schrieb:>> 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.>> Ich aktualisiere nachher gleich mal meinen Branch, dann kannst du es dir> anschauen. In "db_update_steps.php" siehst du wie die Tabelle aussieht> (case-Nr. 20). Falls du noch Vorschläge hast, was man zusätzlich noch> für Spalten gebrauchen könnte, gib Bescheid. Dann habe ich noch die> beiden Klassen "debug_log.php" und "debug_log_element.php" erstellt. In> "debug.php" siehst du wie die Klasse eingesetzt wird, und wie die> Ausgabe des Logs aussieht.
Mach ich. Dann kann ich das auch gleich schon einbauen. Das Update wäre
auch was für mein Update-System zum Testen ;-)
> Vieles ist aber noch sehr provisorisch. Fehlerbehandlungen gibts bisher> noch praktisch keine in eigentlich all meinen Klassen. Das rüste ich> dann erst später nach (mit exceptions).
Du kannst es in meiner class/html.php sehen, wie ich eine
Fehlerbehandlung durchführe.
> Eine 1:1 Übersetzung ist es natürlich nicht, sonst würde OOP nicht viel> Sinn machen. Funktionen, die direkt Antworten auf SQL-Querys> durchführen, gibt es nicht mehr. SQL Querys werden allgemein viel> weniger verwendet, das meiste wird direkt durch "ein geschicktes> OOP-Design" erledigt. Nur noch "auf unterster Ebene" werden noch SQL> Querys eingesetzt.
Ich hab nicht alle Klassen durchgeschaut. Du hast einige Funktionen in
der Datenbankklasse drin, die ich persönlich da nicht reingebaut hätte.
Alles rund um die Updates gehören in eine andere Klasse, die nur für die
Updates zuständig ist. Ansonsten sehen die Klassen schon richtig gut aus
:-) Nur noch die Templates dazu, ein bisschen aufräumen und unsere 0.3
wäre fertig.
Udo Neist schrieb:> Ich hab nicht alle Klassen durchgeschaut. Du hast einige Funktionen in> der Datenbankklasse drin, die ich persönlich da nicht reingebaut hätte.> Alles rund um die Updates gehören in eine andere Klasse, die nur für die> Updates zuständig ist.
Das Updatesystem, das bisher in meinem Branch lag, war ja auch noch nach
dem alten Prinzip. Heisst, es wird nur die Datenbank aktualisiert,
deshalb ist die Updatefunktion auch in der Datenbankklasse.
Jetzt sind schon erste Funktionen vorhanden für das neue Updatesystem,
da habe ich einfach mal ein bisschen rumprobiert. Diese Funktionen sind
dann in der Klasse "System", weil sie das System updaten :-) Eine eigene
Update Klasse finde ich irgendwie komisch. Ein Update ist kein "Ding",
also kein Objekt. Ein Update aktualisiert das System und müsste von der
Logik her eine Methode der System-Klasse sein.
Ist aber ein stückweit auch Ansichts-/Geschmackssache ;-)
> Ansonsten sehen die Klassen schon richtig gut aus> :-) Nur noch die Templates dazu, ein bisschen aufräumen und unsere 0.3> wäre fertig.
xD das hört sich ja ganz einfach an :-)
Urban B. schrieb:> Jetzt sind schon erste Funktionen vorhanden für das neue Updatesystem,> da habe ich einfach mal ein bisschen rumprobiert. Diese Funktionen sind> dann in der Klasse "System", weil sie das System updaten :-) Eine eigene> Update Klasse finde ich irgendwie komisch. Ein Update ist kein "Ding",> also kein Objekt. Ein Update aktualisiert das System und müsste von der> Logik her eine Methode der System-Klasse sein.>> Ist aber ein stückweit auch Ansichts-/Geschmackssache ;-)
Ich betrachte das ganze System als Objekt, das ich dann in Teilen
update. Das man das an eine System-Klasse koppelt, kann ich mir auch
vorstellen. Ist halt nur die Frage, in welcher Form das Update dann
läuft. Ob klassisch mit einem eigenen Script für das System oder halt
kurze Anweisungen, die interpretiert werden. Beim Letzteren wäre der
Interpreter ja ein Objekt des Systemsobjekts. Also sowas wie:
1
if ($befehl=='copy') $system->interpreter->copy()
2
if ($befehl=='rename') $system->interpreter->rename()
@Udo
Ich wäre jetzt an der Stelle, wo ich das Lieferantensystem umbauen will
(damit man einem Bauteil mehrere Lieferanten zuordnen kann). Nur fehlt
da noch das entsprechende Datenbankupdate...
Darf ich dich nochmal auf diesen
Beitrag "Re: PART-DB RW 1.2" aufmerksam machen?
:-)
Hättest du grad Zeit dich mal daran zu versuchen?
mfg
Hallo!
Die Part-DB RW - Lagerverwaltung ist ziemlich genau das, was ich mir
für meine Teileverwaltung vorstelle.
Aber macht es denn Sinn, dass jeder einzelne Nutzer einen Webserver mit
PHP und Mysql Datenbank betreiben muß?
Ich habe daher einen Verbesserungsvorschlag, den ich in der TODO-Liste
nicht gefunden habe.
http://code.google.com/p/part-db/issues/list
Vergleichbar mit Wordpress könnte man auch eine gemeinsame Instanz
benutzen. Man kann sich Wordpress entweder selbst installieren oder
unter der gemeinsam genutzten Instanz Wordpress.com einfach ein neues
Blog oder einen neuen Nutzer hinzufügen.
Ich würde daher auch die Part-db Lagerverwaltung am liebsten irgendwo
installieren, wo sich jeder mit seinem Login anmelden und seine Teile
verwalten kann. Die "Stammdaten" müßte dann nicht jeder einzeln pflegen.
Das Thema wurde schon mal angesprochen (s.u.).
Im Moment sehe ich das so, dass ich die aktuelle Version dazu um
Benutzerkonten erweitern müßte.
Wären denn noch mehr Interessenten an so einer gemeinsamen Pflege der
"Stammdaten" interessiert? Ich fände es schade, wenn dadurch ein
"SW-Branch" entsteht.
Der Gedanke wurde schon mal angesprochen:
Bauteilegucker schrieb:> Eine Endlosarbeit ist es …, wenn jeder immer wieder neu die> Daten eingeben muss, die doch bei einem bestimmten Bauteil für ALLE, die> es in ihre Datenbank eintragen, immer und immer wieder dieselben sind.> Sich diese Arbeit zu teilen, wäre für alle eine RIESIGE> Arbeitsersparnis.Olof Gutowski schrieb:> Und irgendwie wäre es schön, wenn man Datensätze mit anderen Usern> tauschen könnte, …Georg schrieb:> Ein Aussteller hatte diese Software weitentwickelt. …> Diese version hatte auch eine Benutzerverwaltung und ein> Projektmanagment, man konnte Bauprojekte verwalten und die Teile aus der> Datenbank wurden einbezogen.
Eine wichtige Anmerkung dazu war:
Mehmet Kendi schrieb:> Für mich macht es wenig Sinn, wenn ich> z.Bsp. auf all die tausend Bauteile von Farnell Zugriff haette. Wüsste> echt nicht, was ich damit anfangen sollte.
Ich denke, es müßte in der Datenbank eine Tabelle geben, die die vom
einzelnen Nutzer verwendeten Bauteile kennzeichnet. Wenn man ein neues
Bauteil anlegen möchte, würde man zunächst in den gemeinsam genutzten
Stammdaten aller Nutzer suchen und das Bauteil quasi für sich
"aktivieren". Nur wenn man es dort nicht findet, legt man es wirklich
neu an und es ist dann auch für andere in den gemeinsamen Stammdaten zu
finden.
Um seine Daten jederzeit auf eine eigene Instanz kopieren zu können,
wäre dazu noch eine Export-Funktion für die eigenen Daten
(Lagerbestände) und die genutzten Stammdaten nötig (XML, CSV oder SQL).
Noch eine Idee (Priorität niedrig):
Armin Baumgardt schrieb:> und 1000 Stk in der Überbestandskiste
Hierbei ging es um verschiedene Lagerorte
(http://code.google.com/p/part-db/issues/detail?id=29).
Daraus könnte bei einer gemeinsam genutzten Instanz sogar eine neue
Funktion entstehen: Wenn man Teile benötigt, kann man schauen, ob ein
anderer davon noch welche loswerden will, und es müssen keine neuen
Teile gekauft werden. Davon hätten alle was.
Bauteilegucker schrieb:> Sogar die jeweiligen> Eagle/KICAD/...-libs könnte man gleich mit integrieren, …
Den Sinn/Vorteil habe ich noch nicht ganz verstanden.
Hallo Torsten!
Torsten C. schrieb:> Aber macht es denn Sinn, dass jeder einzelne Nutzer einen Webserver mit> PHP und Mysql Datenbank betreiben muß?
Nein. Aber auch daran wir gearbeitet: Eine Multiuser-Version auf einem
zentralen Webspace.
Aber noch sind wir nicht soweit.
Torsten C. schrieb:>> Sogar die jeweiligen>> Eagle/KICAD/...-libs könnte man gleich mit integrieren, …> Den Sinn/Vorteil habe ich noch nicht ganz verstanden.
Damit würde die aufwändige, unkomfortable Suche nach dem passenden
Bauteil in der entsprechenden PCB-Software entfallen.
Grüße
b.r
Torsten C. schrieb:> Ich habe daher einen Verbesserungsvorschlag, den ich in der TODO-Liste> nicht gefunden habe.b.r schrieb:> … daran wir gearbeitet: Eine Multiuser-Version auf einem> zentralen Webspace
Wird die Liste denn noch gepflegt, oder gibt es noch mehr Listen?
b.r schrieb:> Damit würde die aufwändige, unkomfortable Suche nach dem passenden> Bauteil in der entsprechenden PCB-Software entfallen.
Und wie genau geht das dann weiter, z.B. in Eagle? Im Lib-Browser muß
ich das Bauteil doch eh suchen, oder kann man das Bauteil per Drag&Drop
aus der Part-DB in den Schaltplan schieben?
Torsten C. schrieb:> Wird die Liste denn noch gepflegt,
Ja.
> oder gibt es noch mehr Listen?
Nein.
> b.r schrieb:>> Damit würde die aufwändige, unkomfortable Suche nach dem passenden>> Bauteil in der entsprechenden PCB-Software entfallen.> Und wie genau geht das dann weiter, z.B. in Eagle? Im Lib-Browser muß> ich das Bauteil doch eh suchen, oder kann man das Bauteil per Drag&Drop> aus der Part-DB in den Schaltplan schieben?
Ich könnte mir vorstellen, das man die benötigten Teile als Lib aus
part-db exportiert und dann alles an einem Platz hat.
Grüße
b.r
Torsten C. schrieb:> Nach dem> Thread Beitrag "Teile-Verwaltung für elektronische Bauteile" zur> "Part-db Lagerverwaltung" ist das nämlich mindestens schon der> dritte Thread.
Das Thema "Teile-Verwaltung für elektronische Bauteile" kannte ich gar
nicht. Ursprünglich ging es dort ja auch gar nicht um Part-DB, sondern
um ein anderes Programm. Die Entwickler von Part-DB findet man hier,
oder im letzten Thread (das wegen seiner Länge nun durch diesen hier
abgelöst wurde).
Torsten C. schrieb:> Soll im Artikel Part-DB RW - Lagerverwaltung unter "Wünsche /> Verbesserungsvorschläge / Bugreports" der Link auf den neuen Thread Nr.> 269289 angepaßt werden?
Habe ich gleich erledigt, danke für den Hinweis.
Torsten C. schrieb:> Ich habe daher einen Verbesserungsvorschlag, den ich in der TODO-Liste> nicht gefunden habe.
Ein Issue zur Benutzerverwaltung gibt es ja schon, und jetzt habe ich
ihn noch ein bisschen ergänzt bezüglich dem von dir angesprochenen
Thema: https://code.google.com/p/part-db/issues/detail?id=8Torsten C. schrieb:> Im Moment sehe ich das so, dass ich die aktuelle Version dazu um> Benutzerkonten erweitern müßte.
Wie im Issue zu lesen ist, wird daran gearbeitet. Wir stellen momentan
auch gleich auf objektorientierte Programmierung und Templates um, das
gibt eine Menge Arbeit und wird auch dementsprechend etwas dauern bis
wir soweit sind.
Torsten C. schrieb:> b.r schrieb:>> Damit würde die aufwändige, unkomfortable Suche nach dem passenden>> Bauteil in der entsprechenden PCB-Software entfallen.>> Und wie genau geht das dann weiter, z.B. in Eagle? Im Lib-Browser muß> ich das Bauteil doch eh suchen, oder kann man das Bauteil per Drag&Drop> aus der Part-DB in den Schaltplan schieben?
Es beantwortet zwar nicht direkt deine Frage, aber:
Der Upload von Dateien wird in Zukunft sehr universell gestaltet. Heisst
also, der Benutzer kann hochladen was auch immer er will. Von mir aus
soll er auch Werbefilme von Bauteilen hochladen wenn er es für sinnvoll
hält :-) Dann kann also jeder Benutzer selber entscheiden was er für
Sinnvoll hält und was nicht.
@Udo
Du hast ja noch was bezüglich der Währung geschrieben. Eigentlich wäre
es schlussendlich ja am besten, wenn man bei jedem Bauteil bzw. bei
jedem Preis eines Bauteiles die Währung separat angeben kann. Dann kann
man Teile, die man im Ausland (wo eine andere Währung gilt) kauft, in
der tatsächlichen Währung erfassen, und muss es nicht selber umrechnen.
Irgendwie könnte man dann bestimmt auch noch die aktuellen Wechselkurse
aus dem Internet holen um Preise in fremden Währungen zusätzlich auch
noch in der eigenen Währung anzeigen zu lassen (oder man gibt die
Wechselkurse alternativ auch manuell ein).
Wir könnten dann eine currencymgr.php erstellen, wo man all seine
verwendeten Währungen inkl. Wechselkurs (bzw. URL wo man den Wechselkurs
bekommt) verwalten kann. Dort kann man dann auch gleich die
Standardwährung wählen, die halt vorzugsweise verwendet werden soll.
Ich als Schweizer habe schon ein paarmal in DE eingekauft und würde
diese Funktion natürlich sehr begrüssen :-) Dann sehe ich auch wie die
Teile aus DE immer günstiger werden mit der Zeit (der Eurokrise sei
dank)^^
Wenn da niemand was dagegen einzuwenden hat, schreibe ich das noch in
unsere Issues.
Bezüglich des Debug-Logs bin ich mir mittlerweile nicht mehr sicher ob
es wirklich vorteilhaft ist wenn die Meldungen in der Datenbank abgelegt
werden. Bei Problemen mit der Datenbank gibts dann nämlich auch kein
Debugging mehr, was relativ unpassend ist :-)
Ausserdem müsste man aktiv Endlosschleifen bekämpfen wenn es
Datenbankprobleme gibt. Meldet eine Funktion (die etwas mit der
Datenbank machen will) ein Fehler, kommt die Log-Funktion, die natürlich
ebenfalls auf die Datenbank zugreifen will, dieser Zugriff führt dann
aber wieder zu einer neuen Fehlermeldung, die geloggt werden will, und
so dreht sich das System dann im Kreis :-)
Der ganze Debug-Kram sollte daher eigentlich möglichst unabhängig vom
ganzen Rest des Systems funktionieren. Um die Logs zu speichern wäre die
einzige Möglichkeit dann wohl nur noch mit Dateien. Vielleicht könnte
man dazu eine XML-Datei verwenden, damit man trotzdem noch einigermassen
vernünftig mit Attributen usw. arbeiten kann.
Klar, wenn die Schreibrechte fehlen funktioniert auch dieses System
nicht. Allerdings kann man die Schreibrechte prüfen, und bei der Ausgabe
der Logs dann eine Meldung bringen "Sie haben keine Schreibrechte, es
können keine Meldungen geloggt werden", dann weiss man direkt wo das
Problem liegt.
Ich habe jetzt mal eine dateibasierte Version des Debug-Systems in
meinen Branch hochgeladen. Die Klasse heisst "debug_log.php" und die
Debug-Seite ist "debug.php".
Das Ganze funktioniert so:
Existiert eine Datei "log/debug_log.xml", heisst das, dass das Logging
aktiv ist, und neue Meldungen landen in dieser Datei. Existiert keine
solche Datei, gilt das Logging automatisch als deaktiviert.
Damit später (wenn es die Benutzerverwaltung gibt) die einfachen
Benutzer keinen Zugriff aufs Debug-System haben, habe ich einen
Passwortschutz eingebaut. In der Datei "log/debug_log_password.txt"
speichert man einfach den MD5-Hash des gewünschten Passwortes ab. Ich
habe es bewusst so "steinzeitmässig" gemacht, damit die Debugklasse
keinen Zugriff auf die Datenbank braucht (um Admin-Berechtigungen zu
prüfen), aber trotzdem gewissermassen geschützt ist. Ist das Logging
aktiv, können zwar die Benutzer theoretisch ebenfalls die Meldungen
anschauen und das Logging deaktivieren. Es liegt dann halt beim
Administrator, dass er das Debugging auch wieder deaktiviert (und damit
automatisch auch alle Logs löscht, weil die Datei dann weg ist).
Aktivieren kann man das Logging nur mit dem oben genannten Passwort.
Tauchen in der Debugklasse selber Fehler auf, werden diese ebenfalls
erfasst und können per Klassenmethode get_class_errors() geholt werden.
Funktionieren tuts soweit schonmal ziemlich gut. Aber wie immer bei mir
gilt: Es ist erstmal nur ein Test, es kann sich noch einiges ändern :-)
So, nach langem Rumprobieren scheint jetzt das Datenbankupdate für das
neue Lieferantensystem zu funktionieren (Tabelle "orderdetails"). Ich
hoffe das passt so. Ausserdem werden die Tabellen "datasheets" und
"pictures" zu einer einzigen Tabelle "files" zusammengefasst.
https://code.google.com/p/part-db/source/browse/branches/kami89/db_update_steps.php?spec=svn524&r=524
Der Benutzerverwaltungs-Kram ist bisher nur provisorisch und wird noch
nicht verwendet.
Bei folgenden Sachen war ich mir nicht ganz sicher, ob man die löschen
darf:
- Spalte "manual_input" in "preise": Wird gar nicht verwendet, oder?
- Spalte "visible" in "parts": Ist nachher ja Sache der
Benutzerverwaltung
- Tabelle "pending_orders": Wurde noch nie gebraucht?!
@K.J. oder b.r: Weiss einer von euch Bescheid über diese Dinge?
mfg
Urban B. schrieb:> So, nach langem Rumprobieren scheint jetzt das Datenbankupdate für das> neue Lieferantensystem zu funktionieren (Tabelle "orderdetails"). Ich> hoffe das passt so. Ausserdem werden die Tabellen "datasheets" und> "pictures" zu einer einzigen Tabelle "files" zusammengefasst.
Gibt es eigentlich ein paar Features, die man schon in den 'trunk'
portieren könnte, oder ist alles Klassenabhängig?
> - Spalte "manual_input" in "preise": Wird gar nicht verwendet, oder?
Jain.
Gesetzt wird es an zwei verschiedenen Stellen: In
'readme/partdb-autoprice.py' wird es bei Neueinträgen/Updates auf '0'
gesetzt. price_add in der lib.php setzt es auf '1'.
Aber verwendet wird es bisher noch nicht. Vielleicht ist es aber nicht
ganz verkehrt, zum Preis die folgenden Informationen zu speichern: Datum
der letzten Aktualisierung und Herkunft der Preisinformation (Webseite,
Angebot o.ä.)
> - Spalte "visible" in "parts": Ist nachher ja Sache der> Benutzerverwaltung
Ich hatte die Spalte eingeführt, um die Bauteilansicht in
'open/openlist.php' einschränken zu können. Wenn die Benutzerverwaltung
eingeschränkenten Gastzugriff erlaubt, kann das gerne dort mit
einfließen.
Es sollen z.B. in einer Firma nur die 'offiziellen' Bauteile für alle
sichtbar sein.
> - Tabelle "pending_orders": Wurde noch nie gebraucht?!
Doch: Verwaltung/Tools -> Zeige -> Zu bestellende Teile
Grüße
b.r
b.r schrieb:> Gibt es eigentlich ein paar Features, die man schon in den 'trunk'> portieren könnte, oder ist alles Klassenabhängig?
Ne also ohne Klassen läuft eigentlich überhaupt nichts aus meinem
Branch. Man müsste extra neue Funktionen schreiben um diese Features in
den Trunk übernehmen zu können.
b.r schrieb:> Gesetzt wird es an zwei verschiedenen Stellen: In> 'readme/partdb-autoprice.py' wird es bei Neueinträgen/Updates auf '0'> gesetzt. price_add in der lib.php setzt es auf '1'.>> Aber verwendet wird es bisher noch nicht. Vielleicht ist es aber nicht> ganz verkehrt, zum Preis die folgenden Informationen zu speichern: Datum> der letzten Aktualisierung und Herkunft der Preisinformation (Webseite,> Angebot o.ä.)
Hmm ok stimmt, das autoprice.py habe ich ganz vergessen. Dann lasse ich
diese Spalte mal in der Tabelle drin. Das Datum der letzten
Preisaktualisierung wird ja bereits aufgezeichnet, das lasse ich auch so
drin. Herkunft der Preisinformation könnte man später noch einbauen wenn
es mal möglich sein sollte, die Preise direkt von Webseiten zu beziehen
(direkt aus Part-DB heraus). Momentan gibt es ja nur die zwei
Möglichkeiten "manuell" und "autoprice.py", daher genügt vorläufig der
Boolean "manual_input".
b.r schrieb:> Ich hatte die Spalte eingeführt, um die Bauteilansicht in> 'open/openlist.php' einschränken zu können. Wenn die Benutzerverwaltung> eingeschränkenten Gastzugriff erlaubt, kann das gerne dort mit> einfließen.> Es sollen z.B. in einer Firma nur die 'offiziellen' Bauteile für alle> sichtbar sein.
OK dann könnte man theoretisch sogar noch etwas weiter gehen, und
"Attribute" für Bauteile einführen. Dann kann der Benutzer (bzw. der
Admin) festlegen, welche Attribute es geben soll, z.B. "inoffiziell" und
"geheim". Beim Anlegen eines Bauteiles erscheint dann für jedes Attribut
eine Checkbox die man anwählen kann. In der Benutzerverwaltung legt man
dann bei jedem Benutzer fest, auf welche Attribute er Zugriff hat und
auf welche nicht. Momentan gibt es ja auch schon ein Attribut
"obsolete", das man später dann nicht mehr separat behandeln müsste.
Für den Gastzugang legt man später übrigens einfach einen Benutzer
"Gast" an und definiert seine Rechte. Dann gelten diese Attribute auch
für nicht-eingeloggte Benutzer.
Aber das hat momentan eine niedrige Priorität, das muss noch etwas
warten. Ich schreibs aber mal in unsere ToDo Liste.
b.r schrieb:>> - Tabelle "pending_orders": Wurde noch nie gebraucht?!> Doch: Verwaltung/Tools -> Zeige -> Zu bestellende Teile
Ja, aber dort werden ja einfach die Teile aus der Tabelle "parts"
geholt, wo "instock" kleiner als "mininstock" ist. Die Tabelle
"pending_orders" ist bei mir jedenfalls immer leer, auch wenn in "Zu
bestellende Teile" Teile angezeigt werden. Meine Vermutung ist, dass die
Tabelle dazu da ist, um Teile als bestellt markieren zu können. Dann
würden sie nicht mehr unter "Zu bestellende Teile" aufgelistet werden,
obwohl der Bestand noch tief genug wäre. Aber implementiert scheint es
noch nicht zu sein, ich habe nichts gefunden wo man Teile als "bestellt"
markieren könnte.
Naja, ich lass die Tabelle wohl mal drin und schreibe einen ToDo-Eintrag
dazu.
mfg
Urban B. schrieb:> Ne also ohne Klassen läuft eigentlich überhaupt nichts aus meinem> Branch. Man müsste extra neue Funktionen schreiben um diese Features in> den Trunk übernehmen zu können.
Na dann wird es Zeit, die Klassen in den Trunk zu holen, oder?!
[Attribute]
> Aber das hat momentan eine niedrige Priorität, das muss noch etwas> warten. Ich schreibs aber mal in unsere ToDo Liste.
Klingt gut.
[pending_orders]
> Aber implementiert scheint es> noch nicht zu sein, ich habe nichts gefunden wo man Teile als "bestellt"> markieren könnte.
Stimmt. Bisher wird die Tabelle nur gelesen. Zum ersten Mal taucht das
Feature in part-db-0.1d-beta (showparts.php) auf. Da die Tabelle bisher
nicht beschrieben wird und der Originalautor nicht mehr mitmacht, können
wir die Tabelle und die zugehörigen Abfragen gerne entfernen.
> Naja, ich lass die Tabelle wohl mal drin und schreibe einen ToDo-Eintrag> dazu.
Oder so.
Grüße
b.r
b.r schrieb:> Urban B. schrieb:>> Ne also ohne Klassen läuft eigentlich überhaupt nichts aus meinem>> Branch. Man müsste extra neue Funktionen schreiben um diese Features in>> den Trunk übernehmen zu können.> Na dann wird es Zeit, die Klassen in den Trunk zu holen, oder?!
Das kommt schon noch, aber das braucht schon seine Zeit bis auch
wirklich alles vernünftig läuft :-)
Ich habe jetzt einen neuen Branch "uneist_kami89" angelegt, in dem die
beiden Branches "uneist" und "kami89" verschmolzen werden.
mfg
Hi, hab grade mal versuch den Brunch "uneist_kami89" zu installieren
kann das sein das es ein Pfade Problem gibt ?
Jedenfalls wen es nicht im Hauptordner liegt das hat mich auch schon
immer bei der org. Version gestört gehabt das man bei keine Absoluten
Pfade angeben konnte, wehre noch was für die ToDo liste ebenso wie
absolute WEB Pfade das würde auch viele Probleme Lösen z.b. bei der
Mobile Version ist mir das schon sehr unangenehm aufgefallen(die Mobile
Version wehre mit den Brunch eh obsolet da das über das neue
Templatesystem gut umzusetzen wehre).
Ansonsten schon mal ein Fettes LOB an kami und die anderen.
K. J. schrieb:> Hi, hab grade mal versuch den Brunch "uneist_kami89" zu installieren> kann das sein das es ein Pfade Problem gibt ?
Hallo K.J.!
Meinst du die Pfade der include-Anweisungen? Oder welche Pfade meinst
du?
Ich kann hier grad kein Pfade-Problem feststellen, bräuchte also mehr
Informationen von dir um das nachvollziehen zu können.
K. J. schrieb:> Jedenfalls wen es nicht im Hauptordner liegt das hat mich auch schon> immer bei der org. Version gestört gehabt das man bei keine Absoluten> Pfade angeben konnte, wehre noch was für die ToDo liste ebenso wie> absolute WEB Pfade das würde auch viele Probleme Lösen
Hmm meinst du die Pfade für Bilddateien/Datenblätter? :-)
Da dachte ich, dass man nur den zum Hauptordner relativen Pfad verwenden
soll. Nur für Dateien ausserhalb des Hauptordners sollen über den ganzen
Pfad angesprochen werden.
K. J. schrieb:> z.b. bei der> Mobile Version ist mir das schon sehr unangenehm aufgefallen(die Mobile> Version wehre mit den Brunch eh obsolet da das über das neue> Templatesystem gut umzusetzen wehre).
Jup, ich denke mal für eine mobile Version wird es dann ein extra
Template geben.
K. J. schrieb:> Ansonsten schon mal ein Fettes LOB an kami und die anderen.
Dankeschön :-)
P.S.
Ich habe gleich nochmal eine neue Version ins SVN geladen mit einigen
Änderungen.
So, ich habe jetzt (r533) noch ein System eingebaut, um auf jeder Seite
möglichst einheitlich und einfach Fehlermeldungen/Bestätigungsmeldungen
und Sicherheitsnachfragen (z.B. beim Löschen) ausgeben zu können.
In der Datei supmgr.php ist dies sehr schön zu sehen (es handelt sich um
das Array $messages). Beim Anlegen und Bearbeiten von Lieferanten
erscheinen Bestätigunsmeldungen bzw. Fehlermeldungen am oberen Rand,
beim Löschen erscheint die Sicherheitsnachfrage in dieser Box.
(Durch die ganzen Exceptionhandler wirkt die supmgr.php leider schon
langsam etwas unübersichtlich. Vielleicht lässt sich da noch was
verbessern...)
Falls schwerwiegende Fehler im Skript auftreten, so wird nur diese Box
mit den Fehlermeldungen ausgegeben, der Rest der Seite wird dann nicht
angezeigt (es folgt aber noch ein "Reload"-Button um wieder zur
vollständigen Seite zu kommen falls der Fehler z.B. durch eine per
POST/GET übermittelte Variable entstanden ist).
Ich denke, das Ziel wären schlussendlich dann mal schöne JavaScript
Dialoge, die auch optisch was hermachen. Aber mit JavaScript kenne ich
mich zu wenig aus, und irgendwann muss die neue Version ja auch mal
fertig werden :-)
Auch habe ich das "Bedienkonzept" der supmgr.php etwas abgeändert. Am
besten schaut ihr es euch selbst an, der Branch müsste eigentlich so
Funktionieren (voraussetzung ist aber eine Datenbank der Version 12!).
Ich hoffe ihr seit damit einverstanden :-)
So und jetzt ab ins Bett xD
Urban B. schrieb:> K. J. schrieb:>> Hi, hab grade mal versuch den Brunch "uneist_kami89" zu installieren>> kann das sein das es ein Pfade Problem gibt ?>> Hallo K.J.!> Meinst du die Pfade der include-Anweisungen? Oder welche Pfade meinst> du?> Ich kann hier grad kein Pfade-Problem feststellen, bräuchte also mehr> Informationen von dir um das nachvollziehen zu können.>
Naja wir haben ja immer Dateipfade Relativ angegeben also z.b.
img/blablub.png, sinnvoller ist es dieses in der Config zu erweitern
z.b. bei Bineren Dateien oder Uploadordnern ...:
${Pfaddateisystem}/blablub.png = /var/www/...../blablub.png
Bei PHP Dateien den webpfad:
${Relativerpfad}/start.php = http://example.com/...../start.php
Warum ist auch eigentlich klar bei den Brunch wird das sichtbar mal
greift z.b. die nav.php auf templates... zu mal ist es andersrum da
greift das Template auf Dateien im Hauptordner von der Partdb zu da
klappt das mit den Relativen Pfaden nicht mehr.
Ich hoffen das war jetzt verständlich.
Ich hab das nie gemacht gehabt weil ich nie gedacht hätte das es so
viele Leute nutzen würden das würde auch eine ganze mänge Probleme
anderer USER Lösen.
http://partdb.grautier.com/uneistkami89/ wehre nen beispiel das es nicht
geht so wie es ist sieht man im html Quellcode recht gut wen die
Installation im Hauptordner der subdomain wehre würde es gehen im
unterordner nicht.
b.r schrieb:> Torsten C. schrieb:>> Wird die Liste denn noch gepflegt,> Ja.>>> oder gibt es noch mehr Listen?> Nein.>>> b.r schrieb:>>> Damit würde die aufwändige, unkomfortable Suche nach dem passenden>>> Bauteil in der entsprechenden PCB-Software entfallen.>> Und wie genau geht das dann weiter, z.B. in Eagle? Im Lib-Browser muß>> ich das Bauteil doch eh suchen, oder kann man das Bauteil per Drag&Drop>> aus der Part-DB in den Schaltplan schieben?> Ich könnte mir vorstellen, das man die benötigten Teile als Lib aus> part-db exportiert und dann alles an einem Platz hat.>> Grüße> b.r
Dazu habe ich noch eine Idee, wir haben hier in der Firma das Problem
das 2 Entwickler jeweils eine eigene Bauteil-bibliothek aufgebaut haben.
Ich habe jetzt mal angefangen die Bibliotheken zusammenzufassen, dabei
habe ich einen SVN-Server aufgesetzt. Dadurch das Eagle 6 jetzt
XML-Dateien einsetzt geht das ziemlich gut.
Ich ahbe das ganze so eingerichtet das es einen trunk gibt in dem alle
Bibliotheken gepflegt werden und jeder Entwickler einen eigenen brunch
hat in dem er seine eigene Bibliothek pflegen kann, so kann es nicht
passieren, dass wenn Entwickler A eine Änderung an einem Bauteil macht
Entwickler B ebenfalls betroffen ist.
Weiter geplant ist dann, das die Entwickler einmal im Monat einen tag
ihres branches anlegen und diese wieder in den trunk übernommen werden.
Wenn man ein SVN im Netz aufsetzen möchte reicht es wahrscheinlich aus
wenn man einen trunk anlegt wo nur wenige Leute Schreibzugriff haben
aber jeder Lesezugriff und einen bruch wo jeder dann Bibliotheken
einreichen kann. Ein paar Freiwillige pflegen die Bauteile dann in den
trunk ein.
Wenn man sowas in Angriff nimmt sollte man sich aber ein paar Gedanken
über 'Guidlines' machen, sonst findet man in der Bibliothek kaum etwas.
Ich habe mal eine Bibliothek angehangen wie ich das bei uns umgesetzt
habe.
Ich habe mal noch ein Bild von ein paar Bauteilen angehangen wie das in
3D aussieht, die können zwar nicht mir Eagle3D oder EagleUP mithalten,
können dafür aber von einem Gehäuse-Designer im CAD-Programm verwendet
werden.
Wer Interesse hat sowas aufzubauen, kann sich mal melden. Ich hätte da
sogar noch einen kleinen V-Server zum testen mit der Domain pcb-parts.de
:-)
K. J. schrieb:> Naja wir haben ja immer Dateipfade Relativ angegeben also z.b.> img/blablub.png, sinnvoller ist es dieses in der Config zu erweitern> z.b. bei Bineren Dateien oder Uploadordnern ...:>> ${Pfaddateisystem}/blablub.png = /var/www/...../blablub.png
Ja, intern wird jetzt eigentlich auch mit absoluten Pfaden gearbeitet,
dazu gibt es die Konstante BASE, die in der start_session.php definiert
wird, und zwar mit dirname(_FILE_). Ich denke das sollte eigentlich
ein gutes System sein, da _FILE_ ja immer den kompletten Pfad zur
start_session.php liefert, also müsste dirname(_FILE_) dann den Pfad
der Part-DB Installation sein. Und _FILE_ ist auch unabhängig davon,
aus welcher Datei heraus nun die start_session.php included wurde, es
liefert immer den Pfad zur start_session.php.
Für die HTML-Ausgabe denke ich aber es ist besser wenn das
Serververzeichnis (z.B. "/var/www/") wieder entfernt wird. Ich finde es
geht niemeanden was an, in welchem Ordner Part-DB installiert ist.
Fürs HTML sollte es da doch keine Probleme geben, wenn man für
Dateipfade immer alles nach dem "var/www" verwendet, also z.B.
"/part-db/img/partdb/favicon.ico" für die Favicon-Deklaration im
HTML-Header, oder liege ich da falsch? (Der komplete Pfad der Datei wäre
dann "/var/www/part-db/img/partdb/favicon.ico")
K. J. schrieb:> Warum ist auch eigentlich klar bei den Brunch wird das sichtbar mal> greift z.b. die nav.php auf templates... zu mal ist es andersrum da> greift das Template auf Dateien im Hauptordner von der Partdb zu da> klappt das mit den Relativen Pfaden nicht mehr.
Nein, in PHP wird es nicht zu Problemen führen, da immer mit der
BASE-Konstante gearbeitet wird bei den includes, also z.B.
include_once(BASE.'/lib/class.HTML.php');
Es gibt allerdings eine einzige Ausnahme, und das ist die
start_session.php, weil vor dem Includen dieser Datei die BASE-Konstante
ja noch nicht existiert. Aber da man in jeder PHP-Datei ja weiss, wo die
start_session.php (relativ zur ausgeführten Datei) liegt, kann man diese
auch ohne Probleme mit dem relativen Pfad einbinden.
K. J. schrieb:> http://partdb.grautier.com/uneistkami89/ wehre nen beispiel das es nicht> geht so wie es ist sieht man im html Quellcode recht gut wen die> Installation im Hauptordner der subdomain wehre würde es gehen im> unterordner nicht.
OK da scheint aber das Problem zu sein, dass in den Pfaden im Header der
beginnende Slash fehlt. Ich habe mal eine neue Revision hochgeladen,
probier die mal aus, ich hoffe dann funktionierts.
Ich werde wohl in der start_session.php noch eine Konstante
DOCUMENT_ROOT anlegen, die dann immer den Pfad nach z.B. "/var/www/"
beinhaltet. Ich vermute nämlich, dass bei dir $_SERVER['DOCUMENT_ROOT']
keinen Slash am Ende hat, bei mir aber schon. Deshalb würde es Sinn
machen, eine Konstante DOCUMENT_ROOT anzulegen, die dann immer
definierte Slashes hat, damit man sich in den Skripten nicht mehr darum
kümmern muss.
So, jetzt ist das Pfade-Problem in der Online Demo behoben, scheint wohl
wirklich an der Inkonsistenz der Variable $_SERVER['DOCUMENT_ROOT']
gelegen haben.
Jetzt werden also absolute Pfade ausgehend vom DOCUMENT_ROOT verwendet,
so wie hier beschrieben:
http://de.selfhtml.org/html/allgemein/referenzieren.htm#absolut
Etwas komisch ist aber der Fehler in der showparts.php, es scheint keine
Spalte "name" in der Tabelle "files" zu geben? Die sollte eigentlich
beim Datenbankupdate angelegt worden sein...
Dafür funktioniert das Debugging, damit kann ich dann den Fehlern, die
in der Online Demo auftauchen, nachgehen.
Danke noch fürs Einrichten des Demo-Servers, der ist auf jeden Fall
nützlich wie man jetzt schon feststellen kann :-)
mfg
Urban B. schrieb:>> Jetzt werden also absolute Pfade ausgehend vom DOCUMENT_ROOT verwendet,> so wie hier beschrieben:> http://de.selfhtml.org/html/allgemein/referenzieren.htm#absolut
Jup funtzt
>> Etwas komisch ist aber der Fehler in der showparts.php, es scheint keine> Spalte "name" in der Tabelle "files" zu geben? Die sollte eigentlich> beim Datenbankupdate angelegt worden sein...>
Hm schau morgen mal aber ansich lief das Update sauber durch
> Dafür funktioniert das Debugging, damit kann ich dann den Fehlern, die> in der Online Demo auftauchen, nachgehen.>> Danke noch fürs Einrichten des Demo-Servers, der ist auf jeden Fall> nützlich wie man jetzt schon feststellen kann :-)>
Jup hab das alles noch nicht ganz fertig wollte am Anfang beim aufrufen
eine Auswahlseite machen in der man die normale oder den Brunch zum
testen ausmehlen kann.
So langsam wirds werde mich die tage mal in das neue System reinleasen
sieht jedenfalls ziemlich gut aus bis jetzt.
K. J. schrieb:> Jup hab das alles noch nicht ganz fertig wollte am Anfang beim aufrufen> eine Auswahlseite machen in der man die normale oder den Brunch zum> testen ausmehlen kann.
OK, super!
> So langsam wirds werde mich die tage mal in das neue System reinleasen> sieht jedenfalls ziemlich gut aus bis jetzt.
Du wirst nicht mehr viel von den alten Funktionen wiedererkennen, soviel
kann ich dir schonmal sagen :-)
Als "Musterbeispiel" um zu schauen wie die Klassen verwendet werden,
empfehle ich die supmgr.php, die sieht jetzt etwa so aus wie ich mir das
vorgestellt habe.
Wird jetzt beim Demoserver eigentlich auch schon täglich eine neue
Datenbank eingespielt?
Urban B. schrieb:> K. J. schrieb:>> Wird jetzt beim Demoserver eigentlich auch schon täglich eine neue> Datenbank eingespielt?
Nein noch nicht bin in MYSQL noch nicht so fit bin aber dabei.
hab die Startseite fertig vielleicht hat ja einer noch eine
Verbesserungs Idee
http://partdb.grautier.com/
Aso fast vergessen zur fehlenden Tabelle hab mal in die DB geschaut
"name" gibt es nicht als ROW aber "filename" ? ist das vielleicht das
Problem ?
EDIT: Jup dadran lag es
K. J. schrieb:> Nein noch nicht bin in MYSQL noch nicht so fit bin aber dabei.
OK alles klar.
> hab die Startseite fertig vielleicht hat ja einer noch eine> Verbesserungs Idee>> http://partdb.grautier.com/
Cool! Aber irgendwie scheint es ein Problem mit dem Zeichensatz zu
geben, bei mir werden ä, ö, ü nicht richtig angezeigt...
K. J. schrieb:> Aso fast vergessen zur fehlenden Tabelle hab mal in die DB geschaut> "name" gibt es nicht als ROW aber "filename" ? ist das vielleicht das> Problem ?
ne es müsste eigentlich beides geben, "name" und "filename". Mit "name"
kann man dann nämlich den Dateien auch gescheite Namen geben wie z.B.
"AVR AppNote AN123" oder "Anschlussschema" usw.
In der db_update_steps.php sieht die entsprechende Stelle so aus:
1
// table "pictures" will now be changed to "files"
$updateSteps[] = "ALTER TABLE `files` ADD `name` TINYTEXT NOT NULL AFTER `id`";
14
$updateSteps[] = "ALTER TABLE `files` ADD `class_name` TINYTEXT NOT NULL AFTER `name`";
15
$updateSteps[] = "ALTER TABLE `files` ADD `type_id` INT(11) NOT NULL AFTER `element_id`";
16
$updateSteps[] = "UPDATE `files` SET name=filename";
17
$updateSteps[] = "UPDATE `files` SET type_id='1'";
18
$updateSteps[] = "UPDATE `files` SET class_name='Part'";
Heisst also, "pict_fname" müsste vorher vorhanden gewesen sein, und
hätte nun in "filename" umbenannt werden müssen. Ursprünglich wurde
"pict_fname" in der Datei createtables-FOR-V0.2.1.sql angelegt. Kann es
vielleicht sein dass bei dir aus irgendeinem Grund diese Spalte
"pict_fname" nicht vorhanden war?
EDIT: ääh nix studiert....es geht ja um "name", und die hätte beim
Datenbankupdate einfach angelegt werden müssen wie man im Code oben
sieht.
Ok so geht das danke.
Werde mich eh nochmal mit Mysql rumschlagen müssen man kommt neuerdings
an die komplette Reichelt Datenbank ran ich schaue mir das ganze grade
an ob man die vielleicht sinnvoll Parsen und bereitstellen kann leider
ist das ganze in einem recht großen SQLLite File ich wandel das grade um
aber das wird ne kleine Ewigkeit dauern das ganze in eine Mysql DB zu
Quetschen b.z.w. vorher nur das wichtige rauszufiltern da da z.b. Bilder
als Binery Blob drinnen sind.
Wehre noch mit Reichelt abzuklären ob das erlaubt ist, entweder die User
müssen die Datei selber runterladen, oder Reichelt erlaubt das
bearbeiten dann würde ich das ganze in eine Mysql DB stopfen als Mirror
bereitstellen müsste man wen es was wird halt mal erfragen.
Hmm ja wäre cool wenn man dann direkt Teile aus der Reichelt Datenbank
in die eigene Part-DB importieren könnte.
Ich habe grad noch den Branch aktualisiert, jetzt werden noch zwei
zusätzliche Konstanten in der config.php verlangt. Und zwar die Befehle
bzw. Pfade zu "mysqldump" und "mysql", welche dann per exec() für die
Datenbankbackups und -wiederherstellung verwendet werden können.
Könntest du diese beiden Konstanten noch in die config.php des
Demo-Servers aufnehmen? Eine Vorlage gibts wie immer in der
config.php_template. Und könntest du eine Datenbank der Version 12 in
den backup-Ordner legen? Wenn dann die Backup/Restore Funktion
funktioniert, kann ich auch selber die Datenbank der Demo wieder auf die
Version 12 zurücksetzen wenn es mal nötig ist oder ich was ausprobieren
möchte. Dann brauchen wir die tägliche Datenbankwiederherstellung
eigentlich gar nicht, wenn ich es manuell machen kann ist das sogar noch
besser :-)
Gescheite Fehlermeldungen von den exec() Befehlen gibt es übriegens noch
nicht, das kommt später noch. Aber immerhin sollte zuverlässig erkannt
werden ob es erfolgreich war oder nicht :-) Dann sollten wenigstens
keine leeren Backup-Dateien mehr entstehen, was vorher ziemlich
"gefährlich" war.
EDIT:
Der Fehler in der "files" Tabelle war übrigens nicht der einzige Fehler.
Auch "id_manufacturers" fehlt in der Tabelle "parts"...
EDIT2:
Übrigens muss nach dem nächsten SVN Update sowieso wieder eine Datenbank
der Version 12 eingespielt werden. Falls die Backup/Restore Funktion
nicht funktioniert, wäre ich froh wenn du noch von Hand schnell eine
neue (bzw. alte) Datenbank einspielen könntest :-)
Hi,
Das mit den EXEC geht nicht bei mir das auch aus Gutten Grund es ist ein
echter Server da ist das nicht sinig.
ich könnte dir mysqldumper aufsetzen für die DemoDBs wen du möchtest.
hm vielleicht sollte ich DB noch mal komplett neu einspielen und schauen
wo der Fehler liegt.
Ansonsten hab ich hier noch dayli Backups der letzten 5 jahre ;-)
Zur DB von reichelt es ist etwas schwerer als gedacht die sqllite DB ist
AES Verschlüsselt, stehe aber grade mit Reichelt im Kontakt der
FB-Zuständige sagte das es da wohl ne API für gibt, die frage ist halt
ob wir daran dürfen und in welcher form.
> Das mit den EXEC geht nicht bei mir das auch aus Gutten Grund es ist ein> echter Server da ist das nicht sinig.
Ach so okay :-)
> ich könnte dir mysqldumper aufsetzen für die DemoDBs wen du möchtest.
Eigentlich könnten wir doch mysqldumper auch gleich in Part-DB mit
einbauen oder? Ich schaue mir das mal an wie das so funktioniert.
> hm vielleicht sollte ich DB noch mal komplett neu einspielen und schauen> wo der Fehler liegt.
Jo ich denke mal nach dem Einspielen einer neuen Datenbank sollte das
Problem behoben sein. Ich mache halt nicht für jedes Datenbankupdate ein
neues "case" in die Updatefunktion weil es sonst schnell sehr viele
"cases" geben würde :-) Deshalb muss man dann halt von Zeit zu Zeit
wieder eine Datenbank der Version 12 einspielen...
> Ansonsten hab ich hier noch dayli Backups der letzten 5 jahre ;-)
Hehe ja ich denke darin sollten wir was passendes finde :-)
> Zur DB von reichelt es ist etwas schwerer als gedacht die sqllite DB ist> AES Verschlüsselt, stehe aber grade mit Reichelt im Kontakt der> FB-Zuständige sagte das es da wohl ne API für gibt, die frage ist halt> ob wir daran dürfen und in welcher form.
Okay, bin gespannt was da noch rauskommt.
mfg
Hmm MySQLDumper ist ja ein ganz geiles Ding! Es in Part-DB einzubinden
macht aber eher wenig Sinn da es ja was komplett eigenständiges ist.
Allerdings sollte es später, wenn es Systemupdates für Part-DB gibt,
auch direkt aus Part-DB heraus aufgerufen werden können. Denn immer vor
einem Systemupdate sollte die Datenbank automatisch gesichert, und bei
einem misslungenen Update wiederhergestellt werden.
Ich habe im MySQLDumper Forum gelesen dass es ab der Version 2 auch eine
API für einen solchen externen Aufruf geben soll, das wäre dann
natürlich super. Vielleicht kommt die Version 2 ja heraus bevor unser
Updatesystem fertig ist, dann hat sich das Problem auch erledigt :-D
Ich denke also, dann werden wir die Backup/Restore Funktion komplett aus
Part-DB entfernen, und stattdessen vielleicht irgendwo einen Hinweis
platzieren dass man dafür MySQLDumper benutzen kann.
Dann bräuchten wir also doch noch etwas für den Demo Server, um alte
Datenbanken wiederherzustellen.
So, ich habe jetzt die config.php nochmal etwas verändert. Die
Einstellungen werden nun nicht mehr in der Datenbank gespeichert,
sondern in einem Array, das in der config.php liegt.
Der Grund dafür ist, dass es einfach ein paar Einstellungen gibt, die
auch funktionieren sollen wenn die Datenbank aufgrund eines Fehlers
nicht gelesen werden kann. Der Nachteil ist halt, dass nun die
Einstellungen bei einem Datenbankbackup nicht mitgesichert werden. Aber
so wirklich wichtig sind diese Einstellungen eh nicht, die hätte man
schnell wieder eingestellt wenn sie wirklich mal verloren gehen
würden...
@K.J. könntest du bitte bei Gelegenheit eine neue config.php erstellen
(Vorlage gibts wie immer in der config.php_template)? Nachher kann man
übrigens auch die Datenbank-Verbindungsparameter bequem über Part-DB
einstellen, was ich aber noch mit einem Passwortschutz versehe weil
sonst ja jeder die Online Demo lahmlegen könnte^^ Daher solltest du in
$config['admin']['password'] ein MD5-Hash eines Passwortes abspeichern
(oder einfach irgendwas reinschreiben damit es komplett gesperrt wird).
mfg
@K.J.
Wie ich sehe, hast du den Menüeintrag "System" nun entfernt in der
Online Demo. Ich vermute mal du willst nicht, dass man die
Datenbank-Verbindungsparameter sehen kann :-)
Dazu habe ich jetzt noch einen neuen Parameter in der config.php
hinzugefügt. Stellt man $config['is_online_demo'] auf 'true', dann
werden die Verbindungsparameter ausgeblendet, der "Übernehmen" Button
ist deaktiviert (und in der php ist nochmals ein Schutz damit keine
neuen Werte übernommen werden können), und in der Systemkonfiguration
wird die PHP-Version ausgeblendet.
Alle anderen Einstellungen sind unbedenklich, da dürfen die Leute auch
ruhig dran rumschrauben. Auch auf der Debug-Seite kann man eigentlich
kein Unfug treiben.
Ich finde es in den Online-Demos immer schade wenn die
Konfigurationsseiten ausgeblendet werden, ich jedenfalls interessiere
mich immer dafür, was man denn alles so einstellen kann :-)
Wäre das so in Ordnung für dich? Dann müsstest du einfach noch den
entsprechenden Parameter in der config.php auf 'true' stellen. Sorry
dass ich immer an der config.php rumschraube ;-)
Das entsprechende Update lade ich heute noch ins SVN. Übrigens habe ich
die config.php_template etwas umgebaut. Und zwar heisst die jetzt
config_defaults.php, wo alle Parameter auf Standardwerte gesetzt werden.
Diese wird direkt vor der config.php included, somit beinhalten alle
Parameter, die in der config.php nicht existieren, automatisch die
Standardwerte. Auch muss man die config.php gar nicht mehr von Hand
anlegen beim Installieren von Part-DB. Beim ersten Start sind einfach
die Standardeinstellungen aktiv, was sicherstellt, dass das Skript
vollumfänglich funktioniert, bis auf die Datenbankverbindung natürlich.
Dann stellt man einfach über "System" -> "Datenbank" die
Verbindungsparameter und über "System" -> "Konfiguration" die anderen
Einstellungen ein, und die config.php wird automatisch angelegt.
mfg
K. J. schrieb:> WoW sieht echt gut aus !!!
Danke :-)
Wie soll eigentlich die neue Version heissen, was meint ihr?
0.2.3? 0.5.0? 1.0.0? sonstwie? (wobei dann zuerst aber mal release
kandidaten erscheinen, also z.B. als "1.0.0 RC1" veröffentlicht werden
würden)
Ich kann mich nicht entscheiden :-)
Zurück aus meinem Mini-Urlaub ;-) Ich werde mir die nächsten Tage mal
den gemeinsamen Branch vornehmen und dort weiter machen.
Nach meiner Meinung wäre wohl eine Versionbezeichung 0.3.x besser
geeignet, denn ausser einem Rewrite ist ja praktisch nichts neues
hinzugekommen. Wenn die Benutzerverwaltung und ein paar andere Wünsche
eingebaut sind, wäre der Sprung auf eine 1er Version sinvoll.
Grüße
Udo
Udo Neist schrieb:> Zurück aus meinem Mini-Urlaub ;-) Ich werde mir die nächsten Tage mal> den gemeinsamen Branch vornehmen und dort weiter machen.
Na dann willkommen zurück :-)
Bei einigen Seiten habe ich die Templates gleich selber angelegt, nach
etwas Einarbeiten in die von dir erstellten Seiten ging das ganz gut :-)
> Nach meiner Meinung wäre wohl eine Versionbezeichung 0.3.x besser> geeignet, denn ausser einem Rewrite ist ja praktisch nichts neues> hinzugekommen. Wenn die Benutzerverwaltung und ein paar andere Wünsche> eingebaut sind, wäre der Sprung auf eine 1er Version sinvoll.
Jo, macht Sinn. Ich nehme mal "0.3.0 RC1" für die erste neue Version
wenn da niemand was dagegen einzuwenden hat.
Ach ja, ich lade jetzt eigentlich täglich meine Änderungen ins SVN hoch.
Wäre gut wenn du das auch tun würdest wenn du weiter an unserem Branch
arbeitest, damit wir kein Durcheinander bekommen.
Und unsere beiden alten Branches sind nun zwar völlig nicht mehr
aktuell, aber ich würde da nichts löschen weil es dort noch Dateien
gibt, die ich (noch) nicht in den neuen Branch übernommen habe. Also
wenn du im neuen Branch etwas vermisst, dann schau mal im alten Branch
nach :-)
mfg
EDIT:
Übrigens, wozu haben wir eigentlich in der get_svn_revision() eine
Variante mit shell_exec() und eine, die die SVN Dateien ausliest?
Zweiteres müsste doch eigentlich immer funktionieren, und könnte deshalb
doch gleich immer verwendet werden, oder?
> Na dann willkommen zurück :-)> Bei einigen Seiten habe ich die Templates gleich selber angelegt, nach> etwas Einarbeiten in die von dir erstellten Seiten ging das ganz gut :-)
So schwer ist die Template-Engine ja nicht zu verstehen :-) Smarty & Co
sind schwerer.
> Jo, macht Sinn. Ich nehme mal "0.3.0 RC1" für die erste neue Version> wenn da niemand was dagegen einzuwenden hat.
Ok.
> Ach ja, ich lade jetzt eigentlich täglich meine Änderungen ins SVN hoch.> Wäre gut wenn du das auch tun würdest wenn du weiter an unserem Branch> arbeitest, damit wir kein Durcheinander bekommen.> Und unsere beiden alten Branches sind nun zwar völlig nicht mehr> aktuell, aber ich würde da nichts löschen weil es dort noch Dateien> gibt, die ich (noch) nicht in den neuen Branch übernommen habe. Also> wenn du im neuen Branch etwas vermisst, dann schau mal im alten Branch> nach :-)
Ich hab unsere beiden, den gemeinsamen und den offiziellen Teil hier
vorliegen. Man muss ja auch mal schauen, was man selbst für einen Mist
gebaut hat, wenn eine Funktion nicht mehr will.
> EDIT:> Übrigens, wozu haben wir eigentlich in der get_svn_revision() eine> Variante mit shell_exec() und eine, die die SVN Dateien ausliest?> Zweiteres müsste doch eigentlich immer funktionieren, und könnte deshalb> doch gleich immer verwendet werden, oder?
Es würde die direkte Variante ausreichen, aber mit diesem Code wollte
ich auch zeigen, dass man shell_exec() nicht ungeprüft verwenden kann.
Nicht überall kann man auf diese oder ähnliche Funktionen zurückgreifen
(Sicherheit).
Udo Neist schrieb:> Es würde die direkte Variante ausreichen, aber mit diesem Code wollte> ich auch zeigen, dass man shell_exec() nicht ungeprüft verwenden kann.> Nicht überall kann man auf diese oder ähnliche Funktionen zurückgreifen> (Sicherheit).
hm?
Eben genau deshalb meine ich ja, dass man die shell_exec auch gleich
komplett entfernen könnte. Das Auslesen der SVN-Dateien sollte hingegen
eigentlich doch IMMER funktionieren (oder zumindest nicht weniger häufig
als shell_exec). Und wenn eine der beiden Varianten IMMER funktioniert,
dann macht eine Fallunterscheidung ja gar keinen Sinn, dann kann man
auch gleich die zuverlässigere der beiden nehmen.
In der eigentlichen Diskussion ging es ja nicht nur um
get_svn_revision(), sondern eher um ein paar Stellen im Code, die
ungeprüft solche Funktionen wie shell_execute() ausführen. Hab ja auch
noch eine andere Funktion gefunden, die nicht überall anzutreffen ist
und daher nachgebildet werden muss. Sowas steht oft nur in den
Anmerkungen oder findet man in den Kommentaren.
Wo es sinnvoll ist, würde ich immer die direkte, über PHP nutzbare
Version nehmen, bevor ich auf die Shell zurückgreifen muss. Schmeiß`
also den Teil mit shell_execute() raus :-)
Udo Neist schrieb:> In der eigentlichen Diskussion ging es ja nicht nur um> get_svn_revision(), sondern eher um ein paar Stellen im Code, die> ungeprüft solche Funktionen wie shell_execute() ausführen. Hab ja auch> noch eine andere Funktion gefunden, die nicht überall anzutreffen ist> und daher nachgebildet werden muss. Sowas steht oft nur in den> Anmerkungen oder findet man in den Kommentaren.
Jup, das stimmt. Ich werde für solche Funktionen gleich noch eine eigene
Datei "lib.functions.php" anlegen. Aber auch wenn jetzt noch an ein paar
Stellen solche "problematischen" Funktionen genutzt werden würden, davon
geht die Welt nicht unter :-) Für solche Dinge gibt es ja die
Möglichkeit, dass die User hier im Forum Feedback geben können :-)
> Wo es sinnvoll ist, würde ich immer die direkte, über PHP nutzbare> Version nehmen, bevor ich auf die Shell zurückgreifen muss. Schmeiß`> also den Teil mit shell_execute() raus :-)
Schon geschehen :-)
Urban B. schrieb:>>> Nach meiner Meinung wäre wohl eine Versionbezeichung 0.3.x besser>> geeignet, denn ausser einem Rewrite ist ja praktisch nichts neues>> hinzugekommen. Wenn die Benutzerverwaltung und ein paar andere Wünsche>> eingebaut sind, wäre der Sprung auf eine 1er Version sinvoll.>> Jo, macht Sinn. Ich nehme mal "0.3.0 RC1" für die erste neue Version> wenn da niemand was dagegen einzuwenden hat.>
Hi Ja ich wehre auch für 0.3.x.x denke die 1.x.x.x sollten wir uns für
sehr stabiele Versionen aufbewahren.
So, ich habe jetzt mal angefangen den Source Code mit Doxygen
Kommentaren zu kommentieren, um mal zu schauen ob da eine nützliche
Dokumentation bei rauskommt. Denn bei den vielen Klassen verliert man
schnell mal den Überblick welche Methoden/Attribute nun von welcher
Klasse geerbt werden usw. Und das manuelle Zeichnen der Klassendiagramme
bringts ja nicht wirklich, das ist viel zu aufwändig um die Diagramme
aktuell zu halten.
Ein Beispiel, wo ich mit dem Kommentieren fertig bin, is die Klasse
"Category". Hier ist die Dokumentation, die Doxygen erstellt hat:
http://partdb.grautier.com/uneistkami89/documentation/doxygen/html/class_category.html
Oder für die Klasse "DBElement" hat Doxygen dieses coole Klassendiagramm
erstellt:
http://partdb.grautier.com/uneistkami89/documentation/doxygen/html/class_d_b_element__inherit__graph.png
Also ich persönlich finde, die Doku ist sehr gut gelungen, und wird bei
der Entwicklung für viel mehr Übersicht sorgen. Das Kommentieren des
Codes ist ja nicht wirklich aufwändig, man muss eigentlich nur grad die
wichtigsten paar Doxygen-Befehle kennen (@brief, @param, @retval,
@throws). Ich habe mich übrigens für das "@" (und gegen das "\" )
entschieden, weil ich Anfangs auch noch die Ergebnisse von PHPDoc sehen
wollte, und dort wird nur das "@" unterstützt. Ausserdem gefällt mir das
"@" auch optishc besser.
PHPDoc fand ich übrigens eigentlich auch nicht schlecht, aber
anscheinend kann man damit keine Diagramme erstellen wenn ich das
richtig sehe.
Bei Doxygen gibts aber auch etwas, das mir nicht so gefällt. Und zwar
sieht man z.B. bei der oben genannten Doku von "Category" drei mal die
Methode "delete()", weil diese Methode dreimal vorkommt in den
Elternklassen von Category. Aber eigentlich wäre es doch viel besser,
wenn nur die jeweils unterste dieser Methoden angezeigt werden würden,
die anderen machen ja keinen SInn irgendwie. Oder habe ich vielleicht
irgendwas falsch gemacht, dass es so angezeigt wird (?).
Man könnte natürlich auch alle geerbten Methoden/Attribute ganz
ausblenden, aber ich finde es sehr nützlich wenn man auch die geerbten
Dinge sieht. Man will ja schliesslich wissen, welche Methoden auf ein
bestimmtes Objekt angewendet werden können, und da gehören die geerbten
Methoden nunmal dazu.
Was meint ihr zu der Doku? Ist das für euch okay wenn wir das so
weiterführen? Oder habt ihr bessere Vorschläge?
Das Erstellen bzw. Aktualisieren der Doku ist übrigens ganz einfach.
Einfach im Ordner documentation/doxygen/ ein Terminal öffnen und
"doxygen Doxyfile" ausführen...
mfg
P.S. Aufgrund einiger Arbeiten an den Klassen wird die Demo momentan
nicht wirklich gut funktionieren. Keine Angst, das sind keine Bugs, das
ist so "gewollt" :-)
Auch wenn ich noch nicht ganz hinter den neuen OOP-Code gestiegen bin,
hab ich mal angefangen show_obsolete_parts.php auf Templates
umzuschreiben. Desweiteren hatte ich noch einen Fehler in
get_svn_revision() beseitigt. Es sollte settype($revision, 'integer')
statt settype($svn, 'integer') heißen.
[Edit]
Fehler beim Upload. Ich muss die Änderungen nochmal einschecken :(
Revision 564 eingescheckt :-)
Zwei zusätzliche Dateien:
- apache2-part-db.conf ist für das Modul mod_xsendfile gedacht. Es ist
für die schnellere Auslieferung von Dateien per X-SENDFILE-Header
nützlich.
- Ich habe noch das Shell-Script svn.sh dazugepackt, die ein paar
svn-Kommandos zusammenfasst. Wird später in ein neues Unterverzeichnis
"development" verschoben, welches Tools für die Entwicklung aufnehmen
soll. Im Release sollte man dieses Verzeichnis herausnehmen.
Udo Neist schrieb:> Auch wenn ich noch nicht ganz hinter den neuen OOP-Code gestiegen bin,> hab ich mal angefangen show_obsolete_parts.php auf Templates> umzuschreiben.
Auf den ersten Blick wird man ein bisschen von den ganzen Klassen
erschlagen, ich weiss :-) Aber dafür ist alles sehr strukturiert
aufgebaut, es ist nichts mehr doppelt vorhanden usw. Nach ein bisschen
Einarbeiten sollte es gut verständlich sein denke ich.
Um die Klassen besser zu verstehen, ist auch die Doxygen-Doku sehr
geeignet, die auch die ganzen Klassendiagramme inkl. Vererbung zeigt.
Sehr zentral ist auf jeden Fall die Klasse "DBElement" mit den Methoden
"set_attributes()", "check_values_validity()" und "add()". Die sollte
man verstanden haben damit man auch den Rest versteht. Mit
"check_values_validity()" werden alle Werte, die in die Datenbank
geschrieben werden (beim Anlegen oder Bearbeiten eines Datensatzes) auf
Gültigkeit überprüft und ggf. noch leicht angepasst. Jede Klasse lässt
zuerst alle seine Elternklassen die Werte überprüfen, danach werden die
Klassenbezogenen Werte überprüft.
Falls du etwas nicht verstehst helfe ich natürlich gerne weiter.
Udo Neist schrieb:> - apache2-part-db.conf ist für das Modul mod_xsendfile gedacht. Es ist> für die schnellere Auslieferung von Dateien per X-SENDFILE-Header> nützlich.
Ah okay, und wird die Datei automatisch geladen oder muss die noch
irgendwie eingebunden werden?
Udo Neist schrieb:> - Ich habe noch das Shell-Script svn.sh dazugepackt, die ein paar> svn-Kommandos zusammenfasst.
Ich frage mich, obs das wirklich braucht.
- Tabs durch Leerzeichen ersetzen kann doch jeder (Quelltext-)Editor
automatisch?
- Dateien mit Tildezeichen gibt bei mir auch, werden aber von SVN nicht
berücksichtigt. Ich vermute mal, das könnte man also irgendwie so
einstellen dass solche Dateien ignoriert werden?
Bei deiner letzten Änderung wurden in Google Code einen Haufen Dateien,
die du gar nicht bearbeitet hast, als bearbeitet markiert. Weisst du
woher das kommt? Könnte es sein, dass dein Shell-Skript irgendwie etwas
an den Dateien verändert hat?
> Wird später in ein neues Unterverzeichnis> "development" verschoben, welches Tools für die Entwicklung aufnehmen> soll. Im Release sollte man dieses Verzeichnis herausnehmen.
Jup, gute Idee!
mfg
Urban B. schrieb:> Sehr zentral ist auf jeden Fall die Klasse "DBElement" mit den Methoden> "set_attributes()", "check_values_validity()" und "add()". Die sollte> man verstanden haben damit man auch den Rest versteht. Mit> "check_values_validity()" werden alle Werte, die in die Datenbank> geschrieben werden (beim Anlegen oder Bearbeiten eines Datensatzes) auf> Gültigkeit überprüft und ggf. noch leicht angepasst. Jede Klasse lässt> zuerst alle seine Elternklassen die Werte überprüfen, danach werden die> Klassenbezogenen Werte überprüft.>> Falls du etwas nicht verstehst helfe ich natürlich gerne weiter.
Ich werde mich damit mal beschäftigen. Eigenen Code versteht man
schneller, bei fremden dauert das ja immer ne Weile ;-)
> Udo Neist schrieb:>> - apache2-part-db.conf ist für das Modul mod_xsendfile gedacht. Es ist>> für die schnellere Auslieferung von Dateien per X-SENDFILE-Header>> nützlich.>> Ah okay, und wird die Datei automatisch geladen oder muss die noch> irgendwie eingebunden werden?
Ne, der gehört zum Apache-Webserver. Ich werde das wohl mal komplett
fertig schreiben, damit man es in die Konfiguration des Webserver
leichter einfügen kann.
> Udo Neist schrieb:>> - Ich habe noch das Shell-Script svn.sh dazugepackt, die ein paar>> svn-Kommandos zusammenfasst.>> Ich frage mich, obs das wirklich braucht.
Programmierer sind faul ;-) Immer wiederkehrende Aktionen werden halt in
kleine Scripte ausgelagert. So ist halt svn.sh entstanden.
> - Tabs durch Leerzeichen ersetzen kann doch jeder (Quelltext-)Editor> automatisch?
Die meisten können das. Ich hab das allerdings hinzugefügt, um auch
externen Code entsprechend anzupassen.
> - Dateien mit Tildezeichen gibt bei mir auch, werden aber von SVN nicht> berücksichtigt. Ich vermute mal, das könnte man also irgendwie so> einstellen dass solche Dateien ignoriert werden?
Bei mir hat SVN auch schon mal diese Dateien hinzugefügt. Kommt auch
darauf an, mit was man da arbeitet. Ich nutze hier nur die Konsole.
> Bei deiner letzten Änderung wurden in Google Code einen Haufen Dateien,> die du gar nicht bearbeitet hast, als bearbeitet markiert. Weisst du> woher das kommt? Könnte es sein, dass dein Shell-Skript irgendwie etwas> an den Dateien verändert hat?
Es verändert nur PHP und Templates. Es werden ja nicht nur Tabs ersetzt,
sondern auch die Leerzeichen von Leerzeilen gelöscht. In meinem Editor
werden die Leerzeichen dann durch Punkte dargestellt, was etwas stört.
Ich arbeite halt nicht mit Netbeans oder Eclipse, sondern mit dem schon
etwas betagtem Quanta+.
>> Wird später in ein neues Unterverzeichnis>> "development" verschoben, welches Tools für die Entwicklung aufnehmen>> soll. Im Release sollte man dieses Verzeichnis herausnehmen.>> Jup, gute Idee!
Hab ich bei mir schon umgesetzt. Da drin ist auch die install.sh, die
die Installation per Shell ermöglicht.
So. Bin auch wieder zurück aus dem Urlaub.
Zum Thema:
[get_svn_revision]
svnversion zeigt auch an, ob lokal was modifiziert wurde.
Wenn man in den .svn Dateien nachschaut findet man nur die Nummer vom
letzten commit.
Mir gefällt ersters wesentlich besser, aber es ist nicht überall
verfügbar.
Grüße
b.r
SVN merkt sich in der Datei schon, ob was modifiziert wurde. Es wird
dann ein "M" angehängt. svnversion macht auch nicht viel anderes, als
den Status zu interpretieren.
Hallo!
Kann es sein, dass das fertig gepackte Release-Paket nicht ganz aktuell
ist?
Folgendes Paket habe ich geladen: PartDB-0.2.2.tar.gz vom Samstag, 2.
Juni 2012 10:56
Trotz 0.2.2 im Dateinamen, erscheint in der Oberfläche nach der
Installation die Version 0.2.1
So fehlt bei der Footprintverwaltung z.B. die Bilderzuordnung...
Die SVN-Version läuft leider auch nicht mit dem darin enthaltenen
0.2.1er SQL-Init-Script aus readme/
Könnte jemand mal die aktuelle Version vom Demoserver zur Verfügung
stellen oder zumindest ein SQL-Init-Script für den SVN-Versionsstand?
Danke!
Marvin Hohlfeld schrieb:> Hallo!>> Kann es sein, dass das fertig gepackte Release-Paket nicht ganz aktuell> ist?>
ist recht aktuell, wegen der umstellung wird das momenten nicht
Aktualisiert.
> Installation die Version 0.2.1>> So fehlt bei der Footprintverwaltung z.B. die Bilderzuordnung...>
Jup diese sind, in den beiden Extrapaketen ausgelagert weil die recht
gross sind.
> Die SVN-Version läuft leider auch nicht mit dem darin enthaltenen> 0.2.1er SQL-Init-Script aus readme/>> Könnte jemand mal die aktuelle Version vom Demoserver zur Verfügung> stellen oder zumindest ein SQL-Init-Script für den SVN-Versionsstand?>> Danke!
Die svn Version kanst selber ausschecken wie das geht steht auf der
Google Code seite, das init Script geht glaube ich nur für die 0.3.x
Version, diese ist momentan aber noch nicht wirklich Produktiv
brauchbar.
Die SVN-Version auszuchecken ist nicht das Problem, nur fehlt mir
hierfür ein SQL-Skript zur Datenbank-Initialisierung! Das alte Skript
funktioniert mit der SVN-Version nicht, da sich die Datenbankstruktur
geändert hat.
Also woher bekomme ich nun ein lauffähiges SQL-Dump..? :-)
Hallo Leute,
Soeben habe ich eine neue Version hochgeladen (r567). Jetzt ist es auch
möglich die Preise auf eine bestimmte Menge zu beziehen (z.B. 10Euro /
100Stk.), was z.B. für Kabelschuhe, bei denen die Lieferanten die Preise
häufig auf 10 oder 100 Stk. beziehen, nützlich ist. Dann ist man auch
nicht mehr auf die Genauigkeit von 0,01 beschränkt, was vorher der Fall
war. Das entsprechende Attribut heisst "price_related_quantity".
Und dann gibt es noch das Attribut "min_discount_quantity". Damit lassen
sich verschiedene Preise für verschiedene Bestellmengen definieren
(Stichwort Mengenrabatt).
Kleine Zusammenfassung wie das Lieferanten-/Preissystem aufgebaut ist:
- Jedes Bauteil kann 0+ Einkaufsinformationen ("Orderdetails") enthalten
- Jede Einkaufsinformation enthält genau einen Lieferanten, eine
Bestellnummer (kann auch leer sein) und 0+ Preisinformationen
("Pricedetails")
- Alle Einkaufsinformationen eines Bauteiles haben unterschiedliche
Lieferanten (pro Lieferant maximal eine Einkaufsinformation)
- Hat eine Einkaufsinformation mindestens eine Preisinformation, so muss
mindestens bei einer davon "min_discount_quantity = 1" sein
@K.J.
Wegen dem überarbeiteten Preissystem ist wieder eine Änderung der
Datenbank nötig. Da es etwas "tiefergreifende" Änderungen sind, habe ich
nicht einen neuen Updateschritt ("case") hinzugefügt, sondern das Update
von v12 auf v13 entsprechend angepasst (ist sauberer so). Das bedeutet
dann aber, dass man bei der Online Demo wiedermal eine 12er Datenbank
einspielen müsste.
Übrigens habe ich in die "config_defaults.php" die zwei neuen Variablen
$config['db']['backup']['name'] und $config['db']['backup']['url']
eingefügt, welche man z.B. für MySQLDumper verwenden kann. Kopiert man
die entsprechenden beiden Zeilen in die config.php und gibt eine URL für
MySQLDUmper ein, wird im Menü von Part-DB direkt ein Link zu MySQLDumper
angezeigt.
Ah ja, wo wir grad beim Menü sind, für was war das Update r566 gedacht?
:-) Jetzt erscheint die Doku als Untermenü von "Zu bestellende Teile"?!
xD
mfg
Urban B. schrieb:> Ah ja, wo wir grad beim Menü sind, für was war das Update r566 gedacht?> :-) Jetzt erscheint die Doku als Untermenü von "Zu bestellende Teile"?!> xD
Ups, habe nichts gesagt...Habs zu wenig genau angeschaut, da ist mir
nicht aufgefallen dass mit der Revision 566 der Fehler aus der Revision
565 behoben wurde ;-)
mfg
Da ja die Umstellung auf Templates dank Urban fast fertig ist, wäre es
vielleicht sinnvoll, die Templates mehrsprachig auszuführen? Mir schwebt
eine Ergänzung der class.HTML.php in der Art vor, das man beim Setzen
einer Template-Variable prüft, ob es ein String ist und ob dafür eine
Übersetzung existiert. Statische Texte werden natürlich auch
berücksichtigt. Basis ist dabei die Variable $config['language'].
@Urban weist du ungefähr nen datum wo die 12er DB mal in der normalen
PartDB Aktuell war ? Die DBs die ich rumliegen habe gehen alle nicht,
sonst müste ich dummerweise stundenlang DB Backups ausprobieren um ne
passende zu finden ;-(
Udo Neist schrieb:> Da ja die Umstellung auf Templates dank Urban fast fertig ist, wäre es> vielleicht sinnvoll, die Templates mehrsprachig auszuführen?
Ich finde dafür ist es noch zu früh. Ein Uploadmanager wäre momentan
viel wichtiger, denn ohne den funktioniert das neue Konzept mit den
Dateianhängen nicht wirklich gescheit.
K. J. schrieb:> @Urban weist du ungefähr nen datum wo die 12er DB mal in der normalen> PartDB Aktuell war ? Die DBs die ich rumliegen habe gehen alle nicht,> sonst müste ich dummerweise stundenlang DB Backups ausprobieren um ne> passende zu finden ;-(
Naja, die aktuellste Version aus dem SVN Trunk hat die Version 12, mit
so einer müsste es gehen. Ich habe mal eine solche Datenbank hier
angehängt, bei mir funktioniert diese einwandfrei.
mfg
Ah, jetzt scheint die Demo zu funktionieren, super!
Ich habe mal dem Bauteil "GS 14P" in der Kategorie "IC-Sockel" ein paar
Einkaufsinformationen und Preise hinzugefügt, damit man die
Möglichkeiten des neuen Preissystems sehen kann:
http://partdb.grautier.com/uneistkami89/show_part_info.php?pid=247
Was meint iht dazu? Verbesserungsvorschläge? Klar, das Bearbeiten dieser
Einkaufsinformationen könnte man grafisch sicher noch etwas
ansprechender gestalten. Falls jemand mal nicht weiss was er mit seiner
Zeit machen will... :-D
Bei der Berechnung des Durchschnittspreises ist glaub noch ein Fehler in
der Datenbankabfrage, also nicht wundern wenns mal nicht stimmt... ;-)
mfg
@K.J.
Hmm irgend etwas stimmt aber mit der Datenbank der Demo immernoch
nicht... Kann es sein dass es in der Tabelle "parts" noch eine Spalte
"id_supplier" gibt? Eigentlich hätte die beim Update von v12 auf v13
gelöscht werden müssen, aber ich habe in der online Demo einen Fehler
entdeckt der darauf hinweist, dass es diese Spalte noch gibt in der
Tabelle "parts".
Könnte es vielleicht sein dass der Benutzer einfach zu wenige Rechte
hat, z.B. um eine Tabellenspalte zu löschen?
@Udo Neist
Ich hänge gerade an einem "Problem" mit den Templates. Und zwar bin ich
die Erzeugung der Tabellen am umgestalten, um sie universell einsetzen
zu können (in der vlib_table.tmpl sollen die Tabellen für
show_category_parts.php, show_device_parts.php, show_order_parts.php
usw. generiert werden, aber halt mit unterschiedlichen Tabellenspalten.)
Das ist ansich eigentlich noch kein Problem. Aber sobald auf der
gleichen Seite mehrere Tabellen gbraucht werden, funktioniert das nicht
mehr so, weil der Name des Loops ja in der vlib_table.tmpl "hardgecoded"
ist, man aber mehrere verschiedene solche Loops brauchen würde. z.B. für
die Suchfunktion wäre es notwendig, damit man für jede Kategorie eine
separate Tabelle zeichen kann. Oder in der show_device_parts.php werden
auch zwei Tabellen gezeichnet wenn man nach einem Bauteil gesucht hat
("Teile per Name zuordnen") und die Suchergebnisse aufgelistet werden.
Als erstes kam ich auf die Idee, einfach die erste und die letzte Zeile
von vlib_table.tmpl in die aufrufende *.tmpl Datei auszulagern, um den
Loops verschiedene Namen geben zu können. In diesen Dateien hätte dann
der Aufruf etwa so ausgesehen:
1
<div class="outer">
2
<h2>Teile in der Kategorie "{TMPL_VAR NAME="category_name"}"</h2>
3
<div class="inner">
4
<table>
5
{TMPL_LOOP NAME="table"}
6
{TMPL_INCLUDE FILE="../vlib_table.tmpl"}
7
{/TMPL_LOOP}
8
</table>
9
</div>
10
</div>
Leider scheint das so nicht zu funktionieren (Include in einem Loop
drin)...
Verstehst du was ich meine?
Hättest du eine Idee wie man das bewerkstelligen könnte?
mfg
Möglichkeit 1: Lad das Template als String, ersetze den Namen des Loops
und füttere den String an vlibTemplate. Man muss nicht unbedingt eine
Datei übergeben.
Möglichkeit 2: Mach doch einfach einen
TMPL_IF/TMPL_ELSEIF/TMPL_ELSE-Konstruktion daraus.
Grüße
Udo
Urban B. schrieb:> @K.J.> Hmm irgend etwas stimmt aber mit der Datenbank der Demo immernoch> nicht... Kann es sein dass es in der Tabelle "parts" noch eine Spalte> "id_supplier" gibt? Eigentlich hätte die beim Update von v12 auf v13> gelöscht werden müssen, aber ich habe in der online Demo einen Fehler> entdeckt der darauf hinweist, dass es diese Spalte noch gibt in der> Tabelle "parts".> Könnte es vielleicht sein dass der Benutzer einfach zu wenige Rechte> hat, z.B. um eine Tabellenspalte zu löschen?>
Jup stimmt ich werde das alles mal Manuell machen müssen wollte meine
Daten in der DB lassen, aber das geht nicht weil das wohl irgendeine
Buggy DB aus irgendeiner ... Version ist ;-)
Sorry, ich war hier einige Wochen nicht mehr aktiv. Bevor ich nun alle
Threads der letzten Wochen lese, kann mir jemand sagen wie weit die
Benutzerverwaltung ist (für myparts.info) ?
Apropos, anscheinend wird myparts.info nicht wirklich benutzt. Sollte
das an verloren gegangenen Zugangsdaten usw. liegen, dann lasst es mich
wissen.
Für alle die mit "myparts.info" nichts anfangen können, hier ist eine
kurze Erklärung:
Ich habe die Domain myparts.info registriert, um damit jeden User die
Möglichkeit zu geben Part-DB zu nutzen (selbstverständlich kostenlos).
Derzeit ist man einem Webspace abhängig.
Der eigentliche Vorteil von myparts.info ist jedoch der, dass man nicht
alle Daten immer wieder von neuem eingeben muss, sondern dass man von
den Daten der anderen Benutzer profitiert. Wenn z.B. Conrad den Preis
für ein Bauteil anpasst und ein User diesen aktualisiert sehen alle User
den aktuellen Preis. Das gleiche gilt für die Gehäuseformen,
Datenblätter, usw.
...und falls einer der Entwickler es nicht mitbekommen haben sollte. Ich
stelle jedem Entwickler Webspace und Datenbank zur Verfügung, welche zu
Test- und Präsentations-Zwecken genutzt werden können (oder auch für
anderes, wie FTP, usw.). Einfach eine PN an mich dann richte ich euch
einen Account auf myparts.info ein.
Die Benutzerverwaltung ist, wenn überhaupt, nur ziemlich rudimentär
vorhanden. Erstmal macht Urban die Umsetzung auf OOP fertig, bevor wir
dann die Benutzerverwaltung integrieren. Ziel ist es, eine
funktionsgleiche oder leicht erweiterte Version 0.3.0 als neue stabile
Version zu veröffentlichen.
Udo Neist schrieb:> Möglichkeit 1: Lad das Template als String, ersetze den Namen des Loops> und füttere den String an vlibTemplate. Man muss nicht unbedingt eine> Datei übergeben.
Das kann ich aber ja nicht innerhalb einer *.tmpl Datei machen, kann
dann also auch nicht mehrere Tabellen innerhalb einer Template-Datei
haben.
> Möglichkeit 2: Mach doch einfach einen> TMPL_IF/TMPL_ELSEIF/TMPL_ELSE-Konstruktion daraus.
Hmm ich verstehe nicht, wie ich dann mehrere Tabellen in einer
Template-Datei verwenden kann?
Ich habe es jetzt aber mal so gelöst, dass die Template-Dateien
aufgeteilt werden. Pro Template-Datei ist dann zwar immernoch nur
maximal eine Tabelle möglich, aber wenn mehrere Tabellen auf der
gleichen Seite benötigt werden kann dann einfach die jeweilige
Template-Datei mehrmals ausgegeben werden, halt jedesmal mit einem
anderen Loop für die Tabelle. Ich vermute mal damit können wir leben...
K. J. schrieb:> Jup stimmt ich werde das alles mal Manuell machen müssen wollte meine> Daten in der DB lassen, aber das geht nicht weil das wohl irgendeine> Buggy DB aus irgendeiner ... Version ist ;-)
Habe vorher grad noch gemerkt dass meine Datenbank, die ich hier
gepostet habe, auch noch einen Bug enthält. Ein paar Teile haben nämlich
einen Footprint zugeordnet, der gar nicht existiert. Kommt wohl daher
dass es mal diese "gefährlichen" Checkboxen bei den Footprints gab, mit
denen man ruck zuck ein paar Footprints löschen konnte xD Jetzt mit den
Klassen fällt das auf, da die Klassen eine Exception werfen wenn so ein
Fall eintritt...(was auch so gewollt ist)
@Christian R.
Wie Udo schon geschrieben hat wird erstmal der gesamte Code auf OOP
umprogrammiert, und das dauert eben seine Zeit. Klingt relativ
unspektakulär, aber mal in Zahlen ausgedrückt sind das ca. 8'000 (!)
Codezeilen, die bisher neu geschrieben wurden.
Die Benutzerverwaltung existiert momentan nur so als "Dummy", also als
eine Klasse die noch nichts macht. Einfach so als Vorbereitung, damit
der spätere Ausbau dann einfacher wird. Die Version 0.3.0 wird wohl noch
gänzlich ohne Benutzerverwaltung daherkommen.
Was aber bereits kommen wird, ist ein komplett neues Preissystem :-)
Siehe Online-Demo -> Kategorie "IC-Sockel" -> Bauteil "GS 14P"
mfg
Urban B. schrieb:>> Möglichkeit 2: Mach doch einfach einen>> TMPL_IF/TMPL_ELSEIF/TMPL_ELSE-Konstruktion daraus.>> Hmm ich verstehe nicht, wie ich dann mehrere Tabellen in einer> Template-Datei verwenden kann?
Mal kurz in Pseudocode geschrieben:
if loop3 then
table-konstrukt 3
else if loop 2 then
table-konstrukt 2
else if loop 1 then
table-konstrukt 1
end if
Also man geht von der größten zur kleinsten Tabelle rückwärts.
> Ich habe es jetzt aber mal so gelöst, dass die Template-Dateien> aufgeteilt werden. Pro Template-Datei ist dann zwar immernoch nur> maximal eine Tabelle möglich, aber wenn mehrere Tabellen auf der> gleichen Seite benötigt werden kann dann einfach die jeweilige> Template-Datei mehrmals ausgegeben werden, halt jedesmal mit einem> anderen Loop für die Tabelle. Ich vermute mal damit können wir leben...
Ist die bessere Alternative :-) Auf die Mehrfachnutzung könnte man
eventuell noch mit einem (HTML-)Kommentar im Template hinweisen, damit
man nicht gleich in andere Fehler rennt.
Grüße
Udo
Udo Neist schrieb:> Mal kurz in Pseudocode geschrieben:>> if loop3 then> table-konstrukt 3> else if loop 2 then> table-konstrukt 2> else if loop 1 then> table-konstrukt 1> end if
Wenn die drei table-konstrukte alle dieselben sind, funktioniert das
aber nicht, da der Name des Loops ja dort drin hardgecodet ist. Und
falls es drei verschiedene Konstrukte sind, dann wars das mit den
Flexiblen Tabellen :-)
Aber das hat sich jetzt ja eigentlich erledigt, ich glaub das passt so
wie ich es jetzt gemacht habe (z.B. für show_device_parts.php oder
show_search_parts.php).
Übrigens, er Upload-Manager bereitet mir immernoch Kopfschmerzen :-)
Falls du Zeit und Lust hast, wäre ich echt froh wenn du dich um diesen
kümmern könntest. Klar - es hat noch Zeit, der Rest ist auch noch nicht
so schnell fertig. Aber so langsam sollte man schon mal mit dem Teil
anfangen...
Greez
Udo Neist schrieb:> Gut, dann werde ich mal nach dem Uploader schauen :-)
OK super! :-)
Ein paar Infos dazu gibt es ja in unseren Issues auf Google Code (wobei
nicht jeder dort aufgeführten Punkte zwingend berücksichtigt werden
muss, nicht alles ist sinnvoll^^)
Urban B. schrieb:> wobei> nicht jeder dort aufgeführten Punkte zwingend berücksichtigt werden> muss
Jepp. Lieber erstmal etwas rudimentärer. Je eher das Templatesystem in
den Hauptzweig (trunk) kommt, um so eher kann ich mich wieder ad der
Entwicklung beteiligen ;-)
Grüße
b.r
Urban B. schrieb:> Udo Neist schrieb:>> Gut, dann werde ich mal nach dem Uploader schauen :-)>> OK super! :-)>> Ein paar Infos dazu gibt es ja in unseren Issues auf Google Code (wobei> nicht jeder dort aufgeführten Punkte zwingend berücksichtigt werden> muss, nicht alles ist sinnvoll^^)
Es ist zwar nicht das beste Demoscript, aber man kann damit mehrere
Files quasi parallel hochladen (asynchron per XMLHttpRequest). Firefox
soll wohl dabei um 100 Dateien schaffen.
Das Script selbst besteht neben dem obligatorischen Javascript noch aus
einer PHP-Klasse, die die Verabeitung der geschickten Dateien übernimmt.
Von der Idee her, soll beim Upload entweder ein generelles
Zielverzeichnis genutzt werden oder die Dateien werden in Abhängigkeit
des Mime-Typs in verschiedene einsortiert.
http://weinbauer73.myparts.info/ajax/ajax.phphttp://weinbauer73.myparts.info/file-uploader.tar.gz
PS: Leider sind auf myparts.info die Funktionen is_dir() und
is_writeable() nicht nutzbar, obwohl es aus logischen und
sicherheitstechnischen Gründen sinnvoll wäre.
Ich habe den File-Uploader umgeschrieben. Die Verzeichnisrechte werden
jetzt direkt per fileperms() ermittelt. Die (optionalen)
Zielverzeichnisse werden direkt über ein Array mit Mimetyp =>
Verzeichnis bestimmt und liegen unterhalb des in ajax->UploadDir
gespeicherten Verzeichnisses.
Der Aufruf lautet jetzt http://weinbauer73.myparts.info/ajax/index.php,
da ajax.php nur noch die Verabeitung übernimmt. Das Archiv habe ich
upgedatet.
Hmm warum heisst die Klasse eigentlich "ajax"? Das hat irgendwie ja so
gut wie nichts mit dem Uploader zu tun ;-)
Und dann bin ich mir nicht sicher ob du mich richtig verstanden hast,
deshalb eine kurze Zusammenfassung:
Der Uploadmanager soll nicht nur Dateien hochladen können, sondern man
soll auch die Dateien, die sich bereits auf dem Server befinden,
durchsuchen ("browsen"), umbenennen, löschen und verschieben können.
Halt alles was man auch mit lokalen Dateien machen kann. Und man soll
z.B. für Dateianhänge von Teilen auch Dateien auswählen können, die sich
bereits auf dem Server befinden (also ohne eine Datei hochladen zu
müssen).
Vielleicht wäre "Dateimanager" (bzw. "Filemanager") ein geeigneter Name
für das "Ding". "Uploadmanager" bringt irgendwie nicht so richtig die
Möglichkeiten dieses Dinges zur Geltung... :-)
Beispiel:
Ich lege das Bauteil ATMega8-16PU an. Dann klicke ich auf "Dateianhang
hinzufügen" (o.ä.), und es öffnet sich der Manager. Da das Datenblatt,
das ich anhängen will, noch nicht auf dem Server existiert, wähle ich im
Manager das Zielverzeichnis, die hochzuladene Datei (lokaler Dateiname
od. Internet-URL) und lasse die Datei hochladen. Dann markiere ich sie
und klicke auf "OK". Nun wird das Datenblatt zum ATMega8-16PU
hinzugefügt.
Dann lege ich das Bauteil ATMega8-16AU an, das natürlich genau das selbe
Datenblatt besitzt wie die DIP-Version. Ich klicke also wieder auf
"Dateianhang hinzufügen". Im nun eingeblendeten Manager suche ich nun
einfach nach dem bereits existierenden Datenblatt für den Mega8, wähle
es aus und klicke auf "OK".
Dateien, die hochgeladen werden, dürfen nur im Unterverzeichnis "media/"
gespeichert werden. Um Dateien auszuwählen, muss aber auch das
Verzeichnis "img/" zur Verfügung stehen, um z.B. einem Footprint ein
Bild aus "/img/footprints/" zuweisen zu können.
Ein Vorschlag, wie der Dialog ungefähr aussehen könnte, habe ich hier
mal gepostet: Beitrag "Re: PART-DB RW 1.2"
mfg
Ajax ist ne Abkürzung für "Asynchronous JavaScript and XML", daher der
Name.
Wikipedia: Es bezeichnet ein Konzept der asynchronen Datenübertragung
zwischen einem Browser und dem Server. Dieses ermöglicht es,
HTTP-Anfragen durchzuführen, während eine HTML-Seite angezeigt wird, und
die Seite zu verändern, ohne sie komplett neu zu laden.
Zum Script: Im Moment ist es ein reiner Uploader. Um Dateien
manipulieren zu können, müsste ich nur ein paar grundlegende Funktionen
wie Copy, Move, Delete und Rename sowie ein Dateiauswahlfeld hinzufügen.
Bis auf den Dateiexplorer (also das Dateiauswahlfeld) ist das andere
recht schnell erledigt. Bei den Klassen werde ich allerdings Ajax (hier
XMLHttpRequest) als eigenständige Klasse belassen und den Rest in eine
andere einbauen.
Warum Ajax? Das ganze muss mehr oder weniger asynchron ablaufen, sonst
wäre das ganze ziemlich aufwendig oder langsam.
Udo Neist schrieb:> Ajax ist ne Abkürzung für "Asynchronous JavaScript and XML", daher der> Name.
Jo, das ist schon klar, aber wenn ich mir die Klasse so anschaue, fällt
mir auf, dass in jedem Methodennamen das Wort "Upload" vorkommt. Die
ganze Klasse scheint also für den Upload von Dateien zuständig zu sein.
Ob das nun mit Ajax oder mit sonstwas geschieht, ist Nebensache. Ein
Klassenname soll schliesslich die Funktion der Klasse repräsentieren,
und nicht die Art und Weise, wie sie funktioniert.
Ausserdem ist das eigentliche Ajax ja viel mehr in der *.js Datei.
Das ganze ist in zwei Tagen im Büro neben der Arbeit entstanden und
hatte erstmal den reinen Upload zum Ziel. Zudem hab ich in den Issues
nur was von Upload-Manager gelesen. Alles andere kommt noch :)
Udo Neist schrieb:> Das ganze ist in zwei Tagen im Büro neben der Arbeit entstanden und> hatte erstmal den reinen Upload zum Ziel. Zudem hab ich in den Issues> nur was von Upload-Manager gelesen. Alles andere kommt noch :)
OK alles klar :-)
Ich wusste nicht so richtig wie ich deine letzten Posts einordnen soll
(Man hätte es z.B. so interpretieren können, als wäre der Uploadmanager
deiner Meinung nach schon fast fertig :-)
Daher wollte ich nochmal nachfragen, nicht dass wir uns irgendwie total
falsch verstanden haben.
Aber jetzt ist das ja geklärt, alles in Ordnung xD
mfg
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
Hallo,
Also eine (teilweise veraltete) Anleitung gibt es hier:
http://www.mikrocontroller.net/articles/Part-DB_RW_-_Lagerverwaltung
Eine etwas aktuellere Anleitung gibt es im Archiv der v0.2.2 in der
Datei /readme/INSTALL.txt.
Wo liegt denn genau dein Problem, wo kommst du nicht weiter?
Welches Betriebssystem setzt du ein?
Falls du Part-DB auf einem normalen Windows Rechner laufen lassen
willst, empfiehlt es sich eine virtuelle Maschine zu installieren (z.B.
VirtualBox mit einem virtuellen Ubuntu). Dort setzt du einen Webserver
auf, kopierst das Archiv von Part-DB nach /var/www/, legst z.B. mit
PHPMyAdmin eine Datenbank und ein Benutzer an und passt die Datei
config.php von Part-DB an.
Wenn Probleme auftauchen, dann teile uns dein exaktes Problem mit, dann
können wir auch konkrete Antworten geben.
mfg
Ich habe vor längerem ein einfaches Installationsscript zur Einrichtung
der Datenbank geschrieben, das per Shell ausgeführt werden muss.
http://code.google.com/p/part-db/source/browse/branches/uneist/install.shhttp://code.google.com/p/part-db/source/browse/branches/uneist/readme/createtables-FOR-V0.2.1-rev12.sql
Das Script liegt dabei im Root-Verzeichnis von Part-DB, der SQL-Dump im
Verzeichnis readme. Das Script fragt ein paar Variablen ab, bevor es
die Datenbank erstellt. Es erzeugt eine config_db.php, deren Inhalt in
die config.php übernommen werden muss. Sollte das Script als Root
ausgeführt werden, so werden auch die Verzeichnisse backup und
update (ist in der stable-Version nicht vorhanden) auf den Apache-User
gesetzt.
Getestet unter openSUSE 11.2 und höher.
Wenn es gewünscht wird, kann ich das Script auch für die stable-Version
umschreiben. Dann könnte man auch die Install.txt endlich aktualisieren.
Urban B. schrieb:> Dort setzt du einen Webserver auf, kopierst das Archiv von Part-DB nach> /var/www/
Nicht jedes Linux nutzt /var/www. Nach FHS wäre /srv/www (nutzt z.B.
openSUSE) der bessere Ort dafür. Das richtige Zielverzeichnis kann man
in der Konfiguration des jeweiligen Webservers nachschauen. Einfach nach
"DocumentRoot" schauen :-)
Udo Neist schrieb:> Urban B. schrieb:>> Dort setzt du einen Webserver auf, kopierst das Archiv von Part-DB nach>> /var/www/>> Nicht jedes Linux nutzt /var/www.
Jo ich weiss, war auch auf den Vorschlag "Ubuntu" bezogen. Ist aber
nicht richtig klar wenn man es liest, da hast du recht :-)
mfg
Hallo
Ich habe die Part-db mal Testweise auf einem Xampp installiert und die
Footprints hineinkopiert. Leider kann ich bei neu erstellen Bauteilen
erst die Footprints auswählen wenn ich bei den Footprints die Checkbox
aktiviere.
Gibs da ein Script oder ist das ein Bug? Ich habe nich Lust mehrer
hundert Checkboxen anzuklicken ;-)
Gruß Christoph
Hast du auch das Update der Datenbank durchgeführt? Damit sollten die
Infos zu den Footprints eingespielt werden. Die SQL-Datei zur
Installation enthält nur die Struktur und die Versionsnummer.
Christoph B. schrieb:> Hallo>> Ich habe die Part-db mal Testweise auf einem Xampp installiert und die> Footprints hineinkopiert. Leider kann ich bei neu erstellen Bauteilen> erst die Footprints auswählen wenn ich bei den Footprints die Checkbox> aktiviere.>> Gibs da ein Script oder ist das ein Bug? Ich habe nich Lust mehrer> hundert Checkboxen anzuklicken ;-)>> Gruß Christoph
Das ist kein Bug, sondern ein Feature :-)
Es stehen nur diejenigen Footprints zur Auswahl, die man auch selber
hinzugefügt hat (unter Bearbeiten -> Footprints, oder mit den Checkboxen
die du ja schon gefunden hast).
Der Grund dafür ist, dass die meisten Leute ein eher kleines Sortiment,
mit vielleicht so 50 verschiedenen Footprints haben. Würden alle
vorhandenen Footprints automatisch zur Verfügung stehen, wären die ca.
1700 Footprints extrem unübersichtlich.
Ausserdem ist vielen nicht klar, dass die Footprint-Bilder von den
Footprints ansich unabhängig sind. Man kann auch Footprints anlegen, die
kein Bild haben! Die Bilder sind also quasi nur optional.
Von mir aus könnten wir mal ein "Standardpaket" von Footprints bereits
in die Installation integrieren, dass zumindest die gebräuchligsten
Footprints bereits im System drin sind...
mfg
danke für die Antwort
Gibt es einen einfacher Weg als die 1700 Footprints von Hand einzeln
hinzuzufügen?
Wenn ich z.B eine Diode hinzufüge muss ich immer erst in
Tools/Footprints den Haken setzen bevor er der Footprint unter
Bearbeiten/Footprints zur Verfügung steht.
Christoph B. schrieb:> Gibt es einen einfacher Weg als die 1700 Footprints von Hand einzeln> hinzuzufügen?
Bisher nicht. Aber ich frage mich, wozu man alle 1700 Footprints
wirklich im System haben will, das wird doch nur extrem unübersichtlich?
Und ein sehr grosser Teil von den Bildern sind eh nur Steckverbinder,
die kaum einer jemals gekauft hat...
Christoph B. schrieb:> Wenn ich z.B eine Diode hinzufüge muss ich immer erst in> Tools/Footprints den Haken setzen bevor er der Footprint unter> Bearbeiten/Footprints zur Verfügung steht.
Dazu gibt es doch extra das Eingabefeld "Direkteingabe/Neu". Da kann man
direkt beim Anlegen eines neuen Bauteiles auch gleich noch einen neuen
Footprint anlegen, ohne den Umweg über Bearbeiten -> Footprints.
mfg
Habe nun alles getestet und mir sind 2 Sachen aufgefallen die man
vieleicht verbessern könnte.
Beim Hinzufügen von Bauteilen aktiviere ich die Checkbox "Weitere
Bauteile erfassen:"
In der neuen Eingabenmaske bleibt der Lagerstand stehen doch der Name
wird automatisch um 1 Hinaufgezählt. So wird beim nächsten Bauteil aus
75 Ohm --> 75 Ohn.
Des weiteren wäres es vieleicht noch fein dann auch noch der Footprint
und der Lagerort automatisch vom vorigen Bauteil übernommer wird.
Gruß Christoph
Hallo Christoph,
All deine genannten Sachen sind in der aktuellen SVN-Version bereits
umgesetzt. Um diese Version zu installieren benötigst du einen SVN
(Subversion) Client. Die Download-URL (bzw. den ganzen Befehl) findest
du hier: https://code.google.com/p/part-db/source/checkout
Falls du (wie [verständlicherweise] einige Andere auch) nicht verstehst
wie man es installiert kriegt, such mal im Internet nach Anleitungen, da
solltest du fündig werden.
Falls du konkrete Fragen dazu hast, frag einfach hier nach. Aber eine
komplette Anleitung für SVN werde ich nicht schreiben ;-)
mfg
@Christoph
Und, hat's geklappt mit der Installation der aktuellen SVN-Revision?
@all
Ich überlege gerade ob es das Attribut "obsolete" für die Bauteile
überhaupt noch braucht. Zuerst dachte ich, wir sollten es einfach vom
Bauteil "ablösen" und in die Einkaufsinformationen (Klasse
"Orderdetails") verschieben, da dieses Attribut ja immer auf einen
bestimmten Artikel eines Lieferantes bezogen ist, und nicht auf das
Bauteil ansich.
Dann kam ich aber auf die Idee, dass man bei einem nicht mehr
erhältlichen Bauteil einfach die entsprechenden Einkaufsinformationen
löschen könnte. Ein Bauteil würde dann als "obsolete" gelten, sobald es
keine einzige Einkaufinformation mehr gibt zu diesem Teil.
Einziger Nachteil wäre dann halt, dass die Bestellnummern und die Preise
auch gelöscht werden, und somit später nicht mehr vorhanden sind falls
man sie mal noch brauchen könnte.
Ich würde jetzt sagen, dieser Nachteil ist ziemlich irrelevant, und
diese Lösung daher vorzuziehen. Ich würde aber trotzdem gerne mal eure
Meinung dazu hören.
Also, was meint ihr, wie soll das Attribut "obsolete" gehandhabt werden?
mfg
P.S. @K.J.
Ich werde heute noch eine neue Version in unseren Branch hochladen.
Wegen Änderungen am Datenbankupdate v12 -> v13 müsste wieder eine
Datenbank der Version 12 geladen werden, sonst gibts hübsche
Fehlermeldungen :-)
Ach ja, warum ist in der Online-Demo eigentlich der Menüeintrag "System"
wieder verschwunden? :-)
Urban B. schrieb:> P.S. @K.J.> Ich werde heute noch eine neue Version in unseren Branch hochladen.> Wegen Änderungen am Datenbankupdate v12 -> v13 müsste wieder eine> Datenbank der Version 12 geladen werden, sonst gibts hübsche> Fehlermeldungen :-)>> Ach ja, warum ist in der Online-Demo eigentlich der Menüeintrag "System"> wieder verschwunden? :-)
Ah ka. hatte gestern die DB gefixt aber an der config war ich nicht bei,
mal schauen, jo ich werde da mal ne saubere DB einspielen und einfach
nur einige Testeinträge machen.
Christoph B. schrieb:> Hallo>> Ich habe nun die Version 0.2.2 am Laufen, da mir die Beta zu unsicher> ist. Will nicht nochmals mehrere 100 Bautteile eintragen ;-)
Okay, aber die Bauteile müsstest du natürlich nicht nochmals eintragen,
deine Datenbank mit allen Bauteilen usw. wird übernommen (wobei ein
Backup vor der Installation sicher trotzdem angebracht ist, da die
Datenbankstruktur aktualisiert wird und ein "Downgrade" nicht mehr
möglich ist).
Und unsicher würde ich die momentane SVN-Revision nicht nennen, es sind
eigentlich keine gröberen Bugs bekannt.
Aber wenn du mit der stabilen 0.2.2 zufrieden bist, spricht natürlich
nichts dagegen, bei dieser zu bleiben.
mfg
K. J. schrieb:> Ah ka. hatte gestern die DB gefixt aber an der config war ich nicht bei,> mal schauen, jo ich werde da mal ne saubere DB einspielen und einfach> nur einige Testeinträge machen.
Gibts denn jetzt mit deiner 12er Datenbank immernoch Probleme? In der
Demo scheint jetzt eigentlich alles zu funktionieren habe ich das
Gefühl, ich konnte jedenfalls keinen Datenbankfehler mehr finden.
Übrigens habe ich im 0.3.0-Branch eine Datenbank der Version 12
abgelegt, diese könntest du natürlich auch für die Online-Demo
verwenden, die sollte problemlos laufen und hat auch ein paar hübsche
Baugruppen wo man ein bisschen was sehen kann :-)
Sie befindet sich hier:
https://part-db.googlecode.com/svn/branches/uneist_kami89/development/testfiles/database/v12_kami89.sql
mfg
Urban B. schrieb:> In der> Demo scheint jetzt eigentlich alles zu funktionieren habe ich das> Gefühl, ich konnte jedenfalls keinen Datenbankfehler mehr finden.
OK hab nichts gesagt, beim Erfassen von neuen Bauteilen gibts einen
Fehler weil vermutlich eine Datenbankspalte fehlt...
Übrigens habe ich jetzt (r581) noch etwas geändert, damit bei
Datenbankfehlern eine aussagekräftigere Meldung im Debug-Log erscheint
(die bisherigen Meldungen waren nicht sehr aussagekräftig). Falls es
beim Datenbankupdate zu Problemen kommen sollte, würde man nun
vielleicht im Debug-Log noch weitere Hinweise auf die Fehlerursache
finden.
Und den Menüeintrag "System" habe ich in der Online Demo wieder
aktiviert, vermutlich hat einfach jemand an der Konfiguration
rumgespielt und diesen Eintrag deaktiviert. Ich werde wohl noch eine
Sicherung einbauen dass man dies bei der Online Demo nicht deaktivieren
kann.
K. J. schrieb:> Ok ist gefixt
Wunderbar, funktioniert :-)
Urban B. schrieb:> Also, was meint ihr, wie soll das Attribut "obsolete" gehandhabt werden?
Will sich dazu keiner äussern? :-)
Ausserdem habe ich gleich noch eine andere Frage. Ich bin nämlich grad
an der Importfunktion dran, und da frage ich mich, ob der Import von
bestehenden Bauteilen in bestehende Baugruppen überhaupt Sinn macht.
Man muss dazu ja bereits alle IDs der Bauteile kennen, was aber nicht
der Fall ist, wenn man bisher seine Baugruppen in Excel o.ä. verwaltet
hat. Für diesen Fall ist also diese Importfunktion sowieso nicht zu
gebrauchen.
Ich wüsste nicht, wofür dann diese Importfunktion zu gebrauchen wäre.
Hat jemand von euch einen guten Grund, warum wir diese Funktion nicht
einfach rauswerfen sollen?
Der Import von Bauteilen würde natürlich weiterhin bestehen bleiben,
dort ist der Sinn relativ einfach zu erkennen xD
mfg
Na, will sich denn keiner äussern? :-D
Die Baugruppen-Importfunktion fliegt einfach raus wenn niemand weiss
wozu man die gebrauchen kann ;-)
Bezüglich "obsolete" Attribut kann ich mich nicht entscheiden wie ich es
machen soll, mir persönlich ist es relativ egal wie es gemacht wird.
Daher wäre ich froh mal eure Meinungen zu hören...
mfg
Urban
Urban B. schrieb:> K. J. schrieb:>> Ok ist gefixt>> Wunderbar, funktioniert :-)>> Urban B. schrieb:>> Also, was meint ihr, wie soll das Attribut "obsolete" gehandhabt werden?>> Will sich dazu keiner äussern? :-)>
Könnte ich jetzt so nicht da ich das nicht nutze.
> Ausserdem habe ich gleich noch eine andere Frage. Ich bin nämlich grad> an der Importfunktion dran, und da frage ich mich, ob der Import von> bestehenden Bauteilen in bestehende Baugruppen überhaupt Sinn macht.>>> Der Import von Bauteilen würde natürlich weiterhin bestehen bleiben,> dort ist der Sinn relativ einfach zu erkennen xD>> mfg
Jup stimme ich dir zu.
> Ausserdem habe ich gleich noch eine andere Frage. Ich bin nämlich grad> an der Importfunktion dran, und da frage ich mich, ob der Import von> bestehenden Bauteilen in bestehende Baugruppen überhaupt Sinn macht.>>> Der Import von Bauteilen würde natürlich weiterhin bestehen bleiben,> dort ist der Sinn relativ einfach zu erkennen xD
Also ich setze bzw. plane die part-db bei uns in der Firma bzw. für mich
als Arbeitsmittel einzusetzen. Ich find die die Baugruppen Import
Funktion schon praktisch. Ich setze als Leiterplatten Tool Eagle und als
BOM Skript das bom-ex ULP ein. Bei dem Skript kann man sich eine
Datenbank mit der Zuordnung von Bauteilen und verschiedenen
Eigenschaften (wie z.B. die part-dB ID) anlegen. Wenn ich dann meine BOM
exportiere kann ich mir eine CSV Datei erzeugen lassen, welche ich in
die part-db importieren kann. Darüber kann man dann Baugruppen erstellen
ohne jedes Teil extra eingeben zu müssen (bei Leiterplatten >100 Teile
macht das doch niemand von Hand, oder?).
Super praktisch wäre natürlich eine Kombination aus Baugruppen und
Bauteil Import. Sprich, wenn Bauteile noch keine part-db ID haben,
werden sie neu angelegt.
Grüße
Thomas
Thomas Kühne schrieb:> Wenn ich dann meine BOM> exportiere kann ich mir eine CSV Datei erzeugen lassen, welche ich in> die part-db importieren kann.
Ah cool, auf die Idee bin ich noch gar nie gekommen :-)
Das ist natürlich ein Argument für die Baugruppen-Importfunktion. Dann
bleibt die also drin ;-)
Danke für diesen Input!
Thomas Kühne schrieb:> Super praktisch wäre natürlich eine Kombination aus Baugruppen und> Bauteil Import. Sprich, wenn Bauteile noch keine part-db ID haben,> werden sie neu angelegt.
Hmm ich denke, das lässt sich einbauen.
Uhu Uhuhu schrieb:> Wo findet man denn das aktuelle Installationspaket?
Kommt drauf an welche Version du meinst. Die letzte stabile Version
0.2.2 gibts hier: https://code.google.com/p/part-db/downloads/list
Eine aktuellere Version (die auch sehr stabil läuft) kann man nur per
SVN Client downloaden, die liegt nämlich im "Trunk":
https://code.google.com/p/part-db/source/browse/trunk
Und die aktuelle Entwicklerversion (zukünftig v0.3.0, noch weit entfernt
von "stabil") gibts hier:
https://code.google.com/p/part-db/source/browse/branches/uneist_kami89
Letztere beide gibts auch als Online-Demo: http://partdb.grautier.com/
Gruss
Urban
Ich habe eine Uraltversion in einer VM laufen, bei der aber mittlerweile
der aufklappbare Kategorienbaum nicht mehr funktioniert.
Deswegen würde ich gerne auf eine aktuelle umstellen. Wie sieht es denn
mit Datenkompatibilität aus?
Uhu Uhuhu schrieb:> Ich habe eine Uraltversion in einer VM laufen, bei der aber mittlerweile> der aufklappbare Kategorienbaum nicht mehr funktioniert.
Hatte ich auch schon, war irgend ein Fehler meinerseits, ich glaube es
waren falsche Dateirechte oder sowas...
Uhu Uhuhu schrieb:> Deswegen würde ich gerne auf eine aktuelle umstellen. Wie sieht es denn> mit Datenkompatibilität aus?
Sollte kein Problem sein, die Datenbankstruktur wird automatisch (bzw.
per Button-Klick) angepasst. Einfach vorher ein Backup der Datenbank
machen, damit man bei einem Fehler auch wieder problemlos "Downgraden"
kann. Ansonsten ist (übrigens auch bei erfolgreichem Update) kein
Downgrade mehr möglich.
mfg
Urban B. schrieb:> Hatte ich auch schon, war irgend ein Fehler meinerseits, ich glaube es> waren falsche Dateirechte oder sowas...
Das kann eigentlich nicht sein, denn das Teil läuft bei mir in einer VM,
die ich - außer über den Browser - schon lange nicht mehr angefaßt habe.
Urban B. schrieb:> Sollte kein Problem sein, die Datenbankstruktur wird automatisch (bzw.> per Button-Klick) angepasst.
So einfach scheint es doch nicht zu sein.
Ich habe das alte part-db-Verzeichnis umbenannt und den Code unter truc
in ein neues part-db-Verzeichnis kopiert und config.php an meine alte DB
angepaßt.
Der Server startet die neue Part-db, der Kategoriebaum wird korrekt
angezeigt, aber das Anzeigen der Daten im rechten Bereich klappt nicht.
Direkt nach dem Start bekomme ich dort nur eine Meldung
Unknown column 'filename' in 'field list'
Wenn ich eine Kategorie anklicke, gibts eine rudimentäre Seite mit
folgender Meldung:
Unknown column 'parts.description' in 'field list'
Sieht also stark danach aus, daß die neue part-db andere Vorstellungen
von der DB hat, als mysql.
Leider finde ich mit grep keine Datei, die den String 'Unknown column'
enthält.
Hmm welche Version hattest du denn vorher installiert?
Im Menü von Part-DB aus dem Trunk sollte es einen Eintrag "Datenbank"
geben, was steht da welche Datenbankversion installiert ist?
Auf dieser Seite solltest du eigentlich auch das Datenbankupdate machen
können falls es nicht schon automatisch gemacht wurde.
Ich bin noch nicht allzu lange hier bei Part-DB, die Versionen vor 0.2.2
habe ich noch nie gesehen, daher kann ich dazu leider nicht viel sagen.
Uhu Uhuhu schrieb:> Leider finde ich mit grep keine Datei, die den String 'Unknown column'> enthält.
Die Fehlermeldung kommt auch nicht von Part-DB selbst, sondern von
MySQL.
Falls du es nicht hinkriegst kannst du mir auch gerne mal die alte
Datenbank per PN schicken, dann kann ich es mir mal anschauen.
mfg
Urban B. schrieb:> Hmm welche Version hattest du denn vorher installiert?
Das war eine Version 0.1, aber theborg ging etwas schlampig mit
führenden Nullen um...
> Im Menü von Part-DB aus dem Trunk sollte es einen Eintrag "Datenbank"> geben, was steht da welche Datenbankversion installiert ist?
Es ist Version 1. Nachdem ich dem user einige zusätzliche Permissions
gegeben hatte, lief der Update glatt durch.
Uhu Uhuhu schrieb:> Das war eine Version 0.1, aber theborg ging etwas schlampig mit> führenden Nullen um...
OK bei so alten Versionen kenne ich mich nicht aus, aber ich schätze mal
das Update sollte trotzdem funktionieren.
Übrigens hat die Version von Part-DB (die Dateien an sich) nichts mit
der Datenbankversion (1 bis 12) zu tun, das kann anfangs etwas verwirren
;-)
Uhu Uhuhu schrieb:> CREATE command denied to user 'part-db'@'localhost' for table 'internal'
Hier ist auch schon der Hund begraben. Der Datenbankbenutzer hat nicht
genügend Rechte um eine neue Tabelle anzulegen. Am besten gibst du (z.B.
per phpMyAdmin) einfach alle Rechte für die entsprechende Datenbank,
dann gibts deswegen sicher nie mehr Probleme.
Nach einem misslungenen Update empfiehlt es sich übrigens, für den
nächsten Versuch wieder die alte Datenbank einzuspielen weil sonst
diverse Befehle mehrfach ausgeführt werden, und so zu neuen Fehlern
führen können.
Heisst also:
- Zuerst die Rechte des Benutzers anpassen
- Wieder die alte Datenbank einspielen (vorher die aktuelle komplett
löschen!!)
- Nochmal das Update starten, dies sollte nun ohne Fehler durchlaufen
mfg
Ja, da fehlten 3 Permissions - die hat er jetzt und der Update auf
Version 2 lief glatt durch. Jetzt fehlen wohl nur noch 10 Updates...
Nein, da wurde nur Version 2 abgezeigt, obwohl er Version 12 hat.
Jetzt scheints zu funktionieren - vielen Dank für die Nachhilfe.
Uhu Uhuhu schrieb:> Ja, da fehlten 3 Permissions - die hat er jetzt und der Update auf> Version 2 lief glatt durch. Jetzt fehlen wohl nur noch 10 Updates...
OK das ist ja schonmal was. Aber jetzt macht er bei den Updates nicht
weiter? Theoretisch sollten alle Updates bis Version 12 in einem Rutsch
durchlaufen.
Gibts Fehlermeldungen o. ä.?
Uhu Uhuhu schrieb:> Jetzt scheints zu funktionieren - vielen Dank für die Nachhilfe.
Ah, schon wieder zu schnell geantwortet^^
Super dass es jetzt auch noch geklappt hat, ich hoffe Part-DB gefällt
dir :-)
Ein alter Fehler ist noch immer drin: Wenn man mehrere Datenblätter
speichert, ist nur eins aus der Teleliste heraus zugreifbar.
Ganz früher wurde für jedes hinterlegte Datenblatt ein Link angezeigt.
Irgend jemand hat das dann rausgeschmissen.
Uhu Uhuhu schrieb:> Ein alter Fehler ist noch immer drin: Wenn man mehrere Datenblätter> speichert, ist nur eins aus der Teleliste heraus zugreifbar.>> Ganz früher wurde für jedes hinterlegte Datenblatt ein Link angezeigt.> Irgend jemand hat das dann rausgeschmissen.
Ist ab der Version 0.3.0 wieder drin, brauchst nur noch ein wenig Geduld
bis die fertig ist :-)
Prima.
In den Quellen ist auch eine Datei open/openlist.php, die eine
Lagerliste erzeugt. Die könnte man unter tools einbinden. Damit sie
funktioniert sind ab Zeile 25 folgende Änderungen nötig:
Hallo zusammen,
Sorry dass sich im Moment nicht viel tut im Entwicklerbranch. Ich habe
momentan leider nicht so viel Zeit zum programmieren, da ich noch an
anderen Projekten arbeite und auch das Studium seine Zeit braucht. Ich
werde aber versuchen wieder ein bisschen an Part-DB weiterzuarbeiten.
@Udo
Wie sieht es mit dem Upload-Manager aus, bist du da weitergekommen?
mfg
Urban
@Urban
Leider nicht, bin auch zeitlich im Beruf ziemlich ausgelastet. Musste
auch noch recht kurzfristig ein anderes Projekt auf die Beine bringen.
Und vor Weihnachten stapelt sich ja auch privat so manches. Sobald ich
wieder Zeit habe, geht es weiter.
Aktuell sind verschiedene Befehle schon implementiert (ein Glück hatte
ich sowas ja schon in meiner Update-Klasse drin), aber es ist noch keine
UI vorhanden.
Okay, dann muss die Version 0.3.0 halt noch etwas länger warten bis sie
fertiggestellt wird...
Im Grossen und Ganzen ist sie aber eigentlich ja schon ziemlich weit,
neben dem Uploadmanager und der Import/Export-Funktionen sind es
mehrheitlich nur noch Kleinigkeiten, die noch gemacht werden müssen.
Wie heisst es gleich nochmal, "Gut Ding will Weile haben"? :-D
Sind die Funktionen unter "Lagerorte umbenennen/löschen/sortieren"
irgendwo beschrieben, insbesondere was die Kästchen "voll" und "noch
Platz" bewirken?
Uhu Uhuhu schrieb:> Sind die Funktionen unter "Lagerorte umbenennen/löschen/sortieren"> irgendwo beschrieben, insbesondere was die Kästchen "voll" und "noch> Platz" bewirken?
Beschrieben sind die nirgens (die Doku ist noch ziemlich bescheiden ;-).
Mit dem Kästchen "voll" kannst du einfach den Lagerort als voll
markieren, damit du siehst dass dort kein Platz mehr ist. Intern hat
dieses Attribut aber keine Funktion, es dient nur zur Kennzeichnung.
Mit dem Kästchen "noch Platz" lässt sich einfach das Kreuz im Kästchen
"voll" wieder entfernen, das ist irgendwie etwas unglücklich gelöst.
Aber wie immer: In Version 0.3.0 wird auch das etwas besser :-)
Danke für die Erläuterung.
Habt ihr schon irgendwas ausgemacht, wie die Doku aussehen soll? Ich
denke, ich kann brauchbare Anleitungen verfassen und würde mich damit am
Projekt beteiligen, wenn das erwünscht ist.
Uhu Uhuhu schrieb:> Danke für die Erläuterung.
Kein Problem :-)
> Habt ihr schon irgendwas ausgemacht, wie die Doku aussehen soll? Ich> denke, ich kann brauchbare Anleitungen verfassen und würde mich damit am> Projekt beteiligen, wenn das erwünscht ist.
Cool, also von meiner Seite wäre das sogar sehr erwünscht, und ich denke
mal da hätte auch sonst niemand was dagegen.
Ich denke, die Doku müsste auf jeden Fall direkt im Browser benutzbar
sein, sonst macht sie nicht viel Sinn. Eine Suchfunktion wäre natürlich
auch nicht schlecht.
Kennst du ein gescheites Tool um solche Hilfeseiten zu erstellen? Oder
besser selber was kleines Bauen?
Urban B. schrieb:> Kennst du ein gescheites Tool um solche Hilfeseiten zu erstellen? Oder> besser selber was kleines Bauen?
Darüber habe ich mir bisher keine Gedanken gemacht. Was mir spontan
einfällt, wäre ein MoinMoin-Wiki, das man parallel zum part-db Server
installiert. Das hätte den Vorteil, daß man es leicht pflegen kann, der
Benutzer es leicht erweitern/anpassen kann und eine Suchfunktion dabei
ist.
Vielleicht könnte man das Wiki ja als Funktion in part-db integrieren.
Auf jeden Fall könnte man auch in die part-db-Seiten Links auf die Hilfe
einbauen.
Es wäre gut, wenn die Online-Hilfe/die Doku auch separat von Part-DB
upgedatet werden könnte, um Fehler darin schneller ausbügeln und zum
"Kunden" zu bringen. So könnte man die Konfiguration zwischen lokaler
oder netzweiter (Intranet oder Internet) Hilfe umschalten.
Uhu Uhuhu schrieb:> Darüber habe ich mir bisher keine Gedanken gemacht. Was mir spontan> einfällt, wäre ein MoinMoin-Wiki, das man parallel zum part-db Server> installiert.
Sieht interessant aus, das kannte ich bisher noch gar nicht. Allerdings
habe ich nach einem ganz kurzen Blick in den Sourcecode das Gefühl, dass
das viel zu viel des Guten ist, also total überdimensioniert für unser
doch relativ kleines Projekt :-)
Ich kenne mich allgemein nicht so mit Wikis o.ä. aus, aber ich vermute
mal, bei solchen Systemen wird der Inhalt (also die selbstgeschriebene
Hilfe) in einer Datenbank abgelegt?
Dann müsste das System auf jeden Fall mit einer SQLite funktionieren,
ansonsten wird das Hochladen eines Updates per SVN "schwierig". Mit
SQLite müsste das ja aber funktionieren...
Ausserdem sollte sich das Hilfesystem ohne Eingriff des Benutzers
installieren lassen wenn man Part-DB installiert. Wäre irgendwie doof
wenn man das Hilfesystem noch selber irgendwie
installieren/konfigurieren müsste.
Uhu Uhuhu schrieb:> Vielleicht könnte man das Wiki ja als Funktion in part-db integrieren.> Auf jeden Fall könnte man auch in die part-db-Seiten Links auf die Hilfe> einbauen.
Jup, so hätte ich mir das auch vorgestellt.
Urban B. schrieb:> Ich kenne mich allgemein nicht so mit Wikis o.ä. aus, aber ich vermute> mal, bei solchen Systemen wird der Inhalt (also die selbstgeschriebene> Hilfe) in einer Datenbank abgelegt?
MoinMoin ist - leider - in Pearl geschrieben, aber damit hat man nichts
zu tun. Die Wikiseiten sind normale Dateien, die den Text in dem Format
enthalten, wie man es im Quelltext-Editor eingibt.
> Allerdings> habe ich nach einem ganz kurzen Blick in den Sourcecode das Gefühl, dass> das viel zu viel des Guten ist, also total überdimensioniert für unser> doch relativ kleines Projekt :-)
Das ist ein Schwäbische-Hausfrau-Argument - das juckt keinen.
Udo Neist schrieb:> Es wäre gut, wenn die Online-Hilfe/die Doku auch separat von Part-DB> upgedatet werden könnte, um Fehler darin schneller ausbügeln und zum> "Kunden" zu bringen.
Das sollte wegen der einfachen Dateistruktur kein größeres Problem sein.
Updates müßten einfach als neue Version importiert werden. Der Anwender
hat dann die Möglichkeit, sich die Änderungen gegenüber seiner letzten
Version anzeigen zu lassen.
Dokuwiki kommt ohne Datenbank aus, nutzt Dateien. Man braucht nur ein
Unterverzeichnis zu packen und entpacken, schon ist die Aktualisierung
der Texte erledigt :-) Ich nutze Dokuwiki für verschiedenste Zwecke,
darunter auch eine Developer-Doku.
Dokuwiki gefällt mir mittlerweile besser, als MoinMoin...
In Tools | Footprints ist ein ziemlich lästiger Fehler:
- Das Laden der Footprintliste dauert seine Zeit - das ist normal
- Unnormal ist, daß die Seite jedesmal neu geladen wird, wenn man
von einem anderen Tab, oder einem anderen Fenster in FF auf die
Footprint-Liste umschaltet.
Der Fehler macht das nachträgliche Suchen von Footprints für bereits
angelegte Teile zur Geduldprobe.
Nachtrag: Das Problem mit der Footprints-Seite liegt daran, daß die
Seite zu groß ist und FF sie neu rendert, wenn der Tab hervorgeholt
wird.
Alles in allem frage ich mich allerdings, welchen praktischen Nutzen
diese Bildchen haben.
Uhu Uhuhu schrieb:> Alles in allem frage ich mich allerdings, welchen praktischen Nutzen> diese Bildchen haben.
Ich finde die Bilder schon praktisch.;-) SO sieht man auf den ersten
Blick welche Bauform man auf Lager hat
Christoph B. schrieb:> SO sieht man auf den ersten Blick welche Bauform man auf Lager hat
Nur ob der Chip jetzt breit- oder schmalbeinig ist, das siehst du nicht
- da bist du mit dem Namen besser bedient...
Seh ich genauso wie Uhu, die Footprint Bilder finde ich eher unwichtig.
Ein weiteres Beispiel dafür sind passive SMD Komponenten, ob das Bild
jetzt 0402 oder 0603 oder so darstellt erkennt man auch nicht wirklich
und muss es ja auch nicht, der Name sagt doch genug. Allerdings stören
die Footprints auch nicht und wer will, muss sie ja nicht
installieren...
Mehr als 6 Wochen mit Audits und Prüfmethodenumstellung sowie der
Weihnachtsstress ist rum. Auf gehts an die Arbeit am Filemanager...
Was soll der Filemanager alles können? Up- und Download ist ja die
wenigste Arbeit, hauptsächlich das UI muss ich machen.
Grüße
Udo
Udo Neist schrieb:> Mehr als 6 Wochen mit Audits und Prüfmethodenumstellung sowie der> Weihnachtsstress ist rum. Auf gehts an die Arbeit am Filemanager...
Cool :-) Bei mir dauerts leider noch ein paar Wochen bis der
Prüfungsstress vorbei ist... :-(
Udo Neist schrieb:> Was soll der Filemanager alles können? Up- und Download ist ja die> wenigste Arbeit, hauptsächlich das UI muss ich machen.
Also wichtig ist sicher mal, dass man per Button auf irgendeiner Seite
den Manager als Popup (schöner wäre natürlich ein schönes
JavaScript-Fenster, das sich einfach über die Seite legt, aber das wäre
nur Kosmetik...) öffnen kann, und beim Schliessen dieses Managers muss
irgendwie der gewählte Dateinamen (besser ein Array mit 0...unendlich
Strings) an die ursprüngliche Seite (mit dem Button) übermittelt werden.
Im Manager selbst muss es die Möglichkeit geben, die Dateien in
"img/footprints/", "img/iclogos/" und "media/" zu durchsuchen, am besten
auch mit Suchfunktion (welche man natürlich auch noch später nachreichen
könnte, da nicht zwingend notwendig). Rudimentäre Dateioperationen wie
Löschen, Verschieben, Kopieren, Ordner anlegen sollten auch möglich
sein, wobei aber nur im Verzeichnis "media/" Schreibrechte vorhanden
sein dürfen, im Ordner "img/" sind nur Dateien, die von Part-DB
bereitgestellt werden, dort darf der User keine Schreibrechte haben.
Dann natürlich die Uploadfunktion. Zielordner (irgenwo in "media/")
wählen, lokale Dateien oder Internet-URL wählen, und Dateien hochladen
lassen. Bei der Angabe einer Internet-URL soll die Datei direkt aus dem
Internet auf den Server runtergeladen werden (Dateiname der Zieldatei
sollte dabei wählbar sein). Möchte ein Benutzer übrigens eine
Internet-URL verwenden, die Datei aber nicht runterladen (z.B. um immer
auf das aktuelle Datenblatt verwiesen zu werden), so braucht er den
Manager gar nicht erst aufzurufen, sondern gibt einfach direkt die URL
in das Adressfeld z.B. in edit_part_info.php ein.
Ich hoffe ich habe nichts vergessen ;-)
mfg
Den Filemanager als neues DIV über die Part-DB zu legen ist nicht
wirklich ein Problem. Fast alle Aktionen werden dann über Ajax laufen.
Einen Multi-Uploader muss ich mir auch erstmal anschauen. Was recht
einfaches hab ich unter http://davidwalsh.name/multiple-file-upload
gefunden. Nur geht das wohl mit dem IE nicht. SWFUpload wäre wohl
besser. Schau ich mir mal genauer an.
Hallo Udo,
Ich habe mal noch die Debug-Möglichkeiten von Part-DB etwas ergänzt. Und
zwar wird im Debug-Modus das "error reporting level" von PHP
hochgesetzt, damit man möglichst viele Fehlermeldungen bekommt (zum
Aufspüren von unsauber programmierten Codezeilen oder als "deprecated"
markierten Funktionen). Nur "strict errors" werden nicht ausgegeben (ich
kann mir nicht erklären wofür man diese Meldungen gebrauchen kann - zum
Teil kommen da Meldungen, die völlig unbegründet sind).
Soweit sieht das bei mir ganz gut aus, es kommen trotz hohem "error
reporting level" keine Fehlermeldungen mehr. Doch sobald man in Part-DB
"Template-Debugging" aktiviert, hagelt es nur noch von "undefined
offset" und "deprecated function", alle durch die Datei
"lib/vlib/vlibTemplate/debug.php" verursacht.
Mache ich etwas falsch, oder ist die genannte Datei wirklich so unsauber
programmiert? Das ist natürlich schade, diese Meldungen müssen weg,
damit man das höhere error reporting level auch optimal zum debuggen
einsetzen kann.
VLib wird wohl leider nicht mehr wirklich aktiv weiterentwickelt (auf
Sourceforge letzte Änderung im Jahr 2009)... Ich habe trotzdem mal die
neuste Version runtergeladen und in Part-DB eingebaut (oder hast du mit
Absicht eine ältere Version verwendet?). Bezüglich der Fehlermeldungen
hat es aber nichts bewirkt.
Ausserdem musste ich schon etwa ein halbes Dutzend mal Apache neu
starten, weil irgendwas mit vlib geklemmt hat. Bei Änderungen am HTML
Code von irgendwelchen Seiten aktualisiere ich die entsprechende Seite
alle paar Sekunden wieder, um zu schauen wie sich die Änderung im Code
im Browser bemerkbar macht. Doch manchmal kommt nach einem Refresh
plötzlich nur noch ein "vlib parse error", selbst wenn ich die
entsprechende *.tmpl Datei komplett leere, kommt der Fehler weiterhin.
Erst ein Neustart von Apache behebt den Fehler und die Seite wird wieder
geladen.
Ich habe keine Ahnung was da das Problem sein könnte, vielleicht
irgendwas mit dem Cache-Mechanismus (den ich nicht näher kenne) von
vlib?
Konntest du diesen Fehler auch schon nachvollziehen? Hast du eine Idee
was das sein könnte?
mfg
Ich hatte vor Jahren die letzte nicht auf Sourceforge gehostete
vlib-Version geladen und seitdem verwende ich diese. Updaten wäre wohl
angebracht ;-) Das mittlerweile PHP weiter ist und daher Fehler von vlib
produziert werden können, versteht sich daher von selbst. Den Debug-Code
verwende ich sehr selten, eher kommentiere ich Bereiche im Template aus
und kann so den Fehler einkreisen.
Ich habe auch hin und wieder Hänger mit vlib und Ajax, wobei da eher der
Cache vom FF wohl dazwischenfunkt. Mit Chrome gehts besser. In der
vlibIni.php lässt sich das Verhalten der Engine beeinflussen. Die
Variable CACHE_LIFETIME lässt sich ja auch 0 setzen, was das
Cache-Verhalten praktisch abschalten sollte. Dann ist aber der Aufruf
von vlibTemplateCache() sinnlos und man kann vlibTemplate() verwenden.
Udo Neist schrieb:> Ich hatte vor Jahren die letzte nicht auf Sourceforge gehostete> vlib-Version geladen und seitdem verwende ich diese. Updaten wäre wohl> angebracht ;-)
OK, das Update lade ich heute noch ins SVN hoch.
> Das mittlerweile PHP weiter ist und daher Fehler von vlib> produziert werden können, versteht sich daher von selbst.
Jup, das würde die "deprecated"-Meldungen begründen. Die meisten
Fehlermeldungen stammen jedoch von Zugriffen auf Array-Elemente, die gar
nicht existieren. Man müsste also an vielen Stellen noch ein "if
isset()" einfügen. Mal schauen, vielleicht nehme ich mal mit dem
Entwickler von vlib Kontakt auf um das zu klären.
> Den Debug-Code> verwende ich sehr selten, eher kommentiere ich Bereiche im Template aus> und kann so den Fehler einkreisen.
Um zu schauen, wie die Loop-Strukturen und die übergebenen Variablen so
aussehen, ists aber manchmal ganz praktisch. Ich habe es zwar auch nur
selten verwendet, trotzdem möchte ich diese Funktion nicht wieder
rausnehmen müssen :-)
> Ich habe auch hin und wieder Hänger mit vlib und Ajax, wobei da eher der> Cache vom FF wohl dazwischenfunkt. Mit Chrome gehts besser. In der> vlibIni.php lässt sich das Verhalten der Engine beeinflussen. Die> Variable CACHE_LIFETIME lässt sich ja auch 0 setzen, was das> Cache-Verhalten praktisch abschalten sollte. Dann ist aber der Aufruf> von vlibTemplateCache() sinnlos und man kann vlibTemplate() verwenden.
Also bei "normaler" Verwendung von Part-DB hatte ich noch nie Probleme,
nur beim Entwickeln wo ich sehr häufig ganz kleine Änderungen an den
*.tmpl Dateien vorgenommen habe, und das Ergebnis im Browser jedes mal
per Refresh aktualisierte. Naja, wenn das Caching wirklich ein ernstes
Problem darstellen würde, können wir es dann ja immernoch ausschalten...
Urban B. schrieb:>> Den Debug-Code>> verwende ich sehr selten, eher kommentiere ich Bereiche im Template aus>> und kann so den Fehler einkreisen.> Um zu schauen, wie die Loop-Strukturen und die übergebenen Variablen so> aussehen, ists aber manchmal ganz praktisch. Ich habe es zwar auch nur> selten verwendet, trotzdem möchte ich diese Funktion nicht wieder> rausnehmen müssen :-)
print_r($array); und im Browser den Quelltext anzeigen lassen ;-)
Verschachtelte Arrays sind mit 0=>array, 1=>array usw. aufzubauen.
Udo Neist schrieb:> print_r($array); und im Browser den Quelltext anzeigen lassen ;-)
Ja klar geht das auch :-)
Aber im Debug-Modus brauchts nur einen einzigen Buttonklick und man hat
alle Loops und alle Variablen, die auf der jeweiligen Seite verwendet
werden, schön aufgelistet. Und das auch noch in einem separaten Popup,
so dass die Seite an sich nicht verändert wird (macht man ein print_r()
bevor der HTML-Header geschrieben wurde, funktionieren z.B. die header()
Funktionen nicht mehr, es "verfälscht" dann also quasi das Ergebnis -
wenn auch nur selten wirklich spürbar).
Schlussendlich kann ja jeder so debuggen wie er möchte. Ich fände es nur
schade, diese bereits in vlib integrierte Debugmöglichkeit zu vermeiden,
nur weil niemand die genannten "if isset()" ergänzen möchte. Wenn ich
mal Zeit habe kann ich das ja auch selber übernehmen und dann den neuen
Code an den vlib-Entwickler schicken, vielleichts wirds ja in
Sourceforge aufgenommen... Aber momentan habe ich anderes zu tun ;-)
Ich habe den Filemanager schonmal ein nutzbares UI verpasst, allerdings
noch nicht für die Part-DB. Sobald noch die Befehle (Rename, Delete,
Copy, Move, Up- und Download) funktionieren, kann ich es dank CSS sehr
einfach an Part-DB anpassen.
Im Moment besteht der Filemanager aus einigen vlib-Templates, ein CSS, 3
Javascript-Dateien (ajax.js, dom.js und filemanager.js) und verwendet an
manchen Stellen, bedingt durch den Einbau in ein anderes Framework, noch
dojo. Letzteres ist für den Filemanager innerhalb von Part-DB nicht
notwendig und wird entfernt.
Hi Leute,
Wird Aktuell noch an der part-db gewerkelt?
Hätte gern mal die Part-DB 0.3.0 getestet,bzw offline also auf VM.
Gibt's aber ja noch nicht zum dl,sondern nur Online.
Daher meine zweite frage: Wann kommt denn ca die neue Raus?
Was ich mir zudem wünschen würde ist das man die toten links von Google
raus nehmen könnte, und das ganze ein wenig Übersichtlicher Gestalten
würde z.B im bereich
https://code.google.com/p/part-db/source/detail?r=588 mal genauer sagen
würde wo und welche php das jeweils ist?
Trotzdem echt gute Arbeit!
PS: Sollte irgendwann mal die Arbeit dran eingestellt werden,sei es aus
Zeitmangel oder so,wie auch immer. Würde mich freuen es fortführen zu
dürfen?
Die Entwicklung steht nicht. Wir hatten in den letzten Wochen weniger
Zeit für das Projekt. Derzeit entwickle ich einen Filemanager, der die
alten Up-/Downloadformulare genauso wie Copy/Move/Rename/Delete und
ähnliche Befehle für die verschiedenen Inhalte wie Grafiken ersetzt. Ich
kann diesen allerdings noch nicht in Part-DB integrieren, da er noch ein
paar Funktionen eines Javascript-Frameworks nutzt, die ich ersetzen
will.
Marco tom Suden schrieb:> Hi Leute,
Hallo!
> Wird Aktuell noch an der part-db gewerkelt?
Jain, bei mir sind grad Semesterprüfungen :-(
In einer Woche kanns aber weitergehen :-)
> Hätte gern mal die Part-DB 0.3.0 getestet,bzw offline also auf VM.> Gibt's aber ja noch nicht zum dl,sondern nur Online.
Die Sources sind ja im Google Code, die kann man runterladen:
https://code.google.com/p/part-db/source/browse/#svn%2Fbranches%2Funeist_kami89
Dazu brauchst du nur einen SVN Client. Einfach mal im Internet nach
einer SVN (Subversion) Anleitung suchen.
Bei Linux muss das Paket "subversion" installiert sein, danach einfach
diesen Befehl im Terminal ausführen:
Dann wird das gesamte Projekt in den home-Ordner runtergeladen.
> Daher meine zweite frage: Wann kommt denn ca die neue Raus?
Schwierig zu sagen ;-) Wenns fertig ist^^
> Was ich mir zudem wünschen würde ist das man die toten links von Google> raus nehmen könnte, und das ganze ein wenig Übersichtlicher Gestalten> würde z.B im bereich> https://code.google.com/p/part-db/source/detail?r=588 mal genauer sagen> würde wo und welche php das jeweils ist?
hmm? Verstehe kein Wort ;-)
Die Google-Code Projektseite können wir nicht verändern, die hat Google
entwickelt^^
> Trotzdem echt gute Arbeit!
Danke :-)
> PS: Sollte irgendwann mal die Arbeit dran eingestellt werden,sei es aus> Zeitmangel oder so,wie auch immer. Würde mich freuen es fortführen zu> dürfen?
Keine Angst, es geht schon weiter :-)
Die v0.3.0 ist aber ein sehr grosser Schritt (auch wenn man davon nicht
sehr viel sieht, im Hintergrund ist praktisch alles komplett neu), daher
dauert es halt seine Zeit.
Ok das mit dem Übersichtlich hat sich erledigt. Die php's haben ja den
namen,hat sich ja einiges getan.
Habe mit das ganze mal geladen und ins Verzeichnis gepackt.
Nun habe ich aber zweierlei Probleme!.
1. Bekomme ich eine Fehlermeldung beim Aufrufen der Seite:
Strict Standards: Non-static method vlibIni::vlibTemplate() should not
be called statically, assuming $this from incompatible context in
C:\xampp\htdocs\part-db2\lib\vlib\vlibTemplate.php on line 849
Strict Standards: Non-static method vlibIni::vlibTemplate() should not
be called statically, assuming $this from incompatible context in
C:\xampp\htdocs\part-db2\lib\vlib\vlibTemplate.php on line 851
Sollte hoffentlich eher ein geringes probtem sein.
2. Habe ich bei dem Verzeichnis das ich per TortoiseSVN geladen hab.
Bei der vlibTemplate.php & config_defaults.php einen Roten Punkt
mit(!).
Alles andere ist Grün.
Habe auch ein Update versucht, funzt aber nicht.
Die "Strict Standards" Meldungen kommen vermutlich von einem zu hoch
eingestellten Error-Reporting-Level bei deinem Webserver (Apache?).
Du hast schon mindestens PHP in der Version 5.3, oder? Das ist nämlich
Voraussetzung für Part-DB 0.3.0.
Ich schaue dass ich heute Nachmittag noch die aktuellste Version ins SVN
hochlade, dort ist dann auch noch einen rudimentären Installer
inbegriffen, der unter Anderem auch die ganzen Tabellen in der Datenbank
erzeugt.
Ich melde mich dann hier nochmal wenn das hochgeladen ist.
Also bei mir ist im Grunde doch alles Aktuell,oder?
MYSQL:5.5.24 PHP:5.4.3 Apache:2.2.22
Hab das auch mit Wampserver2.2 versucht, dort sehen optisch die Fehler
zwar anders aus,aber selber Fehler.
Urban B. schrieb:> Ich schaue dass ich heute Nachmittag noch die aktuellste Version ins SVN> hochlade, dort ist dann auch noch einen rudimentären Installer> inbegriffen, der unter Anderem auch die ganzen Tabellen in der Datenbank> erzeugt.
Besten Dank!
Was bedeuten eigentlich die Roten Punkte mit dem(!),die vom svn prog
angezeigt werden?
So, die neue Version ist hochgeladen. Jetzt kannst du die Dateien
nochmal runterladen. Beim nächsten Aufruf der Seite sollte dann der
Installationsassistent kommen.
Du kannst entweder mit einer komplett leeren MySQL Datenbank, oder mit
einer Datenbank der Version 12 loslegen. Auf keinen Fall die Datenbank
vom produktiven System (letzte stabile Part-DB Version) benutzen!! Eine
Kopie davon geht natürlich.
Marco tom Suden schrieb:> Also bei mir ist im Grunde doch alles Aktuell,oder?> MYSQL:5.5.24 PHP:5.4.3 Apache:2.2.22
Ja, das passt.
> Was bedeuten eigentlich die Roten Punkte mit dem(!),die vom svn prog> angezeigt werden?
Ich kenne TortoiseSVN nicht, aber bei meinem SVN Client werden Dateien
rot markiert, die nicht mehr aktuell sind. Wegen dem Cache sind die
Icons aber nicht immer aktuell. Im Zweifelsfall einfach die Dateien
löschen und nochmal per SVN runterladen lassen (gilt natürlich nur für
"Systemdateien". Bei allen Dateien, die nicht im SVN existieren [z.B.
config.php] funktioniert das nicht).
Marco tom Suden schrieb:> 1. Bekomme ich eine Fehlermeldung beim Aufrufen der Seite:> Strict Standards: Non-static method vlibIni::vlibTemplate() should not
Bei Apache kann man den "Error Reporting Level" einstellen, da musst du
die "strict standards" deaktivieren.
Hier bei Ubuntu liegen die Einstellungen in /etc/php5/apache2/php.ini,
die entsprechende Zeile sieht bei mir so aus:
Hi Urban B.
Hab das ganze komplett neu geladen inkl neuer Database.
Auch die Änderung in der php.ini Sieht bei mir so aus:
Common Values:
; E_ALL (Show all errors, warnings and notices including coding
standards.)
; E_ALL & ~E_NOTICE (Show all errors, except for notices)
; E_ALL & ~E_NOTICE & ~E_STRICT (Show all errors, except for notices
and coding standards warnings.)
; E_COMPILE_ERROR|E_RECOVERABLE_ERROR|E_ERROR|E_CORE_ERROR (Show only
errors)
; Default Value: E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED
; Development Value: E_ALL
; Production Value: E_ALL & ~E_DEPRECATED & ~E_STRICT
; http://php.net/error-reporting
error_reporting = E_ALL & ~(E_STRICT | E_DEPRECATED)
Bei der Installation zeigte er mir ebenfalls Fehler an.
Nach der Installation bestehen die selben Fehler dennoch.
Oh, nach genauerem Betrachten der Fehlermeldung habe ich gemerkt, dass
in der vlibIni.php tatsächlich ein Fehler war (bzw. sehr unschöne
Programmierung). Ich frage mich schon ein bisschen, was sich da der
Entwickler von vlib überlegt hat, ist ja ultrakomisch was der da gemacht
hat^^ (zur Info: vlib wurde nicht von uns entwickelt, alles im
vlib-Ordner stammt nicht von uns).
Ich habe nun mal wenigstens ein "public static" vor die Methoden
geschrieben, jetzt dürften diese Fehlermeldungen nicht mehr kommen.
Aktualisiere einfach deine Installation nochmal per SVN.
Falls es trotzdem noch weitere Fehlermeldungen gibt, einfach nochmal
hier melden :-)
@all
Ich habe gerade rausgefunden, dass die derzeit benutzte MySQL Engine
"MyISAM" gar keine Transaktionen unterstützt. Das ist natürlich sehr
schade, für die User wären Transaktionen nämlich sehr von Vorteil, da
die Datenbank keine halbfertigen Operationen mehr übernehmen würde.
Ein Beispiel wäre, wenn der Benutzer alle Teile einer Baugruppe abbucht
(Button "Teile abfassen") und mittendrin ein Fehler auftauchen würde.
Dann wären die ersten paar Teile erfolgreich abgefasst worden, doch die
restlichen Bauteile konnten aufgrund des Fehlers nicht mehr abgefasst
werden. Der Benutzer hat dann keine Change zu erkennen, bis wohin die
Abbuchung noch erfolgreich war, bzw. er merkt nicht mal dass ein Teil
der Bauteile abgebucht wurden, und ein Teil nicht.
Ein Fehler kann z.B. duch ein Programmierfehler verursacht werden, oder
durch eine gleichzeitige Transaktion eines anderen Benutzers. Zweiteres
ist zwar erst ab mehr als vielleicht 10 bis 20 Benutzer einigermassen
realistisch, doch in einem kleinen Unternehmen könnte dies durchaus zu
einem Problem werden.
Könnte man mit Transaktionen arbeiten, würden alle Änderungen, die
bereits erfolgreich abgeschlossen wurden, wieder problemlos rückgängig
gemacht werden. Beim Beispiel mit den Baugruppen würde das dann
bedeuten, dass einfach kein einziges Bauteil abgebucht wurde. Das wäre
für den Benutzer dann ganz einfach nachzuvollziehen und es gibt keine
falschen Bestände in der Datenbank.
Es gibt doch nichts mühsameres als eine schiefgelaufene Transaktion die
dann so halbfertig in der Datenbank verewigt bleibt ;-)
Daher wäre vielleicht ein Umstieg auf "InnoDB" sinnvoll. Ich kenne mich
damit leider nicht wirklich aus, doch nach ein paar Recherchen im
Internet dürfte InnoDB etwas langsamer sein als MyISAM. Kommt aber immer
drauf an was man macht (Lesen / Schreiben). Nach ein paar Tests mit
Part-DB habe ich festgestellt, dass das Laden der Bauteile einer
Kategorie etwa doppelt so lange dauert wie mit MyISAM. Meine VM mit
einem Kern meines i7-3770k und 2GB RAM schafft nun 240 Bauteile in 180ms
statt in 90ms. Interessanterweise dauert es umso länger, je mehr
CPU-Kerne ich der VM zuordne...Bei 4 Kernen dauert es um die 500ms, das
ist schon beachtlich. Ich denke mal dass VirtualBox da irgendwie
ausbremst...
Nun, die längere Ladezeiten sind zwar mühsam wenn man einen langsamen
Server hat oder viele Bauteile auf einmal anzeigen möchte. Ich
persönlich bin aber der Meinung, dass die Konsistenz der Datenbank
wichtiger ist als die Geschwindigkeit. Ausserdem könnte man die
Bauteilelisten auch auf mehrere Seiten aufteilen, so dass z.B. maximal
200 Teile pro Seite angezeigt werden (so wie es ja in jedem Online-Shop
auch üblich ist).
Was meint ihr dazu? Udo, hast du vielleicht schon Erfahrungen mit InnoDB
gemacht?
P.S.
Seit MySQL 5.5 ist InnoDB sowieso zur Standard-Engine geworden, das ist
ja schonmal kein schlechtes Zeichen. Vielleicht wird die Performance in
der nächsten Zeit ja auch noch verbessert...
EDIT:
Und etwas mehr Geschwindigkeit könnte man vermutlich auch noch mit ein
paar Optimierungen von Part-DB rausholen. Bisher habe ich die Klassen
natürlich noch nicht sonderlich auf Geschwidnigkeit getrimmt, sondern
vielmehr auf die Funktionalität.
Ich würde den Umstieg auf InnoDB befürworten. Geschwindigkeit ist nicht
das Ziel, sondern Datensicherheit und Nutzbarkeit der Part-DB. Ich würde
auch jede Suchanfrage auch auf x Ergebnisse einschränken. Wer benötigt
schon den gesamten Bestand am Bildschirm? Die Einschränkung könnte man
ja auch mit einer Checkbox oder in der Konfiguration ein- oder
ausschalten.
Ich habe die Abhängigkeit meines Filemanagers vom dojo-Framework soweit
beseitigt. Download eines ausgewählten Files funktioniert. Bin gerade an
der Verarbeitung von Befehlen (Rename, Delete, Copy und Move). Der
Dialog dazu fehlt noch komplett. Erst wenn das alles funktioniert, dann
gehts an den Upload. Meine Shell-Klasse werde ich wohl nicht benötigen,
werde das im Filemanager direkt integrieren.
Okay also wenn ich das alles richtig verstanden habe, genügt ja für jede
Tabelle ein einziger, kleiner Befehl:
1
ALTER TABLE `xy` ENGINE=InnoDB
Das kann man problemlos als ganz normales Datenbankupdate in die
db_update_steps.php schreiben, der Benutzer merkt gar nichts davon.
Zumindest bei meinen Test hat das funktioniert, bzw. deutet die
gesunkene Geschwindigkeit darauf hin, dass es funktioniert hat :-)
Falls dadurch noch Probleme verursacht werden, ist das ja schnell wieder
rausgenommen...
Jetzt muss ich einfach "nur" noch alle Klassen etwas umbauen, damit die
auch sinnvoll mit den Transaktionen umgehen können.
Ausserdem habe ich noch erste Versuche mit SQLite gestartet. Ich finde,
SQLite macht es den Hobby-Anwendern, die nicht viel Ahnung von
Datenbanken haben, sehr viel leichter als MySQL. Und fürs Hobby genügt
SQLite allemal, und Transaktionen werden auch unterstützt. Ich weiss
noch wie schwer ich mich getan habe, als ich das erste mal eine MySQL
Datenbank gebraucht habe. Da kann ich gut verstehen wenn einige User das
Handtuch werfen und zur "Konkurrenz" gehen.
Ebenfalls für eine einfachere Handhabung habe ich einen Installer
gebaut, der beim ersten Aufruf der Seite automatisch gestartet wird.
Dort lassen sich bequem die wichtigsten Einstellungen tätigen (vor allem
die Verbindung zur Datenbank). So muss sich auch niemand mehr von Hand
um die config.php kümmern, und falls eine SQLite Datenbank verwendet
wird, muss nichtmal eine Datenbank vorbereitet werden.
Eigentlich dachte ich ja, mit dem Einsatz von PDO sollte SQLite ganz
leicht auch unterstützt werden. Tja, ganz so einfach ist es dann aber
leider doch nicht :-( Es gibt einige MySQL-Befehle, die SQLite nicht
kennt bzw. anders formuliert werden müssen. Ausserdem müssen in SQLite
scheinbar alle Indizes über die gesamte Datenbank eindeutig sein, nicht
nur in der jeweiligen Tabelle. Daher müsste ich noch ein paar Indizes
umbenennen. Irgendwie sollte das dann aber schon auch noch funktionieren
denke ich mal :-)
Und wegen dem Upload-Manager, du kannst dich ja melden wenn er
einigermassen fertig ist, dann schauen wir mal wie wir den am besten
einbauen.
Urban B. schrieb:> Und wegen dem Upload-Manager, du kannst dich ja melden wenn er> einigermassen fertig ist, dann schauen wir mal wie wir den am besten> einbauen.
Mach ich :-) Bin ja schon mitten drin. Die Befehle werden auch schon
ausgeführt. Aktuell fehlen mir nur noch ein paar Dialoge und der
Upload-Teil.
So da bin ich mal wieder.
Kommt mir vor als hätte ich euch mit den Fehlern bei mir, ein wenig
unterstützt. ;-) Ok bin zwar kein php Profi,kenne mich momentan nur
bedingt damit aus,wo ich aber meine Kenntnisse in nächster Zeit
ausarbeiten werde.
Deswegen frag ich ja hier,also wenn ich euch in form von Testen etc
irgendwie unterstützen kann. Stehe ich euch gern dafür Bereit!
Ich bin nach betrachten der einzelnen Versionen,begeistert und von dem
Ganzen sehr Überzeugt. Positiv natürlich! Es hat sich einiges dran
getan,
also dem sei gelobt.
Naja nun aber zum eigentlichen warum ich mich melde ist, ich habe es nun
folgendermaßen ausgeführt:
Zuerst hab ich die Database komplett geleert war somit vor der
Installation also Leer Ohne Tabellen usw!
Danach habe ich kein Update gemacht sondern Alles nochmal Neu aus der
svn geladen!
Als ich die Installation gestartet habe also die install.php aufgerufen
hab.
War ich erstmal überzeugt das alles so läuft wie es soll,sprich es war
ein Sauberes Bild da Ohne Fehler!
Als jedoch die Installation Abgeschlossen war, kam die herbe
Ernüchterung, nämlich nichts, weder Fehler noch die DB, einfach ein
Schlichtes Weiß ohne jede art von Text.
Habe mal die php_error_log angehängt in der am Ende Fehler angezeigt
werden ,die aber nun eine Undefinierte Variable in der debug.php
bettreffen.
"PHP Deprecated" ist erstmal kein Fehler, sondern nur ein Hinweis, das
die genannte Funktion als "nicht mehr erforderlich/als überholt"
markiert wurde und irgendwann in der Zukunft entfällt. Man sollte sich
als Programmierer dann eine Alternative ausdenken (z.B. eine eigene
Funktion schreiben, die entsprechend heißt.
"PHP Notice" heißt nur, hier gibts einen Hinweis. In der Regel sind das
nicht definierte Variablen oder Indices eines Arrays.
Den anderen Fehler schaue ich mir in der Klasse mal an. Eventuell kann
ich den Fehler beheben.
Fehler: PHP Strict Standards: Non-static method vlibIni::vlibTemplate()
should not be called statically, assuming $this from incompatible
context
Ich habe im Konstruktor den Block
1
if (is_array(vlibIni::vlibTemplate()))
2
{
3
foreach (vlibIni::vlibTemplate() as $name => $val)
4
{
5
$this->OPTIONS[$name] = $val;
6
}
7
}
durch die ältere Methode
1
$vlibIni = new vlibIni;
2
if (is_array($array = $vlibIni -> vlibTemplate()))
3
{
4
foreach ($array as $name => $val)
5
{
6
$this->OPTIONS[$name] = $val;
7
}
8
}
ersetzt. Ich hoffe, dass damit der Fehler behoben ist.
Die Meldungen sind mir alle bekannt, die kommen alle von vlib (wenn ich
keine übersehen habe). Wie ich schonmal hier geschrieben habe, ist vlib
leider teilweise sehr unsauber programmiert. Eventuell versuche ich mal
Kontakt mit dem Entwickler aufzunehmen um das zu klären.
Wie Udo bereits schrieb, sind das aber alles nur Warnungen, die sollten
eigentlich keinen Einfluss auf die Funktionsweise der Webseite haben.
Du kannst aber mal versuchen ganz am Anfang in der Datei
"start_session.php" die folgenden Zeilen einzufügen:
1
error_reporting(E_ERROR);
2
ini_set("display_errors", 0);
Damit sollten nun definitiv keine Warnungen mehr auf der Seite
ausgegeben werden. Wichtig ist aber, dass in der config.php die
Einstellung $config['debug']['enable'] auf "false" gesetzt ist, das ist
standardmässig aber schon so eingestellt wenn du den Debug-Modus noch
nicht aktiviert hast.
Ich habe auch schon festgestellt, dass nur noch eine weisse Seite kam,
anstatt die Warnungen. Das komplette Deaktivieren dieser Warnungen hat
dann geholfen. Eigentlich komisch, ich weiss nicht warum das so war.
Marco tom Suden schrieb:> Deswegen frag ich ja hier,also wenn ich euch in form von Testen etc> irgendwie unterstützen kann. Stehe ich euch gern dafür Bereit!
Das ist super, Tester können wir immer gebrauchen! Vor allem scheinst du
ja mit Windows zu arbeiten, ich entwickle hier aber nur mit Linux. So
kannst du uns helfen Fehler aufzudecken, die nur Windows betreffen.
Dass noch nicht alles funktioniert in der Version 0.3.0 sollte dir ja
klar sein, da sie noch in Entwicklung ist. Also wenn mal eine Funktion
nicht funktioniert kann das durchaus auch so "gewollt" sein.
@Udo
Ich habe eigentlich vorher in der vlibIni.php die Methoden static
gemacht, damit sie mit vlibIni::... aufgerufen werden können. So wie es
aussieht werden diese Funktionen immer nur mit den :: aufgerufen, static
würde dann also SInn machen. Wobei aber die ganze Konfiguration total
komisch ist, wer macht schon eine Klasse für die Einstellungen, wo dann
einfach die Arrays über Methoden geholt werden?! ;-)
@Urban
Ich hab nicht ganz auf die Zeiten im Logfile geschaut. Scheint so, dass
Marco deine Änderung schon geholt hatte und damit der Fehler behoben
ist. Du kannst meine Änderung wieder rückgängig machen, da ich die
originale Methode nur auskommentiert habe.
Urban B. schrieb:> Das ist super, Tester können wir immer gebrauchen! Vor allem scheinst du> ja mit Windows zu arbeiten, ich entwickle hier aber nur mit Linux. So> kannst du uns helfen Fehler aufzudecken, die nur Windows betreffen.>> Dass noch nicht alles funktioniert in der Version 0.3.0 sollte dir ja> klar sein, da sie noch in Entwicklung ist. Also wenn mal eine Funktion> nicht funktioniert kann das durchaus auch so "gewollt" sein.
:-) Das hast Richtig Erkannt,das ich mit Windows Arbeite genau.
Helfen tue ich euch dabei sehr gern. Das das ganze also die 0.3.0 noch
quasi so zu sagen in den Kinderschuhen steckt,und noch reichlich Fehler
besitzt ist mir ganz klar.
Naja ich sehe das ganze recht Positiv. Zumindest wenn ich mal was von
der DB bei mir sehen könnte.
Ich versuche mir grad mal einen kleinen Überblick zu verschaffen, wie
das ganze überhaupt Code technisch abläuft.
Um vtl sogar das Problem genauer Definieren zu können.
Das die Meldungen die ich vorhin als Fehler bezeichnete, keine sind ist
mir auch grade aufgefallen, also mal wieder was gelernt.
Ich habe grade mal eben die Änderung der Methode wie Udo Neist beschrieb
versucht, also das Ergebnis bleibt wie gehabt,weises Bild ohne jeglichen
Inhalt. Was mir an genau dieser Methode auffiel das sie Auskommentiert
also Grün war!
Edit: Ok da war ich wohl zu schnell :-)
Udo Neist schrieb:> Du kannst meine Änderung wieder rückgängig machen, da ich die> originale Methode nur auskommentiert habe.
Ist gemacht. Entweder bin ich zu blöd, oder es gibt in Google Code keine
Möglichkeit, eine Änderung rückgängig zu machen bzw. eine frühere
Revision wiederherzustellen?! Sollte doch eigentlich möglich sein würde
ich meinen...
@ Marco tom Suden
Hast du mal die zwei Zeilen in die start_session.php eingefügt? hat das
nichts gebracht?
Marco tom Suden schrieb:> Ich versuche mir grad mal einen kleinen Überblick zu verschaffen, wie> das ganze überhaupt Code technisch abläuft.> Um vtl sogar das Problem genauer Definieren zu können.
Auskommentieren ist hier das Zauberwort :-D Nach wie vor das Nr. 1
Debugwerkzeug bei mir :-)
Ich kann im Moment dein Problem mit der weißen Seite nicht überprüfen,
da ich wohl keine ganz aktuelle Datenbank habe. Mir fehlt die Tabelle
"part-db.pricedetails". Ansonsten läuft nach dem erstmaligen Aufruf von
install.php soweit alles, egal ob mit oder ohne meiner Änderung an
vlibTemplate.php.
Ansonsten besteht die Frage, ob Javascript aktiv ist. Ohne JS
funktioniert Part-DB nicht vollständig.
Edit: Muss wohl meine Datenbank mal löschen und neu aufbauen. Sind noch
ein paar mehr SQL-Fehler aufgetaucht.
Ja die Zeilen habe ich eingefügt.
In der config.php hab ich bisher nichts verändert.
Ergebnis ist bei mir zumindest so geblieben.
Nun hab ich aber auch keine neuen Einträge mehr in der php_error_log.
Somit auch keine Meldungen mehr von bestehenden Fehlern etc.
Udo Neist schrieb:> Ich kann im Moment dein Problem mit der weißen Seite nicht überprüfen,> da ich wohl keine ganz aktuelle Datenbank habe. Mir fehlt die Tabelle> "part-db.pricedetails".
Wenn du mit einer Datenbank der Version 12 beginnst, sollte alles
Notwendige mit den Datenbankupdates nachgerüstet werden, auch die
Tabelle "pricedetails". Wenn du also eine Part-DB Installation aus dem
SVN-*Trunk* oder die noch ältere aus der Download-Seite (V0.2.2) hast,
kannst du die Datenbank von dort kopieren und dann diese für Part-DB
0.3.0 verwenden. Die wird dann entsprechend angepasst durch die
DB-Updates.
Aber es gilt immernoch: Die Datenbank ist dann nicht mehr
abwärtskompatibel, eine upgedatate DB kann also nicht mehr mit den
stabilen Versionen von Part-DB verwendet werden. Daher nur mit Kopien
der produktiven Datenbank arbeiten, nicht mit dem Original! :-)
@Marco tom Suden
Ich habe sonst auch keine Ahnung mehr wodurch das Problem verursacht
werden könnte. Vielleicht findest du es ja noch raus. Ansonsten kann ich
später eventuell auch selbst mal einen Windows Server aufsetzen zum
probieren (trotz Windows-Allergie!^^).
Ich hatte die Datenbankversion 13 genutzt. Wahrscheinlich war die etwas
inkompatibel zu deiner Version und irgendein Update hat fehlgeschlagen.
Ich werde da wohl von vorne anfangen müssen. Ich habe ja noch kein
Produktivsystem am Start, alles nur für die Entwicklung.
Udo Neist schrieb:> Ich hatte die Datenbankversion 13 genutzt. Wahrscheinlich war die etwas> inkompatibel zu deiner Version und irgendein Update hat fehlgeschlagen.
Ja, ich musste ab und zu das Update von v12 auf v13 nochmal ändern, es
ging nicht anders. Daher funktioniert auch die Online-Demo nicht mehr
korrekt, da gibts auch noch Datenbankfehler. Man müsste nur wieder mal
eine DB der Version 12 einspielen.
Udo Neist schrieb:> Ich werde da wohl von vorne anfangen müssen. Ich habe ja noch kein> Produktivsystem am Start, alles nur für die Entwicklung.
Für diesen Fall habe ich den Ordner "development/testfiles/database"
erstellt. Ich habe dort meine DB v12 vom Produktivsystem abgelegt, damit
auch Leute ohne eigenes Produktivsystem mit richtigen Datensätzen testen
können:
https://part-db.googlecode.com/svn/branches/uneist_kami89/development/testfiles/database/v12_kami89.sql
Hi ich meld mich grad noch a mal.
Ich habe das ganze mal über Wammp laufen lassen.
Selbes Resultat!
Dann habe ich das mit Fierfox ausprobiert, mit Meldung wie auf dem Bild.
Mir scheint es so als würde das Layout geladen aber kein Inhalt.
Da ich Chrome als Standard verwende,bekam ich über F12 unten eine Art
Konsole,dort sieht man auch den geladenen Inhalt, aber was mir auffiel
das die (/) bei den links einmal / und dann \ sind.
Ob da nun relevant ist weis ich grad nicht.
Zumindest betreffen die beiden Fehler, genau diese Zeilen.
Was mir der bzw die was im Grunde ein und das selbe ist,glaub ich
mal,sagt ist das es lokal nicht erlaubt sei. Ok steht ja da. Aber wie
Ändern?
Ah ok wenn ich über die Konsole den Pfad Änder also von
C:\wamp\www\part-db-0.3.0/startup.php in startup.php also nur die php
datei angebe,
zeigt er mir alles an.
Nur wo sind diese angegeben? da sie beim erneuten laden wieder so sind
wie vorher.
Es sind da aber noch weitere Probs aber dazu komme ich Später wenn alles
läuft.
das Problem sein dürfte. Die Definition der Basisverzeichnisse ist unter
Linux richtig. Vielleicht macht da Wamp Probleme. Mangels letzterem kann
ich da nicht viel dazu sagen.
So habs habe in der vlib_frameset.tmpl Folgende Einträge entfernt,bzw
geändert:
<frameset cols="300,*" frameborder="0" framespacing="0" border="0">
<frame name="navigation_frame" src="{TMPL_VAR
NAME="relative_path"}navigation.php">
<frame name="content_frame" src="{TMPL_VAR
NAME="relative_path"}startup.php">
</frameset>
in
<frameset cols="300,*" frameborder="0" framespacing="0" border="0">
<frame name="navigation_frame" src="navigation.php">
<frame name="content_frame" src="startup.php">
</frameset>
Also nur ( {TMPL_VAR NAME="relative_path"} ) entfernt und nun läuft es
soweit.
Nur sieht es bei mir nun so aus wie auf dem Bild.
Hat jmd ne Lösung?
Udo Neist schrieb:> Ersetze in start_session.php folgende Zeile define('BASE_RELATIVE',
str_replace(DOCUMENT_ROOT, '', BASE.'/'));
> durch define('BASE_RELATIVE', '');> und du hast das gleiche für alle Templates erreicht.
Das geht nun aber runter wie butter. Es Läuft!
Was ist eigentlich damit gemeint?
Die SVN Revision konnte nicht aus
"C:\wamp\www\part-db-0.3.0/.svn/entries" gelesen werden.
Scheint jedoch auch was damit zu tun zu haben wegen \.../, oder?
An sich sieht das schon ganz ordentlich aus. sogar meine Alte Database
aus 0.2.2 geht. Also die Inhalte zumindest.
Dan kann es ja so langsam auf Fehler, bzw Bug suche gehen.
Marco tom Suden schrieb:> Was ist eigentlich damit gemeint?>> Die SVN Revision konnte nicht aus> "C:\wamp\www\part-db-0.3.0/.svn/entries" gelesen werden.
Das ist nur eine Meldung, dass in der Datei die Revisionsangabe fehlt.
Anscheinend wurde das Format dieser Datei geändert, denn in älteren
Versionen von SVN konnte man dies auslesen. Wahrscheinlich ist das ganze
in eine SQLite-Datenbank mit dem Namen wc.db gewandert. Manche Server
verbieten Shellzugriffe von PHP aus und daher wurde von "svnversion" per
system() in get_svn_revision() auf eine manuelle Lösung umgestellt. Die
funktioniert halt nicht mehr. Ich begebe mich mal auf die Suche nach
einer Lösung.
Ein Glück hatte ich erst vor kurzem das Firefox-Addon SQLite-Manager
installiert ;-) Folgendes habe ich gefunden: Die wc.db enthält in der
Tabelle eine Spalte 'revision', in der die gewünschte Information
gespeichert ist.
Das nervt echt dass Linux und Windows unterschiedliche Trennzeichen in
Dateipfaden verwenden. In den PHP-Dateien könnte man dafür die Konstante
"DIRECTORY_SEPARATOR" verwenden, doch in den *.tmpl Dateien ist es etwas
mühsamer. OK man könnte dort auch so eine Konstante erstellen...Ich muss
aber erst mal rausfinden ob das überhaupt notwendig ist, denn unter
Windows laufen die Webseiten, die Linux-Dateipfade verwenden,
normalerweise ja auch.
Die SVN-Fehlermeldung kommt bei mir auch, bei SVN hat das Dateiformat
mal geändert und ich kam bisher noch nicht dazu, das anzupassen. Danke
Udo, dass du die Recherche gleich selbst übernommen hast :-)
Udo Neist schrieb:> Ersetze in start_session.php folgende Zeile> define('BASE_RELATIVE', str_replace(DOCUMENT_ROOT, '', BASE.'/'));> durch> define('BASE_RELATIVE', '');
Und wie siehts mit dieser Variante aus, funktionierts so auch?
Also die Ausgabe:
dirname=C:\wamp\www\part-db-0.3.0
docroot=C:/wamp/www/
Bei dem:
define('BASE_RELATIVE', str_replace(DOCUMENT_ROOT, '',
BASE.DIRECTORY_SEPARATOR));
Bleibt wie vorhin das bild weiß!,
jedoch sind die Pfadangaben mit den \ durchgehend einheitlich.
C:\wamp\www\part-db-0.3.0\navigation.php
PS: (Is nur nebenbei bemerkt!)
Hab grade mal das Greenway Theme mal angesehen und mit dem bild
http://1.2.3.12/bmi/www.mikrocontroller.net/wikifiles/thumb/5/56/Greenway.png/150px-Greenway.png
Verglichen,da ist bis auf Grüne schrift alles wie bei dem Standard. Aber
da habe ich schon die 2 Bilder von der 0.2.2 genommen. Muss nur noch ein
wenig angepasst werden.
Greenway ist eine Variation des Standards und kein eigenes Thema. Ich
denke, nach dem Abschluss der 0.3er Entwicklung werden wir die Frames
ablösen und auch neue Themen anbieten können.
Udo Neist schrieb:> Greenway ist eine Variation des Standards und kein eigenes Thema. Ich> denke, nach dem Abschluss der 0.3er Entwicklung werden wir die Frames> ablösen und auch neue Themen anbieten können.
Ahso ok. Oder so.
Meinte nur, da das auf bild, bei mir halt nicht so aussieht.
Aber wenn das so ist,ist das auch ok.
Marco tom Suden schrieb:> Also die Ausgabe:> dirname=C:\wamp\www\part-db-0.3.0> docroot=C:/wamp/www/
Danke! Ist ja lustig dass es einmal mit Slash und einmal mit Backslash
daherkommt...das ist doch total verwirrend.
Ich glaube, jetzt habe ich den Fehler aber gefunden. Versuch mal das
hier:
So zeigt er mir das
Urban B. schrieb:> Ich glaube, jetzt habe ich den Fehler aber gefunden. Versuch mal das> hier:define('BASE', dirname(_FILE_));> define('DOCUMENT_ROOT', rtrim($_SERVER['DOCUMENT_ROOT'], '/\ '));> define('BASE_RELATIVE', str_replace(DOCUMENT_ROOT, '',
BASE.DIRECTORY_SEPARATOR));
So zeigt er mir das damit.
Bei mir läuft das wenn ich folgende Zeilen eingebe:
define('BASE', dirname(_FILE_));
define('DOCUMENT_ROOT', rtrim($_SERVER['DOCUMENT_ROOT'], '/'));
define('BASE_RELATIVE', '');
Damit werden sogar die Kommentare Grau ( /\ ),
so rum bleiben sie normal ( \/ )
Es legt definitiv an diese Zeile:
define('BASE_RELATIVE', '');
Wenn ich diese Auskommentiere und die
define('BASE_RELATIVE', str_replace(DOCUMENT_ROOT, '', verwende geht
nichts.
Die Zeile mit \/ bei dir ist's andersrum Funktioniert bei mir, /\ so rum
jedoch nicht.
Also schließe ich diese aus.
Da geb ich dir recht das verwirrt einen, mal so rum und mal so hmm.
Wofür ist die Zeile: define('BASE_RELATIVE', ''); denn zuständig bzw wo
oder was greift denn darauf zu?
PS: Wie ist das eigentlich wenn ich z.B einen Bug oder so behoben hab
oder ähnlich. Euch das zugänglich zu machen, ohne das das mit den
Vorhandenen Dateien in Konflikt gerät?
Jetzt fehlt das Leerzeichen von '/\ ', dann wirkt der Backslash als
Steuerzeichen oder wie man das nennt. Besser wären eigentlich zwei
Backslashes hintereinander. Aber ich habe noch ein anderes Problem
bemerkt, jetzt sieht es so aus:
Wenn das immer noch nicht funktioniert, dann setz BASE_RELATIVE mal von
Hand. Welche dieser beiden Varianten funktioniert?
1
define('BASE_RELATIVE', '/part-db-0.3.0/');
2
define('BASE_RELATIVE', '\part-db-0.3.0\');
Marco tom Suden schrieb:> Wofür ist die Zeile: define('BASE_RELATIVE', ''); denn zuständig bzw wo> oder was greift denn darauf zu?
Damit können Pfadangaben (Links und Bilder) immer relativ zum
Verzeichnis des Webservers angegeben werden, bei dir also z.B.
"/part-db-0.3.0/ordner/datei.xy". Das funktioniert dann auch unabhängig
davon, ob das Ziel eines Pfades im gleichen Ordner wie die ausgeführte
Datei liegt oder irgendwo ganz anders. Möchte man in der Datei
/part-db-0.3.0/ordner/xy.php die Grafik /part-db-0.3.0/img/xy.png
einbinden, braucht es kein Link wie "../img/xy.png", sondern ganz
einheitlich BASE_RELATIVE."img/xy.png", was dann durch
"/part-db-0.3.0/img/xy.png" ersetzt wird.
Ich weiss aber nicht ob das auch unter Windows so funktioniert bzw. ob
ein Pfad mit Slashes oder Backslashes verlangt wird. Ich hoffe, du
kannst es rausfinden mit dem testen der obigen Codezeilen :-)
Marco tom Suden schrieb:> PS: Wie ist das eigentlich wenn ich z.B einen Bug oder so behoben hab> oder ähnlich. Euch das zugänglich zu machen, ohne das das mit den> Vorhandenen Dateien in Konflikt gerät?
Hmm wie meinst du das genau? Also das einfachste ist, wenn du nur die
geänderten Codezeilen hier postest, dann können wir das überprüfen und
einbauen.
Urban B. schrieb:> Ausserdem habe ich noch erste Versuche mit SQLite gestartet.
Das halte ich nicht für notwendig. Ich bin auch nicht gerade
Datenbankexperte, hatte aber mit MySQL (unter Linux) bisher keine
unüberwindbaren Probleme.
Je mehr Möglichkeiten man im Unterbau versteckt, desto mehr kann schief
gehen und um so schwieriger wird es im Zweifelsfall, dahinterzukommen,
was gerade schief gegangen ist.
Uhu Uhuhu schrieb:> Das halte ich nicht für notwendig. Ich bin auch nicht gerade> Datenbankexperte, hatte aber mit MySQL (unter Linux) bisher keine> unüberwindbaren Probleme.
Dass wir damit keine Probleme haben, heisst noch lange nicht, dass
andere auch keine Probleme damit haben :-)
Ausserdem ist das Erstellen von Backups mit SQLite noch ein wenig
einfacher, da man nur eine Datei sichern muss. Verwendet man MySQL, ist
z.B. MySQLDumper eine Möglichkeit, doch das ist auch schon wieder ein
Mehraufwand.
Ausserdem ist es ja nicht so, dass man für SQLite das Rad neu erfinden
muss. Ich weiss nicht ob du mitgekriegt hast, dass ab Version 0.3.0 ein
PDO (http://php.net/manual/de/book.pdo.php) zum Einsatz kommt. Das
erleichtert einem die Unterstützung für verschiedene Datenbanken enorm.
Ich muss mir das dann nochmal genau anschauen, aber ich vermute,
schlussendlich müssen nur die Update-Schritte leicht umgeschrieben
werden, damit sie bei beiden Datenbanken funktionieren. Ich habe mal
meine MySQL Datenbank in SQLite umgewandelt, Part-DB hat damit dann
sofort funktioniert ohne zu knurren. Einzig die Updateschritte müssen
wohl angepasst werden, und das ist ja keine grosse Sache wenn man mal
weiss worauf man achten muss. Das, was ich bisher schonmal rausgefunden
habe, schrieb ich schonmal in die db_update_steps.php rein, damit dort
jeder nachlesen kann worauf man achten muss:
https://part-db.googlecode.com/svn/branches/uneist_kami89/updates/db_update_steps.php
Nach dem Schreiben eines Update-Schrittes sollte man halt schnell mit
beiden Datenbanken probieren obs funktioniert, das ist aber keine grosse
Sache...
Übrigens soll auch die Geschwindigkeit für eher kleinere Datenbanken bei
SQLite ein Stück höher sein als bei MySQL. Für den Hobby-Anwender bringt
SQLite also eigentlich nur Vorteile mit sich, ich persönlich würde
vielleicht sogar auch auf SQLite umsteigen, einfach weil es
unkomplizierter ist.
Urban B. schrieb:> Nach dem Schreiben eines Update-Schrittes sollte man halt schnell mit> beiden Datenbanken probieren obs funktioniert, das ist aber keine grosse> Sache...
Tja, doppelter Testaufwand... Ich habe einige Erfahrung mit
Softwaretests und Fehlersuche nach Abstürzen beim Anwender und mein Sinn
für diese Metier sagt mir: "tus nicht und schon gar nicht ohne Not".
Stecke die Arbeit lieber in eine sehr solide Installationsroutine mit
Diagnose und unterstütze den Einsatz der für die DB gebräuchlichen
Datensicherungstools so, daß auch ein unbedarfter Nutzer damit klar
kommt.
Uhu Uhuhu schrieb:> Tja, doppelter Testaufwand... Ich habe einige Erfahrung mit> Softwaretests und Fehlersuche nach Abstürzen beim Anwender und mein Sinn> für diese Metier sagt mir: "tus nicht und schon gar nicht ohne Not".
Ja, grundsätzlich gebe ich dir da recht, keine Frage. Ich finde aber,
dass SQLite doch ziemlich starke Vorteile für den Endanwender mit sich
bringt. Einerseits natürlich die einfachere Handhabung bei der
Installation (der User muss nicht selbst eine Datenbank anlegen),
andererseits ermöglicht SQLite es uns Entwicklern, die Datenbankbackups
selbst zu übernehmen. Heisst also, wenn SQLite eingesetzt wird, kann
Part-DB z.B. vor jedem Datenbankupdate selbstständig ein Backup der DB
anlegen. Der Benutzer bekommt so völlig "kostenlos" eine höhere
Sicherheit. Aber auch die regelmässigen Backups könnte Part-DB dann
übernehmen.
Nutzt der Benutzer MySQL, können wir nicht viel mehr machen, als bei der
Installation einen Hinweis einzublenden wie "Machen Sie regelmässig und
vor jedem Datenbankupdate ein Backup!". Und dann ist da noch die
Möglichkeit, sich einen Link im Menü von Part-DB zu erstellen, die dann
z.B. zu MySQLDumper führt.
Aber mal ehrlich: Es wissen sooo viele Leute, dass man regelmässig
Backups machen sollte. Nur, wieviele davon machen es wirklich? Leider
nur ein Bruchteil davon. Ähnlich wird es wohl auch bei Datenbanken sein.
Daher finde ich es wichtig, dass Part-DB die Backups selbstständig
anlegen kann. Nach Zeitplan, und vor jedem Datenbankupdate. Nur ist das
bei MySQL sehr aufwändig und fehleranfällig, bei SQLite hingegen ist es
ein Kinderspiel.
Ich könnte mir dann sogar vorstellen, dass SQLite zur Standarddatenbank
von Part-DB wird, also schon voreigestellt ist bei der Installation.
Und wenn dann theoritisch wirklich mal ein DB-Update schief laufen
würde, wäre es kein Problem, da der ursprüngliche Zustand ja dank des
Backups ganz einfach wiederhergestellt werden kann :-) Das kann
natürlich vollautomatisch ablaufen, ohne Eingriffe des Benutzers. Bei
MySQL wüsste ich aber nicht mal, wie man vor einem Update zuerst ein
Backup erstellen könnte. Mehr als ein Hinweis "Machen Sie jetzt ein
Backup!" fällt mir da nicht ein. Wird das Backup nicht gemacht, hat der
Benutzer ein Problem wenn beim Update etwas schief läuft...Dann kann man
die DB nur noch von Hand retten, also alle Updateschritte z.B. in
phpMyAdmin durchführen.
Wenn du eine gute Möglichkeit zur Sicherung/Wiederherstellung einer
MySQL Datenbank kennst, die nicht allzu aufwändig ist und trotzdem
zuverlässig funktioniert und sich gut in Part-DB integrieren lässt, wäre
das natürlich auch super. Doch solange ich keine solche Möglichkeit
kenne, ist für mich SQLite interessanter weil wir den Benutzern mehr
Sicherheit bieten können.
Versteh mich nicht falsch - ich will nicht MySQL schlechtmachen oder so.
Ich finde einfach, die Sicherheit der Datenbanken der Part-DB-Benutzer
hat höchste Priorität. Diese Sicherheit können wir mit SQLite problemlos
bieten, bei MySQL hingegen müssen wir die Verantwortung dem Benutzer
abgeben. Wer MySQL nutzen möchte, kann dies natürlich machen, doch dann
muss er sich auch selber um die Backups kümmern.
Uhu Uhuhu schrieb:> Stecke die Arbeit lieber in eine sehr solide Installationsroutine mit> Diagnose
Das kommt sowieso, unabhängig davon ob nun SQLite auch eingebaut wird
oder nicht :-) Angefangen habe ich schonmal damit (install.php), ist
aber erstmal nur rudimentär, das wird noch ausgebaut.
mfg
Urban B. schrieb:> Jetzt fehlt das Leerzeichen von '/\ ', dann wirkt der Backslash als> Steuerzeichen oder wie man das nennt. Besser wären eigentlich zwei> Backslashes hintereinander. Aber ich habe noch ein anderes Problem> bemerkt, jetzt sieht es so aus:define('BASE', dirname(_FILE_));> define('DOCUMENT_ROOT', rtrim($_SERVER['DOCUMENT_ROOT'], '/\\'));> define('BASE_RELATIVE', str_replace(str_replace('/', DIRECTORY_SEPARATOR,
DOCUMENT_ROOT), '', BASE.DIRECTORY_SEPARATOR));
Also ich hab das mal versucht, soweit läuft das.
Aber! der Ganze bereich Verwaltung / Tools ist nicht erreichbar (Not
Found
The requested URL /part-db-0.3.0/part-db-0.3.0system_config.php was not
found on this server.)
Alles andere wie Baugruppen und die Kategorien sind aufrufbar!
define('BASE_RELATIVE', '/part-db-0.3.0/'); Funktioniert komplett!,also
auch Verwaltung und co.
Bei define('BASE_RELATIVE', '\part-db-0.3.0\');bekomme ich eine Meldung,
Parse error: syntax error, unexpected T_CONSTANT_ENCAPSED_STRING in
C:\wamp\www\part-db-0.3.0\start_session.php on line 83
Demnach wird alles unterhalb der Zeile ausgegraut,quasi Grauer Text!
Habe die laufende start_session.php mit denen genannten Änderungen mal
angehängt.
Marco tom Suden schrieb:> define('BASE_RELATIVE', '/part-db-0.3.0/'); Funktioniert komplett!,also> auch Verwaltung und co.
OK damit weiss ich jetzt dass Windows da auch Slashes haben will, und
nicht Backslashes. Ich habe die start_session.php nochmals angepasst,
jetzt müsste es eigentlich für Linux und Windows korrekt funktionieren.
Die neue Version ist schon im SVN, einfach schnell updaten lassen.
Hallo Urban,
Ich schreibe euch mal wie die Datensicherung EleLa macht:
Ich habe das mit der Datensicherung der MySQL DB in EleLa relativ leicht
gelöst:
- Man wählt die Sicherungsdatei aus, die ist eine SQLite Datenbank
- Darauf hin erstellt EleLa eine komplett neue SQLite Datenbankdatei mit
allen Tabellen (ich gehe mal davon aus, das kann PHP genauso machen,
nicht existierende Datei angeben und CREATE TABLE ...)
- Kopiert alle Datensätze von MySQL dort hinein.
Daraus ergeben sich 3 Vorteile:
- Die Sicherungsdatei ist automatisch eine Datenbank, die direkt mit
EleLa weiter benutzt werden kann (z.B. wenn man mal was in der Sicherung
kontrollieren möchte, und man muss das Backup nicht zurück spielen)
- Supereinfach zu Implementieren
- Die aktuelle Programm-Version kennt die Datenstruktur und macht in
jedem Fall ein korrektes Backup.
Beim zurück spielen des Backups geht EleLa so vor:
- Überprüfung der Version der Sicherung, ggf Update der Datenbankdatei,
denn ein Zurückspielen benötigt die gleiche Struktur
- Löschen aller MySQL Daten und zurückspielen der Daten, einzeln je
Tabelle
Vielleicht hilft das euch ja. Wenn Ihr Tipps benötigt, was die
Kompatibilität der SQL Befehle usw. angeht kann ich auch helfen.
MySQL/SQLite haben nur wenige Unterschiede.
Ich hatte zu Anfang auch größere Anfragen, weil der einfache User sich
mit MySQL/Einrichtung schwer tut. Jetzt da EleLa auch einfach mit einem
einfachen Setup und SQLite funktioniert gibt es kaum noch Rückfragen.
Wir könnten dem User für das Backup der MySQL-Datenbank ja ein kleines
Shellscript an die Hand geben, das er/sie dann in /etc/cron.* kopiert.
Bei den meisten Linux-Distris sollte ein Wrapper dann diese Scripte
automatisch im Kontext von cron ausführen. Unter Windows gibts auch
einen Scheduler, aber fragt mich nicht, wie man den quasi von Part-DB
aus einrichten könnte.
Markus Müller schrieb:> Hallo Urban,>> Ich schreibe euch mal wie die Datensicherung EleLa macht:
Hallo Markus,
Danke für die Info, ist tatsächlich eine sehr elegante Lösung die du da
gefunden hast! Ich denke, ich werde mir das mal genauer anschauen,
vielleicht wäre das für uns wirklich auch eine gute Lösung.
Markus Müller schrieb:> Vielleicht hilft das euch ja. Wenn Ihr Tipps benötigt, was die> Kompatibilität der SQL Befehle usw. angeht kann ich auch helfen.> MySQL/SQLite haben nur wenige Unterschiede.
Ja, ich habe eben festgestellt dass nur die Datenbank-Updates (Struktur
anpassen) von den Inkompatibilitäten betroffen sind, z.B. dass es
AUTOINCREMENT anstatt AUTO_INCREMENT heisst. Für die Benutzung braucht
man solche Befehle aber nicht, da läuft auch SQLite ohne jegliche
Anpassung auf Anhieb. Zumindest konnte ich nach einem kurzen Test noch
keine Probleme feststellen.
Und die Anpassung der Updateroutinen ist nunmal nicht wirklich eine
riesige Sache, meistens werden eh nur ganz kleine Sachen verändert. Nur
grad jetzt für die Version 0.3.0 gibt es sehr viele Änderungen. Da die
ganze Entwicklung für die 0.3.0 aber eh schon sehr lange dauert, kommt
es nicht mehr drauf an ob man nun das grosse Datenbankupdate zusätzlich
auch noch SQLite-kompatibel macht.
Markus Müller schrieb:> Ich hatte zu Anfang auch größere Anfragen, weil der einfache User sich> mit MySQL/Einrichtung schwer tut. Jetzt da EleLa auch einfach mit einem> einfachen Setup und SQLite funktioniert gibt es kaum noch Rückfragen.
Also werden nur die Backups als SQLite abgespeichert, oder kann man auch
direkt von Anfang an mit SQLite arbeiten?
Udo Neist schrieb:> Wir könnten dem User für das Backup der MySQL-Datenbank ja ein kleines> Shellscript an die Hand geben, das er/sie dann in /etc/cron.* kopiert.
Da gibts aber zwei Probleme:
- Erstens wird so sicher kein einfacher Benutzer mehr ein Backup machen,
weil er damit nicht zurechkommt, es ist einfach zu kompliziert
- Zweitens läuft diese Variante so nicht auf jedem gemieteten Webserver
(Hoster). Klar gibt es meistens auch cron, doch ich wüsste nichtmal wie
man sowas einrichtet. Ein Backup einer SQLite Datenbank hingegen
funktioniert problemlos auch auf einem Webspace. Und auch der Vorschlag
von Markus dürfte dort problemlos funktionieren.
mfg