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
Urban B. schrieb:> (der User muss nicht selbst eine Datenbank anlegen)
Das kann auch die Installationsroutine erledigen.
> wenn SQLite eingesetzt wird, kann> Part-DB z.B. vor jedem Datenbankupdate selbstständig ein Backup der DB> anlegen.
PHP kann doch ein Shell-Skript, bzw. das Windows-Äquivalent dazu
starten, oder nicht?
> Versteh mich nicht falsch - ich will nicht MySQL schlechtmachen oder so.
Mir geht es nicht um MySQL - hätten wir SQLite, dann wäre meine
Argumentation gegenüber MySQL dieselbe -, sondern um den Testaufwand.
Wir unterstützen zwei Betriebssysteme und wenn wir dann auch noch zwei
Datenbanken unterstützen, dann muß - wenn man es solide machen will -
schon der vierfache Testaufwand betrieben werden.
Wie gründlich man als Entwickler sowas dann letztlich macht, wirst du
selbst wissen. Mein innerer Schweinehund hat mich meistens davor
bewahrt, das auch nur annähernd gründlich genug zu tun und die Quittung
kam dann mit ziemlicher Sicherheit hinterher.
Markus Müller schrieb:> 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
Warum sicherst du in eine SQLite DB?
Ich habe in einem Rails-Projekt recht gute Erfahrungen mit dem
Dump-Programm von MySQL gemacht. Das kickt man an und schon hat man eine
Textdatei, die alle Daten enthält, mit der man eine leere DB befüllen
kann und das Anlegen einer leeren DB kann man per Skript machen, das aus
der Installationsroutine angekickt wird.
Uhu Uhuhu schrieb:> PHP kann doch ein Shell-Skript, bzw. das Windows-Äquivalent dazu> starten, oder nicht?Uhu Uhuhu schrieb:> Ich habe in einem Rails-Projekt recht gute Erfahrungen mit dem> Dump-Programm von MySQL gemacht. Das kickt man an und schon hat man eine> Textdatei, die alle Daten enthält, mit der man eine leere DB befüllen> kann und das Anlegen einer leeren DB kann man per Skript machen, das aus> der Installationsroutine angekickt wird.
Ja, genau so hatten wir es schonmal eingebaut, das funktioniert auch
wunderbar solange man genügend Rechte hat, so ein Skriptauszuführen. Unser Ziel ist es aber, dass Part-DB weitgehendst auch
auf einem einfachen Webspace läuft - und da ist dann häufig nix mehr mit
Skripte ausführen, weil exec() vom Hoster gesperrt ist.
Urban B. schrieb:> 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.
Jo hab das update gemacht wie du sagtest,mit der aus der svn.
Also es läuft super. Fehler hinsichtlich dessen habe ich keine mehr.
Damit währe glaube ich mal diese Punkt abgehakt,oder.
Was is denn sonst noch so auf der Bug-list oder wie man das jetzt
nennt?.
Marco tom Suden schrieb:> Damit währe glaube ich mal diese Punkt abgehakt,oder.
Jup, die Pfad-Konstanten sollten somit (hoffentlich) auf allen Systemen
funktionieren.
Marco tom Suden schrieb:> Was is denn sonst noch so auf der Bug-list oder wie man das jetzt> nennt?.
Nun, da sind noch einige Sachen. Zum richtig Testen ist es eigentlich
noch zu früh denke ich. Eine ToDo-Liste gibts noch in der
Quellcode-Dokumentation (nicht alle Punkte betreffen aber die Version
0.3.0 - einige können noch länger warten, z.B. die System-Updates und
die Benutzerverwaltung).
Wenn du in der config.php die Einstellung "developer_mode" auf "true"
stellst, kommt ein neuer Menüpunkt "Entwickler-Werkzeuge" zum Vorschein,
dort drin ist dann der Link zur Quellcode-Dokumentation.
Wichtig wäre mir in nächster Zeit mal jemand der sich mit Datenbanken
etwas besser auskennt, da einige kompliziertere Abfragen noch nicht
genau das machen was sie sollten :-)
>z.B. dass es AUTOINCREMENT anstatt AUTO_INCREMENT heisst
Bei SQLite deklariere ich das Feld nur als "INTEGER NOT NULL PRIMARY
KEY" und es ist automatisch ein Autoincrement-Feld.
EleLa merkt sich den CREATE TABLE Code als SQLite Syntax. Dazu habe ich
eine Routine geschrieben "ChgQueryCreateSQL()", die biegt alles um auf
MySQL und PostgreSQL. Feldtypen, AutoIncrement und Indize.
Wichtig ist, dass Felder mit der gleichen Funktion auch den gleichen
Name haben, wie "ID" "Bezeichnung" "Beschreibung" "AendDatum" um die
globalen Funktionen besser nutzen zu können.
>Also werden nur die Backups als SQLite abgespeichert, oder kann man auch>direkt von Anfang an mit SQLite arbeiten?
EleLa kann SQLite, MySQL und PostgreSQL. Nach dem ersten Setup wird man
in der Regel mit SQLite beginnen um mal rein schnuppern zu können ob
einem überhaupt das Programm gefällt und es sind auch schon einige
Datensätze (Widerstände) vorhanden.
Jederzeit kann man auf MySQL oder PostgreSQL wechseln.
Wenn man in EleLa nur die Verbindungsdaten des MySQL Servers eingibt, so
kann EleLa mit einem Tastenklick eine neue Datenbank samt aller Tabellen
automatisch anlegen (der MySQL-User muss natürlich die Rechte haben).
Ein Import der bestehenden SQLite Daten in MySQL und man hat innerhalb
weniger Sekunden MySQL als Server.
Mit EleLa ist der Wechsel der Datenbank ein Kinderspiel und alles
Menügeführt.
Markus Müller schrieb:> EleLa merkt sich den CREATE TABLE Code als SQLite Syntax. Dazu habe ich> eine Routine geschrieben "ChgQueryCreateSQL()", die biegt alles um auf> MySQL und PostgreSQL. Feldtypen, AutoIncrement und Indize.
So ähnlich habe ich mir das auch vorgestellt. Da Part-DB bis jetzt nur
MySQL unterstützte, sind alle Updatebefehle auch in MySQL Syntax
gespeichert. Nun habe ich in der Updateroutine einfach mal ein
rudimentärer "Konverter" eingebaut, der eben z.B: ein "AUTO_INCREMENT"
automatisch durch ein "AUTOINCREMENT" ersetzt, oder sowas wie
"ENGINE=InnoDB" entfernt.
Ich habe auch festgestellt dass mit SQLite das hier nicht funktioniert:
1
INSERT INTO tabelle SET key=value
Das hier funktionier hingegen bei SQLite und MySQL:
1
INSERT INTO tabelle (key) VALUES (value)
Schlussendlich müssen wir Entwickler uns einfach darauf einigen, dass
immer die zweite Variante verwendet wird. Das sollte eigentlich kein
Problem sein, an andere Code-Guidelines halten wir uns ja auch.
Und wenn wirklich mal eine fehlerhafte Datenbankabfrage in ein Release
kommt - davon geht die Welt auch nicht unter. Ausser der Fehler passiert
beim Datenbankupdate und es existiert kein Backup - dieses Problem
hätten wir aber bei SQLite sicher nicht, und wenn wir dein System für
das Backup einer MySQL Datenbank auch noch einbauen, existiert das
Problem auch bei MySQL nicht mehr.
Markus Müller schrieb:> EleLa kann SQLite, MySQL und PostgreSQL. Nach dem ersten Setup wird man> in der Regel mit SQLite beginnen um mal rein schnuppern zu können ob> einem überhaupt das Programm gefällt
Genau sowas finde ich für Einsteiger sehr wichtig, darum "kämpfe" ich ja
auch für die Unterstützung von Part-DB für SQLite :-)
Auch der Installer, den es bisher noch nicht gab, finde ich wichtig. Ich
bin mir ziemlich sicher, dass schon viele Leute Part-DB runtergeladen
haben, dann aber mit dem Einrichten überfordert waren und es aufgegeben
haben. Das ist natürlich schade, denn mit einem benutzerfreundlichem
Installer und SQLite-Datenbank lässt sich das weitgehendst verhindern.
Dass man auch einfach zwischen verschiedenen Datenbanken wechseln kann,
ist für den Anfang sicher nicht notwendig. Später, wenn wir mehr Zeit
für solche Sachen haben, könnte man natürlich immernoch einen
"Konverter" einbauen. Momentan haben wir aber wichtigere Sachen zu tun
:-)
EDIT:
Ich habe in unseren "Issues" gleich mal einen Link eingefügt zur
Beschreibung der Datenbanksicherung von Markus:
https://code.google.com/p/part-db/issues/detail?id=3
>Später, wenn wir mehr Zeit für solche Sachen haben
Ja, klar. War bei mir am Anfang auch nicht drin und kam erst später.
Macht erst mal weiter mit eurem Projekt und bringt das auf einen guten
Stand.
Irgend wann einmal, wenn PartDB gut läuft können wir auch mal dran gehen
und EleLa/PartDB von der Datenstruktur her angleichen, dann wäre EleLa
und PartDB mit dem gleichen Datenbestand nutzbar. Ein Front-End für
Lokal und eines Internettauglich :-)
Im moment sind die noch zu verschieden, hier die EleLa-DB:
http://www.mmvisual.de/Hilfe/EleLa/TutorialDB/TutDB.htm
Habe grad mal alles durch gegangen,als ich bei Zeige/Statistik an kam,
dauerte es erst ne weile bis überhaupt was angezeigt wurde.
Zuerst war es ne art Fehlermeldung, wo was von Time-out 30 sec etc
stand.
Nach dem 2 Versuch öffnete sich die Seite wie sie soll, jedoch fiel mir
sofort das Karo mit (?) ins Auge. Das sicherlich das € darstellen
soll,was glaub ich mal an der Kodierung UTF-8 / ANSI liegt.
Demnach habe ich in der config.php unten diese Auskommentierte Zeile
wieder Aktiv gemacht:
$manual_config['money_format']['de_DE'] = '%!n Euro';
Naja dementsprechend wird nun statt dem Karo (Euro) ausgegeben.
Nach Änderung dieser Zeile in:
$manual_config['money_format']['de_DE'] = '%!n €'
war das Karo wieder da,logisch da die config.php in ANSI Kodiert ist,
als ich sie jedoch in UTF-8 Kodiert hab war das € Zeichen da.
Wie es sicherlich soll.
Ich weis grad nicht,ob das bei euch auch so ist.
Daher dachte ich ich schreib euch das einfach mal.
Daß ein unbedarfter User mit MySQL zurecht kommt, ist letztendlich eine
Frage der Anleitung, nach der er das macht. Er muß ja nicht im Einzelnen
verstehen, was da passiert, aber so lange er ein Kochrezept an die Hand
bekommt, nach dem er nur Schritt für Schritt vorgehen muß, dann wird er
diese Klippe nehmen. Und wenn man ihn zusätzlich noch mit Skripten
versorgt, die ihn vor Tippfehlern bewahren, dann ist das ganz prima.
Nur ohne, oder mit einer Doku, die in Rudimenten über diverse Threads,
Quelltexte, Readmes etc. pp. verstreut ist, wird das natürlich nix.
Marco tom Suden schrieb:> Habe grad mal alles durch gegangen,als ich bei Zeige/Statistik an kam,> dauerte es erst ne weile bis überhaupt was angezeigt wurde.
Das ist eine Baustelle, wo mal einer mit mehr Datenbankkenntnissen ran
muss :-) Momentan habe ich dort noch improvisiert, es werden Sachen mit
PHP berechnet, die man (mit genügend Kenntnissen^^) auch mit SQL machen
könnte, damit würde es gleich viel schneller gehen.
Marco tom Suden schrieb:> Nach dem 2 Versuch öffnete sich die Seite wie sie soll, jedoch fiel mir> sofort das Karo mit (?) ins Auge. Das sicherlich das € darstellen> soll,was glaub ich mal an der Kodierung UTF-8 / ANSI liegt.
Ja, das ist auch ein Problem von mir, weil ich da den Durchblick noch
nicht habe mit den verschiedenen Kodierungen :-( In der Konfiguration
kannst du übrigens noch den Zeichensatz ändern, bringt das auch nichts
wenn du den auf "ISO-8859-1" stellst?
In den *.tmpl Dateien sind bisher auch alle ä, ö, ü ganz normal
gschrieben, und nicht in HTML-Schreibweise (ä). Bei mir
funktioniert das zwar, ich weiss aber nicht inwiefern das auch mit
anderen Systemen kompatibel ist, bzw. ob sich das mit dem Ändern des
Zeichensatzes lösen lässt.
Udo, hast du hier vielleicht den Durchblick und kannst mir mit ein paar
Sätzen mal einen kurzen Crashkurs geben? :-D
Ich finde die Schreibweise ä mühsam und würde sie gerne vermeiden
wenn es geht.
Markus Müller schrieb:> Irgend wann einmal, wenn PartDB gut läuft können wir auch mal dran gehen> und EleLa/PartDB von der Datenstruktur her angleichen, dann wäre EleLa> und PartDB mit dem gleichen Datenbestand nutzbar. Ein Front-End für> Lokal und eines Internettauglich :-)> Im moment sind die noch zu verschieden, hier die EleLa-DB:> http://www.mmvisual.de/Hilfe/EleLa/TutorialDB/TutDB.htm
Uiuiui, da hat sich ja schon richtig was ergeben bei dir :-D Gegen deine
DB sieht unsere ja grad mickrig aus :-D
Also falls das mal was werden würde mit dem Angleichen von
Part-DB/EleLa, dann sicher erst in ferner Zukunft. Unsere nächsten Ziele
sind erstmal die Version 0.3.0 stabil zu machen. Dann arbeiten wir auf
die Version 1.0.0 hin, wo nochmal sehr viel getan werden muss: es soll
eine Benutzerverwaltung und ein automatisches System-Update geben.
Die Arbeit geht uns erstmal also nicht aus :-)
Uhu Uhuhu schrieb:> Daß ein unbedarfter User mit MySQL zurecht kommt, ist letztendlich eine> Frage der Anleitung, nach der er das macht.
Ja stimmt schon auch. Aber dann müssen wir wieder zwei verschiedene
Anleitungen schreiben, eine für Windows und eine für Linux. Ist also
auch doppelter Aufwand.
Naja - ich werde mir in den nächsten paar Wochen das Thema SQLite
nochmal genauer anschauen und ausführlichere Tests machen. Dann kann man
besser abschätzen wieviel Mehraufwand es wirklich bedeutet. Bis jetzt
habe ich aber den Eindruck, mit ein paar SQL Guidelines kriegen wir das
sehr gut in den Griff.
Urban B. schrieb:> Ja, das ist auch ein Problem von mir, weil ich da den Durchblick noch> nicht habe mit den verschiedenen Kodierungen :-( In der Konfiguration> kannst du übrigens noch den Zeichensatz ändern, bringt das auch nichts> wenn du den auf "ISO-8859-1" stellst?
Ja das geht auch, meinte nur wenn man das auf utf-8 hat geht's nicht.
Mit ISO-8859-1 geht's auch mit auskommentierter Zeile.
Unter utf-8 jedoch nicht.
Wenn du nichts dagegen hast,würde mir gern mal die ganze
Konstruktion,etwas genauer ansehen,vtl Find ich ja ne Lösung dafür ;-).
Marco tom Suden schrieb:> Ja das geht auch, meinte nur wenn man das auf utf-8 hat geht's nicht.> Mit ISO-8859-1 geht's auch mit auskommentierter Zeile.>> Unter utf-8 jedoch nicht.>> Wenn du nichts dagegen hast,würde mir gern mal die ganze> Konstruktion,etwas genauer ansehen,vtl Find ich ja ne Lösung dafür ;-).
Ach so, dann ist doch alles gut? :-)
Genau für diesen Fall gibts doch die Möglichkeit, den Zeichensatz zu
ändern.
Meine Vermutung ist, dass Zeichen wie ä halt immer funktionieren,
unabhängig vom Zeichensatz. Verwendet man aber ganz normale Zeichen wie
ä, ö, ü, so muss man dem Browser halt mitteilen wie er die Zeichen
interpretieren soll. Ist aber nur eine Vermutung von mir, da ich
eigentlich mit Webseiten-Entwicklung nicht viel am Hut habe.
Vielleicht sollte man in der Installationsroutine eine Erkennung des
Betriebssystems einbauen. Wird Windows verwendet, soll der Zeichensatz
automatisch auf ISO-8859 gesetzt werden, ansonsten auf utf-8.
Urban B. schrieb:> Ach so, dann ist doch alles gut? :-)> Genau für diesen Fall gibts doch die Möglichkeit, den Zeichensatz zu> ändern.
Ja aber mir ist grade aber aufgefallen das andere texte wie der Button
(Einstellungen übernehmen) plötzlich unter ISO Merkwürdige Zeichen
enthalten.
Wenn man die config.php dann aber wieder in utf konvertiert ist alles
easy,und sauber.
Da gibts aber sicherlich ne Lösung für.
Ich versuche grad der Statistik bei zu bringen die Daten aus der
Database direct aus zu lesen,vtl läuft es dann schneller.
Zu dem Kodierung's Konstrukt,fällt mir sicher auch was ein ;-)
Die Zeichen in der DB sollten immer UTF-8 sein, denn wenn man mal einen
Server-Umzug von Windows <> Linux macht, dann sollte der eine Export
beim anderen Import immer gehen.
Zum zweiten ist UTF-8 unter Linux Standard.
Mit htmlentities() sollte das ganze dann auch korrekt gewandelt werden.
>Uiuiui, da hat sich ja schon richtig was ergeben bei dir :-D
Bei meiner Versino 0.x war das auch noch so. ;-)
Um so mehr PartDB nutzen um so mehr Anforderungen und entsprechend
Tabellen/Felder wird es geben.
Foreign Key's nutze ich nicht, denn SQLite kann das nicht. Wird alles im
Programm geprüft.
Markus Müller schrieb:> Foreign Key's nutze ich nicht, denn SQLite kann das nicht. Wird alles im> Programm geprüft.
Grad die Foreign Keys muessen vom Datenbanksystem ueberprueft werden.
Die Integritaet der Datenbank wird ja schliesslich hauptsaechlich von
fehlerhaften Referenzen in andere Tabellen bedroht.
Die Ueberpruefung der referenziellen Integritaet muss unbedingt vom DB
System gemacht werden. Dazu muessen die Foreign Keys natuerlich in den
Schemadefinitionen definiert werden. Das wird vermutlich eine ganze
Menge Fehler aufbringen, weil ein INSERT dann schlicht nicht moeglich
ist, wenn es den Key, auf den verwiesen wird, noch nicht gibt. In dem
Fall muss man dann die Statements im PHP Code umstellen.
Viele Gruesse
Christoph
Markus Müller schrieb:> Die Zeichen in der DB sollten immer UTF-8 sein, denn wenn man mal einen> Server-Umzug von Windows <> Linux macht, dann sollte der eine Export> beim anderen Import immer gehen.
Ja, das macht Sinn. Ist bei Part-DB auch standardmässig auf UTF-8
gesetzt, kann jedoch geändert werden. Theoretisch könnte man diese
Möglichkeit vielleicht auch noch rauswerfen, also dass es immer mit
UTF-8 arbeitet, da dies ja jeder MySQL Server unterstützen sollte.
Markus Müller schrieb:> Foreign Key's nutze ich nicht, denn SQLite kann das nicht.
Sicher? http://www.sqlite.org/foreignkeys.html
Stimmt, jetzt kann SQLite das. Ab der Version 3.6.19.
Ich nutze schon viel länger SQLite und damals konnte SQLite das nicht.
Wenn Du jetzt SQLite mit Foreign Keys unter Linux nutzt, dann musst Du
auch sicherstellen, dass die DLL libsqlite.so auch wirklich eine
aktuelle ist. Ältere Linux-Distris haben zum Teil nicht die neueste
libsqlite mit dabei. Ich meine sogar, als ich vor einem halben Jahr mal
Debian in eine VBox installiert habe, dass dort auch nur eine
V3.6.irgendwas dabei war und nicht mal eine 3.7.x.
Bei mir überprüft EleLa die Konsistenz der Daten und ich zeige auch
entsprechende Fehlermeldungen. Wenn das nur die DB macht, dann kommen
kryptische Meldungen auf den Bildschirm und das ist immer schwierig zu
handeln. Foreign Keys sind nur für den Notfall da, falls man mal ein Bug
in der Programmierung drin hat, um die Daten zu schützen.
EleLa macht auch alles mit UTF-8, da das Standard der
Programmierumgebung Lazarus ist. Damit wäre schon mal der erste
Meilenstein für das Zusammenspiel gelegt ;-)
Bei MySQL lege ich die DB immer mit dem Code an:
1
CREATE DATABASE IF NOT EXISTS <######> DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci
Also hier unter Ubuntu 12.10 ist SQLite 3.7.13 in den offiziellen
Paketquellen. Wie es auf den gängigen Webservern aussieht, weiss ich
aber nicht.
Part-DB hat eigentlich eh schon "relativ hohe" Anforderungen an die
PHP-Version (mind. 5.3), da sollte die hohe Anforderung bei SQLite auch
nicht mehr so schlimm sein. Obwohl man meinen würde, dass heute PHP5
Standard ist, musste ich meinen Webhoster anfragen ob Sie mir PHP 5.3
installieren könnten. Die haben immer noch PHP4, und per Webfromular
kann man es auf 5.2 aktualisieren lassen. Mit einer persönlichen Anfrage
aktualisieren sie aber auch auf 5.3.
Alternativ könnte man immernoch im Installer schreiben:
Entweder SQLite >= 3.6.19, oder dann MySQL.
Obwohl auch in Part-DB seit der Version 0.3.0 die Beziehungen sehr genau
"von Hand" überprüft werden, ist die Überprüfung durch das
Datenbanksystem per Foreign Keys doch nochmal ein Plus an Sicherheit.
Das werde ich noch einbauen müssen, bis jetzt werden nämlich auch bei
MySQL keine Foreign Keys verwendet...
@Markus
Habe ich das eigentlich richtig verstanden, dass bei SQLite die Indizes
innerhalb der ganzen Datenbank eindeutig sein müssen, bei MySQL aber nur
innerhalb einer Tabelle?
Nein, bei mir sich die Indizes nur innerhalb der Tabelle eindeutig. Das
geht so wie ich oben gezeigt habe.
Aber, wenn man bei SQLite den letzten Datensatz (z.B. ID = 15) löscht,
dann ist der letzte ID = 14. Wenn man nun einen neuen Datensatz anlegt,
so erhält der wieder 15. Bei MySQL würde der Datensatz die ID = 16
erhalten. SQLite ist schon eine wirklich einfache Datenbank, SQLite ist
fast wie ein Müllschlucker und frisst alles.
Besonders musst Du auf Datums und Zeitfelder aufpassen und die besser
als Float Felder abfragen und selbst in das gewünschte Anzeigeformat
wandeln, damit habe ich ständig Probleme. Das Datumsfeld als Float
abzufragen macht bei MySQL keine Probleme.
Die SQLite Version kannst Du mit dem SQL Befehl einfach auslesen:
SELECT sqlite_version() AS Vers
Markus Müller schrieb:> Nein, bei mir sich die Indizes nur innerhalb der Tabelle eindeutig. Das> geht so wie ich oben gezeigt habe.
Hmm okay, dann muss ich mir das nochmal anschauen...Ich bekam immer eine
Fehlermeldung (blabla...already exists...blabla) wenn ein gleichnamiger
Index bereits in einer anderen Tabelle vorhanden war.
Momentan habe ich aber für sowas keine Zeit. Ab Freitag kanns dann
wieder richtig weitergehen :-)
Vermutlich muss nur der Name des Indizes eindeutig sein, den also so
z.B. benennen:
TabellenName_FeldName_IX
Probiere das mal.
PS: Index oder Primary key? Nicht dass wir jetzt da was durcheinander
bringen.
Bei sieht das z.B so aus:
CREATE TABLE IF NOT EXISTS bauteil (
ID INTEGER NOT NULL PRIMARY KEY,
: :
AendDatum DATETIME);
CREATE TABLE IF NOT EXISTS bauteillager (
ID INTEGER NOT NULL PRIMARY KEY,
: :
AendDatum DATETIME);
Hinterher erzeuge ich die Indizes.
Markus Müller schrieb:> Vermutlich muss nur der Name des Indizes eindeutig sein, den also so> z.B. benennen:> TabellenName_FeldName_IX
Ja, genau das meine ich. Es gibt bei uns verschiedene Tabellen, die
gleichnamige Spalten haben. Also eine Spalte "A" in Tabelle 1, und eine
Spalte "A" in Tabelle 2. Bei beiden ist diese Spalte A auch ein Index
(nicht Primary Key) und heisst ebenfalls "A". Und da bekomme ich bei
SQLite eine Fehlermeldung dass so ein Index schon existiert, bei MySQL
hingegen funktioniert es. Daher kam die Vermutung, dass die Namen der
Indizes bei MySQL nur innerhalb einer Tabelle eindeutig sein müssen, bei
SQLite jedoch innerhalb der ganzen Datenbank.
Aber ein "Tabellenname_" vor die Index-Namen zu setzten ist natürlich
kein Problem, werde ich dann vermutlich so einbauen.
Als nächstes (wenn ich wieder Zeit habe) werden aber erstmal überall
Transaktionen eingebaut, damit im Fehlerfall immer ein Rollback
durchgeführt werden kann. Und dann den Installer noch etwas ergänzen,
die Importfunktionen wieder zum laufen bringen, einige kleine Bugs
beheben usw usw... :-)
mfg
Transaktionen machen die DB auch schneller, da erst mal nichts auf die
Disk geschrieben wird.
Wenn Du fragen zu SQL Befehlen hast kannst Du mir auch eine PN
schreiben.
Ich kann Dir auch Teile von EleLa schicken, damit Du siehst wie ich z.B.
"ChgQueryCreateSQL()" mache oder Felder im Update hinzufüge.
Ist halt Lazarus/Pascal und Du müsstest das umschreiben auf PHP.
Markus Müller schrieb:> Transaktionen machen die DB auch schneller, da erst mal nichts auf die> Disk geschrieben wird.
Aber beim COMMIT wird synchron geschrieben, was den
Geschwindigkeitsvorteil wieder relativiert.
Transaktionen dienen der Datenkonsistenz und nicht der Geschwindigkeit.
Erst wenn alle SQL-Aktionen innerhalb einer Transaktion fehlerfrei
ausgeführt wurden, dann erfolgt das COMMIT und die Datenbank schreibt
die Daten endgültig auf Platte. Wenn man Geschwindigkeit herausholen
möchte, dann per Indices, Keys, Cache etc. SQLite ist zwar nett, aber
nur für Einzelplatzsysteme wirklich sinnvoll. Erstmal ist MySQL zu
bedienen, danach kann man ja auch andere Systeme unterstützen. Die Idee,
SQLite als Backup zu nutzen, finde ich interessant.
Markus Müller schrieb:> Wenn Du fragen zu SQL Befehlen hast kannst Du mir auch eine PN> schreiben.> Ich kann Dir auch Teile von EleLa schicken, damit Du siehst wie ich z.B.> "ChgQueryCreateSQL()" mache oder Felder im Update hinzufüge.
Danke für das Angebot, ich werde darauf zurückkommen wenn ich soweit bin
und Hilfe brauchen könnte.
> Ist halt Lazarus/Pascal und Du müsstest das umschreiben auf PHP.
Das ist kein Problem, ich habe auch mal Pascal programmiert :-)
Udo Neist schrieb:> SQLite ist zwar nett, aber> nur für Einzelplatzsysteme wirklich sinnvoll.
Und genau das wird für viele Benutzer schon genügen, da sie zu Hause
Part-DB nur auf einem einzigen Computer benutzen ;-)
Udo Neist schrieb:> Erstmal ist MySQL zu> bedienen, danach kann man ja auch andere Systeme unterstützen.
Jup, erstmal hat MySQL schon Priorität. Wenn es aber kein grosser
Aufwand ist, kann ich SQLite auch schon in die Version 0.3.0 einbauen.
Übrigens habe ich gerade noch das Auslesen der SVN-Revision mit einem
PDO Objekt gelöst, funktioniert wunderbar :-) Wird in nächster Zeit mal
noch ins SVN hochgeladen...
Der Filemanager nimmt so langsam Formen an. Ich habe heute am
Dialogsystem gearbeitet. Damit ihr euch schon mal ein Bild davon machen
könnt, habe ich zwei Screenshots angehängt.
Das ganze basiert auf zwei Javascript-Klassen mit eigenem Namensraum.
Derzeit fehlt noch die Anbindung der Dialogbuttons an frei definierbare
Funktionen innerhalb der DOM-Klasse. Das Aussehen der Elemente ist in
CSS-Dateien definiert. Im Moment erbt der Dialog noch ein Element der
Webseite, wird aber noch korrigiert. Der PHP-Unterbau benötigt eine
fileIO-Klasse.
Sieht doch schonmal ganz gut aus!
Vielleicht könnte man ja den Bereich "Ausgawähltes File / Dateiinfos"
noch auf die rechte Seite nehmen, dann ist es auch besser für
Bildschirme mit niedriger Auflösung (z.B. 1366x768) geeignet. Die blöden
Netbooks haben einfach eine viel zu niedrige vertikale Auflösung...
Ach ja, falls das noch nicht geplant ist: Ganz oben wäre noch eine
Navigations-Zeile sinnvoll, damit man sieht in welchem Ordner man sich
gerade befindet. Also sowas in der Art:
1
media / footprints / TQFP
Wobei natürlich jedes dieser Elemente ein Link sein könnte um zum
jeweiligen Ordner navigieren zu können.
Bin auf jeden Fall schonmal gespannt auf den fertigen Dateimanager :-)
Urban B. schrieb:> Sieht doch schonmal ganz gut aus!
Danke :-)
> Vielleicht könnte man ja den Bereich "Ausgawähltes File / Dateiinfos"> noch auf die rechte Seite nehmen, dann ist es auch besser für> Bildschirme mit niedriger Auflösung (z.B. 1366x768) geeignet. Die blöden> Netbooks haben einfach eine viel zu niedrige vertikale Auflösung...
Dank CSS lassen sich die 4 Blöcke (Ordner, Dateiinfo, Commands und
Explorer) frei verschieben. Nur die IDs sind fest vergeben.
> Ach ja, falls das noch nicht geplant ist: Ganz oben wäre noch eine> Navigations-Zeile sinnvoll, damit man sieht in welchem Ordner man sich> gerade befindet. Also sowas in der Art:>
1
media / footprints / TQFP
> Wobei natürlich jedes dieser Elemente ein Link sein könnte um zum> jeweiligen Ordner navigieren zu können.
Breadcrumb-Navigation? Existiert schon auf der globalen Ebene der
Webseite und wäre für den Dateimanager recht einfach zu adaptieren. Die
Navigation enthält aber keine Links. Werde ich mal für die nächste Runde
umsetzen.
> Bin auf jeden Fall schonmal gespannt auf den fertigen Dateimanager :-)
:-)
Udo Neist schrieb:> Dank CSS lassen sich die 4 Blöcke (Ordner, Dateiinfo, Commands und> Explorer) frei verschieben. Nur die IDs sind fest vergeben.
OK super!
Udo Neist schrieb:> Breadcrumb-Navigation?
Lol, wusste gar nicht dass das so heisst xD Aber ja, laut Wikipedia ist
das genau das was ich meinte :-) Halt wie in Nautilus, Windows Explorer
usw.
Sind eigentlich die beiden Ordner links oben auf dem Screenshot
aufklappbare Menüs wo dann die ganze Verzeichnisstruktur ersichtlich
ist?
Urban B. schrieb:>> Breadcrumb-Navigation?>> Lol, wusste gar nicht dass das so heisst xD Aber ja, laut Wikipedia ist> das genau das was ich meinte :-) Halt wie in Nautilus, Windows Explorer> usw.>> Sind eigentlich die beiden Ordner links oben auf dem Screenshot> aufklappbare Menüs wo dann die ganze Verzeichnisstruktur ersichtlich> ist?
In meinem Beispiel sind das zwei fest vergebene Verzeichnisse, die
unterhalb eines gemeinsamen Verzeichnisses liegen. Ausserhalb dieser
Verzeichnisse kann der Filemanager nicht zugreifen.
Natürlich lassen sich diese Verzeichnisse auch ändern. Entsprechend dem
Einsatzzweck muss man die Konfiguration und Suchfunktion anpassen. Ich
habe mal die Dateisuchfunktion rauskopiert, damit man mal eine
Vorstellung davon hat.
Udo Neist schrieb:> In meinem Beispiel sind das zwei fest vergebene Verzeichnisse, die> unterhalb eines gemeinsamen Verzeichnisses liegen. Ausserhalb dieser> Verzeichnisse kann der Filemanager nicht zugreifen.
Jup, ich denke schlussendlich soll der Benutzer die Verzeichnisse
"img/footprints/", "/img/iclogos/" und "media/" im Dateibrowser zur
Verfügung haben. In "img/..." darf er aber nur Leserechte haben, da die
dort enthaltenen Dateien von Part-DB verwaltet werden, also auch Updates
bekommen. Fummelt der Benutzer da drin rum, gibts nur ein Chaos.
Für die Dateien des Benutzers ist der Ordner "media/" vorhanden, dort
kann er tun und lassen was er möchte. Part-DB hingegen wird dort keine
Dateien ablegen.
Möchte ein Benutzer z.B. die Footprint-Bilder auf eine andere Art und
Weise sortiert haben, so muss er unseren Footprint-Ordner nach media/
kopieren und dort nach seinen Wünschen organisieren.
Urban B. schrieb:> Udo Neist schrieb:>> In meinem Beispiel sind das zwei fest vergebene Verzeichnisse, die>> unterhalb eines gemeinsamen Verzeichnisses liegen. Ausserhalb dieser>> Verzeichnisse kann der Filemanager nicht zugreifen.>> Jup, ich denke schlussendlich soll der Benutzer die Verzeichnisse> "img/footprints/", "/img/iclogos/" und "media/" im Dateibrowser zur> Verfügung haben. In "img/..." darf er aber nur Leserechte haben, da die> dort enthaltenen Dateien von Part-DB verwaltet werden, also auch Updates> bekommen. Fummelt der Benutzer da drin rum, gibts nur ein Chaos.
Ich kann ja den Filemanager soweit ergänzen, dass er neben den
Verzeichnisnamen auch Rechte verwaltet. Wäre also sowas wie:
1
$dir[0]['dir']="img/footprints/";
2
$dir[0]['name']="Footprints";
3
$dir[0]['type']="image";
4
$dir[0]['mode']="ro";
5
$dir[1]['dir']="img/iclogos/"
6
$dir[1]['name']="IC Logos";
7
$dir[1]['type']="image";
8
$dir[1]['mode']="ro";
9
$dir[2]['dir']="media/"
10
$dir[2]['name']="Media";
11
$dir[2]['type']="";
12
$dir[2]['mode']="rw";
>> Für die Dateien des Benutzers ist der Ordner "media/" vorhanden, dort> kann er tun und lassen was er möchte. Part-DB hingegen wird dort keine> Dateien ablegen.>> Möchte ein Benutzer z.B. die Footprint-Bilder auf eine andere Art und> Weise sortiert haben, so muss er unseren Footprint-Ordner nach media/> kopieren und dort nach seinen Wünschen organisieren.
Jupp. Ich werde zwar erst einmal nur einzelne Dateien verwalten können,
aber wenn das klappt, dann ist es auch kein Problem, mehrere Dateien zu
bearbeiten. Es bleibt nur zu überlegen, ob auch Verzeichnisse bearbeitet
werden dürfen oder ob die Struktur einmal festgelegt wird.
Wenn der Filemanager in der jetzigen Form fertig ist, werde ich ihn ins
Part-DB-Repo rüberziehen, damit wir den zusammen weiter entwickeln
können. Die Software steht unter CC-BY-SA 3.0-Lizenz.
Udo Neist schrieb:> Ich kann ja den Filemanager soweit ergänzen, dass er neben den> Verzeichnisnamen auch Rechte verwaltet. Wäre also sowas wie:> [...]
Das wäre super! Dann kann er auch ganz einfach angepasst werden wenn mal
noch neue Verzeichnisse hinzukommen.
Udo Neist schrieb:> Jupp. Ich werde zwar erst einmal nur einzelne Dateien verwalten können,> aber wenn das klappt, dann ist es auch kein Problem, mehrere Dateien zu> bearbeiten. Es bleibt nur zu überlegen, ob auch Verzeichnisse bearbeitet> werden dürfen oder ob die Struktur einmal festgelegt wird.
Was meinst du mit "Verzeichnisse bearbeiten"? Umbenennen, Kopieren, neue
Verzeichnisse erstellen? Das sollte natürlich in "media/" schon möglich
sein, sonst muss der Benutzer ja all seine Dateien in einen Topf werfen.
Oder eben das ganze Verzeichnis "img/footprints" (rekursiv) nach
"media/footprints" kopieren sollte auch möglich sein.
Erstmal ist aber wichtig dass man Dateien hochladen und hochgeladene
Dateien auswählen kann, die man dann den Bauteilen zuordnen kann...
Ich bin grad die Updateschritte auf die DB-Version 13 nochmal am
anpassen. Es werden noch diverse Änderungen vorgenommen: Umstellung auf
InnoDB, zusätzliche TIMESTAMP-Spalten, und - sehr wichtig - es werden
Foreign Keys hinzugefügt.
Es gibt aber immernoch einen Updateschritt, der nicht funktioniert. Ich
wäre froh wenn mir hier jemand helfen könnte, da meine SQL-Fähigkeiten
begrenzt sind ;-)
Es geht um folgendes:
Bisher (bis DBv12) war es erlaubt, einem Bauteil eine Bestellnummer
und/oder ein Preis zuzuordnen, ohne einen Lieferanten anzugeben. All
diese Daten befanden sich in der Tabelle "parts". Jetzt ist dies aber
nicht mehr erlaubt.
Für Bauteile, die keinen Lieferanten, jedoch eine Bestellnummer und/oder
ein Preis besitzen, wird einfach ein Lieferant "Unbekannt" erzeugt:
1
INSERT IGNORE INTO `suppliers` (name, parent_id) VALUES ('Unbekannt', NULL)
Dann soll die ID von diesem (evtl. neuen) Lieferanten allen Bauteilen
zugeordnet werden, die noch keinen Lieferanten (parts.id_supplier == 0),
jedoch eine Bestellnummer (parts.supplierpartnr != '') und/oder einen
Preis (preise.price > 0) haben. Mein Versuch sieht so aus:
1
UPDATE `parts` SET parts.id_supplier = (SELECT `id` FROM `suppliers` WHERE name='Unbekannt') WHERE (parts.id_supplier = 0) AND ((preise.price > 0) OR (parts.supplierpartnr != ''))
Ich glaube, man sieht was der Befehl machen sollte. Allerdings muss da
wohl noch ein JOIN rein, damit genau der Preis geholt wird, der zum
jeweiligen Bauteil gehört. Die Tabelle "preise" wird über die Spalte
"part_id" mit einem Bauteil verknüpft. Dabei kann es aber auch Bauteile
geben, die keinen Eintrag in der Tabelle "preise" haben! Mehr als ein
Eintrag kann (sollte...) aber nicht existieren.
Ausserdem, wenn es jetzt mehrere Lieferanten mit Namen "Unbekannt" gäbe,
sollte es trotzdem funktionieren (einfach einer dieser Lieferanten
nehmen, egal welcher). Ich bin mir nicht sicher wie sich da mein Befehl
verhalten würde...
Ist sicher nur eine Kleinigkeit für jemanden der was davon versteht :-)
Wäre super wenn mir da jemand helfen könnte, dann würde wenigstens mal
das Datenbankupdate funktionieren.
Falls mehr Infos gebraucht werden, einfach melden.
mfg
na, nur nicht alle auf einmal! :-D
Ich hätte auch gleich schon das zweite "Problem":
Bevor die Foreign Keys hinzugefügt werden, sollen alle Datenbankeinträge
mit einer "toten" parent_id auf die oberste Ebene gesetzt werden, also
parent_id = NULL setzen. Ansonsten ist die Gefahr eines Fehlschlages
beim Update zu hoch, weil es sein könnte dass es in der Spalte
'parent_id' IDs gibt, die nicht (mehr) existieren (sollte zwar
theoretisch nicht vorkommen - habe aber auch schon merkwürdige Dinge in
meiner Datenbank gesehen)
Pseudo-Code für die Tabelle "categories":
1
UPDATE `categories` SET parent_id=NULL WHERE (parent_id existiert nicht in categories.id)
Für die anderen Tabellen kann ich das Ding natürlich auch selber
anpassen.
mfg
Kann mir denn wirklich keiner helfen? ;-)
Ich habe noch diverse andere Sachen gemacht, die ich gerne wiedermal ins
SVN laden würde, aber ohne das Datenbankupdate funktionieren die
nicht...
Wenn sich keiner meldet, frage ich dann halt mal in einem MySQL Forum
nach... Die Updateschritte sollten halt wirklich wasserdicht sein, und
das krieg ich mit meinen MySQL-Fähigkeiten nicht hin :-(
Die Tabelle mit PHP auf machen und mit einer Schleife durchlaufen?
Es muss ja nicht unbedingt ein SQL Script sein, komplexere Teile können
auch per PHP bearbeitet werden.
Markus Müller schrieb:> Die Tabelle mit PHP auf machen und mit einer Schleife durchlaufen?> Es muss ja nicht unbedingt ein SQL Script sein, komplexere Teile können> auch per PHP bearbeitet werden.
Nein es sollte wenn möglich schon direkt per MySQL Queries erledigt
werden, da das bisherige Updatesystem so aufgebaut ist dass nur MySQL
Befehle abgearbeitet werden können. Ausserdem sollten die genannten
Operationen ja problemlos mit MySQL lösbar sein, es liegt nur an meinem
begrenzen Fähigkeiten dass ich es nicht hinkriege ;-)
Ich weiß das jetzt auch nicht auswendig und müsste in der Doku
nachlesen. Ich habe das zumindest in meinen Updates so gelöst um die
Unterschiede der SQL Syntax korrekt behandeln zu können.
Damit habe ich sogar die Möglichkeit gleiche Updates mehrfach aus zu
führen, da erst geprüft wird ob z.B. das Feld nicht doch schon existiert
und dann erst angelegt wird. Bei einem reinen SQL Script ist das viel
schwieriger.
Markus Müller schrieb:> Damit habe ich sogar die Möglichkeit gleiche Updates mehrfach aus zu> führen, da erst geprüft wird ob z.B. das Feld nicht doch schon existiert> und dann erst angelegt wird. Bei einem reinen SQL Script ist das viel> schwieriger.
Jup, das war bisher tatsächlich ein Problem. Ich habe jetzt aber einen
Zähler eingebaut, der sich merkt bei welchem Updateschritt ein Abbruch
stattfand. So kann beim nächsten Versuch wieder an der gleichen Position
weitergemacht werden. Beim Update von v12 auf v13 ist das auch dringend
notwendig, da wird so viel an der DB verändert... ;-)
Das ganze Updatesystem soll später aber sowieso nochmal überarbeitet
werden, da wir auch Systemupdates unterstützen möchten. Bisher wird nur
die Datenbank an die neue Systemversion angepasst nachdem der Benutzer
das System selbst aktualisiert hat.
OK also ich habs nochmal selbst probiert, und ich glaube sogar ich habs
hingekriegt :-) Bei den Tests die ich durchgeführt habe, stimmte das
Ergebnis jedenfalls...
Ich habe jetzt mal alle Änderungen ins SVN hochgeladen (r594).
Achtung! Es wird jetzt wieder eine Datenbank der Version 12
vorausgesetzt, da ich den Schritt von v12 auf v13 verändert habe! Eine
DB v12 liegt ja nach wie vor im "development" Ordner.
Die Online Demo wird nun in nächster Zeit vermutlich auch nicht mehr
richtig funktionieren, da muss auch erstmal wieder eine frische DB
geladen werden...
So, vielleicht kriege ich nun sogar auch noch die anderen
Datenbankprobleme hin, die in der Doxygen Doku noch aufgelistet sind ;-)
mfg
P.S.
Falls es bei euch Probleme geben sollte beim DB-Update, bitte melden,
vielleicht ist ja doch noch ein Wurm drin ;-)
Urban B. schrieb:>> Die Online Demo wird nun in nächster Zeit vermutlich auch nicht mehr> richtig funktionieren, da muss auch erstmal wieder eine frische DB> geladen werden...>
Leuft ;-)
>> P.S.> Falls es bei euch Probleme geben sollte beim DB-Update, bitte melden,> vielleicht ist ja doch noch ein Wurm drin ;-)
Jap aus irgendeinen Grund, wird der Datenbank Zeichensatz bei mir auf
schwedisch gestellt für die umbenannten Tabellen.
Was noch nett ist das neuerdings erst nach dem kompletten Update die DB
Rev. geändert wird so kann man das auch selber grade biegen und dann das
script nochmal durchlaufen lassen.
K. J. schrieb:> Leuft ;-)
Super, danke! :-)
K. J. schrieb:> Jap aus irgendeinen Grund, wird der Datenbank Zeichensatz bei mir auf> schwedisch gestellt für die umbenannten Tabellen.
Hmm dann musst du dir wohl noch eine schwedische Tastatur besorgen ;-)
Ne im Ernst, ich bin mir noch unsicher was die Befehle "CHARSET=..." und
"COLLATE=..." genau bringen. Vorher haben wir ja eine Tabelle so
erzeugt:
1
DROP TABLE IF EXISTS `categories`;
2
CREATE TABLE IF NOT EXISTS `categories` (
3
`id` int(11) NOT NULL AUTO_INCREMENT,
4
`name` mediumtext COLLATE utf8_unicode_ci NOT NULL,
Hier wird ja der Zeichensatz auf utf8_unicode_ci gesetzt. Aber was, wenn
jemand einen anderen Zeichensatz haben möchte (auf Windows?) ? Oder wird
das niemand wollen? ;-) Über die Konfiguration lässt sich ja jetzt der
Zeichensatz des PDO setzen. Dieser Zeichensatz sollte dann eigentlich ja
auch beim Anlegen neuer Tabellen verwendet werden nehme ich mal an. So
ist halt der Zeichensatz nicht mehr hardgecoded, sondern der Benutzer
kann ihn selber wählen. Aber ob das wirklich Sinn macht... Sollte man
besser den Zeichensatz wieder auf utf8 hardcoden und die
Konfigurationsmöglichkeit rauswerfen?
Und dann gibts da noch das "COLLATE=...". Hier bin ich mir auch nicht
sicher. Wird da nicht standardmässig utf8 verwendet, wenn die Tabelle
sowieso den utf8-Zeichensatz verwendet? Oder muss das wirklich noch
separat angegeben werden?
Die blöden Zeichensätze bereiten mir echt Kopfschmerzen... :-(
K. J. schrieb:> Was noch nett ist das neuerdings erst nach dem kompletten Update die DB> Rev. geändert wird so kann man das auch selber grade biegen und dann das> script nochmal durchlaufen lassen.
Jup, wenn ein Update fehlschlägt wird die aktuelle Position in der
config.php abgelegt, damit beim nächsten Versuch wieder an der gleichen
Position weitergemacht werden kann. Vorher war es echt mühsam wenn mal
ein Update fehlgeschlagen hat... ;-)
Markus Müller schrieb:> Foreign Key's benötigen InnoDB.
Ja, deshalb werden zu Beginn des Updates alle Tabellen auf InnoDB
umgestellt:
1
ALTER TABLE `categories` ENGINE=InnoDB
Aber das hat mit dem Zeichensatz eigentlich ja nichts zu tun, oder?
Übrigens ist mir grad noch ein schlimmer Fehler im DB Update
aufgefallen, es waren plötzlich alle Einkaufsinformationen doppelt
vorhanden :-) Ist jetzt aber gefixt (r596).
Kann man eigentlich in Google Code nicht einzelne Verzeichnisse aus dem
Changelog rausnehmen? Die Änderungen an der Doxygen Doku nerven extrem
in der Änderungsliste, die wirklich wichtigen Änderungen gehen so total
unter...
Übrigens, ich habe jetzt mal ein Dokuwiki in Part-DB mit eingebaut. Wer
möchte, kann gerne daran arbeiten :-)
Und dann habe ich noch diverse Sachen gefixt: Man kann nun endlich nach
Lieferanten und Bestellnummern suchen, die Statistik wird jetzt viel
schneller geladen (Preisberechnung per MySQL statt PHP) und die
Footprint-Bilder Auflistung habe ich umgebaut. Beim Aufrufen von Tools
-> Footprints werden nun nicht mehr die über tausend Bilder geladen
(sehr mühsam bei langsamen PCs). Wer es trotzdem wieder haben möchte,
kann es in der Konfiguration ändern.
mfg
K. J. schrieb:> Jap aus irgendeinen Grund, wird der Datenbank Zeichensatz bei mir auf> schwedisch gestellt für die umbenannten Tabellen.
Ich habe mal die CHARSET=... und COLLATE=... wieder hinzugefügt (r598),
könntest du nochmal eine DB v12 laden und schauen obs nun klappt?
Ausserdem gibts jetzt ein paar neue Sachen in Part-DB 0.3.0:
1
- Export für gesuchte Teile, Baugruppen und zu bestellende Teile
2
- Eigene Exportformate können ziemlich einfach in der config.php definiert werden
3
- Baugruppen können zum Bestellen vorgemerkt werden (damit tauchen Sie in der Liste der zu bestellenden Teile auf - war ziemlich tricky, vielleicht gibts da noch Bugs...)
4
- Obsolete Einkaufsinformationen werden in den Tabellen nicht mehr angezeigt
So langsam aber sicher wird die ganze Sache ziemlich kompliziert ;-) Die
Einkaufsinformationen und Preisinformationen machen es einem nicht
leicht, aber ich denke der Aufwand lohnt sich. Wenn man das selbe
Bauteil mal bei diesem, mal bei einem anderen Lieferanten bestellt, muss
das halt auch irgendwie gescheit verwalten können...
Gute Nacht! :-)
Urban B. schrieb:> K. J. schrieb:>> Jap aus irgendeinen Grund, wird der Datenbank Zeichensatz bei mir auf>> schwedisch gestellt für die umbenannten Tabellen.>> Ich habe mal die CHARSET=... und COLLATE=... wieder hinzugefügt (r598),> könntest du nochmal eine DB v12 laden und schauen obs nun klappt?>
Supi geht.
An dieser Stelle einfach mal ein Lob an Urban für seine Arbeit :-)
Ich hänge derzeit an den AJAX-Routinen für den IE (hab nur den 8er)
fest. JScript ist halt nicht Javascript und das nervt tierisch :(
K. J. schrieb:> Supi geht.
OK dann lassen wir das mal so :-)
Ich habe mich jetzt übrigens mal noch ein bisschen mit dem Thema
Zeichensätze beschäftigt, da ich damit immernoch Mühe hatte. Einerseits
haben wir ja den HTTP Zeichensatz (im HTML Header), und andererseits den
Zeichensatz der Datenbank.
Die Kommunikation mit der Datenbank können wir wohl auf UTF-8 hardcoden
denke ich (mit "SET NAMES utf8"). Jeder (einigermassen aktuelle) MySQL
Server sollte UTF-8 unterstützen, so können Probleme und
Missverständnisse vermieden werden. Übrigens habe ich heute
herausgefunden dass der Befehl "SET NAMES utf8" bisher gar nicht
funktioniert hat, in der nächsten Revision die ich hochlade,
funktioniert es dann aber.
Eventuell könnte es aber bei einigen Benutzern zur falschen Darstellung
von Umlauten führen. In früheren Versionen von Part-DB wurden die Daten
wohl in "latin1" in der Datenbank abgelegt. Die Backups davon werden bei
mir nun aber als UTF-8 interpretiert und somit die Umlaute falsch
dargestellt. Ich bin mir aber nicht sicher ob das nur bei alten Backups
passiert, oder obs auch im normalen Betrieb dann plötzlich passiert
(beim Update auf eine neue Version von Part-DB)...Im schlimmsten Fall
müssten die Benutzer dann ihre latin1-Datenbank nach UTF-8 konvertieren.
Ist zwar irgendwie blöde, aber wenn man jetzt einfach was "bastelt" wird
uns das Problem auf immer und ewig verfolgen ;-)
Und dann zum HTTP-Zeichensatz. Der gibt eigentlich dem Browser ja nur
bekannt, wie die Daten codiert sind. Da gibt es einmal die (ich nenne
sie mal) "dynamischen" Daten, die z.B. von der Datenbank kommen, die
erhalten wir immer in UTF-8 und werden auch so ausgegeben. Und dann
gibts noch die "statischen" Daten, die hardgecoded (in *.php oder
*.tmpl) sind. Die sind ja auch alle in UTF-8 codiert. Teilweise gibts
Umlaute noch in HTML-Schreibweise, die könnten wir aber auch noch durch
Umlaute (im Klartext) ersetzen. Es ist also immer alles UTF-8, somit
könnten wir doch den HTTP-Zeichensatz auch auf UTF-8 hardcoden, oder?
Wenn jetzt ein Windows Server eingesetzt wird, sind ja die Dateien von
Part-DB immernoch UTF-8 und es müsste weiterhin funktionieren schätze
ich. Oder liefert ein Apache Server auf Windows etwa latin1 Ausgaben,
auch wenn die PHP/TMPL Dateien UTF-8 codiert sind? Das bin ich mir nicht
so ganz sicher...
Zusammengefasst würde ich also sagen: Wir könnten alles auf UTF-8
hardcoden und es sollte tzotzdem auf allen Server-Systemen richtig
funktionieren. Einzig bei der Bearbeitung der PHP/TMPL Dateien unter
Windows muss man darauf aufpassen, dass die Dateien auch wieder UTF-8
codiert gespeichert werden. Aber das sollte ja jeder ernstzunehmende
Code-Editor beherrschen.
K. J. schrieb:> Aso hab mich mal ans Wiki gemacht,
Super! :-)
Uhu hat sich ja diesbezüglich auch mal gemeldet, vielleicht müsstest du
mit ihm mal besprechen ob/was/wie/wann er auch noch an der Doku
arbeitet.
> ich weis nur nicht ob ein einfaches> Coppy der Seiten reicht damit sie übernommen werden.
mmh ich verstehe die Frage nicht ganz. Also grundsätzlich solltest du im
DokuWiki einfach Änderungen machen und dann die Dateien ins SVN
hochladen können. Man sieht ja in der Online-Demo dass das bereits
geklappt hat.
Übrigens habe ich nur mal ein paar grobe Einstellungen gemacht im
DokuWiki. Vielleicht gäbe es noch ein paar andere Sachen die man ändern
könnte. z.B. macht es nicht viel Sinn dass der Benutzer schlussendlich
auch die Möglichkeit hat, Änderungen an der Doku durchzuführen (sieht
irgendwie komisch aus wenn man die Doku einer Software selbst verändern
kann). Da könnte man sicher noch ein bisschen was anpassen...
Udo Neist schrieb:> An dieser Stelle einfach mal ein Lob an Urban für seine Arbeit :-)
Vielen Dank :-)
Ja, werd mich drum kümmern werde auch mal schauen ob wir das ganze nicht
mal etwas abspecken können alleine die Sprachfiles sind son eine ganze
menge die wir nicht brauchen, denke DE und EN werden reichen, das
gleiche für die doxigen doku die ist sowas von aufgebläht.
K. J. schrieb:> Ja, werd mich drum kümmern werde auch mal schauen ob wir das ganze nicht> mal etwas abspecken können alleine die Sprachfiles sind son eine ganze> menge die wir nicht brauchen, denke DE und EN werden reichen,
Jup, gute Idee.
K. J. schrieb:> das gleiche für die doxigen doku die ist sowas von aufgebläht.
Ja es sind halt sehr viele Dateien, aber viel weglassen kann man da
nicht denke ich. Ausserdem kriegt der Endanwender die Doxygen-Doku
nicht, die ist nur für Entwickler. Der ganze Ordner "development" kommt
schlussendlich nicht in die Download-Archive, deshalb habe ich die
Doxygen Doku auch von "documentation" nach "development" verschoben.
Was ich aber schön finden würde, wäre wenn man die Änderungen im Ordner
"doxygen" im Changelog in Google Code irgendwie ausblenden könnte. Aber
ich vermute mal das ist nicht möglich (?)...
@ Marco tom Suden (falls du noch mitliest)
Wenn du auf deinem Windows Server den HTTP Zeichensatz auf "UTF-8"
einstellst, werden dann die Umlaute richtig dargestellt (nicht bei den
Daten schauen die aus der Datenbank kommen, sondern bei statischen
Inhalten, z.B. die Tabellenüberschrift "Datenblätter")?
Urban B. schrieb:> z.B. macht es nicht viel Sinn dass der Benutzer schlussendlich> auch die Möglichkeit hat, Änderungen an der Doku durchzuführen (sieht> irgendwie komisch aus wenn man die Doku einer Software selbst verändern> kann).
Das sehe ich nicht ganz so. Wenn die Doku schlecht ist - MS ist in
dieser Disziplin ganz große Klasse! - ist es mehr als wünschenswert, daß
man als Nutzer z.B. leeres Stroh eliminieren, verkorkste Übersetzungen,
oder Formulierungen reparieren kann...
Dokuwiki ist genau dafür ganz prima geeignet: man kann neue Versionen
einspeisen und private Änderungen notfalls mit Hilfe der diff-Funktion
finden und übernehmen, falls sinnvoll.
Aber es ist durchaus sinnvoll, die Änderbarkeit an einen speziellen
Wiki-Login zu koppeln, daß nicht aus Versehen Änderungen gemacht werden.
Der Username muß natürlich bekannt gemacht werden.
Uhu Uhuhu schrieb:> Aber es ist durchaus sinnvoll, die Änderbarkeit an einen speziellen> Wiki-Login zu koppeln, daß nicht aus Versehen Änderungen gemacht werden.> Der Username muß natürlich bekannt gemacht werden.
Ja, so ähnlich hätte ich mir das auch vorgestellt. Also dass
standardmässig die Editier-Buttons nicht sichtbar sind (die meisten
Anwender werden die nicht brauchen), aber mit der Möglichkeit, dass man
eben doch was verändern kann wenn man möchte (z.B. wir Entwickler
brauchen das ja). Sei es ein Login, oder evtl. auch in der Konfiguration
von Part-DB eine Option wie "Änderungen in der Dokumentation zulassen".
Wie gesagt, ich habe mich nicht grossartig mit DokuWiki beschäftigt. Ich
habs einfach mal in Part-DB eingefügt und ein paar grundlegende
Einstellungen getätigt, so dass wir mal eine Grundlage für die Doku
haben. Ihr dürft daran gerne noch Einstellungen verändern usw.
Uhu Uhuhu schrieb:> Udo Neist schrieb:>> JScript ist halt nicht Javascript und das nervt tierisch :(>> Tja, das ist das Echo des Browserkrieges.
Problem ist gelöst. Ajax funktioniert jetzt auch mit dem IE8. Jetzt muss
ich erstmal einen Schönheitsfehler im Bezug auf die Testseite beheben,
dann kommen die Kommandos hinzu. Ich habe mir überlegt, dass ich die
Verzeichnisse per Konfiguration von Änderungen ausnehmen kann (jetziges
Verhalten). Alternativ würde man per Einfachklick das Verzeichnis zum
Bearbeiten markieren und ein weiterer Klick würde das Verzeichnis
öffnen. Neue Ordner können nur dann erstellt werden, wenn eine weitere
Konfigurationsoption dies freischaltet. Schließlich soll nicht jeder an
der bestehenden Struktur was ändern können, eventuell neu erstellte
Verzeichnisse würde vom System u.U. auch gar nicht berücksichtigt
werden.
Ne, derzeit haben wir kein Release-Fahrplan. Nach meinem Wissen gibt es
derzeit drei Baustellen:
1) Umstellung des Codes auf Modul-/Klassenbasis
2) Neuer Filemanager
3) Dokumentation im Form eines Wikis
Ich vermute mal, dass wir irgendwo bei 90% sind. Am eigentlichen Code
arbeitet derzeit nur Urban und ich bin am Filemanager dran. Nach der
Veröffentlichung der Version 0.3 soll die Kommunikation zwischen
Anwendung und Server auf Ajax umgestellt werden und somit die veraltete
Frame-Variante komplett ersetzen.
Für den produktiven Betrieb ist die 0.2.x vorgesehen.
Grüße
Udo
So, die Importfunktionen sollten nun (r606) auch funktionieren. Falls
noch jemand Bugs findet, bitte melden :-)
Ihr glaubt gar nicht, wie froh ich bin dass wir nun Transaktionen
verwenden können :-D Eine Funktion, die die Werte aus dem Import-Text
auf Gültigkeit überprüft, wurde so zum Kinderspiel. Einfach alles normal
importieren, aber am Schluss ein Rollback statt einem Commit ausführen
:-)
Ausserdem habe ich den Code-Styleguide vom Google-Code Wiki in die
Doxygen-Doku verschoben. So gibts schlussendlich nur zwei
Nachschlagewerke: Die Doxygen Doku für Entwickler, und das DokuWiki für
Anwender (und beide Nachschlagewerke sind natürlich auch online auf der
Demo-Seite verfügbar).
So braucht es das Google Code Wiki gar nicht mehr.
Den Code-Styleguide sollte demnächst dann unter
http://partdb.grautier.com/uneistkami89/development/doxygen/html/styleguide.html
erreichbar sein.
Gespeichert ist die Seite übrigens unter
"development/doxygen/related_pages/". Man kann sehr schön eigene Seiten
in die Doxygen Doku aufnehmen, die sich dann auch ins Menü integrieren.
Wie man das genau macht, kann man in den in diesem Ordner vorhandenen
Dateien nachschauen.
Ich wäre nun übrigens langsam für den Dateimanager bereit, wie sieht die
Lage bei dir aus, Udo? :-)
mfg
Urban B. schrieb:> Ich wäre nun übrigens langsam für den Dateimanager bereit, wie sieht die> Lage bei dir aus, Udo? :-)
Ich wollte heute einige der Kommandos fertig machen, damit der
Filemanager zumindest mit den Basisfunktionen auch nutzbar ist. Vorerst
halt nur für Dateien, das mit den Verzeichnissen kommt später noch dazu.
Den Upload-Teil werde ich die Tage dann integrieren.
Aktueller Stand Filemanager:
- Befehle funktionieren, sind aber auf Dateien beschränkt
- Alle Meldungen über einen modalen Dialog (Formulare, Meldungen)
- Fehlermeldungen des Webservers werden als Statusmeldung direkt im
entsprechenden Block angezeigt (kein Dialog)
- (Access-)Token als Absicherung für die Kommandos, da man auf den
HTTP-Referrer nicht bauen kann
- Vorschau von Grafiken
- Mimetyp-Grafiken für alle anderen Files (optional)
- Anpassen des Designs über CSS. Nur wenige Elemente sind in den
Templates fest über Style-Regeln definiert.
Basis sind XMLHttpRequests und JSON auf Seite von Javascript. Die
Javascript-Klassen haben einen eigenen Namespace.
ToDo:
- Verzeichnisfunktionen einführen
- Fehlermeldungen des Webservers als modaler Dialog
Die aktuelle Version werde ich die Tage von den Eigenheiten meiner
Webseite befreien und erstmal in den Development-Ordner kopieren. Eine
Minidoku füge ich hinzu.
Grüße
Udo
Edit:
Es fehlt noch der Upload-Teil. Hab mich erstmal auf meinen eigenen Code
konzentriert ;-)
Super, dann geht die Version 0.3.0 nun ja endlich langsam in die
Endphase über :-)
Also ich bin auch noch nicht ganz fertig, aber es sind jetzt
hauptsächlich nur noch Kleinigkeiten die noch fehlen. Und beim Testen
werden dann sicher auch noch einige Bugs auftauchen...
Ich wollte dich aber schon lange mal noch was ganz anderes fragen. Du
hast ja mal das Skript "svn.sh" erstellt, das ich mittlerweile übrigens
in "tools.sh" umbenannt habe (habe noch eine neue Funktion hinzugefügt,
die nichts mit SVN zu tun hat). Ein Teil dieser Funktionen sind übrigens
nun auch sehr bequem über Part-DB unter "Entwickler-Werkzeuge"
erreichbar. Ich bin einfach zu faul um jedesmal ein Terminal aufzumachen
;-)
Meine Frage bezieht sich aber auf das Commiten. Du hast ja dort den
Parameter "--force" mit eingebaut. Ich frage mich aber ein bisschen, ob
das geschickt ist. Einerseits werden doch so eventuelle Änderungen im
Repository, die seit dem letzten Update gemacht wurden, einfach
überschrieben, oder? Und andererseits habe ich gelesen dass dann die
Ignore-Dateien auch nicht mehr ignoriert werden (verwende ich für den
Debug-Log und config.php). Zweiteres ist nicht schlimm, aber ersteres
könnte zu Problemen führen wenn man nicht aufpasst.
Ich selber benutze einen grafischen SVN Client der sich in Nautilus
integriert. Bei jedem Commiten überfliege ich alle geänderten Dateien
nochmal um zu prüfen, ob auch wirklich genau das hochgeladen wird, was
hochgeladen werden soll. Und falls meine lokale Kopie nicht mehr aktuell
ist, bekomme ich eine Fehlermeldung weil ich kein "--force" verwende. So
werde ich gezwungen, erst mal ein Update durchzuführen und es wird
sichergestellt dass ich keine Dateien aus Versehen überschreibe.
Ich habe das leider auch schon bei anderen Projekten erlebt (git) dass
Leute einfach mal drauflos committen und Änderungen von Anderen wieder
(aus Versehen) rückgängig machen. Das ist extrem mühsam...
Meine Frage wäre also: Sollten wir da nicht besser das "--force"
entfernen, um unbeabsichtigte Änderungen zu vermeiden?
mfg
Das "--force" bezieht sich ja nur auf "svn add" und durchsucht rekursiv
alle Verzeichnisse. Mit "--no-ignore" würdest du gesperrte Dateien
hinzfügen, so lese ich zumindest die Doku. Zudem fehlt da eh noch der
Befehl "svn resolve --accept working *" (oder ne Variante), um Konflikte
zu lösen. Das Script ist noch lange nicht perfekt und sollte ja auch
erstmal nur die Arbeit in meinem Branch erleichtern. Es ist halt nicht
für Mehrbenutzer-Repos ausgelegt und darf jederzeit angepasst werden :-)
Udo Neist schrieb:> Das "--force" bezieht sich ja nur auf "svn add"
Ups, da habe ich wohl nicht richtig hingeschaut^^ Sorry, ich dachte das
war beim "commit" ;-) Beim "add" sollte das dann ja tatsächlich nicht so
wild sein...
Udo Neist schrieb:> Mit "--no-ignore" würdest du gesperrte Dateien> hinzfügen, so lese ich zumindest die Doku.
Jo nach Doku würde ich das auch sagen, wenn ich aber diverse Meldungen
in Foren richtig verstanden habe, tut es das eben nicht. Ich habs
allerdings nie selber ausprobiert, das Committen mit der Konsole ist mir
etwas ungeheuer. Ich setze da lieber auf hübsche Klicki Bunti GUIs, dann
kommt auch das richtige bei raus :-D
Aber dann hat sich das ja auch mehr oder weniger erledigt. Ich wollte
nur sichergehen dass man (die, die es verwenden) mit dem Skript keine
unbeabsichtigten Sachen im Repo überschreibt.
Das nächste Mal schaue ich mir den Code etwas genauer an bevor ich hier
nachfrage, versprochen! :-D
...wie still es doch sein kann in diesem Thread :-)
Ich habe vor ein paar Wochen noch ein neues (grosses...) Projekt
angefangen, daher ist Part-DB in letzter Zeit leider etwas auf der
Strecke geblieben. Dieses Wochenende versuche ich aber wieder daran zu
arbeiten :-)
@Udo, siehts bei dir (bzw. beim Dateimanager) ähnlich aus oder bist du
in der Zwischenzeit weiter gekommen?
mfg
Urban
Leider nein :( Wird wohl noch bis Ende April oder Mitte Mai dauern, bis
ich wieder mehr Zeit habe. Im Moment raubt mir die Vertretung eines
Kollegen etwas die Zeit. Wie es im Juni aussieht, weiß ich auch noch
nicht. Da steht bei uns eine Reakkreditierung an. Ich versuch zumindest
mal den Uploader zu integrieren, damit wenigstens diese Baustelle im
Dateimanager geschlossen werden kann.
So, habe einen einfachen Uploader integriert. Es wird kein Flash oder
ähnliches verwendet. Nur der Browser sollte möglichst aktuell sein. Es
fehlt nur noch die Option, nach dem Upload direkt ins Zielverzeichnis zu
wechseln.
Ok super, also wenn der Uploader schon funktionsfähig ist, kannst du ihn
ja mal ins SVN hochladen.
Wenn der Uploader einen Haufen Dateien braucht, wäre es vielleicht
sinnvoll wenn wir ihm ein eigenes Verzeichnis spendieren, also im
Hauptverzeichnis einen Unterordner "filemanager/" o.ä. (anstatt
JS-Dateien in "javascript/", CSS in "templates/" usw.)
Das Wechseln nach 5s in das Zielverzeichnis funktioniert jetzt auch. Ob
das auch bei fehlgeschlagenen Uploads funktioniert, kann ich noch nicht
beurteilen, da es nur sporadisch auftritt.
Die Installation in ein eigenes Verzeichnis wäre mir auch lieber, da der
Filemanager ja absichtlich als Add-On/Modul für ein CMS oder ähnliches
gedacht ist. Javascript und CSS müssen eingebunden, die
Grafikverzeichnisse verlinkt werden. Ansonsten sollte es ziemlich
pflegeleicht sein. Ich werde vielleicht morgen mal die aktuelle Version
ins Repo einbinden. In die jetzige Version der Part-DB kann man
allerdings nur das Aufrufen per Popup-Window nutzen. Eigentlich ist es
für die Nutzung innerhalb eines DIV-Elements auf der Hauptseite
vorgesehen. Es wird ein Fenster mit mindestens 600px Breite gebraucht.
Nächstes Feature: Interner Viewer ähnlich eines Dialogs
Unterstützt werden PDF und Images. PDF wird vom jeweiligen Plugin
angezeigt, die Images werden bei Übergröße über CSS skaliert. Letzteres
ist kein ideales Verhalten, aber sollte bei jedem Browser funktionieren.
Kleinere Bilder füllen den Viewer nicht aus. Dieser wird nicht
angepasst. Wäre noch was für die ToDo-Liste. Vielleicht unterstütze ich
später auch noch Videos oder anderes per object-Tag.
Ich habe den Filemanager mit Kommentaren versehen und ein paar kleinere
Anpassungen für Part-DB gemacht. Wie man den Filemanager in einen
Webseite einbaut, kann man in der Datei vlib_filemanager.html sehen.
dom.css und filemanager.css dabei nicht vergessen!
Aktuelle Version ist in der Revision 613 enthalten.
ToDo:
- Viewer soll auch Text-Dateien anzeigen können, dabei soll
Syntax-Highlightning unterstützt werden.
- Hauptverzeichnis für Dateioperationen wird in filemanager.php bzw.
conf.php definiert, aber kann dort noch nicht gesperrt werden. Geht
derzeit nur über eine interne Variable in filemanager.js.
- README ändern, da es nicht mehr aktuell ist.
- Doxygenkompatible Kommentare, kann auch jemand vom Part-DB-Projekt
übernehmen ;-)
Ich habe mir das mal angeschaut aber ich blicke noch nicht so richtig
durch :-(
Wie würde man den Filemanager später z.B. in "edit_part_info.php" (bzw.
dem *.tmpl davon) einbinden?
Die Bedienung stelle ich mir etwa so vor (Bsp. "edit_part_info.php"):
- Der Benutzer klickt unter Dateianhänge/Dateiname auf den Button "..."
- Der Filemanager öffnet sich in einem neuen Fenster (Popup)
- Falls nötig, kann der Benutzer die Datei erst noch hochladen
- Der Benutzer wählt die entsprechende Datei aus und klickt auf "OK"
- Der Filemanager schliesst sich und der Pfad zur gewählten Datei wird
automatisch in das Textfeld "Dateiname / URL" in "edit_part_info.php"
geschrieben.
Wie man das so hinkriegt weiss ich aber leider nicht... ;-)
mfg
Dachte ich mir schon, dass dazu noch Fragen sind :-) Ich werde noch eine
Testseite machen, auf dem der Aufruf für den Upload-Teil gezeigt wird.
Erst wenn die dann so läuft wie angedacht, würde ich den Filemanager in
Part-DB einbauen.
Im Grunde besteht der Uploadmanager nur aus einem Dialogfenster und
einem zweiten Element für die Anzeige des Uploads selbst. Innerhalb der
gleichen Seite wäre es ein
1
onclick="filemanager.command('upload');"
auf einem entsprechenden Button. Für den Aufruf in einem Popup muss man
mehr machen. Erstmal ein onclick-Event, das ein neues Fenster erzeugt.
In dem Fenster wird dann der komplette Filemanager aufgebaut, aber die
normalen Funktionen wären abgeschaltet, d.h. das Element links oben mit
den Verzeichnissen wäre abgeschaltet.
Okay dann warte ich diesbezüglich noch ab :-)
Momentan habe ich noch ein anderes Problem. Unter "Zu bestellende Teile"
werden nun ja jeweils zu jedem Bauteil alle verfügbaren
Einkaufsinformationen angezeigt, jeweils mit einem Radiobutton um
auszuwählen, welchen Artikel man nun genau bestellen möchte. Anhand
dieser Auswahl wird dann übrigens der Gesamtpreis der Bestellung
berechnet, und auch für den Bestelllisten-Export ist diese wichtig.
Das Problem ist nun aber, dass die Radiobuttons etwas höher sind als der
Text alleine, und das führt bei mehreren Einkaufsinformationen zu einer
Verschiebung in der Höhe (zwischen den verschiedenen Spalten). Siehe
angehängtes Bild.
Ich habe keine gescheite Idee, wie man die Zeilen jeweils aufeinander
ausrichten könnte. Die einzige Idee war, dass man für jede
Einkaufsinformation eine eigene Zeile macht, und die dann mit "rowspan"
zusammenfasst wo sie nicht gebraucht werden. Allerdings würde das extrem
viel Aufwand bedeuten, vieles verkomplizieren und neue Probleme mit sich
ziehen.
Hat jemand eine gute Idee wie man das machen könnte?
Nachtrag:
Das Beispiel im Anhang ist natürlich ziemlich übertrieben. Bei 2 oder 3
Einkaufsinformationen ist dieses Problem erst leicht ersichtlich.
Trotzdem ist es unschön und sollte wenn möglich verbessert werden :-)
Auf http://phpbookworm.singollo.de/project/part-db/index.html ist der
Filemanager in zwei Modi zu sehen:
- Innerhalb eines DIV-Elements
- In einem Popup-Fenster
Ausprobieren ist ausdrücklich erlaubt. Fehlerberichte wären sehr
hilfreich, um den Filemanager fertig zu bekommen.
ToDo:
- Breadcrumb-Anzeige der Verzeichnisstruktur hinzufügen.
- README ändern, da es nicht mehr aktuell ist.
- Doxygenkompatible Kommentare, kann auch jemand vom Part-DB-Projekt
übernehmen ;-)
Udo Neist schrieb:> Warum ausgerechnet Radio-Buttons? Select mit allen Infos wäre passender.
Daran habe ich auch schon gedacht. Irgendwie finde ich es aber mit
Radiobuttons übersichtlicher, weil man direkt auf einen Blick alle
Möglichkeiten sieht. So sieht man halt sehr schnell, welche Teile man
bei welchen Lieferanten bekommt und kann so entscheiden, wo man
bestellen möchte.
Wenn ich z.B. 10 zu bestellende Teile habe, müsste ich bei Comboboxen
erst bei jedem einzelnen Teil schauen (klicken, schauen, anwählen), ob
es das bei z.B. Conrad gibt. Bei Radiobuttons sieht man auf einen Blick
- "aha, 3 der Teile gibts bei Reichelt, aber alle 10 gibts bei Conrad,
also bestelle ich alle 10 bei Conrad"
- oder "aha, 5 gibts bei Reichelt und Conrad, die anderen 5 gibts nur
bei Conrad, ich muss also sowieso bei beiden Lieferanten bestellen,
markiere also bei den 5 Teilen wo ich wählen kann jeweils den
Lieferanten mit dem tieferen Preis".
Und dann kommt dann manchmal auch noch der Mindestmengenzuschlag hinzu,
den man berücksichtigen muss...
kurz gesagt: Radiobuttons halte ich für übersichtlicher (klar, wenn
jedes Teil 10 verschiedene Einkaufsinformationen hat, wirds auch
unübersichtlich. Aber ich schätze mal die meisten Benutzer von Part-DB
werden maximal 3 Einkaufsinformationen pro Bauteil haben).
Theoretisch könnte man aber auch beide Varianten implementieren, und die
Wahl dem Benutzer überlassen. Ist eigentlich auch ganz einfach, so wie
die Tabellen jetzt aufgebaut sind (Spalten in der config.php definiert).
Warum dann nicht alle Elemente mit einem identischen height-Wert
ausstatten? Entweder Listen oder DIV/P-Elemente verwenden. Ist bisschen
Fummelarbeit, zugegeben, aber die praktikabelste Lösung.
Funktioniert das dann auch ziemlich
browser-/schriftarten-/betriebssystemunabhängig?
Und sollte man das am besten gleich in CSS machen?
Bin leider in HTML/CSS nicht wirklich fit...ein Beispiel wäre super :-)
Entweder du nimmst bei jedem Element das Inline-Verfahren
1
style="height=1.5em;"
oder du definierst das im CSS
1
eklist{height: 1.5em;}
und bindest das dann als
1
class="eklist"
ein. Im Template muss das dann nur einmal pro Spalte an der richtigen
Stelle der Schleife eingetragen werden. Steht da nur ein BR-Tag, dann
mach mal daraus ein DIV-Element.
PS: Die Höhe hab ich einfach mal beispielsweise genommen. Kommt auf das
Radio-Element an, wie hoch das dann tatsächlich ist. "em" ist eine
relative Größe.
Das scheint zu funktionieren, zumindest im IE und im FF (Win7/Ubuntu)
siehts nun so aus wie es soll.
Dann kann ich das ja endlich mal abhaken...
Wenn ich mich nicht täusche, ist nun etwa alles, was ich für die Version
0.3.0 vorgesehen habe, eingebaut. Ich wäre froh, wenn ein paar Leute nun
langsam mit dem Testen beginnen würden, es gibt sicher noch viele Bugs
und Sachen die ich vergessen habe :-)
Vom geplanten Systemupdate sind halt schon ein paar Fragmente in der
aktuellen Version drin, die kann man ignorieren, die kommen nicht in die
v0.3.0. Aber der Filemanager kommt natürlich rein, der ist aber noch
nicht fertig.
Ich würde mich sehr über Rückmeldungen aller Art (Bugs, Vorschläge,
Bemerkungen) freuen!
Noch nicht wirklich ausgiebig getestet sind übrigens der Installer und
die Import/Exportfunktionen, hier ist also das Testen besonders wichtig.
Ich habe die komplette Testsuite mit dem aktuellen Stand des
Filemanagers reinkopiert. Ist recht groß das ganze, da es neben GeShi
auch noch die vlibTemplate-Engine drin hat. Letztere ist eigentlich
überflüssig, aber ich wollte die Testsuite nicht extra umschreiben.
Die beiden Dateien index.html und popup.html zeigen, wie man den
Filemanager in eine Seite integriert.
Revision 615 steht zur Verfügung.
ToDo:
- Globale Rechte und Benutzerrechte integrieren. Einerseits werden
Standardrechte zu definieren sein, andererseits soll die Token-Abfrage
zu einem Rechtesystem erweitert werden.
- Doxygenkompatible Kommentare, kann auch jemand vom Part-DB-Projekt
übernehmen ;-)
- Aktualisierung von http://weinbauer73.myparts.info/ (Test-Branch)
Udo Neist schrieb:> Ausprobieren ist ausdrücklich erlaubt. Fehlerberichte wären sehr> hilfreich, um den Filemanager fertig zu bekommen.
Gefällt mir schon gut.
Kleinigkeiten hätte ich allerdings:
Obwohl ich bereits im Filemanager einen Unterordner ausgewählt habe bzw
mich darin befinde, muss ich im Uploader den Unterordner erneut
auswählen.
Im IE 9 funktioniert leider weder "Filemanager (gleiche Seite)" noch
"Filemanager (per Popup)" (Popup geht zwar auf, aber es wird kein Inhalt
angezeigt)
Beim FF und Opera gibts kleinere Schönheitsfehler, siehe Anhang.
mfg Pyro
Mit dem erneuten Auswählen im Uploadmanager hab ich erstmal so gemacht.
Kann ich ja noch so umbauen, dass das angezeigte Unterverzeichnis als
Vorauswahl dient.
Im FF habe ich eigentlich keine Darstellungsfehler, hatte das mit der
19er und jetzigen 20er so entwickelt. Mit Opera, Chrome und dem IE (nur
bis IE 8, da nur XP) hab ich es noch nicht probiert, aber ich kann mich
die Tage mal ransetzen.
Ein Fehler hab ich schon gefunden. Ältere Browser verstehen den Mime-Typ
"application/javascript" nicht, sondern die nie standardisierte Version
"text/javascript". Warum der IE 8 dann immer noch das dom-Objekt nicht
findet, konnte ich heute morgen noch nicht klären.
Ich hab dem IE8 zumindest schon mal die Anzeige im gleichen Fenster
beigebracht. Bis auf den Darstellungsfehler und dem fehlenden Support
für den Multifileupload von HTML5 läuft es. Eigentlich wollte ich das
unabhängig von Flash oder Java halten, um nicht irgendwelchen
IT-Restriktionen zu wider zu laufen :(
Hallo,
erstmal vielen Dank für PartDB. Das ist eine tolle Sache und hilft
ungemein. Ich habe eine kleine Ergänzung für den Import von Bauteilen
bei einer Baugruppe gemacht, so dass man nun die Bauteile nicht nur über
die ID sondern auch über den Bauteilnamen importieren kann. Vielleicht
ist das ganze ja auch für andere hilfreich. Der Patch gegenüber dem
branch uneist_kami89 hängt an.
Viele Grüße,
Christoph
Hallo Christoph,
Danke für den Patch, das ist keine schlechte Idee. Ich habe ihn kurz
angeschaut und werde ihn dann gleich übernehmen (mit ein paar
Anpassungen - z.B. wenn es zu einem Namen mehrere exakt gleichnamige
Bauteile gibt, soll der Vorgang abgebrochen werden weil das Ergebnis
nicht eindeutig ist).
Momentan bin ich mich übrigens grad selbst am bestrafen ;-)
Als ich die Klasse "File" und die davon abhängigen Klassen erstellte,
war mir bereits bewusst dass "File" ein nicht sehr geschickter Name ist,
bin aber grad auf keine bessere Idee gekommen. Danach ist es leider in
Vergessenheit geraten... Nun bin ich dabei, den Namen "File" durch
"Attachement" zu ersetzen, diese neue Bezeichung ist viel
aussagekräftiger und zutreffender. Man kann sich ja etwa vorstellen
wieviel Arbeit das gibt... Und nein, automatisches copy&replace geht
nicht, da "File" auch in anderen Zusammenhängen verwendet wird ;-)
Ich werde dann schon bald diese zwei Änderungen ins Repository
hochladen. Dann muss man auf jeden Fall wieder eine Datenbank der
Version 12 laden, da auch die Tabelle "files" in "attachements"
umbenannt wird.
mfg
Hallo,
es freut mich, dass du die Funktion einbaust. Dadurch, dass in meinem
Fall die Namen eindeutig sind, habe ich nicht dran gedacht, da auf
Mehrdeutigkeit zu testen.
Von Klassennamen, mit denen man sich ein Bein stellt, kann ich auch ein
Lied singen (ich verdiene meine Brötchen als Softwareentwickler). Da
hilft dann einfach nur Augen zu und durch :)
Im Moment ist bei mir das Datenschema Version 13. Heißt dass, dass ich
erst ein Downgrade machen muss, bevor ich dann die neue Version mit den
zwei Änderungen verwenden kann?
Viele Grüße,
Christoph
So, die Änderungen sind nun im Repository (r616).
Ich habe vorher gar nicht gesehen, dass im Patch das Suchen des
entsprechenden Bauteiles in "build_deviceparts_import_template_loop()"
geschah, das ist irgendwie nicht so passend weil diese Funktion nur für
das Erzeugen eines Template-Loops (also für die Ausgabe) verantwortlich
ist. Die eigentliche Import-Funktion braucht die Suchfunktion allerdings
auch, daher habe ich sie nun in eine eigene Funktion
"match_devicepart_names_to_ids()" ausgelagert. Scheint soweit zu
funktionieren, wenns Probleme gibt bitte melden :-)
Christoph Emonds schrieb:> Von Klassennamen, mit denen man sich ein Bein stellt, kann ich auch ein> Lied singen (ich verdiene meine Brötchen als Softwareentwickler).
Ja, das glaube ich :-)
Ich bin zwar bei solchen Sachen ein Perfektionist, habe aber das Problem
dass mir manchmal keine passenden Namen einfallen. Das war mir auch
bewusst als ich die Klasse "File" getauft habe, daher stand das schon
von Anfang an auf meiner (virtuellen :-) ToDo-Liste. Die virtuelle
ToDo-Liste ist aber leider auch nicht von Datenverlust befreit :-D
Christoph Emonds schrieb:> Im Moment ist bei mir das Datenschema Version 13. Heißt dass, dass ich> erst ein Downgrade machen muss, bevor ich dann die neue Version mit den> zwei Änderungen verwenden kann?
Ja, die Entwicklung findet momentan im Branch "uneist_kami89" statt, und
die aktuelle Version ist noch nicht für den produktiven Einsatz gedacht.
Heisst also, ich passe die Datenbankstruktur ab und zu wieder an, ohne
ein entsprechendes Update rauszugeben. Stattdessen muss wieder eine alte
Datenbank geladen werden, sonst läuft Part-DB nicht mehr korrekt.
Ein Downgrade auf v12 gibt es nicht. Ich hoffe, du setzt Part-DB 0.3.0
nicht schon produktiv ein? ;-)
mfg
Vielleicht sollte man sich ein Deutsch-Englisch-Wörterbuch neben den PC
legen, um passende englische Wörter zu finden? ;-)
PS: Mittlerweile hab ich auch Win7 in einer virtuellen Umgebung. So kann
ich dann auch in meinem Kurzurlaub um den 1. Mai den Filemanager weiter
entwickeln.
Hmmm... Angenommen ich würde gerne die Datenbankstruktur meines
"Testsystems" migrieren, kann ich mir die dafür nötigen Änderungen aus
den Commit messages zusammensuchen und selber ein Änderungsskript
erstellen? Hast du denn schon eine Idee, wann ein neues Release kommt?
Hatte mich da wohl von dem RC1 auf der Startseite dazu verleiten lassen,
die Version schon einzusetzen.
Vielen Dank schonmal :)
Viele Grüße,
Christoph
> Hatte mich da wohl von dem RC1 auf der Startseite dazu verleiten lassen,> die Version schon einzusetzen.
Naja...Wir entwickeln ja laufend im Repository, und momentan arbeiten
wir auf die 0.3.0 RC1 hin. 0.3.0 Ist also quasi das Ziel, nicht der
momentane Stand. Wenn die RC1 fertig ist, wird sie als Downloadpaket
angeboten. Solange wir kein fertiges Paket anbieten, ist es noch nicht
für Endanwender bestimmt.
Mir scheint, vielen Leuten ist nicht klar bewusst dass das Repository
grundsätzlich nur für die Entwickler gedacht ist. Für den Endanwender
stricken wir dann Archive, die man (ohne SVN Client) runterladen kann.
> Hmmm... Angenommen ich würde gerne die Datenbankstruktur meines> "Testsystems" migrieren, kann ich mir die dafür nötigen Änderungen aus> den Commit messages zusammensuchen und selber ein Änderungsskript> erstellen?
Also zurück zur v12 migrieren wäre ein riesen Aufwand, bzw. u.U. gar
nicht mehr möglich weil dort gewisse Funktionen noch nicht zur Verfügung
standen. Wenn es dir nichts ausmacht wäre es einfacher, wenn du deine
Datenbank von nun an jeweils selber aktualisierst, bis dann die RC1
offiziell fertig ist. Bis dahin sollte es eigentlich fast keine
Änderungen mehr geben (hoffe ich mal ;-).
Die Datenbankupdates sind in der updates/db_update_steps.php
aufgelistet.
Im Commit von r616 siehst du, was du alles ändern müsstest, damit du
deine Datenbank mit der Version 0.3.0 weiterverwenden könntest.
Wenn es nur eine handvoll Artikel sind, würde ich aber eher eine leere
DB v12 nehmen und die Bauteile von Hand übertragen. Halt mit den
Einschränkungen von v12, die z.B. nur einen einzigen Lieferanten pro
Bauteil unterstützt.
> Hast du denn schon eine Idee, wann ein neues Release kommt?
Das ist schwierig zu sagen. Sobald Udo den Dateimanager fertig hat,
können wir ausgiebig mit dem Testen anfangen und dann schon bald einen
ersten Release Kandidaten rausgeben. Ausser die 80/20-Regel macht uns
noch einen Strich durch die Rechnung :-)
Hallo,
mir war schon bewußt, dass das 0.3.0 Repository nicht stabil ist, aber
ich bin halt eher davon ausgegangen, dass sich das weniger auf die
Datenbank als vielmehr auf das Frontend bezieht. Ich hatte mir zuerst ja
auch die 0.2.2 installiert, aber später dann geupgradet, weil ich ja
noch die Änderungen bzgl. des Bauteileimports machen wollte. Da sich ja
schon einiges im Vergleich zur 0.2.2 getan hat, hielt ich es für
sinnvoll, das ganze dann in der aktuellen Version zu machen.
Das ganze ist aber auch kein Problem. Ich bastel mir jetzt einfach immer
wenn es noch Änderungen am Datenbankschema gibt ein Updateskript und
pass das ganze dann bei mir an. Solange solche Änderungen in den
Commitmessages stehen, geht das schon :-)
Auf jeden Fall vielen Dank für das Tool und eure Arbeit.
Viele Grüße,
Christoph
Christoph Emonds schrieb:> Solange solche Änderungen in den> Commitmessages stehen, geht das schon :-)
Jup, das werden sie. Sollten aber wie gesagt nicht mehr häufig
vorkommen.
Christoph Emonds schrieb:> Auf jeden Fall vielen Dank für das Tool und eure Arbeit.
Gerne doch :-)
@K.J. falls du mitliest:
In der Online Demo sollte man nun auch wiedermal eine Datenbank der
Version 12 einspielen. Ausserdem, wäre es vielleicht möglich Doxygen auf
dem Server zu installieren? Ich habe nun nämlich die Doxygen Doku aus
dem Branch entfernt, weil die stört in den Commits einfach zu stark, die
wirklich wichtigen Änderungen gehen dabei unter. Wer sie braucht, kann
sie ja ganz einfach selber erstellen, das Doxyfile ist ja vorhanden.
Wenn nun auf dem Demo Server Doxygen auch installiert wäre, könnte man
ab und zu mal in den Entwicklerwerkzeugen auf "Doxygen Doku
aktualisieren" (o.ä.) klicken, dann steht auch diese Doku wieder online
zur Verfügung. Noch komfortabler wäre natürlich, wenn sie jeweils nach
dem auschecken der aktuellen SVN Revision gleich automatisch erstellt
werden würde, muss aber nicht unbedingt sein.
Gruss
Urban
hi,
erstmal danke für das tolle System, es ist sehr hilfreich!
Ich glaube ich habe einen Bug gefunden: Wenn ich einem Bauteil ein
falsches Bild hochgeladen habe und zum ausbessern ein anderes Bild
hochlade, hat das Bauteil gar kein Bild mehr und jeder weitere Versuch
funktioniert nicht. Aber hochgeladen wird das Bild, also es ist immer im
img/ Verzeichnis. (Habe auch probiert das Bild direkt im Dateisystem zu
löschen, es wird einfach beim hochladen neu erstellt aber im Bauteil
wird kein Bild angezeigt).
c,Ya Chris.
also aktuell ist keine demo funktionsfähig oder sehe ich das falsch. bin
heute mal wieder hierher gekommen um mich etwas über den weiteren
verlauf zu informieren. meine SVN 512er läuft immernoch stabil mit
einigen bugs die aber eher nebensächlich sind. ansonsten ist die partdb
hier im volleinsatz zu unseren Kardex Lagerschränken.
wollte gerade mal die weinbauer demo testen was sich so getan hat bisher
aber dort geht gar nix. weder mit ie noch chrome. anscheinend ist da was
am template falsch wodurch mir das neuerstellen von artikeln verwährt
bleibt.
wäre schön wenn man da extern wieder bisl testen könnte und entsprechend
beid er fehlersuche hilft. Ich habe auch paar bugs in der issue list auf
google eingetragen. ob diese noch in der neuesten vorhanden sind kann
ich aber aufgrund der oben genannten probleme gerade nicht sagen.
gruß kirkdis.
PS: wie schon vor nem halben jahr erwähnt kann ich auch gerne am wiki
und anleitungen zur partdb mithelfen allerdings bräuchte ich da mal ne
neue version zum testen
Hi, ich beuchte mittlerweile mal Hilfe (am besten einer der Entwickler),
zum Thema GPL neuerdings trudelt hier ne menge Post ein, der Part-DB
betreffend mag sich jemand mit mir per Mail in Verbindung setzen.
Danke
hallo kirkdis,
Also momentan gibts nur einen aktiven Branch, das ist der
"uneist_kami89". Der sollte lauffähig sein, in der Online-Demo muss nur
noch eine neue Datenbank eingespielt werden dann läufts dort auch
wieder.
Die anderen Branches sind veraltet, da gibts nichts Interessantes mehr.
Hilfe bei der Doku können wir bestens gebrauchen, dazu gibts im
genannten Branch extra ein DokuWiki das noch auf einen Freiwilligen
Helfer wartet :-)
@K.J.
hast eine PN bekommen.
mfg
Danke ist mir wohl irgendwie entgangen, gibt noch das Typische umlaut
Problem aber da kümmer ich mich gleich noch drum.
@kami installiere auch grade doxigen mal sehn ob ich das hinbekomme weil
mein Server recht restriktiv ist mit fremd Programme ausführen.
Meine Demo funktioniert derzeit gar nicht, da sie einen Stand ausserhalb
unseres SVN-Repos repräsentiert. Ich werde mal die Demo auf den Stand
des Repos updaten und auch mal den Filemanager weiter schreiben. Gerade
das Thema Javascript ist ja nicht ohne, weil fast jeder Browser seine
Eigenheiten hat und man sich oft stundenlang die passende Doku zusammen
suchen muss. Vorallem die unterschiedlichen IEs sind grauslich!
Javascript-Entwickler sind gerne willkommen :)
Wenn bei mir auf der Arbeit die Akkreditierung im Juni gelaufen ist,
dann dürfte ich auch wieder mehr Zeit (und Nerven) für die Entwicklung
haben.
Grüße
Udo
Udo Neist schrieb:> Vorallem die unterschiedlichen IEs sind grauslich!>> Javascript-Entwickler sind gerne willkommen :)>>> Grüße> Udo
Tu dir das nicht an alles unter 7/8 ist für die Reste Tonne und ziemlich
unbeherrschbar, bau ne abfrage rein das der User updaten muss, der
filemanager ist momentan ja nicht zwingent damit die Part-DB leuft.
Doxigen scheint zu laufen auf der DEMO.
Den IE 6 und älter sind bei mir nicht auf der Liste. Warum soll ich mit
den JS (nicht zu verwechseln mit Javascript; M$ wollte keine Lizenzen
kaufen, daher diese Variante der ECMA-Scriptfamilie) unterstützen? Erst
mit IE 7 näherte sich M$ an Javascript an, wobei da selbst im IE 10 noch
Differenzen zum Quasi-Standard der Gecko/Webkit-Systeme bestehen.
Leider ist mir durch eine kleine Unachtsamkeit mein Raid mit den
virtualisierten Windoofs (XP und 7) "abgeraucht", muss beides morgen neu
installieren. Zum Glück hab ich aber noch ein XP auf dem Notebook ;-)
K. J. schrieb:> gibt noch das Typische umlaut> Problem aber da kümmer ich mich gleich noch drum.
Ja, das leidige Problem mit den Umlauten... ;-)
Das Problem liegt aber höchstwahrscheinlich nicht an deiner
Installation, sondern an meiner Datenbank.
Wenn ich mich nicht täusche, liegt das Problem genau genommen an älteren
Versionen von Part-DB. Wenn man da nämlich ISO-8859-1 als HTTP
Zeichensatz verwendet hat, dann wurden die ISO-8859-1-codierten Zeichen
als UTF-8 codierte Zeichen an die MySQL Datenbank übergeben. Beim MySQL
connect ist nämlich kein Zeichensatz angegeben, also müsste automatisch
UTF-8 verwendet werden.
Das würde dann also bedeuten, dass alle Benutzer, die den HTTP
Zeichensatz auf ISO-8859-1 stehen haben, nun falsch codierte Zeichen in
ihrer Datenbank haben. Solange man zum Decodieren auch wieder ISO-8859-1
verwendet, fällt das natürlich nicht auf. Jetzt (v0.3.0) kann man
allerdings den Zeichensatz nicht mehr wählen (weils nichts bringt), und
die falsch codierten Zeichen in der Datenbank äussern sich in Form von
kryptographischen Zeichen auf der Webseite.
Man könnte natürlich weiterhin den Zeichensatz auf ISO-8859-1 stellen,
dann fällt das Problem nicht auf, aber das behebt nicht die Ursache
sondern nur das Symptom.
Die Frage ist jetzt allerdings, wie wir das Problem lösen, ohne dass die
Benutzer all ihre Umlaute von Hand austauschen müssen. Vielleicht würde
es ein MySQL Befehl im Datenbankupdate tun, das alle falsch codierten
Umlaute durch richtig codierte Umlaute ersetzt. Muss mal schauen ob das
funktioniert...
Dabei muss ich aber noch anmerken, dass das alles nur Vermutungen sind.
Ich habe nicht so wirklich viel Erfahrung mit dieser Problematik, ich
habe einfach mal versucht das Phänomen mit logischen Schlussfolgerungen
nachzuvollziehen ;-D
K. J. schrieb:> Doxigen scheint zu laufen auf der DEMO.
Wunderbar!
mfg
mysql und Zeichenkodierung ist schon seit Jahren ein echtes Problem.
Evtl. kann man da mit ein paar manuellen Konvertieroutinen Abhilfe
schaffen, letztendlich muß die Kodierung von der Datenbank über php und
dem Webserver bis zum Browser konsistent sein :-/
Grüße
b.r
Okay also ich habe gerade gemerkt dass meine Testdatenbank-Datei im SVN
schon fehlerhaft ist, daher werden die Umlaute dann auch nach dem Import
noch falsch dargestellt. Ich habe die Datei nun korrigiert und werde sie
mit dem nächsten Commit hochladen.
Irgendwie kommen die falsch codierten Werte ziemlich sicher von einem
Bug in einer früheren Version von Part-DB. In der Zwischenzeit habe ich
aber mindestens einmal meine Datenbank exportiert und wieder Importiert
(Umzug des Servers), durch den Import/Export konnten meine Daten aber
ev. noch zusätzlich beschädigt worden sein. Denn mich macht etwas
stutzig, dass in meiner Datenbank ein 'ä' ganze 4 Bytes belegt, das kann
also nicht nur durch ein falsch codiertes Zeichen entstanden sein. Da
muss mindestens zweimal nacheinander etwas schiefgelaufen sein.
Dieser spezielle Fall lässt sich vermutlich nur durch Textersetzung
korrigieren. Allerdings frage ich mich, ob noch mehr Leute von diesem
Problem betroffen sind.
Hat jemand noch eine Datenbank, die mit einer Part-DB <= 0.2.2 betrieben
wird und noch nie exportiert/importiert wurde?
Falls ja, würde mich interessieren, wie dort die Umlaute abgespeichert
werden. Werden sie in phpMyAdmin korrekt angezeigt? Falls nicht, kann
man sich den Hex-Code anschauen, z.B. damit:
1
SELECT HEX(`name`) FROM categories WHERE ID = 5
Das Umlaute-Problem ist sicher relativ leicht zu lösen. Viel schwieriger
ist es aber, rauszufinden, wie die Datenbanken unserer Nutzer überhaupt
aussehen ;-)
mfg
Eventuell ist in meinem Testbranch noch eine alte Version vorhanden.
PS: Ich habe zwar am Filemanager weiter gearbeitet, kann aber leider
keine Fortschritte beim IE vermelden. Bis einschliesslich IE9 fehlt mir
FormData(), um einen verbesserten Uploader fertig zu stellen. Da muss
ich wohl oder übel auf Flash oder die alte Methode zurück greifen :(
Wobei Flash ja nicht überall zu finden wäre.
Udo Neist schrieb:> Eventuell ist in meinem Testbranch noch eine alte Version vorhanden.
OK wäre super wenn du da bei Gelegenheit mal nachschauen könntest :-)
Udo Neist schrieb:> PS: Ich habe zwar am Filemanager weiter gearbeitet, kann aber leider> keine Fortschritte beim IE vermelden. Bis einschliesslich IE9 fehlt mir> FormData(), um einen verbesserten Uploader fertig zu stellen. Da muss> ich wohl oder übel auf Flash oder die alte Methode zurück greifen :(> Wobei Flash ja nicht überall zu finden wäre.
Hmm also das klingt, als ob es noch etwas länger dauern wird (?).
Theoretisch könnten wir sonst ja auch nochmal den simplen Upload-Button
wie bisher verwenden bis der neue Dateimanager fertig ist. Dann könnten
wir den ersten Release Kandidat der Version 0.3.0 schon sehr bald zum
Download anbieten, und du kannst dir für den neuen Uploader problemlos
die Zeit nehmen, die du brauchst.
Arbeiten kann man ja auch mit dem alten Uploader, bisher ging das
schliesslich auch :-)
Falls niemand etwas dagegen hat, würde ich mich dann mal ums
Fertigstellen der 0.3.0 RC1 kümmern. Das Problem mit der
Zeichencodierung hätte dann jetzt erstmal höchste Priorität, denn das
muss noch vor dem Release behoben werden.
@kami das ist Definitiv ein Datenbank Problem das bekommen wir nicht im
griff 4-Byte für umlaute hat was mit dem Zeichensatz zu tun.
Du hast div. Möglichkeiten den Zeichensatz einzustellen, im Mysql, PHP
und im Script selber, zuletzt noch im Backup, und das sind alles User
Probleme.
Das ist ziemlich unhändelbar die meisten CMS geben das auch nur vor fürs
Script und um den Rest muss sich der User kümmern.
Das einzige was mir so einfallen würde ist die Sonderzeichen vor der
Weitergabe in die DB umzuwandeln und beim Rausholen nochmal, aber das
wehre ziemlich unnötiger Overhead, im Normalfall gibt man seine Backups
nicht weiter.
Also ich habe mal einen Test gemacht. Neue Datenbank angelegt, Struktur
mit dem SQL Skript aus v0.2.2 erzeugt und meine Part-DB 0.2.2 mit dieser
Datenbank verknüpft. Dann eine neue Kategorie 'ä' angelegt und in
phpMyAdmin den Bytecode davon angeschaut.
Das Zeichen 'ä' sollte dem Bytecode 0xC3 0xA4 (UTF-8) bzw. 0xE4
(ISO-8859-1) entsprechen.
Ergebnis mit HTTP Zeichensatz UTF-8: 0xC3 0x83 0xC2 0xA4
Ergebnis mit HTTP Zeichensatz ISO-8859-1: 0xC3 0xA4
Erklärung:
Bei ISO-8859-1 wird das 'ä' als 0xE4 von PHP entgegengenommen und MySQL
übergeben. Da für die Übertragung kein Zeichensatz vereinbart wurde,
beginnt hier ein Glücksspiel. In meinem Fall geht MySQL wohl davon aus,
dass es ISO-8859-1 codiert ist. Intern arbeitet MySQL aber mit UTF-8,
also wird das Zeichen nach UTF-8 konvertiert und als 0xC3 0xA4 in der
Datenbank abgelegt. In diesem Fall wird das Zeichen also richtig codiert
in der Datenbank abgelegt.
Bei UTF-8 wird das 'ä' als 0xC3 0xA4 von PHP entgegengenommen und MySQL
übergeben. MySQL nimmt aber wieder an es sei ISO-8859-1. 0xC3 entspricht
dann 'Ã', 0xA4 entspricht '¤'. Beide Zeichen werden dann wieder
(unnötigerweise!) nach UTF-8 konvertiert. 'Ã' ergibt dann 0xC3 0xA4, '¤'
entspricht 0xC2 0xA4.
Zusammengefasst kann man also sagen, dass zwei Fehler das Problem
verursachen:
- Beim Verbindungsaufbau mit dem MySQL Server wird kein Zeichensatz
vereinbart. Es ist reine Glückssache, dass der richtige Zeichensatz
verwendet wird
- Der Benutzer kann in Part-DB den HTTP Zeichensatz selber einstellen.
Wählt er den falschen, gibts ein Durcheinander.
Lösungsvorschlag:
- Für die MySQL-Verbindung wird IMMER UTF-8 verwendet (hardcoded). Das
ist in der aktuellen Entwicklerversion bereits so gemacht.
- Der HTTP Zeichensatz wird IMMER auf UTF-8 eingestellt (hardcoded), der
Benutzer kann es nicht ändern. Was er nicht ändern kann, kann er nicht
falsch machen ;-) Ausserdem wäre hier m.M.n. ISO-8859-1 sowieso falsch,
weil unsere PHP/TMPL Dateien ja auch UTF8-codiert sind.
Machen wir diese Umstellung, wird es Benutzer geben die nach dem Update
auf 0.3.0 das gleiche Problem haben wie ich. Lösen könnte man es mit
Search&Replace in der Datenbank.
Ich werde mal schauen wie die "4-Byte-Codes" der wichtigsten paar
Zeichen (Umlaute und noch ein paar Sonderzeichen) lauten und ein
entsprechender Search&Replace Befehl ins Datenbankupdate einbauen.
Man könnte beim Update einfach einen Dump der Datenbank machen, den mit
Recode auf UTF-8 trimmen und wieder einspielen. 100% sicher ist das
Verfahren nicht, aber immerhin besser als das Scannen aller Daten und
halbmanuell das ändern. Beim Einlesen "--default_character_set utf8"
nicht vergessen, damit MySQL nicht wieder was falsch macht ;-)
Dump:
mysql --default_character_set utf8 -uUSER -pPASS DATABASE <dump
Weitere Optionen können hilfreich sein, z.B.
--add-drop-table
--hex-blob
--create-options
--extended-insert
Wobei einige Optionen bereits mit per Default gesetzt sind (siehe auch
--opt).
Udo Neist schrieb:> mysqldump
Können wir leider nicht verwenden weil das bei den meisten Hostern nicht
läuft ;-)
Part-DB sollte möglichst ohne exec() auskommen sonst kann man es auf
einem normalen Webspace nicht mehr verwenden...
Das Ersetzen mit dem MySQL Befehl "REPLACE()" habe ich grad getestet,
funktioniert zumindest bei meiner fehlerhaften Datenbank super. Ist
sicher nicht sehr elegant, aber allemal besser als gar nichts
unternehmen ;-)
Hallo,
ich hab da ein Problem mit part-db beim Webhoster Strato. Anscheinend
stimmen die Links nicht. Beim Aufruf der Startseite bekomme ich folgende
Meldungen:
The requested URL /mnt/webj/c0/03/5587203/htdocs/part-db/navigation.php
was not found on this server.
Nach meinem Verständnis ist der Teil "/mnt/webj/c0/03/5587203/htdocs"
der Pfad auf dem Server, jedoch nicht die richtige URL von außen.
Versuchsweise habe ich in "start_session.php" folgende Zeile angepasst:
define('BASE_RELATIVE', './');
Danach konnte ich auf part-db zugreifen. Allerdings denke ich mal das
dass nicht so ganz der richtige Weg ist. Hat da einer von euch einen
Tipp ?
Gruß
Dirk
So, habe grad nochmal ein Update hochgeladen (r619), da sind noch ein
paar wichtige Änderungen drin. Unter anderem auch eine Migration der
alten config.php in das neue Format, damit man die Einstellungen nicht
nochmal tätigen muss.
Übrigens war bisher ja der PayPal-Link tot, weil Jacobs PayPal-Konto
nicht mehr erreichbar ist. Nach Absprache mit K.J. geht der Link nun
(zumindest vorläufig) auf mein PayPal Konto. Falls tatsächlich Spenden
getätigt werden, werde ich es sammeln und bei Erreichen eines
nennenswertes Betrages hier bekanntgeben um das weitere Vorgehen
abzuklären.
Vermutlich werde ich schon bald den aktuellen Entwickler-Branch in den
Trunk mergen, und dann ein Paket für die 0.3.0 RC1 zum Download
anbieten.
mfg
Urban B. schrieb:> Übrigens war bisher ja der PayPal-Link tot, weil Jacobs PayPal-Konto> nicht mehr erreichbar ist. Nach Absprache mit K.J. geht der Link nun> (zumindest vorläufig) auf mein PayPal Konto. Falls tatsächlich Spenden> getätigt werden, werde ich es sammeln und bei Erreichen eines> nennenswertes Betrages hier bekanntgeben um das weitere Vorgehen> abzuklären.
Jup passt, Paypal ist manchmal recht kompliziert wen das Konto aus
Sicherheitsgründe dicht ist, da kein Geld drauf war tue ich mir das
nicht an.
Will ungerne deren Datenbank mit den geforderten Sachen füttern, die
haben echt komische Forderungen.
>> Vermutlich werde ich schon bald den aktuellen Entwickler-Branch in den> Trunk mergen, und dann ein Paket für die 0.3.0 RC1 zum Download> anbieten.>> mfg
Das Paket muss ich glaube ich erstellen b.z.w. Uploaden, glaub das kann
ich nur als einziger.
p.s. Hab die Doku für die GPL Geschichte angefangen, leider ist das
ganze recht kompliziert die GPLv2 ist nicht wirklich einfach zu
verstehen.
So hab jetzt mal die print Anweisungen eingefügt und bekomme folgende
Ausgabe:
BASE = "/mnt/webj/c0/03/5587203/htdocs/part-db"
DOCUMENT_ROOT = "/home/strato/http/premium/rid/72/03/5587203/htdocs"
BASE_RELATIVE = "/mnt/webj/c0/03/5587203/htdocs/part-db/"
DIRECTORY_SEPARATOR = "/"
Dirk B. schrieb:> So hab jetzt mal die print Anweisungen eingefügt und bekomme folgende> Ausgabe:>> BASE = "/mnt/webj/c0/03/5587203/htdocs/part-db"> DOCUMENT_ROOT = "/home/strato/http/premium/rid/72/03/5587203/htdocs"> BASE_RELATIVE = "/mnt/webj/c0/03/5587203/htdocs/part-db/"> DIRECTORY_SEPARATOR = "/"
Du hast da zwei unterschiedliche angaben des Pfades, das kann nicht
sein.
Base_relative müsste auch anders sein nämlich der Relative Pfad der URL
also wahrscheinlich "part-db/"
Ich habe keine Ahnung was Strato da hinter den Kulissen macht, aber die
Ausgaben stammen direkt von meinem Webspace bei Strato :-(
Naja, zur Not kann ich immer noch den Pfad manuell im Source anpassen.
> Das Paket muss ich glaube ich erstellen b.z.w. Uploaden, glaub das kann> ich nur als einziger.
OK wenn es dann soweit ist melde ich mich einfach bei dir.
> p.s. Hab die Doku für die GPL Geschichte angefangen, leider ist das> ganze recht kompliziert die GPLv2 ist nicht wirklich einfach zu> verstehen.
Hehe ja das glaube ich ;-) Ich kenne mich da leider auch zu wenig aus,
müsste mich auch erst genauer informieren was da alles geregelt wird...
Dirk B. schrieb:> BASE = "/mnt/webj/c0/03/5587203/htdocs/part-db"> DOCUMENT_ROOT = "/home/strato/http/premium/rid/72/03/5587203/htdocs"> BASE_RELATIVE = "/mnt/webj/c0/03/5587203/htdocs/part-db/"> DIRECTORY_SEPARATOR = "/"
Das ist ja wirklich eine komische Sache, mit solch unterschiedlichen
Pfaden vom Server kommt Part-DB nicht zurecht. Ich habe mal ein bisschen
im Internet nachgeschaut und bin auf das hier gekommen:
http://www.strato-faq.de/artikel.html?sessionID=4ca68360450406176b63d8a14b819b56&id=10
Aber selbst diese Beschreibung passt nicht zu deinen Pfaden, da dort
deine Domain ja nicht enthalten ist. Weiss der Geier, was Strato hier
für Spielchen treibt ;-)
Ich denke mal das ist für uns Entwickler unmöglich, die korrekten Pfade
zu bekommen, vermutlich wirds also auf das hier rauslaufen:
Dirk B. schrieb:> Naja, zur Not kann ich immer noch den Pfad manuell im Source anpassen.
Ja das geht natürlich, wird dann aber bei jedem Update wieder
überschrieben. Ansonsten könnte ich noch eine Funktion einbauen, die es
explizit erlaubt, die Pfade manuell zu setzen, und die dann auch bei
einem Update nicht überschrieben werden. Werde mal schauen was man da
machen kann.
Rein für die Webseite sind die Pfade nicht so kritisch, also wenn die
Seite richtig angezeigt wird passt das schon. Allerdings kann es
Probleme geben bei den Pfaden zu Footprint-Bilder oder Dateianhängen.
Denn bevor ein Pfad zu einer Datei in der Datenbank abgelegt wird, wird
ein Replace druchgeführt, der den BASE Pfad durch "%BASE%" ersetzt. So
gibt es keine Probleme wenn man Part-DB auf einem anderen Server (mit
anderem BASE Pfad) installiert, alle Pfade in der Datenbank
funktionieren dann immernoch weil eben der absolute Pfad dort nicht
abgelegt wird. Wenn du jetzt bei der manuellen Definition der Pfade was
falsches eingibst, könnte es unter Umständen sein dass diese
Textersetzung nicht mehr funktioniert.
Allerdings wäre auch dieses Problem schnell wieder lösbar, du müsstest
dann bei einem Server-Umzug halt manuell in der Datenbank alle
Basis-Pfade noch durch "%BASE%" ersetzten, dann läufts wieder. Wichtig
ist einfach dass du das weisst, sonst ärgerst du dich nach einem Umzug
über die nicht mehr funktionierenden Dateipfade...
mfg
Eine Möglichkeit zum manuellen Setzen wäre natürlich sehr gut.
Zu den Footprints hätte ich sowieso noch eine Frage. Wenn ich z.B. ein
TQFP64 Gehäuse anlegen möchte, wie muss ich das mit den neuen Footprint
Bildern denn machen ?
Wie wäre es mit folgenden Code? Wenn BASE und BASE_RELATIVE auf das
gleiche Verzeichnis zeigen, dann wird "./" als Pfad zurückgegeben,
ansonsten einen aus DOCUMENT_ROOT zusammengebauten (altes Verhalten).
Ob es auf allen Strato-Hosts funktionieren wird, bezweifel ich.
Vielleicht setzt Strato ein BIND oder nen Link auf das Verzeichnis und
schiebt dem Apachen was anderes unter? Ziemlich merkwürdiges Setup.
b.r schrieb
> Zum Ausprobieren gibt es momentan zwei Demo-Seiten:> http://partdb.grautier.com/ ("offiziell")
leider funktioniert die Demo zur Zeit nicht
Dirk B. schrieb:> Zu den Footprints hätte ich sowieso noch eine Frage. Wenn ich z.B. ein> TQFP64 Gehäuse anlegen möchte, wie muss ich das mit den neuen Footprint> Bildern denn machen ?
Nun, das ist momentan ein bisschen blöd...Eigentlich war dafür der neue
Filemanager gedacht. Also man hätte dann den neuen Footprint angelegt
und mit dem Filemanager das passende Bild dazu ausgewählt. Da der
Filemanager aber noch fehlt, müsste man theoretisch den Dateipfad des
entsprechenden Bildes in das Textfeld "Bild:" eintippen (bzw. per
Copy&Paste aus der Footprintbilder-Übersicht).
Es gibt momentan nur einen Workaround der das etwas einfacher macht. Man
kann statt dem Dateipfad einfach z.B. "DIP28" eintippen und so
übernehmen. Weil das Bild dann aber nicht gefunden wird, taucht der
Eintrag dann unter "Footprints mit fehlerhaften Dateinamen" auf, inkl.
Vorschlägen für Dateipfade die ein "DIP28" beinhalten. Dort kann man das
passende dann anwählen und übernehmen.
In der Version 0.2.2 läuft es momentan ja auch nicht anders...
Sobald der neue Filemanager kommt, ist das Problem dann aber auch
beseitigt. Man könnte ja z.B. auch mit dem Zuweisen der Bilder noch
warten und das dann erst später machen wenn der Filemanager fertig ist.
Demo Tester schrieb:> leider funktioniert die Demo zur Zeit nicht
Huch, @K.J. hat mein Update von gestern vielleicht die config.php
zerschossen?
K. J. schrieb:> Urban B. schrieb:>> Huch, @K.J. hat mein Update von gestern vielleicht die config.php>> zerschossen?>> Jup scheinbar ;-)
Hmm ja jetzt habe ich den Fehler gesehen ;-)
Passiert dann wohl bei allen, die schon die 0.3.0 verwendeten.
Macht aber nix, beim Upgrade von der 0.2.2 auf die 0.3.0 oder wenn noch
gar keine config.php vorhanden ist sollte alles funktionieren.
Ich habe jetzt eben noch eine Versionsnummer für die config.php
eingeführt. So kann man im Falle eines Formatwechsels (wie von 0.2.2 auf
0.3.0) die alte config.php aufs neue Format updaten. Steht in der
config.php noch keine Version drin, geht das System davon aus dass es
sich um Part-DB 0.2.2 handelt, was jetzt natürlich nicht stimmt wenn man
bereits Version 0.3.0 benutzt hat weils bisher diese Versionsnummer noch
nicht gab.
Also ich habe mal einen STRATO workaround in start_session.php eingebaut
(r620). Zusätzlich gibt es jetzt auch die Möglichkeit die Pfade ganz
manuell zu setzen in der config.php, falls es noch andere so komische
Server gibt.
@Dirk B.
kannst du mal schauen ob der workaround so funktioniert?
Eine Sache war mir noch bei den Lieferanten aufgefallen. Wenn man dort
eine Webseite angibt ist der Link über dem Eingabefeld zusammengesetzt
aus der Part-db URL und der Lieferanten URL. Das funktioniert natürlich
nicht.
Aus "www.digikey.de" wird z.B. "http:/www.xyz.de/part-db/www.digikey.de
Gruß
Dirk
So heute nen Barcode Scanner bestellt, das einzige was mir für mein
Lager fehlt, also werde ich mich mal dran machen das Sinnvoll
umzusetzen.
Hab extra einen Bestellt der CDC kann, so kann man den einfach als
Tastatur nutzen und man spart sich den ganzen API Krams.
Demo Tester schrieb:> leider funktioniert die Demo zur Zeit nicht
Funktionert wieder. Hab aber einen kleinen Fehler gefunden. Preise
müssen mit einem Punkt eingegeben werden. Ein Komma wird nicht
akzeptiert.
Respekt für die Arbeit
Ich habe auf der Arbeit auch einen Laserbarcodescanner, der über die
alte DIN-Tastaturbuchse bzw. PS/2 läuft. Auch einige neuere USB-Scanner
kann man als USB-HID direkt nutzen.
Dirk B. schrieb:> Eine Sache war mir noch bei den Lieferanten aufgefallen. Wenn man dort> eine Webseite angibt ist der Link über dem Eingabefeld zusammengesetzt> aus der Part-db URL und der Lieferanten URL. Das funktioniert natürlich> nicht.
Ah ja, liegt nur am fehlenden http://, werde das noch einbauen dass es
automatisch vor das www gesetzt wird wenn der Benutzer es weglässt. Ist
dann im nächsten Commit von mir drin.
K. J. schrieb:> So heute nen Barcode Scanner bestellt, das einzige was mir für mein> Lager fehlt, also werde ich mich mal dran machen das Sinnvoll> umzusetzen.
Daran habe ich auch schon lange gedacht dass wir das mal noch einbauen
müssen, super dass du dich da grad drum kümmerst :-)
Jo mich nervt das schon länger, vor alledem ist es wesentlich einfacher
bei der Teile Entnahme und co. ;-)
Meine Private ToDo liste sagt grade:
- Barcodescanner
- Labeldrucker
Hab mir mal etwas Gedanken gemacht, ich hätte gerne den Namen mit auf
dem Barcode, am besten hört sich bis jetzt CODE128 an als Barcode.
Der Aufbau wehre dann <Bauteielnamen>-<PartID><ENT> so weit ich das
jetzt raus gelesen habe ist der auch problemlos per Termoverfahren in
kleinen Dimensionen Druckbar, das kleinste bei mir wehre 66x12mm, da
passen einige Zeichen drauf.
wobei ich grade nicht weis ob der Barcode Scanner sowas wie ENTER
selbständig ausführen kann soll wohl gehen ansonsten müste mann das dem
Barcode mitgeben bei CODE128 geht das.
Schön wäre auch wenn man für jede Einkaufsinformation auch noch einen
Barcode abspeichern könnte, und zwar den vom Lieferanten. So könnte man
z.B. beim Einbuchen von bestellten Teilen den Barcode auf der Verpackung
kurz scannen und dann noch die Stückzahl eingeben. Das würde das Suchen
des Bauteiles ersparen.
Wobei es natürlich auch andere Varianten gäbe für diese Aufgabe, z.B.
ist ja noch ein "pending orders" geplant, damit könnte man eine
Bestellung mit einem Klick einbuchen. Das setzt aber natürlich voraus
dass man auch jede getätigte Bestellung in Part-DB eingibt...
Das würde gehen wen die Strichcodes der Hersteller die Bestellnummern
sind bei Reichelt z.b. ist das nicht so, da ist es wahrscheinlich
irgendeine Lagernummer.
Es gibt eine PDF-Klasse mit Barcode-Support. Mit dem passenden Drucker
hat man direkt entsprechende Etiketten. Ich habe sowas für einen Dymo
Labelwriter 320 bzw. 400 mal umgesetzt (allerdings nur unter Linux und
Cups als Printerserver).
Ja an sowas dachte ich mit PHP eine Print-bare PDF erstellen und dann
direkt drucken, es gibt zwar Barcode Tools für Server aber das sind
externe Programme und dadrauf würde ich gerne verzichten.
Das grobe PHP-Script hab ich fast fertig, ist recht einfach warte jetzt
auf den Scanner hinzukommt das ich das auch gerne am Tablett nutzen
möchte so brauche ich im Lager keinen PC, leider breuchten wir dazu
endlich mal ein Mobile Template.
Und diese ganzen Templates krams verstehe ich momentan nicht
ansatzweise.
K. J. schrieb:> Das würde gehen wen die Strichcodes der Hersteller die Bestellnummern> sind bei Reichelt z.b. ist das nicht so, da ist es wahrscheinlich> irgendeine Lagernummer.
Jo, man müsste den Barcode auf der Verpackung erstmal in Part-DB
registrieren, also einer Einkaufsinformation zuordnen...
Ganz einfach um nur mal den Scanner zu testen.
http://grautier.com/partdb/barcode.php
Der Barcode bei mir besteht aus <Bauteielname><Trenzeichen><pid>,
z.b. <MAX1181><-><84>
Die pid-0 die in der DB ja nicht vorkommen kann, nehme ich für Options:
Ausbuchen-0
Einbuchen-0
Loeschen-0
...
So kann ich über Barcodes die Options aufrufen um mit dem zweiten Scan
dann das Bauteile der PartDB Hinzuzufügen, Entfernen, Löschen...
Die Überlegung wehre noch ein Dritter Scan, z.b. für die Anzahl, oder
Löschbestätigung die frage wehre ob es nicht zuviel Overhead wehre
dreimal Scannen ist schon recht viel was Sagt ihr ?
K. J. schrieb:> Die Überlegung wehre noch ein Dritter Scan, z.b. für die Anzahl, oder> Löschbestätigung die frage wehre ob es nicht zuviel Overhead wehre> dreimal Scannen ist schon recht viel was Sagt ihr ?
Also wenn man es so macht, dass einmal gescannte Optionen und
Stückzahlen gespeichert werden, entsteht ja kein unnötiger Overhead.
Also z.B. so:
- Option "Ausbuchen" scannen
- Stückzahl "3" scannen
- Bauteil 1 scannen --> 3 Stück werden abgebucht
- Bauteil 2 scannen --> 3 Stück werden abgebucht
- Stückzahl "1" scannen
- Bauteil 3 scannen --> 1 Stück wird abgebucht
- Bauteil 4 scannen --> 1 Stück wird abgebucht
- Option "Einbuchen" scannen
- Bauteil 5 scannen --> 1 Stück wird eingebucht
- Bauteil 6 scannen --> 1 Stück wird eingebucht
- usw.
Ich habe gerade eben (r625) den aktuellen Trunk von Part-DB 0.2.2 nach
"tags" kopiert. Nun ist mein SVN Client grad dran, den Branch
"uneist_kami89" in den Trunk zu mergen. Ich hoffe das klappt, das
Programm scheint ein bisschen Mühe zu haben^^
Das heisst dann also, dass von jetzt an die ganze Entwicklung wieder im
Trunk stattfindet.
Ich würde vorschlagen, dass mal ein paar Leute das Update auf die
Version 0.3.0 RC1 machen (aus dem Trunk) und hier berichten ob alles
geklappt hat. Überschreibt man eine Part-DB 0.2.2 Installation mit der
0.3.0 RC1, sollte die alte config.php auf das neue Format aktualisiert
werden und dann noch ein Installer erscheinen um ein paar weitere
Angaben zu erfassen. Dann muss man noch das Datenbankupdate durchlaufen
lassen, und Part-DB 0.3.0 RC1 sollte einsatzbereit sein.
Wenn die ersten Rückmeldungen dann positiv sind, schnüre ich ein Paket
für die Version 0.3.0 RC1, das wir dann zum Download anbieten. (Für das
Updatepaket müssen dann z.B. das Verzeichnis "development" und den
Menüeintrag zu den noch nicht vorhandenen System-Updates entfernt
werden)
...und mein SVN Client ist immernoch am mergen...der braucht wohl noch
eine Weile ;-)
Verdammt jetzt habe ich fast eine Stunde (!!) gewartet und jetzt bricht
der SVN Client mit einer Fehlermeldung ab...das läuft ja super...
So ein Merge ist wohl eine Wissenschaft für sich. Erst wollte ich es mit
dem Merge-Befehl machen, hat aber nicht geklappt. So wie ich das
verstanden habe, müsste ich erst alle Änderungen vom Trunk, die seit dem
Erstellen des Branches "uneist_kami89" commited wurden, in den Branch
mergen, damit ich den Branch wieder in den Trunk mergen kann. Da all
diese commits aber sinnlos sind (weil im Branch eh alles neu ist) habe
ich nun versucht einfach die Dateien aus dem Branch in den Trunk zu
commiten. Jetzt reklamiert er irgendwas wegen Verzeichnissen die Dateien
beinhalten blabla...
Es kann sich also nur noch um Stunden handeln ;-)
So, jetzt scheint es geklappt zu haben (r626) :-)
Hat wieder fast eine Stunde gedauert zum hochladen...
@Udo
Naja, es gibt ja schon die Online Demo von K.J., die müsste sich morgen
ja wieder automatisch aktualisieren. Wenn das Update korrekt
funktioniert, erscheint dann zwar leider der Installer um noch ein
Administratorkennwort zu erstellen. Ist zwar blöd in der Online Demo,
sollte aber sicherheitstechnisch eigentlich unproblematisch sein (man
kann zwar die config vermurksen, aber die ist ja schnell wieder
hergestellt).
@K.J.
Falls jemand in der Online Demo ein Administratorkennwort eingibt,
kannst du in der config.php die Variable
"$config['installation_complete']['admin_password']" auf "false"
stellen, dann erscheint der Installer nochmals um ein neues Kennwort
einzugeben. Ausserdem musst du noch die Variable
"$config['is_online_demo']" auf "true" stellen.
Dann hoffen wir mal dass alles rund läuft ;-)
Urban B. schrieb:> Dann hoffen wir mal dass alles rund läuft ;-)
Schade, war wohl nichts, die Demo ist ziemlich tot :-(
@K.J.
Vielleicht bekommst du gescheite Fehlermeldungen wenn du in der
config.php das Debugging aktivierst (das setzt automatisch das error
reporting level runter damit man alle Fehlermeldungen und Warnungen zu
sehen bekommt). Oder mal die config.php ganz löschen und schauen ob dann
was kommt...
Und danke fürs ändern meiner Mailadresse, hat geklappt :-)
na, noch niemand die 0.3.0 RC1 ausprobiert? ;-)
Ich warte noch auf Fehlerberichte :-D
Wie gesagt, wenn hier die ersten Berichte positiv sind, werde ich
offiziell ein Archiv von der 0.3.0 RC1 stricken und dann zum Download
anbieten.
@K.J. Interessant wäre für mich noch, was bei der Online Demo vom Trunk
passiert ist, da funktioniert momentan ja gar nichts mehr...
Jup dadurch das du den Trunk geändert hast hat die sich zerlegt kümmer
mich Morgen drum.
Aso die neue Version läuft im Produktiv betrieb bei mir gut.
Und ich hab mal ein Testfile in das SVN gelegt für die Barcode
Geschichte ich muss mich aber erstmal mit dem Template System
auseinandersetzen, deswegen ist es grade nur nen Testfile.
Gibt es irgendwo eine kleine Installations-Anleitung?
Ich hatte mal einen Test-Server mit Version 0.2.0 (?) aufgesetzt, aber
nicht viel damit gemacht, kann ich die 0.3.0 da einfach drüber bügeln?
@K.J. OK alles klar.
M. K. schrieb:> Gibt es irgendwo eine kleine Installations-Anleitung?
Naja, so halbwegs gibts eine (mittlerweile veraltete) Anleitung im
DokuWiki:
http://partdb.grautier.com/uneistkami89/documentation/dokuwiki/index.php
Aber die bringt für die Version 0.3.0 eigentlich nicht mehr viel, die
müsste mal überarbeitet werden.
> Ich hatte mal einen Test-Server mit Version 0.2.0 (?) aufgesetzt, aber> nicht viel damit gemacht, kann ich die 0.3.0 da einfach drüber bügeln?
Ja, eigentlich muss man einfach die alten Dateien mit den Neuen
überschreiben. Da aber viele alte Dateien nicht mehr gebraucht werden,
ist es sauberer wenn man alle alten Dateien erst löscht und dann die
Neuen reinkopiert. Nur (falls vorhanden) die hochgeladenen Bilder im
Verzeichnis "img" sollten nicht gelöscht, sondern ins neue Verzeichnis
"media" verschoben werden, und die config.php sollte ebenfalls nicht
gelöscht werden. Alles andere kann man einfach löschen.
Dann sollte beim ersten Aufrufen noch der Installer erscheinen um ein
paar Eingaben zu erfassen. Dann noch das Datenbankupdate (auf das man
hingewiesen wird) durchlaufen lassen und fertig. Datenbank-Backup vor
dem Update machen falls man bereits Datensätze in der Datenbank hat!
Ich habe grad noch ein paar Änderungen hochgeladen (r631). Das
Administratorpasswort wird jetzt nicht mehr einfach als MD5-Hash in der
config.php abgelegt, sondern zuerst versalzen und dann als SHA256-Hash
abgelegt. Für den Fall, dass ein Unberechtigter Lesezugriff auf die
config.php bekommen würde, ist dies eine enorme Verbesserung der
Sicherheit weil so Rainbow Tables nichts mehr bringen.
Ich dachte, diese Änderung mache ich besser jetzt, noch bevor die 0.3.0
offiziell herausgegeben wurde. Bei denjenigen, die die 0.3.0 bereits
verwenden, wird nach dem nächsten Update einfach der
Installationsassistent nochmal aufgerufen, um das Administratorpasswort
neu einzugeben.
Bitte führt das Update auf Revision 631 durch, nachher nehme ich diese
Übergangslösung wieder raus!
Ausserdem habe ich die Dokumentation noch ein bisschen erweitert. Jetzt
ist auch erklärt, wie man Apache, PHP, MySQL und phpMyAdmin installiert.
Getestet habe ich es selbst schnell unter Ubuntu 13.04.
mfg
hmm ich beschäftige mich grad ein bisschen mit dem Thema Sicherheit um
die Doku in diesem Punkt noch zu ergänzen, und eventuell auch noch ein
paar Überprüfungen der Sicherheitseinstellungen in den Sourcecode
einzubauen.
Grundsätzlich gibt es ja zwei Varianten, Part-DB zu installieren.
Entweder installiert man es im Home-Verzeichnis und erstellt eine
Verknüpfung in /var/www, oder man installiert Part-DB direkt in
/var/www/.
Die erste Variante hat den Vorteil, dass man Part-DB ohne root-Rechte
installieren und aktualisieren kann. Allerdings müssten die Dateirechte
für die config.php und das Verzeichnis "media" dann jedoch auf 666 bzw.
777 stehen, weil der Benutzer "www-data" in diesem Fall nicht der
Besitzer der Dateien ist. Nur so kann Apache die config.php beschreiben
und Dateien nach media hochladen. Unschön ist dann allerdings, dass
die von Apache erstellten Dateien dem Benutzer "www-data" gehören, alles
andere aber dem angemeldeten Systembenutzer. Irgendwie ein bisschen ein
Durcheinander wie ich finde...
Daher frage ich mich ein bisschen, ob wir in der Doku besser nur die
zweite Variante erklären, also dass man Part-DB mir root-Rechten in
/var/www/ installiert, den Besitzer auf "www-data" und die Rechte auf
644 bzw. 755 setzt. Das Updaten wird so zwar mühsamer weil es nur mit
Root-Rechten durchgeführt werden kann, insgesamt empfinde ich diese
Variante aber als "sauberer" und auch sicherer (weil die Dateirechte so
eingeschränkter sein können, z.B. 755 statt 777).
Installiert man Part-DB auf dem Webspace eines Hosters, reichen ja auch
644/755 aus um die Dateien beschreiben zu können.
Wobei man noch berücksichtigen sollte, dass das "Update-Root-Problem"
nicht mehr vorhanden ist, sobald wir einen Updater in Part-DB
integrieren. Dann wird das Update nämlich automatisch unter dem Benutzer
"www-data" durchgeführt...
Jetzt wollte ich mal fragen, wie ihr das seht?
Ausserdem kam mir noch eine andere Idee in den Sinn. Irgendwie wäre es
doch schön, wenn alle "individuellen" Dateien in einem separaten
Verzeichnis liegen würden, sauber getrennt von den Part-DB
Systemdateien. Konkret denke ich da an ein Verzeichnis "data", in dem
dann die config.php und das Verzeichnis "media" liegt. Vielleicht
bräuchte man dieses Verzeichnis später auch mal noch für andere Sachen.
So ein data-Verzeichnis würde verschiedene Vorteile bieten:
- Möchte man regelmässige Backups von Part-DB machen, muss so neben der
MySQL Datenbank nur dieses eine Verzeichnis "data" mitgesichert werden.
Alle zu sichernden Dateien befinden sich in diesem Verzeichnis, und
sonst nirgendwo.
- Schreibrechte für den Webserver sind nur in diesem data-Verzeichnis
notwendig, überall sonst sind nur Leserechte nötig. So können die
Dateirechte sehr restriktiv vergeben werden, was sicherheitstechnisch
sicher keine schlechte Sache ist.
- (Man könnte sogar das data-Verzeichnis ausserhalb des Part-DB
Hauptverzeichnisses betreiben, indem man ein Symbolischer Link erzeugt.
So könnte das data-Verzeichnis z.B. auch auf einer Netzwerkfreigabe
liegen, falls das jemand brauchen kann...)
Was meint ihr dazu?
Der einzige Nachteil dieser Umstellung ist eigentlich die Umstellung an
sich^^ Solange die 0.3.0 aber noch nicht offiziell freigegeben wurde,
sollte das aber nicht so tragisch sein...
Ich wäre froh um Rückmeldungen.
mfg
Urban B. schrieb:> Jetzt wollte ich mal fragen, wie ihr das seht?
Ich bin unbedingt für die Installation unter root-Rechten. Diese
Frickeleien mit Benutzerrechten sind einfach nur Murks.
Die Trennung von Code und Konfiguratiosdaten etc. ist auch
wünschenswert.
Urban B. schrieb:> Was meint ihr dazu?
Eine Trennung von Code und Benutzerdaten würde ich auch sehr begrüßen,
vor allem in Hinsicht auf Backups.
Ich würde es durchaus nützlich finden wenn der "Durchschnittspreis für 1
Stk.: *,* €" gleich direkt bei der Bauteileübersicht als Spalte
angezeigt werden würde.
Wie legt man eig in der 0.2.2 Version Footprints an?
Die Footprints habe ich hochgeladen, werden auch unter Tools >
Footprints angezeigt, unter Bearbeiten > Footprints habe ich mir bereits
eine kleine Struktur angelegt, aber ich kann nirgends ein "Bild"
auswählen wie hier im Forum einige Beiträge weiter oben beschrieben
wurde.
Okay ich habe schonmal damit begonnen ein data-Verzeichnis zu erstellen,
und die Doku ist jetzt umgeschrieben für die Installation als root,
direkt in /var/www. Werde das Update bald hochladen.
Gerald *. schrieb:> Ich würde es durchaus nützlich finden wenn der "Durchschnittspreis für 1> Stk.: *,* €" gleich direkt bei der Bauteileübersicht als Spalte> angezeigt werden würde.
Gute Idee, habe das gleich in die v0.3.0 mit eingebaut. Ist aber
standardmässig nicht aktiviert, man muss diese Spalte in der config.php
selber aktivieren. Konkret muss man die Zeile mit dem Arrayelement
"$config['table']['category_parts']['columns']" aus der
config_defaults.php in die config.php kopieren und dort noch die Spalte
"average_single_price" einfügen. Ist halt bis jetzt noch nirgens
dokumentiert welche Spalten zur Verfügung stehen, das muss dann auch mal
noch in die Doku eingebaut werden...
> Wie legt man eig in der 0.2.2 Version Footprints an?> Die Footprints habe ich hochgeladen, werden auch unter Tools >> Footprints angezeigt, unter Bearbeiten > Footprints habe ich mir bereits> eine kleine Struktur angelegt, aber ich kann nirgends ein "Bild"> auswählen wie hier im Forum einige Beiträge weiter oben beschrieben> wurde.
Ich vermute mal, diese Option ist erst nach der Veröffentlichung von
0.2.2 hinzugefügt worden, steht also nur zur Verfügung wenn man Part-DB
direkt per SVN runtergeladen hat. Am besten wartest du auf die Version
0.3.0 :-)
lol, mir ist grad noch was merkwürdiges aufgefallen^^
In der Spalte "Datenblätter" fehlt bei mir im Firefox plötzlich das Icon
für alldatasheet.com. Dateipfad habe ich überprüft, der passt. Cache
geleert, im privaten Modus vom FF probiert, bringt alles nichts. Die
anderen zwei Icons werden richtig angezeigt. Dann habe ich mal die
Bilddatei umbenannt, dann funktionierts wieder. Wieder den alten
Dateinamen gegeben, funktioniert nicht mehr.
Lustigerweise heisst die Bilddatei "ads.png". Da ich es mir nicht anders
erklären konnte, vermutete ich mal dass Firefox aufgrund des Dateinamens
meint, dass es sich bei dem Bild um Werbung handelt. Dann kam mir in den
Sinn, dass es dann aber auch am AdBlock liegen könnte. Und tatsächlich:
Adblock deaktiviert --> Bild wird angezeigt. AdBlock aktiviert --> Bild
wird nicht angezeigt xD
Ich werde dann die Datei von "ads.png" wohl besser mal nach
"alldatasheet.png" umbenennen... ;-)
Urban B. schrieb:> Gute Idee, habe das gleich in die v0.3.0 mit eingebaut. Ist aber> standardmässig nicht aktiviert, man muss diese Spalte in der config.php> selber aktivieren.
Schon mal ein dickes Danke im voraus.
Urban B. schrieb:> Am besten wartest du auf die Version 0.3.0 :-)
Die Umsetzung in der Demoversion gefällt mir schon gut.
Ich bin schon auf das Release gespannt :)
Es ist soweit! Part-DB 0.3.0 RC1 steht ab sofort zum Download bereit!
:-)
https://code.google.com/p/part-db/downloads/detail?name=Part-DB_0.3.0.RC1.tar.gz
In Part-DB 0.3.0 sind jetzt übrigens auch .htaccess Dateien enthalten,
um die Verzeichnisse vor unbefugtem Zugriff zu schützen. Nähere Infos
dazu gibts in der Dokumentation.
Leider ist die Doku momentan aber nicht online verfügbar. Für diesen
Fall habe ich im Verzeichnis "readme" die Datei "INSTALL.txt" noch
ergänzt, ist halt nicht so schön zu lesen weils in Wiki-Syntax
geschrieben ist, aber besser als nichts :-)
@K.J. wäre super wenn du die Online-Demo noch aktualisieren könntest,
damit die Installationsanleitung aufgerufen werden kann.
mfg
Bin grad noch auf eine Idee gekommen. Wir haben ja noch den Webspace von
Christian (holle), da habe ich kurzerhand mal die Doku hochgeladen um
die Zeit zu überbrücken bis die offizielle Demo wieder aktuell ist:
http://kami89.myparts.info/dokuwiki/doku.php
Ist sonst etwas mühsam wenn man sich mit der INSTALL.txt begnügen
muss...
Danke an dieser Stelle nochmal an Christian, und sorry dass es so lange
dauert bis die Benutzerverwaltung umgesetzt wird ;-)
Ach so, ich dachte dass die Demo "Part-DB - 0.2.2 SVN (Aktuell)" auch
täglich ein Update aus dem Trunk holt, und die Demo "Part-DB - 0.3.0 SVN
Testversion" halt aus dem Branch ;-)
Daher ging ich davon aus, dass die Demo "Part-DB - 0.2.2 SVN (Aktuell)"
auch auf die Version 0.3.0 updaten müsste, da die 0.3.0 ja nun im Trunk
liegt.
Dass die Demo "Part-DB - 0.3.0 SVN Testversion" nicht mehr aktualisiert
wird, liegt daran, dass ich den Branch "uneist_kami89" gelöscht habe,
weil die Entwicklung nun ja wieder im Trunk stattfindet und der Branch
daher nicht mehr benötigt wird.
Das Beste wäre dann wohl vermutlich, wenn du die Demo "Part-DB - 0.3.0
SVN Testversion" einfach vom Branch "uneist_kami89" auf den Trunk
umstellst, dann wird die wieder korrekt aktualisiert.
Hab noch einen Wunsch. Beim CSV oder XML export wird der Hersteller und
die Part-ID (pid) nicht in einer Spalte aufgeführt.
Wäre für diese Änderung dankbar.
Christian schrieb:> Hab noch einen Wunsch. Beim CSV oder XML export wird der Hersteller und> die Part-ID (pid) nicht in einer Spalte aufgeführt.> Wäre für diese Änderung dankbar.
Kein Problem, habs gleich eingebaut und hochgeladen
(lib/lib.export.php):
https://code.google.com/p/part-db/source/browse/trunk/lib/lib.export.php?spec=svn640&r=640
Um es zu verwenden musst du in der config.php die entsprechende
$config['export']... Zeile neu definieren (aus config_defaults.php in
die config.php kopieren und dort anpassen). Für die ID-Spalte musst du
"id", für den Hersteller "manufacturer" im String ergänzen.
Hi, nachdem ich nun ebenfalls umgestiegen bin auf die partdb hab ich
gleich mal ne Frage dazu. ;)
Ich würde mir gerne statt dem Lagerort die Bestellnummern ausgeben
lassen.(Ich meine übrigens die Listenanzeige "showparts.php?xx")
Ich weiß nicht genau wieviel Aufwand das ist aber ich würd es mir auch
selbst zutrauen. Kann ja nicht so schwer sein.. Denk ich mir.(Haha)
Leider durchblicke ich den Code noch nicht wirklich. Wäre für ein paar
Tips sehr dankbar.
Grüße CK
Hallo Christopher,
> Ich würde mir gerne statt dem Lagerort die Bestellnummern ausgeben> lassen.(Ich meine übrigens die Listenanzeige "showparts.php?xx")
mmh "showparts.php" klingt nach der Part-DB Version 0.2.2, wenn du den
Release Kandidat der Version 0.3.0 benutzt oder noch auf die finale
Version wartest, ist dein gewünschtes Feature bereits drin :-)
Da müsstest du dir mal die Dateien "config_defaults.php" und die
"config.php" anschauen, speziell die Variable
"$config['table']['category_parts']['columns']"
mfg
Das war ja fast zu einfach um wahr zu sein. Danke ich habs geschafft.
Hab gleich auf RC1 geupdated.
Zeile in der config_defaults.php lautet in meinem Fall nun
Geniales Script... netten Abend wünsche ich noch.
PS: Beim update meldete der Server "File does not exist:
/usr/share/javascript/toggle.js".
Lösung war: In der Datei "/etc/apache2/conf.d/javascript-common.conf"
die Zeile "Alias /javascript /usr/share/javascript/"
Kommentieren/Löschen und Apache neu starten.
Christopher K. schrieb:> Zeile in der config_defaults.php lautet in meinem Fall nun [...]
Jup das funktioniert so zwar, allerdings wird die config_defaults.php
beim nächsten Update wieder überschrieben und deine Einstellung geht
verloren. Daher musst du folgendes machen:
- Diese Zeile in die "config.php" (im Verzeichnis "data") einfügen
- Dort dann "$config" durch "$manual_config" ersetzen (in dieser Zeile)
- Die "config_defaults.php" wieder in Originalzustand bringen (optional)
So ist diese Einstellung dauerhaft in deiner persönlichen Konfiguration
gespeichert, die beim nächsten Update nicht überschrieben wird.
Ist halt leider noch nirgens dokumentiert dass man das so machen muss...
> PS: Beim update meldete der Server "File does not exist:> /usr/share/javascript/toggle.js".>> Lösung war: In der Datei "/etc/apache2/conf.d/javascript-common.conf"> die Zeile "Alias /javascript /usr/share/javascript/"> Kommentieren/Löschen und Apache neu starten.
hmm das scheint wohl ein Problem bei deiner Installation zu sein... Ist
mir jedenfalls bei Ubuntu 12.10 und 13.04 nicht aufgefallen wo ich
Part-DB jeweils teste.
> netten Abend wünsche ich noch.
ebenfalls :-)
Ahh, Das hat super funktioniert mit dem "$manual_config" in der
config.php. Ist natürlich die bessere Lösung.
Das "File does not exist: /usr/share/javascript/toggle.js" Problem hatte
ich bei 2 debian6 Rechnern mit froxxlor. Hatte alles via apt-get
installiert. Merken tut man es wenn man kein Menü sieht in der partdb.
;)
Vielen Dank...
Bin gerade dabei Part-DB 0.3.0 RC1 zu testen.
Gefällt mir grundsätzlich sehr gut :-)
Dazu habe ich vom bestehenden Part-DB 0.2.2 die Datenbank kopiert und
die frische Installation von 0.3.0 RC1 eingefügt => funktioniert alles
keine Probleme.
Jetzt habe ich noch die ganzen Bilder von img nach data/media kopiert =>
um jetzt wieder Vorschaubilder (thumbnails) zu erhalten müsste ich jetzt
jeden Artikel öffnen und das Häkchen "Als Hauptbild verwenden" setzen.
Lösungsvorschlag:
Sollte nur ein Bild vorhanden sein, so wird das automatisch als
"Hauptbild" verwendet oder man übernimmt zumindest die Zuordnung aus der
alten DB Version.
Gerald *. schrieb:> Jetzt habe ich noch die ganzen Bilder von img nach data/media kopiert =>> um jetzt wieder Vorschaubilder (thumbnails) zu erhalten müsste ich jetzt> jeden Artikel öffnen und das Häkchen "Als Hauptbild verwenden" setzen.
Stimmt, das habe ich übersehen. Ich baue gleich ein Datenbankupdate ein,
das dieses Problem im Nachhinein noch korrigiert, du musst nicht überall
das Hauptbild manuell setzen.
Danke fürs Feedback!
Urban B. schrieb:> Ich baue gleich ein Datenbankupdate ein
Ist drin --> Revision 641
Ausserdem habe ich unser DokuWiki noch um einen Read-Only Modus
erweitert, welcher standardmässig aktiviert ist, also die Bearbeitung
von Seiten verhindert. Schreibrechte erhält man, wenn man im
DokuWiki-Verzeichnis eine Datei mit dem Namen
"PART-DB_ENABLE-DOKUWIKI-WRITE-PERMS.txt" anlegt. Dies kann aber auch
bequem in der Part-DB Konfigurationsseite durchgeführt werden, aber nur,
wenn in Part-DB der Ordner "development" existiert (für Nicht-Entwickler
soll diese Option nicht sichtbar sein, so wie die Entwickler-Werkzeuge).
Der Grund für den Read-Only Modus ist einfach: In der Online Demo kann
sonst jedermann irgend einen Schrott da reinschreiben ;-) Insbesondere
bei den Bash-Befehlen stellt dies auch ein Sicherheitsrisiko dar.
In der Online-Demo ist natürlich das Deaktivieren des Read-Only Modus
über die Konfigurationsseite nicht möglich.
Urban B. schrieb:> Urban B. schrieb:>> Ich baue gleich ein Datenbankupdate ein>> Ist drin --> Revision 641
Vielen Dank für die rasche Reaktion!
Wie hast du es den umgesetzt? (kann es erst Sonntag testen)
Gerald *. schrieb:> Vielen Dank für die rasche Reaktion!
Kein Problem, betrifft ja nicht nur dich, sondern auch alle anderen
Benutzer die in Part-DB 0.2.2 Bilder hochgeladen haben.
Und um genau solche Fehler zu finden gibt es ja die Release Kandidaten
:-)
> Wie hast du es den umgesetzt? (kann es erst Sonntag testen)https://code.google.com/p/part-db/source/browse/trunk/updates/db_update_steps.php
Im "case 14" ist jetzt ein Datenbankupdate, das allen Bauteilen, die
noch kein Hauptbild definiert haben, jedoch mindestens ein Bild
besitzen, eines dieser Bilder als Hauptbild definiert.
Um es zu testen müsstest du also einfach die Datei db_update_steps.php
mit der neuen Version überschreiben.
Noch ein kleiner Vorschlag meinerseits:
Um die Übersichtlichkeit zu erhöhen könnte/sollte man "obsolete
Bauteile" bei denen der Lagerstand auf null gesunken ist aus der
Bauteileübersicht ausblenden und nur mehr unter
Verwaltung / Tools > Zeige > Nicht mehr erhältliche Teile
auflisten. Dadurch wären evtl. verknüpfte Datenblätter im Falle des
Falles weiter verfügbar, nur man stolpert nicht ständig über "Leichen".
Gibt es eigentlich einen besonderen Grund warum die Standardfootprints
nicht bereits in der DB eingetragen sind?
Die Struktur könnte man ja von den Footprint Bildern übernehmen.
Würde aus meiner Sicht den Einrichtungsaufwand deutlich minimieren und
die Struktur sollte auch für 95% der Benutzer zutreffend sein (für den
Rest ist verschieben einfacher als neu anlegen).
Gerald *. schrieb:> Um die Übersichtlichkeit zu erhöhen könnte/sollte man "obsolete> Bauteile" bei denen der Lagerstand auf null gesunken ist aus der> Bauteileübersicht ausblenden und nur mehr unter> Verwaltung / Tools > Zeige > Nicht mehr erhältliche Teile> auflisten.
Keine schlechte Idee, ich nehme das mal in unsere ToDo Liste auf (wäre
zwar keine sehr grosse Sache, zwischen der Veröffentlichung der
Release-Kandidaten und dem finalen Release ist aber kein guter Zeitpunkt
um solche neuen Funktionen einzubauen).
Gerald *. schrieb:> Gibt es eigentlich einen besonderen Grund warum die Standardfootprints> nicht bereits in der DB eingetragen sind?
Diese Frage kam hier schon mehrfach :-)
Also standardmässig eingetragen würde ich nicht so gut finden, weil es
sicher viele Leute gibt die entweder gar keine, oder nur wenige
Footprints eintragen (wegen der Übersichtlichkeit). Allerdings fände ich
es auch gut, wenn es eine Option gäbe, mit der man automatisch die
wichtigsten Footprints mit einem Klick hinzufügen könnte. Ich schreib
das auch gleich in die ToDo-Liste.
Dirk B. schrieb:> bei mir wird der Preis mit DM angegeben. Wie kann ich das auf Euro> umstellen ?
In der 0.2.2 Version findest du es in der config.php unter:
$currency = "€";
In der 0.3.0.RC1 Version unter data/config.php müsste es folgender
Punkt sein:
$manual_config['money_format']['de_DE'] = '%!n Euro';
@kami89
Wenn ich über die config.php zusätzliche Spalten einblenden lasse und
danach unter Verwaltung / Tools > System > Konfiguration die Sprache
ändere, fehlen in der config.php meine Einträge für die zusätzlichen
Spalten.
Gerald *. schrieb:> @kami89> Wenn ich über die config.php zusätzliche Spalten einblenden lasse und> danach unter Verwaltung / Tools > System > Konfiguration die Sprache> ändere, fehlen in der config.php meine Einträge für die zusätzlichen> Spalten.
Hast du in der config.php die entsprechenden Einträge mit
$manual_config[] statt $config[] gemacht? Mit $manual_config[] sollte es
dauerhaft gespeichert werden.
Kurze Erklärung
$config[] muss für alle Einstellungen verwendet werden, die in der
config_defaults.php vor dem Kommentar-Block
1
Below, there are attributes which we don't want to save in the user's "config.php".
2
[...]
stehen. Dies sind diejenigen Einstellungen, die bei Updates nicht
überschrieben werden, die bleiben für immer so erhalten wie sie mal
definiert wurden. Alle Einstellungen nach dem Kommentarblock werden
nicht in der config.php gespeichert. z.B. die verfügbaren Sprachen
oder Währungen haben in der config.php grundsätzlich nichts zu suchen.
Diese können bei Updates auch überschrieben werden, z.B. wenn wir eine
neue Sprache oder eine neue Spalte in den Tabellen hinzufügen sollen die
ja dem Benutzer dann auch zur Verfügung stehen, und nicht durch die
config.php wieder mit den alten Werten überschrieben werden. Möchte man
aber trotzdem aus irgend einem Grund an diesen Variablen was verändern,
können sie in der config.php als $manual_config[] überschrieben werden.
Hallo Zusammen,
Erstmal Respekt vor Eurer Arbeit ...
Ich wollte gestern die V 0.3.0.RC1 installieren , aber der Installer
kommt immer nur bis zu der Einstellung " Zeitzone und Sprache" und egal
was ich versuche es endet mit einer Meldung , wie:
Die gewählte Sprache "de_CH" wird vom Server nicht unterstützt!
Bitte installieren Sie diese Sprache oder wählen Sie eine andere.
Was mache ich falsch ?
Wie und wo könnte ich diese Sprachen installieren ?
Installieren wollte ich die Applikation ich auf einem "Schweizer"
WebHost --> andere Webapplikationen machten bisher keine Probleme
Peter Müller schrieb:> Was mache ich falsch ?
Hast du evtl. schon mal versucht "de_CH (UTF-8)" auszuwählen?
Nicht UTF-8 Versionen bringen bei mir auch die genannte Fehlermeldung.
@kami89
Danke für die ausführliche Antwort!
Ich hatte sogar deine Erklärung vom 23.5 gelesen, nur irgendwie...
Egal, mit welcher Auswahl ich es versuche, ich bekomme immer dieselbe
Fehlermeldung ...
Auf dem Server sind folgende Versione aktuell:
PHP-Version: 5.3.10
MySQL-Version: 5.5.29
Perl-Version 5.12.4
Ich habe mich mal an einer Installation versucht. Revision 642 geladen,
Aufruf der Seite:
1
Die Datei "config.php" konnte nicht beschrieben werden. Überprüfen Sie, ob genügend Rechte vorhanden sind.
Kopiere ich die config_defaults.php nach config.php kommt die nächste
Fehlermeldung, wobei diese Meldung noch nicht mal im Part-DB-Design
kommt, sondern nur als Plaintext.
1
Bitte verschieben Sie die folgenden Dateien und Ordner ins Verzeichnis "data":
Warum ist dann die config_defaults.php dann nicht schon im
data-Verzeichnis? Verschiebe ich die zuvor kopierte config.php nach
data, so gibts die nächste Fehlermeldung:
1
Es gab ein Fehler bei der Aktualisierung ihrer config.php:
2
Fehler beim Updaten der config.php: Unbekannte Version!
Einerseits muss die config_defaults.php direkt im Zielverzeichnis liegen
und falls die config.php weder im Hauptverzeichnis noch in data
vorliegt, die config_defaults.php nach config.php kopiert werden. Dazu
sollte die config_defaults.php auch die richtige Versionsnummer tragen.
Für den Anwender wäre eine manuelle Bearbeitung der Konfiguration für
eine Erstinstallation wenig bis gar nicht zumutbar. Wäre doch nett, wenn
wir das nicht benutzerfreundlicher hinbekämen :-)
Peter Müller schrieb:> Egal, mit welcher Auswahl ich es versuche, ich bekomme immer dieselbe> Fehlermeldung ...
Bei welchem Webhoster bist du?
Füge bitte mal am Anfang der start_session.php die folgenden Zeilen ein:
Und stelle hier die Ausgabe rein, vielleicht sieht man da was
auffälliges.
@Udo
1
Die Datei "config.php" konnte nicht beschrieben werden. Überprüfen Sie, ob genügend Rechte vorhanden sind.
Das heisst, dass Apache keine Schreibrechte im Verzeichnis "data" hat,
wo er die config.php anlegen möchte. In der Doku ist beschrieben wie die
Rechte gesetzt werden sollen:
http://kami89.myparts.info/dokuwiki/doku.php?id=installationUdo Neist schrieb:> Kopiere ich die config_defaults.php nach config.php kommt die nächste> Fehlermeldung, wobei diese Meldung noch nicht mal im Part-DB-Design> kommt, sondern nur als Plaintext.> Bitte verschieben Sie die folgenden Dateien und Ordner ins Verzeichnis "data":
Man darf die config_defaults.php NICHT nach config.php kopieren, das
gibt ein Durcheinander. Die config_defaults.php ist nicht mehr wie bei
Part-DB 0.2.2 die config.php.template nur eine Vorlage für die
config.php, sondern die hat jetzt auch eine "richtige" Aufgabe im
System. Dort sind nämlich alle verfügbaren Sprachen, die installierte
Part-DB Version uvm. gespeichert, das hat in der config.php alles nichts
zu suchen.
Dass die Fehlermeldung nicht im Part-DB Design daherkommt ist natürlich
schade, liegt aber daran dass bereits ganz am Anfang der
start_session.php geprüft werden muss, ob sich die genannten Dateien und
Ordner am "falschen" Ort befinden, also noch dort wo sie in Part-DB
0.2.2 abgelegt wurden. Solange diese Dateien (vor allem die config.php)
nicht am richtigen Ort liegen, sollte das Skript nicht weiter ausgeführt
werden damit es nicht zu anderen Problemen kommt. Und weil es zu diesem
Zeitpunkt noch keine Klasse "HTML" und damit Templates gibt, kann nicht
das Design von Part-DB benutzt werden.
Ich kann aber mal versuchen ohne Templates der Fehlermeldung ein Design
zu verpassen, an dem man eindeutig erkennt dass es sich um eine
Fehlermeldung von Part-DB handelt.
Udo Neist schrieb:> Warum ist dann die config_defaults.php dann nicht schon im> data-Verzeichnis?
Weil im data-Verzeichnis nur Dateien sind, die nicht von Part-DB
stammen (bis auf die index.html und .htaccess). Dort sind nur
Benutzerdaten, oder mit anderen Worten, alles was der Benutzer kopieren
müsste um ein Backup anzulegen. Die config_defaults.php hingegen ist
eine Systemdatei von Part-DB, dort dran darf der Benutzer auf keinen
Fall dran rumfummeln. Alles ausserhalb des data-Verzeichnis ist tabu für
den Benutzer, weil es sonst beim nächsten Update gleich wieder
überschrieben werden würde. Das passiert mit den Dateien im
data-Verzeichnis nicht.
Udo Neist schrieb:> Verschiebe ich die zuvor kopierte config.php nach> data, so gibts die nächste Fehlermeldung:> Es gab ein Fehler bei der Aktualisierung ihrer config.php:> Fehler beim Updaten der config.php: Unbekannte Version!
Das war die config.php, die du von der config_defaults.php kopiert hast?
Dann ist klar dass er die nicht updaten kann, weil es keine config.php
von der Part-DB 0.2.2 ist. Der Updater erwartet hier entweder eine
config.php von Part-DB 0.2.2 die er dann aktualisiert, oder aber eine
config.php die mit dem Installer erzeugt wurde und somit eine korrekte
Versionsnummer enthält.
Udo Neist schrieb:> Für den Anwender wäre eine manuelle Bearbeitung der Konfiguration für> eine Erstinstallation wenig bis gar nicht zumutbar. Wäre doch nett, wenn> wir das nicht benutzerfreundlicher hinbekämen :-)
Wozu willst du denn die config.php vor der ersten Benutzung manuell
erstellen wenn es doch einen grafischen Installer gibt, der dann die
config.php korrekt erzeugt? :-)
Es ist eigentlich ganz einfach:
Szenario 1: Neuinstallation, es existiert keine config.php
Part-DB das erste mal aufrufen -> Installer durchlaufen lassen -> fertig
Mächte man zusätzlich noch die Konfuguration manuell verändern kann man
das jetzt tun, weil die config.php jetzt ja existiert.
Szenario 2: Part-DB 0.2.2 auf 0.3.0 updaten
Part-DB 0.3.0 ins Installationsverzeichnis entpacken, alte Dateien
überschreiben. Part-DB aufrufen, Meldung "Dateien nach data verschieben"
befolgen (nichts rumfummeln, nur verschieben). Part-DB nochmals
aufrufen, config.php wird automatisch auf das neue Format aktualisiert,
Installer durchlaufen lassen, fertig.
Und wenn Part-DB motzt dass nicht genügend Rechte zum Schreiben der
config.php vorhanden sind: Korrekte Rechte (nach Doku) vergeben -->
nochmals versuchen --> fertig
:-)
Dann wäre es doch viel sinnvoller, die Fehlermeldung zu korrigieren. Ein
Verweis auf das Wiki wäre hier auch hilfreich. Ein grafischer Installer
sollte mit klaren Meldungen kommen und nicht nur irgendwelche
Fehlermeldungen. In dieser Form würde ich keinesfalls einem Release
zustimmen.
Wenn die Rechte der Verzeichnisse nicht stimmen, sollte das gemeldet
werden. Natürlich könnte eine Routine first_install() ja auch versuchen,
die Rechte zu korrigieren. So verwirrt das ganze. In meinem Filemanager
gibt es eine Klasse class.fileio.php, deren Funktion aboutFile() zeigt,
wie man die Rechte eines Files/Verzeichnisses unter PHP auswertet.
Die config_defaults.php führt in die Irre. Viele PHP-Projekte schleppen
eine solche Datei mit, die dann oft vom Anwender umkopiert werden soll,
damit die Installation klappt. Einfach die Datei gleich schon im
data-Verzeichnis unterbringen und eventuell auch defaults.php nennen
oder eine leere config.php mitliefern? Die config.php aus 0.2.2 würde ja
entsprechend umgeschrieben.
Grüße
Udo
PS: SVN speichert die Datei/Verzeichnisrechte, da sollte man diese von
Anfang an auch richtig einstellen :-)
Udo Neist schrieb:> Dann wäre es doch viel sinnvoller, die Fehlermeldung zu korrigieren.
Klar könnte man sie noch etwas genauer formulieren, ich wollte aber
nicht überall im Skript bei jedem Schreibzugriff noch eine Überprüfung
auf korrekte Dateirechte und ein Versuch dies automatisch zu korrigieren
einbauen, weil sowieso geplant ist eine zentrale Überprüfung auf
korrekte Dateirechte einzubauen. Die hats jetzt halt nur noch nicht in
die 0.3.0 geschafft...
Ich gebe dir schon Recht, ich finde auch eine Überprüfung der
Dateirechte (und ein Versuch, diese automatisch zu korrigieren) muss
eingebaut werden. Aber ich dachte halt, bei der 0.2.2 ging das ja auch
ohne, und es gibt ja eine gute Dokumentation in der beschrieben ist wie
man die Rechte setzt muss, da kann diese Funktion noch aufs nächste
Release warten (wir können ja nicht alle Punkte unserer ToDo-Liste in
die 0.3.0 einbauen, sonst wird die nie fertig...).
Aber von mir aus kann ich das noch einbauen, damit das dann in der 0.3.0
RC2 drin ist.
> Die config_defaults.php führt in die Irre. Viele PHP-Projekte schleppen> eine solche Datei mit, die dann oft vom Anwender umkopiert werden soll,> damit die Installation klappt.
Ja das stimmt, aber trotzdem sollte man einen kurzen Blick in die
Installationsanleitung werfen :-)
Ich habe hier halt ein etwas anderes Konzept gewählt weil ich der
Meinung bin, dass solche Aufgaben ein grafischer Installer übernehmen
soll (wenn sowieso eine grafische Oberfläche vorhanden ist) und nicht
ein händisches Rumkopieren von Dateien. Wozu von Hand Dateien
rumkopieren, wenn es im Installer viel einfacher und schneller geht und
man so auch noch nichts falsch machen kann?
Den Dateinamen "config_defaults.php" könnte ich natürlich in
"DontToucheMe.php" umbenennen, das würde das Problem beheben, ist aber
nicht gerade Entwicklerfreundlich ;-)In dieser Datei werden halt
Standardwerte für die Konfiguration geladen, für den Fall dass diese in
der config.php nicht definiert sind. Da fand ich halt "config_defaults"
passend ;-)
Ich hätte aber zwei Vorschläge, diesem Problem entgegenzuwirken:
- Eine fette Warnung in die config_defaults.php einbauen "do not
copy...read manual at http://......!";
- Mal schauen ob das Skript feststellen kann, ob der Benutzer die
config_defaults.php als Vorlage verwendet hat, um dann eine
Fehlermeldung ausgeben zu können.
> Einfach die Datei gleich schon im> data-Verzeichnis unterbringen und eventuell auch defaults.php nennen> oder eine leere config.php mitliefern? Die config.php aus 0.2.2 würde ja> entsprechend umgeschrieben.
Eine leere config.php mitliefern ist schlecht, dann wird die config.php
des Benutzers bei jedem Systemupdate mit dieser config.php
überschrieben.
Eine defaults.php mitzuliefern dient irgendwie nicht der Bekämpfung der
Ursache, sondern des Symptoms. Die Ursache ist: Der Benutzer meint
fälschlicherweise, er müsse seine config von Hand anlegen. Mit einer
defaults.php lässt man ihn auch noch glauben, das sei richtig so. Die
wirklich richtige Lösung wäre aber, ihm klarzumachen dass er keine
config anzulgenen braucht, sondern einfach http://localhost/part-db/
aufrufen muss und der Installer dann alles für ihn erledigt.
...meine Meinung! :-)
> PS: SVN speichert die Datei/Verzeichnisrechte, da sollte man diese von> Anfang an auch richtig einstellen :-)
Oh das wusste ich gar nicht, danke :-D
mfg
Urban B. schrieb:> Ich gebe dir schon Recht, ich finde auch eine Überprüfung der> Dateirechte (und ein Versuch, diese automatisch zu korrigieren) muss> eingebaut werden. Aber ich dachte halt, bei der 0.2.2 ging das ja auch> ohne, und es gibt ja eine gute Dokumentation in der beschrieben ist wie> man die Rechte setzt muss, da kann diese Funktion noch aufs nächste> Release warten (wir können ja nicht alle Punkte unserer ToDo-Liste in> die 0.3.0 einbauen, sonst wird die nie fertig...).>> Aber von mir aus kann ich das noch einbauen, damit das dann in der 0.3.0> RC2 drin ist.
Schwerwiegend ist das ja nicht, könnte man ja mit einfachen Mitteln
erreichen. Einfach eine kleine Liste von Dateien/Verzeichnisse und deren
Rechte mitliefern, die dann bei der Installation geprüft werden können.
Könnte man aber auch in eine 0.3.1 rein nehmen.
> Den Dateinamen "config_defaults.php" könnte ich natürlich in> "DontToucheMe.php" umbenennen, das würde das Problem beheben, ist aber> nicht gerade Entwicklerfreundlich ;-)In dieser Datei werden halt> Standardwerte für die Konfiguration geladen, für den Fall dass diese in> der config.php nicht definiert sind. Da fand ich halt "config_defaults"> passend ;-)>> Ich hätte aber zwei Vorschläge, diesem Problem entgegenzuwirken:> - Eine fette Warnung in die config_defaults.php einbauen "do not> copy...read manual at http://......!";> - Mal schauen ob das Skript feststellen kann, ob der Benutzer die> config_defaults.php als Vorlage verwendet hat, um dann eine> Fehlermeldung ausgeben zu können.
Letzteres wäre wohl das sinnvollste.
>> Einfach die Datei gleich schon im>> data-Verzeichnis unterbringen und eventuell auch defaults.php nennen>> oder eine leere config.php mitliefern? Die config.php aus 0.2.2 würde ja>> entsprechend umgeschrieben.>> Eine leere config.php mitliefern ist schlecht, dann wird die config.php> des Benutzers bei jedem Systemupdate mit dieser config.php> überschrieben.
Kommt auf das Systemupdate drauf an. Ich weiß jetzt nicht auswendig, ob
bei SVN eine Datei als Tabu zum Update markiert werden kann. Ich glaube
aber sowas mal gelesen zu haben. Für ein internes Systemupdate ist die
config.php sowieso für ein Überschreiben zu schützen, am besten immer
eine Kopie vor dem Update machen.
> Eine defaults.php mitzuliefern dient irgendwie nicht der Bekämpfung der> Ursache, sondern des Symptoms. Die Ursache ist: Der Benutzer meint> fälschlicherweise, er müsse seine config von Hand anlegen. Mit einer> defaults.php lässt man ihn auch noch glauben, das sei richtig so. Die> wirklich richtige Lösung wäre aber, ihm klarzumachen dass er keine> config anzulgenen braucht, sondern einfach http://localhost/part-db/> aufrufen muss und der Installer dann alles für ihn erledigt.>> ...meine Meinung! :-)
Könnte man auch irgendwo tief im System verstecken. Wichtig ist nur,
dass der User nicht direkt mit der config-defaults.php bzw. config.php
in Berührung kommt. Leider gibt es keinen Standard für solche Zwecke :(
>> PS: SVN speichert die Datei/Verzeichnisrechte, da sollte man diese von>> Anfang an auch richtig einstellen :-)>> Oh das wusste ich gar nicht, danke :-D
:-D Wäre ja doof, wenn es nicht so wäre.
Urban B. schrieb:> Peter Müller schrieb:>> Egal, mit welcher Auswahl ich es versuche, ich bekomme immer dieselbe>> Fehlermeldung ...>> Bei welchem Webhoster bist du?>> Füge bitte mal am Anfang der start_session.php die folgenden Zeilen ein:>
>> Und stelle hier die Ausgabe rein, vielleicht sieht man da was> auffälliges.>
Mein Webhoster ist hostpoint.ch
Also ich hab den Code reinkopiert und folgende Meldungen bekommen ...
LC_ALL = false
LC_COLLATE = false
LC_CTYPE = false
LC_MONETARY = false
LC_NUMERIC = false
LC_TIME = false
LC_MESSAGES = false
Gruss Peter
Udo Neist schrieb:> Kommt auf das Systemupdate drauf an. Ich weiß jetzt nicht auswendig, ob> bei SVN eine Datei als Tabu zum Update markiert werden kann.
Du darfst nicht vergessen, dass SVNNICHT der Update-Mechanismus von
Part-DB darstellt. Das einzige "offizielle" Verfahren, seine Part-DB
aktuell zu halten, ist immernoch über den manuellen Download des
*.tar.gz Archives mit anschliessendem Überschreiben der alten Dateien.
Part-DB über SVN aktuell zu halten kann sogar auch mal richtig
schiefgehen, wenn z.B. ein Datenbankupdate in den Trunk geladen wird,
das sich als fehlerhaft herausstellt. Solange dieses Update noch nicht
offiziell rausgegeben wurde, können wir es nochmal verändern. Wer zu
diesem Zeitpunkt aber bereits seine Part-DB über SVN aktualisiert hat,
hat Pech gehabt...
Daher kann man nur davon abzuraten, Part-DB im produktiven Einsatz über
SVN zu aktualisieren, dies sollten wirklich nur Entwickler mit ihren
Testinstallationen von Part-DB machen.
Udo Neist schrieb:>>> PS: SVN speichert die Datei/Verzeichnisrechte, da sollte man diese von>>> Anfang an auch richtig einstellen :-)>>>> Oh das wusste ich gar nicht, danke :-D>> :-D Wäre ja doof, wenn es nicht so wäre.
Hmm bist du dir wirklich sicher dass das so funktioniert? Im Internet
konnte ich dazu nichts finden, in Google Code sieht man die Dateirechte
nirgens und wenn ich die Rechte einer Datei verändere wird sie von SVN
nicht als "verändert" markiert...
Ausserdem, was nützen die UNIX Dateirechte wenn jemand unter Windows auf
einer NTFS Partition arbeitet?
Peter Müller schrieb:> Mein Webhoster ist hostpoint.ch>> Also ich hab den Code reinkopiert und folgende Meldungen bekommen ...> LC_ALL = false> LC_COLLATE = false> LC_CTYPE = false> LC_MONETARY = false> LC_NUMERIC = false> LC_TIME = false> LC_MESSAGES = false
Ahh, ich glaube ich habe das Problem gefunden. Hostpoint erwartet
vermutlich "de_CH.UTF-8" statt "de_CH.utf8":
http://support.hostpoint.ch/index.php?page=ArticleDetailPage&navigation=7&category=29&article=57
Ich bau das noch in Part-DB ein, habe da sowieso grad noch
Optimierungspotential entdeckt :-)
Ich stimme dir da schon zu, nur will ich darauf hinaus, dass wir mit dem
Installer auch ohne Eingriffe ins System direkt starten können.
Existiert keine config.php wird eine angelegt. Stimmen die Rechte nicht,
wird das angezeigt. Alles andere ist Blödsinn.
Mit den Rechten unter Windows müssen wir eh schauen. Das ist eine eigene
Geschichte und sollte später auch berücksichtigt werden. Man kann ja
eine Umfrage starten, wer Part-DB auf welchem OS nutzt :-)
Also ich habe mal angefangen zumindest eine rudimentäre Überprüfung der
Dateirechte einzubauen, die "data" auf Schreibrechte überprüft. Nur habe
ich da gewisse Schwierigkeiten...
In der Doku habe ich ja z.B. für das Verzeichnis "data" die Rechte auf
755 zu stellen. Das gilt allerdings nur, wenn der Besitzer des Ordners
dem Webserver (www-data) entspricht. Das ist aber nicht immer der Fall,
das kommt auf die Infrastruktur drauf an. Bei einem Hoster kann es ja
durchaus sein, dass die Dateien, die über FTP hochgeladen wurden, dem
FTP-Benutzer gehören und nicht dem Webserver.
Das heisst also, es bringt nichts wenn ich "data" auf 755 prüfe, das
einzig Sinnvolle ist, mit is_writable() auf Schreibrechte zu prüfen.
Gibt diese Funktion "false" zurück, kann ich versuchen mit chmod() die
Rechte auf 755 zu setzen. Geht das nicht, kann ich die Meldung ausgeben
dass man die Rechte von Hand ändern muss (mit Verweis auf die Doku).
Wurden die Rechte erfolgreich geändert, aber die Datei ist immernoch
nicht beschreibbar, kann man es mit 775 und schlussendlich mit 777
versuchen.
Das ist irgendwie ein ziemliches Gebastel. Eine andere Idee habe ich
aber nicht, die dann auch auf jedem System funktioniert.
Gibts bessere Vorschläge? :-)
Urban B. schrieb:> Ahh, ich glaube ich habe das Problem gefunden. Hostpoint erwartet> vermutlich "de_CH.UTF-8" statt "de_CH.utf8":> http://support.hostpoint.ch/index.php?page=Article...>> Ich bau das noch in Part-DB ein, habe da sowieso grad noch> Optimierungspotential entdeckt :-)
Hallo,
Habs leider nicht hinbekommen , weil ich weiss nicht, wie das mit den
SVN geht ...
nun gut ich habe jetzt mal die Version 2.1 heruntergeladen und
installiert ...
stehe leider aber schon wieder an ...
Bei der Navigation in "Kategorien","Baugruppen" oder "Verwaltung /
Tools" passiert nichts, wenn ich entweder "alle Anzeigen" oder "alle
Schliessen" klicke ...
Sollte aber für ein DB-Update in die Verwaltung kommen ;-)
Die Navigation in den Online "Test-Datenbanken" gehen ....
Habe die Datenbank jetzt etwa 3 Mal neu installiert inkl. Datenbank
... immer mit demselben Ergebnis -> Navigation funktioniert nicht , auch
eine bereits eingegebene Kategorie ist nicht sichtbar
Was mache ich falsch ?
Christopher K. schrieb:> Das war ja fast zu einfach um wahr zu sein. Danke ich habs geschafft.> Hab gleich auf RC1 geupdated.>> Zeile in der config_defaults.php lautet in meinem Fall nun
$config['table']['category_parts']['columns'] =
'hover_picture;name;description;instock_mininstock;footprint;storelocati
on;datasheets;attachements;button_decrement;button_increment;suppliers;s
upplier_partnrs';
> Geniales Script... netten Abend wünsche ich noch.>> PS: Beim update meldete der Server "File does not exist:> /usr/share/javascript/toggle.js".>> Lösung war: In der Datei "/etc/apache2/conf.d/javascript-common.conf"> die Zeile "Alias /javascript /usr/share/javascript/"> Kommentieren/Löschen und Apache neu starten.
Der String 'id' bei der
configzeile:$config['table']['category_parts']['columns'] läuft in
ein leeres case.
https://code.google.com/p/part-db/source/browse/trunk/lib/class.Part.php
ZEile 1141
Möchte diese Nummer auch auflistenlassen. Benutze für die Sortierung in
der Schublade gleich die ID Nummer. Was muss da geändert werden?
Hm bei mir bleibt beim SVN Update die Part-DB nach dem Dateirechte
setzen hängen.
http://www.partdb.grautier.com/svn/
Die RC1 bin ich grade noch am uploaden, sollte heute Abend auch wieder
Funktionieren.
Zum Dateirechte setzen oben steht da ja was zu, ich würde das nicht vom
Script setzen lassen sondern einfach nur mit dem jeweiligen PHP User
schauen ob es beschreibbar ist oder nicht, so wie es auch bei CMS
Systemen gemacht wird, und dan nur ausgeben was der Benutzer noch ändern
muss, das ist am Problemlosesten.
Gibt es irgendwo eine Übersicht über die Funktionen der Part-DB? Ist das
nur eine Datenbank, oder gibt es auch ein Frontend mit GUI? Ich müsste
meine Lagerhaltung (bei den Bauteilen) nämlich auch mal endlich auf eine
solidere Basis stellen...
Edit: Ich hab gerade den zugehörigen Artikel gefunden:
http://www.mikrocontroller.net/articles/Part-DB_RW_-_Lagerverwaltung
Wenn noch Fragen offen bleiben sollten, melde ich mich nochmal.
Mit freundlichen Grüßen
Thorsten Ostermann
Peter Müller schrieb:> Urban B. schrieb:>> Ahh, ich glaube ich habe das Problem gefunden. Hostpoint erwartet>> vermutlich "de_CH.UTF-8" statt "de_CH.utf8":>> http://support.hostpoint.ch/index.php?page=Article...>>>> Ich bau das noch in Part-DB ein, habe da sowieso grad noch>> Optimierungspotential entdeckt :-)>>> Hallo,> Habs leider nicht hinbekommen , weil ich weiss nicht, wie das mit den> SVN geht ...
Wenn du die 0.3.0 RC1 installiert hast, kannst du vorübergehend
folgendes machen: In der config_defaults.php die Zeile
und dann unter System -> Konfiguration die Sprache auf "de_CH (UTF-8)"
einstellen.
An der config_defaults.php darf man eigentlich NICHTS verändern wie ich
schonmal erwähnt habe. Da diese Änderung aber in der RC2 gleich
standardmässig mit eingebaut ist, kann man hier mal eine Ausnahme
machen.
> stehe leider aber schon wieder an ...> Bei der Navigation in "Kategorien","Baugruppen" oder "Verwaltung /> Tools" passiert nichts, wenn ich entweder "alle Anzeigen" oder "alle> Schliessen" klicke ...
Hast du mal überprüft ob die Dateirechte für die Javascript-Dateien
korrekt sind?
Christian schrieb:> Der String 'id' bei der> configzeile:$config['table']['category_parts']['columns'] läuft in> ein leeres case.
Ja, weil dies in der 0.3.0 RC1 noch nicht möglich war. Du musst die
Datei lib/lib.export.php mit dieser hier ersetzen, dann sollte es gehen:
https://code.google.com/p/part-db/source/browse/trunk/lib/lib.export.phpK. J. schrieb:> Hm bei mir bleibt beim SVN Update die Part-DB nach dem Dateirechte> setzen hängen.
mmh ok schade, aber irgendwie habe ich das schon fast vermutet dass es
da Probleme geben wird ;-)
> Zum Dateirechte setzen oben steht da ja was zu, ich würde das nicht vom> Script setzen lassen sondern einfach nur mit dem jeweiligen PHP User> schauen ob es beschreibbar ist oder nicht, so wie es auch bei CMS> Systemen gemacht wird, und dan nur ausgeben was der Benutzer noch ändern> muss, das ist am Problemlosesten.
Jup, werde ich dann wohl noch so ändern.
mfg
Urban B. schrieb:> Christian schrieb:>> Der String 'id' bei der>> configzeile:$config['table']['category_parts']['columns'] läuft in>> ein leeres case.>> Ja, weil dies in der 0.3.0 RC1 noch nicht möglich war. Du musst die> Datei lib/lib.export.php mit dieser hier ersetzen, dann sollte es gehen:> https://code.google.com/p/part-db/source/browse/tr...
Betreffend dem export der datei hab ichs soweit verstanden. Ich schreibe
von der Auflistung der Treffern bei der Suche oder der
Kategorieauflistung der Bauteilen. Die Parameter die angezeit werden,
können via configzeile:
configzeile:$config['table']['category_parts']['columns']
bearbetet werden. Kann da jetzt einfach den String 'id' angewendent
werden für die Auflistung?
Urban B. schrieb:> Hast du mal überprüft ob die Dateirechte für die Javascript-Dateien> korrekt sind?
Es hat funktioniert ... hatte da etwas vile Probleme mit den
"Datei-Rechten"
Nun funktioniert die Navigation , wie sie sollte :-)
2 Fragen hätte ich noch:
1. das Administatoren Passwort wird trotz korrekter Eingabe nicht wieder
erkannt und akzeptiert
2. kann eine Vorgänger-Datenbank vom Rel 1.04 RC in die neue Datenbank
übernommen werden - oder irgendwie zumindestens die Artikel ,
Lagerorte
usw
Danke für Eure Hilfe
Peter
Peter Müller schrieb:> 1. das Administatoren Passwort wird trotz korrekter Eingabe nicht wieder> erkannt und akzeptiert
Hoppla, da ist was vergessen gegangen ;-) werde ich sofort korrigieren.
Vorübergehend muss man dann halt die Datenbankeinstellungen direkt in
der config.php ändern.
> 2. kann eine Vorgänger-Datenbank vom Rel 1.04 RC in die neue Datenbank> übernommen werden - oder irgendwie zumindestens die Artikel ,> Lagerorte> usw
Das ist zwar schon eine relativ alte Version, sollte aber eigentlich
möglich sein. Einfach unbedingt ein Backup der Datenbank anlegen. Wenns
nicht klappt, könnte man versuchen zuerst mit Part-DB 0.2.2 die
Datenbank auf eine neuere Version zu aktualisieren, und erst dann 0.3.0
zu verwenden.
Urban B. schrieb:> Das ist zwar schon eine relativ alte Version, sollte aber eigentlich> möglich sein. Einfach unbedingt ein Backup der Datenbank anlegen. Wenns> nicht klappt, könnte man versuchen zuerst mit Part-DB 0.2.2 die> Datenbank auf eine neuere Version zu aktualisieren, und erst dann 0.3.0> zu verwenden.
Hat geklappt mit dem update der Datenbank auf 0.3.0 ....
Musste allerdings den Umweg über die Version 2.2 (2.1) machen ...
Das mit den Dateirechten hat sich jetzt auch geklärt ...
Irgendwie hat mir Filezilla diese Datei-Rechte "vermurkst" ...
... mit dem guten alten WS-FTP95 hats sofort auf Anhieb geklappt.
Besten Dank für die gute Unterstützung
Gruss Peter
Funktionieren Ihr bei Euch die Links auf der Startseite (unten) ?
Könnt Ihr den "Titel der Seite:" in der Konfiguration ändern ?
Danke für Feedbacks
Peter
Peter Müller schrieb:> Funktionieren Ihr bei Euch die Links auf der Startseite (unten) ?
Nope, die URLs, die der Google Feed ausliefert sind ja gar keine gültige
Adressen (bzw. die gültige Adresse ist in einem anderen XML-Eintrag).
Ich schreibs mal in unsere ToDo Liste.
> Könnt Ihr den "Titel der Seite:" in der Konfiguration ändern ?
Nein, auch das geht nicht :-) Liegt daran, dass die entsprechende
Einstellung in der zweiten Hälfte der config_defaults.php liegt, und
damit nicht automatisch in der config.php abgelegt wird, das kann man
nur manuell machen.
Allerdings frage ich mich, ob das überhaupt jemand braucht? Wenn man den
Eintrag in der Konfigurationsseite entfernen würde, ginge es einfach
nicht mehr übers Webinterface. Manuell ist es aber nach wie vor mäglich,
den Titel per $manual_config in der config.php zu ändern:
Zum Testen habe ich mal part-db auf meinem Win7 Rechner zusammen mit
einem WAMP System (UniServer) ausprobiert. Leider schlägt schon die
Funktion zum Testen der Dateirechte an und meckert. Schnell hat sich
gezeigt, dass anscheinend unter Windows die Verzeichnisse (z.B. data)
keine "execute" Rechte haben. Nachdem ich einfach mal die "x" Flags bei
den Verzeichnissen aus der Abfrage entfernt hatte, lief alles.
Gibt es dafür eine bessere Lösung ?
Welche Version hast du installiert? Die Frage ist deshalb wichtig, weil
wir ja weiter oben schon die Problematik der Rechtevergabe unter Windows
für die Entwicklerversion angesprochen haben. Man müsste im Installer
wohl noch das Betriebssystem berücksichtigen.
Wenn diese "true" ist, dann wird halt das executable Bit einfach
ignoriert in der Überprüfung der Rechte.
Ausserdem gibts noch einen anderen Bug bei Windows, wegen den mühsamen
Dateipfaden die aus Slashes und Backslashes bestehen. Es gibt ein paar
str_replace() im Code, die nur mit Unix Pfaden zurechtkommen. Da muss
ich mir noch was einfallen lassen...
Dirk B. schrieb:> Die letzte von gestern Abend aus SVN. Sollte also die r645 sein.
Da haste gerade ne Version erwischt, die die Überprüfung von
Datei-/Verzeichnisrechten enthält, aber auf Windows noch nicht getestet
wurde. Aber Urban ist wohl dran, diese Probleme zu beheben.
Also ich sehe momentan zwei Lösungswege, um das Pfad-Problem zu beheben:
1. Variante
Für alle Pfade immer direkt das korrekte Pfad-Trennzeichen (je nach
Betriebssystem) verwenden. Damit dürften wir aber in unserem gesamten
Code NIRGENDWO ein "/" oder "\" verwenden, sondern immer nur
DIRECTORY_SEPARATOR! Ist mühsam, aber verhindert so komische Pfade, in
denen Slashes und Backslashes gleichzeitig vorkommen. Für die Dateipfade
in der Datenbank (z.B. für Footprint Bilder) könnten wir uns vielleicht
darauf einigen, dass IMMER Slashes verwendet werden, also auch unter
Windows. Wird Windows benutzt, müssten dann halt beim Abspeichern und
beim Auslesen aus der Datenbank die Pfade entsprechend umgewandelt
werden. Das stellt sicher, dass die Datenbank komplett
Betriebssystemunabhängig ist, was natürlich anzustreben ist.
in den HTML bzw. TMPL Dateien könnte man dies mit einer
Template-Variable für DIRECTORY_SEPARATOR machen, damit auch im HTML
Code die richtigen Pfad-Trennzeichen verwendet werden können.
2. Variante
in unserem Code immer mit Slashes arbeiten (so wie bisher). Dadurch
können bei Windows dann aber Pfade entstehen, die Slashes wie auch
Backslashes enthalten. Sieht nicht schön aus, funktioniert aber weil
Windows (bzw. Apache) das toleriert. Allerdings müsste man dann bei
allen str_replace() Operationen immer aufpassen, dass es
betriebssystemunabhängig funktioniert, was relativ mühsam sein kann.
Ne Idee wäre, eine Funktion zu schreiben, die einen Pfad entsprechend
korrigiert. Also Slash/Backslash-Kombinationen per RegEx umschreibt und
auch die Pfade richtig setzt. Kann ja auch gleich auf is_dir() oder
is_file() prüfen. Wenn das Ergebnis halt nicht existent ist, wird false
zurückgeliefert, ansonsten den zum Betriebssystem passenden Pfad.
Eigentlich könnten wir ja auch gleich alle Pfade IMMER mt Slashes
schreiben und keine Backslashes mehr zulassen. Auch bei der Konstante
"BASE".
Aufpassen muss man dann nur noch bei Pfaden, die vom System geliefert
werden (z.B. realpath(), scandir(), ...). Die muss man dann sofort in
Unix Pfade umschreiben.
Urban B. schrieb:> Eigentlich könnten wir ja auch gleich alle Pfade IMMER mt Slashes> schreiben und keine Backslashes mehr zulassen. Auch bei der Konstante> "BASE".
Ich habe das jetzt mal so eingebaut (r646). Ich hoffe, damit sind die
Probleme mit Windows-Pfaden behoben. Mit XAMPP 1.8.1 auf Win7 konnte ich
auf den ersten Blick jedenfalls keine Probleme mehr feststellen.
Übrigens habe ich die nächsten 3 Wochen sehr wahrscheinlich nur an den
Wochenenden Internetzugang, also nicht wundern wenn ich nicht erreichbar
bin ;-)
Beim RC1 wurden bei mir anfänglich die Kategorien links nicht
aufgelistet die ich engetragen habe. Konnte es im File
class.StructuralDBElement.php Zeile 379ff. zum Anzeigen bringen.
Hab in den Kategorien eine Kategorie MOSFET's gennant. Dieses Zeichen '
darf nicht geschrieben werden. Dann läufts wenn der Name MOSFET
gebraucht wird.
@Christian
Jup da fehlte noch was, hab ein htmlentities() und ein addslashes()
eingebaut (r650), damit sollten jetzt alle Sonderzeichen korrekt
dargestellt werden. Ist dann in der RC2 mit drin.
mfg
Ich habe die ganze Zeit Version 0.2.2 verwendet. Jetzt wollte ich mal
die neue Version 3 testen, aber ich bekomme das mit der Datenbank nicht
hin. Das Autoupdate der Datenbank scheitert immer von V12 nach V13.
Von V11 auf V12 scheint es problemlos zu klappen.
Beim Update von V12 --> V13 bekomme ich den folgenden Fehler
Fehlermeldung: SQLSTATE[01000]: Warning: 1265 Data truncated for column
'description' at row 1
Manchmal bleibt er auch schon hier hängen:
Schritt: UPDATE `footprints` SET filename = REPLACE(filename, 'ä',
'ä')...FEHLER!
Fehlermeldung: SQLSTATE[42S22]: Column not found: 1054 Unknown column
'filename' in 'field list'
Ich spiele dann immer den SQL Dump der Version 0.2.2 ein.
Die Version 0.2.2 funktioniert auch problemlos.
Die Dateien aus dem Archiv habe ich in einen komplett lehren Ordner des
Webservers entpackt, nur die alte config.php habe ich eingefügt.
Hat jemand eine Idee?
Danke
OK also ich habe mal eine kleine Änderung in der class.Database.php
eingefügt, ersetze diese Datei mal mit dieser hier:
https://part-db.googlecode.com/svn/trunk/lib/class.Database.php
Es gibt wohl noch ein Problem wenn man nach einem Update-Fehler manuell
wieder eine ältere Datenbank einspielt. Denn das neu einspielen kriegt
Part-DB grundsätzlich ja nicht mit und macht dann beim nächsten
Update-Versuch wieder dort weiter, wo beim letzten Mal der Fehler
auftrat. Das ist natürlich falsch, das Update müsste dann wieder von
Vorne beginnen.
Vermutlich kommt daher dann das Problem mit der Spalte
footprints.filename.
Wenn du die Datenbank wieder auf den älteren Stand zurücksetzt, müsstest
du in der config.php die folgenden zwei Werte auf "0" zurücksetzen:
1
$config['db']['update_error']['version'] = 0;
2
$config['db']['update_error']['next_step'] = 0;
Ich muss mal schauen ob man das noch irgendwie verbessern kann, so dass
Part-DB merkt dass ein Backup eingespielt wurde und dann entsprechend
das Update wieder von Vorne beginnt. Ich denke das sollte möglich
sein...
Ich fürchte fast dass ich da noch mehr Probleme bekommen werde.
Nach der Aufforderung eine Zeitzone/Sprache erhalte ich die Meldung:
Die gewählte Sprache "de_DE.UTF-8" wird vom Server nicht unterstützt!
Bitte installieren Sie diese Sprache oder wählen Sie eine andere.
Möglicherweiße liegt das daran dass es auf einem Windowssystem
installiert ist?
Danke
Juergen F schrieb:> Die gewählte Sprache "de_DE.UTF-8" wird vom Server nicht unterstützt!> Bitte installieren Sie diese Sprache oder wählen Sie eine andere.
Dieses Problem (bei Windows Servern) wurde bereits gemeldet und sollte
inzwischen behoben sein. Am besten wartest du noch auf die RC2, da ist
dieser Bugfix dann drin.
mfg
Kleiner Verbesserungsvorschlag:
Die Vorschaubilder der Artikel werden derzeit teilweise sehr stark
verzogen, da immer nur in eine Richtung runter skaliert wird.
Könnte man nicht Höhe und Breite zusammen so lange verringern bis es die
entsprechenden Größe haben?
Ich hätte noch eine Idee für die zukünftigen Versionen:
Die Artikel noch um eine Gewichtsfeld zu erweitern. Sowie bei den
Lagerorten ein max. zulässiges Gesamtgewicht definieren. Dabei lässt
sich pro Fach ein Gewicht definieren, sowie den übergeordneten Regal bzw
Sortimentkasten ein Gesamtgewicht eingeben.
Grüße Gerald
Dazu müsste ein max-width oder max-height im entsprechenden Thema schon
reichen. Bei großen Bildern macht man das jedoch nicht, da skaliert man
die Bilder schon vorher, um die Datenmenge zu verringern. Besser wäre es
aber, wenn die Bilder im Vektor(SVG)-Format wären, aber leider können
nur wenige Browser sowas direkt verarbeiten.
Wenn das gewünscht wird, kann ich eine passende Funktion besteuern.
Gerald *. schrieb:> Die Vorschaubilder der Artikel werden derzeit teilweise sehr stark> verzogen, da immer nur in eine Richtung runter skaliert wird.
Stimmt, das wollte ich eigentlich auch schon lange mal verbessern. Ich
habe jetzt die CSS-Datei entsprechend angepasst, wird nachher noch ins
SVN hochgeladen ist dann in der RC2 drin.
Für grosse Bilder sollen später mal automatisch Thumbnails verwendet
werden, da sonst die Performance stark leiden kann. Aber das muss noch
ein bisschen warten...
> Die Artikel noch um eine Gewichtsfeld zu erweitern.
Ich füge das mal unserer ToDo-Liste hinzu.
Hallo Zusammen,
Ich bin echt begeistert von der Lager-Verwaltung Datenbank und habe
schon fleissig -> Artikel in die Datenbank abgelegt.
Da ich teils ein bisschen grössere Artikel einlagere, wie Kompressoren,
habe ich nun das Problem , dass sich zum Beispiel einer in der
Lagerhalle, einer auf der Baustelle und einer in Reparatur befindet ...
Aktuell habe ich mir denselben Artikel 3x erstellt um ihn an 3
verschiedenen Orten "lagern" zu können ... Die Lagerbewegungen habe ich
in die Notizen geschrieben. Was natürlich nicht so tolle ist.
Frage: Habt Ihr mir eine Idee wie ich das besser handhaben könnte ...
Oder gibt es die Möglichkeit mehrere Lagerorte für ein und denselben
Artikel in dieses Programm zu implementieren ?
Gruss Peter
Hallo Peter,
Momentan gibt es keine "saubere" Variante, um den selben Artikel an
mehreren Orten gleichzeitig zu lagern. In unserer ToDo-Liste ist aber
schon ein Punkt aufgeführt, der diese Thematik anspricht. Das kann aber
noch dauern bis das eingebaut wird.
So eine Funktion ist aber auch nicht ganz trivial. Es gibt mehrere
Probleme, die mit dem Einbauen dieser Funktion auftreten werden. Diese
beginnen schon bei den "+" und "-" Buttons in den Artikellisten. Aus
welchem Lagerort sollen die Artikel nun abgebucht/eingebucht werden wenn
so ein Button geklickt wird? Dasselbe beim Abfassen einer ganzen
Baugruppe, welche Artikel sollen von welchem Lagerort abgebucht werden?
Fragen über Fragen... ;-)
Momentan muss man halt irgendwie improvisieren wenn man den selben
Artikel an verschiedenen Orten lagert. Sei es mit Kommentaren, oder mit
dem Erstellen von mehreren, gleichnamigen Artikeln (für jeden Lagerort
einen).
mfg
Bei der "Version 0.3.0 RC1 (unstable)" hat sich ein Vertipper
eingeschlichen. Bei "Bearbeiten - Footprints" steht im Hinweis-Text:
"Dateinaben" statt "Dateinamen".
Bitte nicht gleich steinigen, dass ich hier solche Banalitäten poste,
aber ich weiß nicht wo ich das sonst "melden" könnte.
Christian R. schrieb:> "Dateinaben" statt "Dateinamen".
Danke, wird korrigiert.
Christian R. schrieb:> Bitte nicht gleich steinigen, dass ich hier solche Banalitäten poste,> aber ich weiß nicht wo ich das sonst "melden" könnte.
Passt schon :-)
Hmmm, irgendwie bekomme ich es nicht hin den Link zu meinem Datenblatt
anzugeben.
Ich kann nur eine Datei auswählen, welche ich hochladen will, aber ich
kann kein Link eintragen.
Und dann ist mir noch aufgefallen dass der Titel ("Part-DB 0.3.0") nicht
geändert werden kann. Man kann zwar einen Titel eingeben, dieser wird
jedoch ignoriert.
Christian R. schrieb:> Ich kann nur eine Datei auswählen, welche ich hochladen will, aber ich> kann kein Link eintragen.
Stimmt...Wird korrigiert.
Christian R. schrieb:> Und dann ist mir noch aufgefallen dass der Titel ("Part-DB 0.3.0") nicht> geändert werden kann. Man kann zwar einen Titel eingeben, dieser wird> jedoch ignoriert.
Ist bereits behoben, kommt dann in die 0.3.0 RC2.
Bei "Verwaltung/Tools" sollte unter "Konfiguration - Datenbank" ein
Button "Jetzt Datenbank Updaten" vorhanden sein. Da drauf klicken ;-)
Mal was anderes...
Wenn ich eine Datei (Datenblatt) hoch laden möchte bekomme ich die
Fehlermeldung "Es gab ein Fehler beim Hochladen der Datei!". Ich nehme
an dass der Ordner nicht genügend Rechte hat. Welchen Ordner muss ich
denn welche Rechte (CHMOD) geben?
Christian R. schrieb:> Wenn ich eine Datei (Datenblatt) hoch laden möchte bekomme ich die> Fehlermeldung "Es gab ein Fehler beim Hochladen der Datei!". Ich nehme> an dass der Ordner nicht genügend Rechte hat. Welchen Ordner muss ich> denn welche Rechte (CHMOD) geben?
Da muss ich noch eine gescheitere Fehlermeldung einbauen. Es gibt
grundsätzlich zwei mögliche Fehlerquellen:
- fehlende Schreibrechte im Ordner data/media/
- maximale Dateigrösse für Uploads überschritten (php.ini)
Für letzteren Punkt siehe auch "PHP konfigurieren":
http://www.partdb.grautier.com/svn/documentation/dokuwiki/doku.php?id=anforderungen
Christian R. schrieb:> Bei "Verwaltung/Tools" sollte unter "Konfiguration - Datenbank" ein> Button "Jetzt Datenbank Updaten" vorhanden sein. Da drauf klicken ;-)
Bei Verwaltunng/Tools ist garnichts. Wer noch mal gucken möchte:
http://peter-partdb.comze.com , Benutzer: gast, Passwort: gast
Peter K. schrieb:> Bei Verwaltunng/Tools ist garnichts. Wer noch mal gucken möchte:> http://peter-partdb.comze.com , Benutzer: gast, Passwort: gast
Auf deinem Server läuft PHP 5.2.17, benötigt wird aber mindestens 5.3.0.
Du musst also entweder erstmal deine PHP Version aktualisieren oder
einen anderen Host suchen.
Bist du sicher dass du Part-DB auf einem öffentlichen Server
installieren möchtest? In den meisten Fällen reicht ein Server im
eigenen LAN. Siehe Doku:
http://www.partdb.grautier.com/svn/documentation/dokuwiki/index.php
Das ganze ist eigentlich Passwortgeschützt durch htaccess, ich habs
gerade nur mal rausgehauen. Kann man das mit den PHP nicht irgendwie
umgehen, mein Hoster will nicht updaten. Villeicht versuch ichs mal bei
Kilu.
Ich will das auf einen Hoster packen, weil mein Server-PC nicht immer an
ist. Ich könnte den Server zwar auf den Werkstatt-PC laufen lassen, aber
wenn ich dann nur mal schnell auf den Laptop gucken will, ob ich
genügend xxx hab ist es blöd, ihn jedesmall anzuschalten
PS: Hab gerade vergessen mich anzumelden
Für genau diese Fälle habe ich ja myparts.info registriert. Leider ist
das bisher noch nicht nutzbar.
Nochmal zur Erinnerung, wie das gedacht ist (wer das noch weiß kann den
folgenden Text einfach überspringen) :
-Eine Große Datenbank, in der die Bauteile angelegt sind (samt Preise
diverser Verkäufer, Links zu Datenblättern, Footprints, usw.)
-Jeder User bekommt eigene Lagerplätze
Nun hätte jeder User die Möglichkeit kostenlos (ohne extra einen eigenen
Webspace mieten zu müssen) seine eigenen Lagerplätze anzulegen und
braucht nur noch die Bauteile auswählen und die Stückzahl eintragen.
Man braucht keine Footprints raus suchen (sind schon beim Bauteil
verknüpft), keine Datenblätter raus suchen (sind ebenfalls schon
Verknüpft), die Preise sind auch schon eingetragen, usw.
Man kann also sehr schnell sein eigenes Lager eintragen.
Wenn ein User nun ein Bauteil hat, welches noch nicht existiert müsste
er es zwar genauso anlegen wie derzeit auch, aber das muss er halt nur
für dieses eine Bauteil und nicht für alle.
Wenn ich z.B. ein 74ALS30 anlege, dann muss ich alle Daten (Footprints,
Datenblatt, Preise) damit verknüpfen. Wenn nun ein anderer User das
gleiche Bauteil benötigt, dann erspart er sich die Arbeit, da das
Bauteil schon vorhanden ist. Einfach auswählen, einem (eigenen)
Lagerplatz zuordnen und die Stückzahl eintragen. Fertig.
Die Vorteile:
-Viel weniger Arbeit beim Anlegen des eigenen Lagers
-Aktuelle Daten (wenn sich der Preis bei Reichelt ändert profitieren
andere User direkt von der Aktualisierung des anderen Users)
-Relativ kleine Datenmengen auf dem Server. Ein
Datenblatt/Footprint/usw. muss nur einmal vorhanden sein, wodurch die
Datenmenge von 1000 User nur unerheblich größer ist als von einem User
(sofern der eine User über ein riesiges Bauteilspektrum verfügt).
Der Nachteil:
-Ein User kann Daten zerstören, welche von einem anderen User mit
genutzt werden (z.B. den Preis bei Conrad & Co. verfälschen).
Der Nachteil ist gravierend und muss unbedingt vermieden werden.
Dazu fällt mir die folgende Möglichkeit ein:
Wenn ein User ein neues Bauteil anlegt oder einen Preis ändert dann
müsste das "lokal" sein, also nur für ihn selber. Gleichzeitig müsste
der Eintrag in einer Liste auftauchen, welche von Moderatoren "geprüft"
wird. Sobald die Daten geprüft wurden müssten diese von lokal auf global
geändert werden.
Beispiel: Ich ändere den Preis eines Bauteils. Dieser neue Preis
erscheint nun sofort bei mir, aber alle anderen sehen noch den alten
Preis. Meine Preisänderung taucht nun in einer Liste auf. Sobald ein
Moderator diese Änderung bestätigt wird der Preis in die "normale große
Datenbank" übernommen und ist ab nun für alle User sichtbar.
Diese Methode benötigt freiwillige Moderatoren.
Um das zu realisieren fehlt Part-DB folgendes:
-Eine Benutzerverwaltung (nötig, da viele User eine gemeinsame Datenbank
nutzen)
-Eine Funktion welche neben den globalen Daten auch lokale Daten nutzt,
welche dann nach einer Prüfung global werden
Was irgendwann vielleicht auch mal interessant sein könnte
(Zukunftsmusik):
Wenn man ein Bauteil braucht welches bei normalen Händlern nicht mehr zu
bekommen ist, dann wäre "Suche Bauteil"-Funktion nützlich. Dies könnte
man so realisieren dass man dieses Bauteil als "gesucht" markiert (am
besten mit einem Preis dem man dafür bietet) und andere User (welches
dieses Bauteil besitzen) eine Benachrichtigung bekommen. Die
Benachrichtigung kann entweder per Mail/PN erfolgen, oder ganz dezent
indem irgendwo ein Symbol erscheint wenn jemand ein Bauteil sucht was
man selber im Bestand hat. Per Klick auf das Symbol könnte man dann im
PopUp-Fenster genaueres erfahren. Auf dieser Weise könnte so mancher
noch zu einem Bauteil kommen, welches er sonst nirgendwo anders bekommen
kann und dementsprechend kann so mancher User alte Restbestände die
irgendwann in der Tonne landen würden sogar noch verkaufen/verschenken.
So, genug gespamt ;-)
Peter K. schrieb:> Kann man das mit den PHP nicht irgendwie umgehen
Ich weiss jetzt grad nicht auswendig welche für Part-DB relevanten
Neuerungen nach PHP 5.2.17 kamen, aber ich glaube es sind schon einige.
Es hat schon einen Grund, warum wir PHP 5.3 voraussetzen ;-)
Um herauszufinden, was genau die Probleme verursacht bei PHP 5.2.17
könntest du mal das Debugging aktivieren
(http://peter-partdb.comze.com/partdb/system_debug.php) und schauen ob
irgendwelche gescheiten Fehlermeldungen auftreten beim Aufrufen der
Startseite.
> mein Hoster will nicht updaten.
Das kann man von einem free Hoster ja auch nicht erwarten ;-) Ich
persönlich bin der Meinung, wer Webspace braucht soll ihn auch bezahlen.
Man bekommt für sehr wenig Geld gescheite Server mit aktueller Software
(PHP, MySQL, ...). Die sind dann auch zuverlässiger (nur so nebenbei:
dein Server meldete vorher mal "Server überlastet") und es gibt einen
kompetenten Support, häufig sogar Sonntags (eigene Erfahrung) :-)
mfg
Auf der Hauptseite kommt jetzt:
Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM, expecting
T_VARIABLE in /home/aXXXXXXX/public_html/partdb/lib/class.DBElement.php
on line 250
Es gibt im Grunde mehrere Wege um den Multiuser Support ins naechste
DB-Layout einzubauen:
. Man aendert das Schema fuer 'part' und fuegt ein zusaetzliches Feld
owner hinzu. Ist fuer Workgroups nicht geeignet
. Fuer ein modernes Usermanagement mit ACLs braucht es einfach fuer die
'parts' eine zusaetzliche Table 'acl_parts'. Dort traegt man den
Fremdschluessel fuer das Part auf das sich der ACL-Eintrag bezieht, den
User sowie Rechte (Lesen,Schreiben etc.) ein. Fertig!
Loesung Zwei hat den Vorteil, dass man das parts Layout nicht antasten
muss. Wenn man mittels SELECT eine Kategorie listet, dann kann man den
Rechtecheck z.B. mittels Join an die ACL Tabelle loesen.
Das ganze koennte man ja auch als vorbereitende Massnahme machen, ohne
den Code dafuer schon haben. Die Felder sind dann auf jeden Fall da.
Klingt als wenn sich der Aufwand in Grenzen halten würde.
Die Daten für myparts.info habe ich ja schon an manche Entwickler weiter
gegeben. Wenn die "untergegangen" sind kann ich die gerne noch mal
zusenden.
@Christian R.:
Vor allem wuerde Multiuser-Support dem Projekt einen gewaltigen Schub
geben. Schliesslich hat nicht jeder potentielle User das Know How
und/oder die Resourcen, die Installation vorzunehmen.
Wichtig waere auch weitere Sprachversion 'English'. Das Aufwand bei
part-db ist aesserst niedrig verglichen mit vielen anderen Programmen.
Oft sind es nur einzelne Woerter, die man in mehreren Sprachen vorhalten
muss.
Diese zwei Schritte wuerden den Nutzerkreis potenzieren! Und damit auch
neue Entwickler auf dieses Projekt aufmerksam machen.
Peter K. schrieb:> Auf der Hauptseite kommt jetzt:> Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM, expecting> T_VARIABLE in /home/aXXXXXXX/public_html/partdb/lib/class.DBElement.php> on line 250
Genau das habe ich befürchtet. Vergiss deinen aktuellen Hoster, mit PHP
5.2 läuft Part-DB nicht.
@Christoph & Christian
In der Softwareentwicklung hört sich eine Änderung schnell mal "einfach"
an. Geht es dann an die Umsetzung, merkt man dann aber meistens dass es
eben doch "etwas" umfangreicher ist ;-)
Seit Part-DB 0.2.2 haben wir ja auch "nur" auf Templates und OOP
umgestellt. Hat aber trotzdem über ein halbes Jahr und rund 10'000
Codezeilen gedauert ;-)
Eine Benutzerverwaltung, die schlussendlich für Firmen, aber auch für
myparts.info geeignet ist, wird sehr aufwändig. Für Firmen ist wichtig,
dass man jedem Benutzer verschiedene Rechte zuweisen kann, damit z.B.
der Monteur die Preise nicht sehen kann. Ausserdem greifen dort alle
Benutzer auf den selben Lagerbestand zu. Für myparts.info sind ganz
andere Sachen wichtig. Jeder Benutzer braucht seinen eigenen
Lagerbestand und es braucht ein Moderatoren-Feature. Dafür braucht man
keine Möglichkeit, einem Benutzer das Leserecht für Preise zu entziehen.
Urban B. schrieb:> @Christoph & Christian> In der Softwareentwicklung hört sich eine Änderung schnell mal "einfach"> an. Geht es dann an die Umsetzung, merkt man dann aber meistens dass es> eben doch "etwas" umfangreicher ist ;-)
Ist schon klar, dass das etliche Aenderungen am Code erfordert und nicht
mal so schnell gecoded ist. Hab auch Erfahrung mit Softwareentwicklung
und den Requests der User :-)
Zum Thema Rechtevergabe:
IMHO sollte auch es nicht der Zweck der part-db sein, mit
professionellen ERP Systemen zu konkurrieren ;-) Also Spalten ausblenden
waere wohl mit Sicherheit Overkill.
Die Lokalisierung ist aber wohl einfacher als die Rechtevergabe. Und
aktiviert mit Sicherheit neues Entwicklerpotential!
Es gibt ja nicht so viele Strings, die der User im Browser am Ende
sieht. Und statt "Neues Teil in dieser Kategorie" koennte man im Sinne
von
i18n("catview_invoke_newpart")
eine Funktion aufrufen. Dann braucht es noch eine Tabelle fuer die
jeweilige Sprache und fertich.
Kinds regards
Christoph schrieb:> IMHO sollte auch es nicht der Zweck der part-db sein, mit> professionellen ERP Systemen zu konkurrieren ;-)
Also ich habe selbst auch schon ein paar ERP Systeme angeschaut, und
musste feststellen, dass diese für einen kleinen Betrieb einfach masslos
überdimensioniert und dadurch viel zu kompliziert sind. Ich konnte kein
(günstiges oder freies) einfaches Lagerverwaltungssystem finden, das für
kleinere Betriebe wirklich geeignet ist. Ich finde, hier könnte Part-DB
eine Lücke schliessen. Mit den professionellen ERP-Systemen soll Part-DB
natürlich nicht konkurrenzieren.
Aber erstens ist die Benutzerverwaltung derzeit grad noch kein Thema,
und zweitens sollten wir uns dazu auch mal die Meinung von K.J. anhören,
er ist schliesslich der Chef hier :-)
Bezüglich Lokalisierung: Das sehe ich ähnlich. Früher oder später
sollten zusätzliche Sprachen verfügbar sein. Aber momentan haben andere
Sachen eine höhere Priorität...
Peter K. schrieb:> Ich habs jetzt bei Kilu installiert. Es zeigt mir aber nichts an, auch> nicht bei Verwaltung/Tools> http://peter-partdb.kilu.de/partdb/
Da scheint JavaScript einfach nicht zu laufen. Sind die Dateirechte für
alle Dateien im "javascript" Ordner korrekt?
Irgendwas stimmt aber sowieso nicht bei deiner Installation, weil die
Umlaute nicht korrekt dargestellt werden. Wie lädst du die Dateien auf
den Webserver hoch? Es scheint als würden die PHP Dateien nicht als
UTF-8 interpretiert werden.
mfg
Normalerweise erkennt ein FTP-Client automatisch ob Text- oder
Binarytransfermode genutzt werden soll. Wenn man unsicher ist, dann
nimmt man Binary für den gesamten Upload.
Grüße
Udo
Bei der Version "0.3.0 RC1 (unstable)" ist die Sortierung etwas
"merkwürdig"
Hier ist mal ein Screenshot:
http://abload.de/img/sortierungtsain.png
Hier ist ein Screenshot von meiner alten Version:
http://abload.de/img/sortierung6xxsh.png
Ich erkenne nicht nach was da sortiert wird.
Edit: Ich hatte aus Versehen den Screenshot meiner alten Version statt
der 0.3.0 hochgeladen ...habe ich hiermit korrigiert
Peter K. schrieb:> Ich habs jetzt bei Kilu installiert. Es zeigt mir aber nichts an, auch> nicht bei Verwaltung/Tools> http://peter-partdb.kilu.de/partdb/
Ja, so hat es bei mir auch ausgesehen wie ich es mit Filezilla auf
meinen Webserver hochgeladen hatte ... mit dem ws-ftp95 hat es dann auf
Anhieb geklappt...
Versuch's mal einem anderen File-uploader
Peter K. schrieb:> das Javascript Verzeichnis ist jetzt auf 777
das ist unklug. da koennen schlimme dinge passieren.
ausserdem hast Du ein Problem mit den Umlauten, da ist wahrscheinlich
der falsche Zeichensatz eingestellt.
Peter K. schrieb:> Auf was soll ich dann Stellen? Kann man den Zeichensatz Nachher> noch> ändern
Der Webserver liefert als Encoding iso-8859-1 aus, aber die Part-DB ist
in utf-8. Dann wird aus den Umlauten, dass was man auf der Startseite
sieht.
Wie man das jetzt umstellt, das koennen die Experten besser beantworten.
Ist unter Umstaenden eine Sache der Webserver-Konfig, hatte ich mal nach
einer Neuinstallation mit Apache.
Noch eine Sache zur Version "0.3.0 RC1 (unstable)".
Wenn ich einen Preis eingebe wird nur der Punkt akzeptiert, aber ich
kann kein Komma eingeben (obwohl der Preis nachher per Komma angezeigt
wird).
Noch eine Frage:
Was muss ich nochmal machen um den Bestand ohne Mindestbestand angezeigt
zu bekommen (siehe Vergleich der beiden Screenshots ein paar Beiträge
weiter oben)?
Christian R. schrieb:> Bei der Version "0.3.0 RC1 (unstable)" ist die Sortierung etwas> "merkwürdig"
Uups, ich dachte das hätte ich behoben (habe nämlich vor langer Zeit
auch schon bemerkt dass falsch sortiert wird) schämPeter K. schrieb:> Auf was soll ich dann Stellen?
Beim Verzeichnis "javascript" sollte 555 für das Verzeichnis, und 444
für die Dateien passen. Steht alles in der Doku:
http://www.partdb.grautier.com/svn/documentation/dokuwiki/doku.php?id=installation> Kann man den Zeichensatz Nachher noch ändern
Der Zeichensatz der PHP Dateien muss man nicht ändern. Alle Dateien von
uns sind UTF-8 codiert und sollen auch genau so verwendet werden. Man
muss einfach beim Hochladen aufpassen, dass die Dateien nicht mit einem
falschen Zeichensatz interpretiert und dann irgendwie umgewandelt
werden. Wie Udo schon erwähnte, sollte man hier einfach "binary"
verwenden wenn man sich nicht sicher ist. In Filezilla gibts dazu die
Einstellung "Standard-Transfertyp: Binär" unter "Übertragungen ->
Dateitypen".
Christian R. schrieb:> Wenn ich einen Preis eingebe wird nur der Punkt akzeptiert, aber ich> kann kein Komma eingeben (obwohl der Preis nachher per Komma angezeigt> wird).
Das Komma wird halt nicht immer gerne als Dezimalpunkt gesehen, weil es
im englischsprachingen Raum als Tausendertrenner verwendet wird wenn ich
micht jetzt nicht irre. Der Punkt hingegen wird eigentlich immer als
Dezimalpunkt interpretiert, was zu keinen Verwechslungen führen kann.
Deshalb wird halt in Part-DB das Komma nicht angenommen...
Christian R. schrieb:> Was muss ich nochmal machen um den Bestand ohne Mindestbestand angezeigt> zu bekommen
In der config.php diese Zeile einfügen:
Urban B. schrieb:>> Kann man den Zeichensatz Nachher noch ändern>> Der Zeichensatz der PHP Dateien muss man nicht ändern. Alle Dateien von> uns sind UTF-8 codiert und sollen auch genau so verwendet werden. Man> muss einfach beim Hochladen aufpassen, dass die Dateien nicht mit einem> falschen Zeichensatz interpretiert und dann irgendwie umgewandelt> werden. Wie Udo schon erwähnte, sollte man hier einfach "binary"> verwenden wenn man sich nicht sicher ist. In Filezilla gibts dazu die> Einstellung "Standard-Transfertyp: Binär" unter "Übertragungen ->> Dateitypen".
Das ist so nicht ganz korrekt. Sein Webserver (Apache) liefert als
Content Type
"Content-Type: text/html; charset=iso-8859-1"
das sorgt fuer die defekten Zeichen. Selbst dann wenn die Dateien
korrekt hochgeladen wurden. Unicode Zeichen sind schließlich Multibyte
und iso-8859 sind SingleByte
Kann man aber umstellen, z.B. mit AddDefaultCharset und Co., manches
geht auch in .htaccess Dateien.
Christoph schrieb:> Das ist so nicht ganz korrekt. Sein Webserver (Apache) liefert als> Content Type> "Content-Type: text/html; charset=iso-8859-1"
Ach so, das habe ich gar nicht gesehen. Aber dazu steht doch die Zeile
im Header jeder (durch PHP generierten) HTML-Datei, die dann dem Client
gesendet wird? Oder habe ich da etwas falsch verstanden?
Christoph schrieb:> Kann man aber umstellen, z.B. mit AddDefaultCharset und Co., manches> geht auch in .htaccess Dateien.
Das habe ich grad unseren .htaccess Dateien noch hinzugefügt. Nach etwas
Recherche im Internet bin ich aber verwirrt was das "AddDefaultCharset"
genau bewirkt. Grundsätzlich teilt es doch dem Client mit, wie eine
Datei codiert ist, die dem Benutzer geschickt wird. Bei HTML ist das
aber doch irgendwie nicht relevant wenn im Header der Zeichensatz
angegeben ist?!
Was ich auch noch nicht in Erfahrung bringen konnte:
Wie interpretiert Apache bzw. der PHP Interpreter eigentlich eine *.php
Datei, also welcher Zeichensatz wird verwendet? Der Interpreter muss ja
wissen, wie die Datei codiert ist, und in der Datei ist dies nicht
direkt ersichtlich. Ermittelt der Interpreter den Zeichensatz einfach
anhand des Inhaltes, also z.B. am Vorhandensein von gängigen
Multibyte-Zeichen?
Urban B. schrieb:>> Das ist so nicht ganz korrekt. Sein Webserver (Apache) liefert als>> Content Type>> "Content-Type: text/html; charset=iso-8859-1">> Ach so, das habe ich gar nicht gesehen. Aber dazu steht doch die> Zeile<meta http-equiv="content-type" content="text/html; charset=utf-8">> im Header jeder (durch PHP generierten) HTML-Datei, die dann dem Client> gesendet wird? Oder habe ich da etwas falsch verstanden?
Aber das was der Webserver von sich aus sendet, kommt zuerst. Dannach
erst die Ausgabe des Skriptes. Mein Firefox hatte bei der Seite von
Peter K. iso-8859-1 aktiv. Kann man unter "Page Info" ansehen.
Vielleicht gilt einfach das erste, was der Browser sieht. Oder noch
schlimmer, jeder Browser macht es anders ==> Chaos.
>> Christoph schrieb:>> Kann man aber umstellen, z.B. mit AddDefaultCharset und Co., manches>> geht auch in .htaccess Dateien.>> Das habe ich grad unseren .htaccess Dateien noch hinzugefügt. Nach etwas> Recherche im Internet bin ich aber verwirrt was das "AddDefaultCharset"> genau bewirkt.
In die .htaccess wuerde ich das nicht von Haus aus reinschreiben. Denn
bei manchen Direktiven kommt es zu einem 500 Internal Server Error, wenn
man diese in der zentralen Apache Config (global oder fuer den Virtual
Hosts) fuer die Verwendung in .htaccess geblockt hat.
> Grundsätzlich teilt es doch dem Client mit, wie eine> Datei codiert ist, die dem Benutzer geschickt wird. Bei HTML ist das> aber doch irgendwie nicht relevant wenn im Header der Zeichensatz> angegeben ist?!
s.o.
>> Was ich auch noch nicht in Erfahrung bringen konnte:> Wie interpretiert Apache bzw. der PHP Interpreter eigentlich eine *.php> Datei, also welcher Zeichensatz wird verwendet? Der Interpreter muss ja> wissen, wie die Datei codiert ist, und in der Datei ist dies nicht> direkt ersichtlich. Ermittelt der Interpreter den Zeichensatz einfach> anhand des Inhaltes, also z.B. am Vorhandensein von gängigen> Multibyte-Zeichen?
Gute Frage. In Variablennamen duerfen diese Zeichen ja nicht vorkommen,
nur in Strings. Und die interpretiert ja erst der Browser. Unklar ist
was bei Stringbearbeitung bearbeitung, da muss php dann doch wissen dass
es UTF-8 ist.....
mmh jedesmal wenn ich denke, jetzt habe ich das mit den Zeichensätzen
richtig begriffen, werde ich wieder eines besseren belehrt, das fängt
langsam an zu nerven ;-)
OK nach einem kurzen Test scheint die Zeichensatz-Angabe im HTML-Header
tatsächlich wirkungslos, wenn ich im PHP Skript ganz am Anfang den
Zeichensatz per header() auf was anderes als UTF-8 setze.
Spontan würde ich dann also einfach sagen, wir bauen in
start_session.php ganz am Anfang diese Zeile ein:
1
header('Content-type: text/html; charset=utf-8');
Damit sollte dann der HTTP Header ja bei jeder Seite von Part-DB auf
UTF-8 gesetzt werden.
Christoph schrieb:> In die .htaccess wuerde ich das nicht von Haus aus reinschreiben. Denn> bei manchen Direktiven kommt es zu einem 500 Internal Server Error, wenn> man diese in der zentralen Apache Config (global oder fuer den Virtual> Hosts) fuer die Verwendung in .htaccess geblockt hat.
Das ist blöd...dann kommt das halt wieder raus.
Christoph schrieb:> Gute Frage. In Variablennamen duerfen diese Zeichen ja nicht vorkommen,> nur in Strings. Und die interpretiert ja erst der Browser. Unklar ist> was bei Stringbearbeitung bearbeitung, da muss php dann doch wissen dass> es UTF-8 ist.....
Stimmt... Dazu habe ich grad folgendes gefunden:
http://www.gerd-riesselmann.de/softwareentwicklung/php-und-utf-8-eine-anleitung-teil-3-php-string-funktionen
Das wird ja immer besser... Dann ersetze ich jetzt halt alle strlen()
noch durch mb_strlen() usw. ;-)
mfg
Erstmal vielen Dank für die schnelle Hilfe, der mit dem Mindestbestand
ausblenden hat geklappt.
Nun habe ich aber immer noch das Problem dass ich kein Datenblatt
hochladen kann (das mit der URL ist ja ein anderes Thema). Es kommt
immer noch die Fehlermeldung "Es gab ein Fehler beim Hochladen der
Datei!".
Nun habe ich mir nochmal die Installationanleitung angesehen. Alle
Dateien haben nun die Rechte 444, alle Ordner haben die Rechte 555.
Der Ordner "Data" hat die Rechte 755 (sowie alle Unterorder) und die
Dateien da drin (und in den Unterordnern) haben die Rechte 644.
Nun komme ich aber mit folgendem Satz nicht klar:
"Ausserdem sollten alle Dateien dem Besitzer „www-data“ gehören: "
Wie kann ich das denn einstellen? Ich verwende FireFTP, aber ich habe
kein Plan wie ich die Benutzerrechte damit ändern kann :-/
Außerdem bin ich mir nicht sicher ob sich das auf "alle" Dateien bezieht
oder nur auf die Dateien im "Data"-Ordner.
Christian R. schrieb:> Nun habe ich aber immer noch das Problem dass ich kein Datenblatt> hochladen kann (das mit der URL ist ja ein anderes Thema). Es kommt> immer noch die Fehlermeldung "Es gab ein Fehler beim Hochladen der> Datei!".
Also die Fehlermeldung habe ich mittlerweile aussagekräftiger gestaltet,
du kannst es mal probieren mit der aktuellsten Version der lib/lib.php:
https://part-db.googlecode.com/svn/trunk/lib/lib.php
Ausserdem gibts jetzt in der Doku einen Hinweis auf mögliche Probleme
beim Upload. Das Problem ist nämlich hauptsächlich, dass in der
Standardeinstellung von PHP nur Dateien bis 2MB hochgeladen werden
können.
Ab morgen sollte der entsprechende Abschnitt in der Doku der Online Demo
verfügbar sein, aber es ist nicht viel, daher kann ichs gleich hier
posten:
> Die Standardeinstellungen von PHP sind in der Regel ganz in Ordnung.> Möchte man aber auch etwas grössere Dateien hochladen können (z.B.> Dateianhänge in Part-DB), muss man eventuell das Dateigrössen-Limit für> Uploads anpassen. Dies macht man in der Datei "php.ini", welche sich bei> Debian-basierten Betriebssystemen im Verzeichnis "/etc/php5/apache2/"> befindet.>> sudo gedit /etc/php5/apache2/php.ini>> In dieser Datei nach dem Stickwort "upload_max_filesize" suchen und den> Wert entsprechend anpassen. Ausserdem müssen die Werte "post_max_size"> und "memory_limit" mindestens gleich gross sein wie> "upload_max_filesize".Christian R. schrieb:> "Ausserdem sollten alle Dateien dem Besitzer „www-data“ gehören: "
Auch diesbezüglich habe ich die Doku um einen Kommentar erweitert:
> Bei gemieteten Webservern, bei denen man die Dateien per FTP hochlädt,> ist der Besitzer der Dateien häufig ein FTP-Benutzer, und nicht der> Benutzer von Apache. In diesem Fall müssen die Rechte für „data“ 775> bzw. 664, oder sogar 777 bzw. 666 lauten, damit Apache auch> Schreibrechte in diesem Verzeichnis erhält.
Vielen Dank für deine Hilfe.
An der Dateigröße kann es in dem Fall nicht liegen, da die Datei gerade
mal 129kb klein ist. Dank deiner verbesserten lib.php bekomme ich nun
folgende Fehlermeldung:
Sie haben keine Schreibrechte im Verzeichnis
"/www/htdocs/xxxxxxxx/xxxxxxxx/holle/data/media/"!
Das war schon ein Kampf die lib.php hochzuladen (ich hatte keine
Schreibrechte mehr, weil ich ja alle Ordner auf 555 gestellt hatte) ;-)
Nun habe ich dem Ordner "Data" und alle Unterordner CHMOD 775 gegeben
...gleiches Ergebnis.
Mit CHMOD 777 klappt es nun, aber ist das nicht etwas gefährlich?
Gibt es da keine andere Möglichkeit, z.B. dass PHP sich als Benutzer
ausgibt und somit 755 reicht?
Nun gibt es da noch ein Problem:
Ich habe das Datenblatt nun hoch laden können (mit CHMOD 777). Wenn ich
es nun lösche und wieder neu hoch laden möchte bekomme ich folgende
Fehlermeldung:
Die Datei "/www/htdocs/xxxxxxxx/xxxxxxxx/holle/data/media/24C08.pdf"
existiert bereits!
Das Problem wird sein dass die Datei nur aus der Datenbank gelöscht wird
(also der Link), aber die Datei auf dem Server verbleibt, weil die
Rechte zum löschen der Datei nicht ausreichen, denn diese wird mit 644
angelegt.
Christian R. schrieb:> Mit CHMOD 777 klappt es nun, aber ist das nicht etwas gefährlich?> Gibt es da keine andere Möglichkeit, z.B. dass PHP sich als Benutzer> ausgibt und somit 755 reicht?
777 ist natuerlich nicht ideal. JEDER auf diesem System (also
insbesondere andere Hosting-Kunden), kann in das Verzeichnis
reinschreiben.
Christian R. schrieb:> Das Problem wird sein dass die Datei nur aus der Datenbank gelöscht wird> (also der Link), aber die Datei auf dem Server verbleibt, weil die> Rechte zum löschen der Datei nicht ausreichen, denn diese wird mit 644> angelegt.
Um eine Datei zu loeschen, sind auf Unix die Zugriffsrechte am
Verzeichnis relevant. D.h. solange Du Files im Verzeichnis ablegen
kannst, kannst Du sie auch loeschen.
Ideal waere es, wenn das Datenverzeichnis vom part-db Installer erzeugt
wuerde (z.B. in einem Skript). Dann gehoert das Verzeichnis dem
Webserver-Nutzer und man kann 755 einstellen. Waehrend der Installation
muesste das uebergeordnete Verzeichnis per FTP auf 777 gestellt werden
und nachher wieder auf 755 zurueck.
Ich hatte ja den Installer benutzt, aber irgendwas ist da falsch
gelaufen. Ich erinnere mich noch daran dass ich einige Ordner von Hand
anlegen musste, da das automatische Anlegen fehlgeschlagen ist.
Muss mich da mal durchwuseln, vielleicht finde ich ja noch einen Weg um
per FireFTP (FTP-Programm vom Firefox) den Owner zu ändern.
Christian R. schrieb:> Ich hatte ja den Installer benutzt, aber irgendwas ist da falsch> gelaufen. Ich erinnere mich noch daran dass ich einige Ordner von Hand> anlegen musste, da das automatische Anlegen fehlgeschlagen ist.
Ah, wusste nicht, dass der Installer die Ordner anlegen kann.
Vielleicht sollte ich mal eine neue Version der part-db installieren ;-)
> Muss mich da mal durchwuseln, vielleicht finde ich ja noch einen Weg um> per FireFTP (FTP-Programm vom Firefox) den Owner zu ändern.
Aendern des Eigentuemers: nur root darf das :-(
Ich weiß nicht mehr genau ob der Installer auch Ordner angelegt hat, ich
weiß nur noch dass ich selber Ordner anlegen musste.
So, habe nun über das eingebettete FTP-Programm meines Hosters den Owner
ändern können (hatte die Auswahl zwischen meinem Benutzeraccount und
PHP-User. Nun hat der Ordner "Data" und alles da drin (Unterordner,
Dateien) den neuen Benutzer www-data.
Der Ordner Data/Media hat immer noch 777 und als Owner www-data und
trotzdem klappt das mit dem Löschen nicht (aus der Datenbank wird die
Verknüpfung gelöscht, aber auf dem Server bleibt die Datei vorhanden).
Edit: Habe die Rechte von Data/Media nun auf 755 gesetzt, das hochladen
des Datenblatts klappt nun auch mit 775.
Warum das mit dem löschen nicht klappt ist mir ein Rätsel.
Ich werde nun erst einmal alles wieder auf 755 setzen, da das mit dem
neuen Owner ja ausreichend ist.
Christian R. schrieb:> Das Problem wird sein dass die Datei nur aus der Datenbank gelöscht wird> (also der Link), aber die Datei auf dem Server verbleibt, weil die> Rechte zum löschen der Datei nicht ausreichen, denn diese wird mit 644> angelegt.
Das Problem ist eher, dass Part-DB gar nicht erst versucht, die Datei zu
löschen ;-) Werde ich noch korrigieren...
Christoph schrieb:> Ideal waere es, wenn das Datenverzeichnis vom part-db Installer erzeugt> wuerde (z.B. in einem Skript). Dann gehoert das Verzeichnis dem> Webserver-Nutzer und man kann 755 einstellen.
Das ist aber auch irgendwie blöd, weil das funktioniert dann ja nur wenn
man eine Neuinstallation macht. Hat man bereits ein Data-Verzeichnis mit
Daten aus einer bestehenden Installation, muss man das ja z.B. per FTP
hochladen und man hat wieder das gleiche Problem wie vorher...
Um dies zu umgehen müsste man z.B. eine Import/Export Funktion anbieten,
damit man die Daten aus einer bestehenden Installation exportieren, und
dann bei einer Neuinstallation wieder Importieren (per Dateiupload)
kann. Wäre sicher eine elegante Lösung, aber nicht mehr für die Version
0.3.0 :-)
Christoph schrieb:> Ah, wusste nicht, dass der Installer die Ordner anlegen kann.
Der Installer legt auch keine Ordner an, der "data" Ordner ist bereits
im Archiv enthalten (inkl. ein paar Dateien, z.B. .htaccess). Nur die
config.php wird vom Installer angelegt.
Urban B. schrieb:> Der Installer legt auch keine Ordner an, der "data" Ordner ist bereits> im Archiv enthalten (inkl. ein paar Dateien, z.B. .htaccess). Nur die> config.php wird vom Installer angelegt.
Hmmm, dann verwechsle ich da anscheinend was mit mysqldumper.
Zum Thema Installer:
Wäre es nicht machbar eine PHP-Datei in den Ordner zu legen, dieser die
Rechte 777 zu geben und die benennt dann die Ordner um, erstellt diese
neu (somit ist www-data der Owner) und kopiert dann die Dateien und
Order aus den umbenannten Ordnern in die neu erstellen Ordner. Danach
einfach die umbenannten Ordner löschen.
...nicht gleich steinigen, ist nur so ein Gedanke (habe keinen Plan von
PHP und Unix) ;-)
Christian R. schrieb:> Gibt es schon etwas neues bezüglich "URL für Datenblatt eintragen"> (Version 0.3.0) ?
Ist bereits im SVN, kommt dann in die 0.3.0 RC2 die ich wahrscheinlich
bald veröffentlichen werde. Alle wichtigen Bugfixes und sonstige
Verbesserungen, die seit der RC1 gemeldet wurden, sind dann in der RC2
drin.
Testen kann man die RC2 in dieser Demo:
http://www.partdb.grautier.com/svn/
So, ich denke es ist an der Zeit, die RC2 zu veröffentlichen. Ich warte
aber noch bis morgen, damit die Doku in der Online-Demo noch
aktualisiert wird (habe heute noch Änderungen ins SVN hochgeladen).
Das Archiv kann man jetzt übrigens per tools.sh, oder noch einfacher
direkt in Part-DB mit den Entwickler-Tools erstellen lassen. Das
garantiert korrekte Dateirechte, Besitzer und Gruppen aller Dateien und
Verzeichnisse. Auch werden benutzerspezifische Dateien wie die
config.php automatisch ausgeschlossen usw.
Ich würde mich übrigens freuen wenn sich jemand am Erweitern der Doku
beteiligen würde, hier gibts noch viel zu tun :-)
Einerseits ist die FAQ-Seite noch ziemlich leer, andererseits könnte man
vielleicht die Installationsanleitung zweiteilen. Einmal für die
Installation auf einem Server mit "direktem Zugang" (auch SSH), und
einmal für die Installation auf einem Webspace per FTP. Da könnte man ja
auch Screenshots von FileZilla o.ä. mit einbauen usw.
Damit man Schreibrechte im DokuWiki erhält, muss man im Part-DB Ordner
"data" einfach eine (leere) Datei mit dem Namen
"ENABLE-DOKUWIKI-WRITE-PERMS.txt" erstellen.
mfg
Hallo Maximilian,
Es hat sich vieles an der Datenbank verändert und damit ist dieses
Skript leider nicht mehr kompatibel.
Vielleicht gibt es ja einen Freiwilligen, der es aktualisiert? :-)
mfg
Hallo an die Experten,
ich nutze die part-db seit Jahren in der Ursprungsversion von C. Lechner
mit einigen selbstgemachten Änderungen.
Kann ich problemlos die bisher aufgebaute Datenbank in der aktuellen
Version nutzen?
Grüße
Hallo thirdgotti,
Das sollte prinzipiell möglich sein. Wichtig ist einfach, dass du zuerst
ein Backup der Datenbank anlegst damit nichts kaputtgehen kann.
Es kann allerdings sein, dass das Update auf die Version 0.3.0 Probleme
verursacht, dann solltest du mal versuchen zuerst auf die 0.2.2, und
danach auf die 0.3.0 zu aktualisieren. So stehen die Changen sehr gut
dass alles klappt.
mfg
Habe es hinbekommen.
Allderdings muss man da etwas tiefer in die Datenbank. Es haben sich
seit meiner "Uralt-Version" einige Tabellennamen und Spaltennamen
geändert. Diese muss man von dem Import ändern. PHPMyAdmin machts
möglich...
Aber sonst scheint das jetzt zu laufen.
thirdgotti schrieb:> Allderdings muss man da etwas tiefer in die Datenbank. Es haben sich> seit meiner "Uralt-Version" einige Tabellennamen und Spaltennamen> geändert. Diese muss man von dem Import ändern.
Das Ändern der Tabellennamen usw. sollte Part-DB selbst übernehmen. Es
sei denn, in deiner alten Version gibts noch keine Tabelle "internal"
mit dem Eintrag keyName="dbVersion". War der bei dir noch nicht
vorhanden?
Wenn du unsicher bist, kannst du mir deine uralt-DB auch per Mail
schicken, dann kann ich mir das mal anschauen und ggf. das Update auf
die neuste Version durchführen.
Urban B. schrieb:> Gerald *. schrieb:>> Die Vorschaubilder der Artikel werden derzeit teilweise sehr stark>> verzogen, da immer nur in eine Richtung runter skaliert wird.>> Stimmt, das wollte ich eigentlich auch schon lange mal verbessern. Ich> habe jetzt die CSS-Datei entsprechend angepasst, wird nachher noch ins> SVN hochgeladen ist dann in der RC2 drin.
Die Lösung gefällt mir. Danke!
Hi,
ich würde gerne die Lagerverwaltung starten, aber es wird mir verwehrt.
Es kommt immer die Fehlermeldung:
Die gewählte Sprache "de_DE" wird vom Server nicht unterstützt!
Bitte installieren Sie diese Sprache oder wählen Sie eine andere.
Ich habe sämtliche Vorgaben ausprobiert, aber bei jeder gibts die
Fehlermeldung.
Ich habe als Server den XAMPP installiert.
Wie kann ich Sprache "de_DE" installieren?
Mit besten Grüßen
Waldemar
Hallo,
vielen Dank, hat wirklich geklappt.
Nur schlage ich mich jetzt ersteinmal damit rum, eine Datenbank
anzulegen, da die ja vorausgesetzt wird. Darauf war ich nicht
vorbereitet.
Beste Grüße
Waldemar
Hallo,
habe mich heute mal rüber gemacht meine 0.2.2 SVN 512 mit der neuen RC2
upzudaten.
allerdings habe ich jetzt auch das Problem mit der fehlenden Sprache.
Geht es da um die Sprache von der Datenbank?
Gruß
Urban B. schrieb:> So, ich denke es ist an der Zeit, die RC2 zu veröffentlichen. Ich> warte> aber noch bis morgen, damit die Doku in der Online-Demo noch> aktualisiert wird (habe heute noch Änderungen ins SVN hochgeladen).>> Das Archiv kann man jetzt übrigens per tools.sh, oder noch einfacher> direkt in Part-DB mit den Entwickler-Tools erstellen lassen. Das> garantiert korrekte Dateirechte, Besitzer und Gruppen aller Dateien und> Verzeichnisse. Auch werden benutzerspezifische Dateien wie die> config.php automatisch ausgeschlossen usw.>> Ich würde mich übrigens freuen wenn sich jemand am Erweitern der Doku> beteiligen würde, hier gibts noch viel zu tun :-)> Einerseits ist die FAQ-Seite noch ziemlich leer, andererseits könnte man> vielleicht die Installationsanleitung zweiteilen. Einmal für die> Installation auf einem Server mit "direktem Zugang" (auch SSH), und> einmal für die Installation auf einem Webspace per FTP. Da könnte man ja> auch Screenshots von FileZilla o.ä. mit einbauen usw.>> Damit man Schreibrechte im DokuWiki erhält, muss man im Part-DB Ordner> "data" einfach eine (leere) Datei mit dem Namen> "ENABLE-DOKUWIKI-WRITE-PERMS.txt" erstellen.>> mfg
Hallo Kami,
ich würde mich bereit erklären die Grundfunktionen unserer Part-DB zu
Beschreiben für alle Neulinge. Habe die alte Version schon auf Herz und
Nieren getestet und seit fast 1,5Jahren im täglichen
Produktionseinsatz...
Jetzt muss ich meine 0.3.0 erstmal fertig updaten. kann mir keiner
weiterhelfen? ich hänge aktuell immernoch im Installscript fest bei der
Sprach- und Ländereinstellung. Ich denke die Datenbank ist bei diesem
Schritt schon geupdatet und ich habe die Befürchtung wenn ich die alte
Version wieder zurückspiele mir da noch mehr Probleme entstehen.
abcdef schrieb:> @kirkdis:> Ich glaube, Du musst auf Deinem Webserver das Locale de_DE installieren.
das ist ne Synology DS107. Ich vermute jetzt auf der Kommandozeile von
dem Linux. Wobei das dann etwas frickelig wird. Kann man das nicht
umgehen? Bei den alten Versionen gabs das Problem nicht.
Den UTF-8 Zeichensatz kann ich leider nicht so einfach integrieren.
Erstmal ist die Box offline und ich habe auch nicht so einfach die
Möglichkeit mit dieser online zu gehen. Auf einem anderen Rechner
herunterladen ist nicht so einfach möglich zumal ich nicht ganz firm mit
der Kommandozeile unter Linux bin. Warum wird das nun in der neuesten
Version abgefragt. Die Datenbank läuft und lief bis jetzt mit
UTF8_gerneral_ci Einstellungen.
Hallo,
Sorry bin grad in den Ferien und komme nur schlecht ins Internet...
Kannst du noch bis nächsten Donnerstag warten? :-)
Weiter oben hier im Thread hatte schonmal jemand das gleiche Problem,
schau mal was ich ihm geschrieben habe, war ein Eintrag in der
config_defaults.php um das Problem vorübergehend zu beheben.
tut mir leid, muss jetzt wieder weiter :-)
Grüsse Urban
Also ich hab mir jetzt mal den Post von dir rausgesucht:
Beitrag "Re: Lagerverwaltung Part-DB V0.2.2"
allerdings unterscheiden sich diese Zeilen von der RC1 zur RC2. ich habe
jetzt ein wenig rumgespielt aber leider keine Lösung bekommen um durch
die Sprachabfrage durchzukommen.
falls mir niemand anderes weiterhelfen kann werde ich wohl bis
Donnerstag warten müssen.
Schönes Wochenende allen..
Gruß
Daniel
Hi, bin nun auf rev 674 mit debian und läuft super. Nur zur Info. ;)
Meine Wünsch wäre es herausfinden zu können welches das letzte
veränderte Bauteil ist, bzw das letzt hinzugefügte.
Ist sowas vielleicht schon irgendwo mit eingebaut?
Danke viiielmals für das tolle Skript.
Grüße Christopher
Welches das jüngste Bauteil ist kann man anhand der ArtikelID sehen.
aber eine suche direkt gibts soweit ich weiss nicht.
Wenn das nicht allzuoft benötigt wird kann man den Umweg über die
Datenbank gehen. Die ID sollte da in einer separaten Spalte aufgelistet
sein ich denke sogar dass ein Änderungsdatum dort hinterlegt ist aber
100% sicher bin ich mir beim Datum nicht.
Gruß Daniel
Datum ist nicht vorhanden, aber das geht über die ID da die Fortlaufend
sind, könte man der Statistik nochmal hinzufügen leider komme ich immer
noch nicht mit dem Template System klar aber, ich schaue mal ob ich das
hinbekomme.
Man könnte ein Log einbauen, dass Einfügen und Änderung von Einträgen
mitschreibt. So könnte man auch nicht mehr verwendete Bestände aufspüren
und eventuell aus dem Lager entfernen/entsorgen. Platz hat man ja
bekanntlich fast so wenig wie Geld ;-)
Edit: Ich kann mir das ja mal anschauen, ob ich so eine Funktion
hinbekomme.
Hi, Es ist ja das "added date" und "modified date" in der Datenbank
vorhanden bei den parts. Soweit war ich schon. ;)... Leider hab ich die
functionen nicht finden können welche so ähnlich sind. Hätte mich selbst
dran versucht. Ist aber fast schon zu hoch für mich.
Es geht mit "mir" darum... Wir befüllen zu dritt die partdb. Und es gibt
zb bei einem Stecker eine Änderung des Datenblattes oder des
Bestellnummer. Nun würde ich gerne am Freitag wissen was sich über die
Woche verändert hat.
Hoffe ihr könnt euch vorstellen was ich in etwa damit bezwecken will.
Dankeschön, Grüße aus Wien
Chris
So, bin wieder zurück :-)
kirkdis schrieb:> habe mich heute mal rüber gemacht meine 0.2.2 SVN 512 mit der neuen RC2> upzudaten.> allerdings habe ich jetzt auch das Problem mit der fehlenden Sprache.> Geht es da um die Sprache von der Datenbank?
Nein, das hat nichts mit der Datenbank zu tun. Man stellt das Land und
die Sprache ein, damit z.B. automatisch die richtige Währung in der
richtigen Formatierung angezeigt wird. Part-DB muss dazu dem
Server-Betriebssystem mitteilen, welche Sprache man verwenden möchte.
Stellt das Betriebssystem die gewünschte Sprache nicht zur Verfügung,
kommt es zu einer Fehlermeldung.
Laut diversen Berichten im Internet haben die Synology NAS anscheinend
standardmässig kein UTF-8 Zeichensatz installiert. Ob das wirklich ein
Problem darstellt, bin ich mir aber grad nicht sicher, muss mir das
erstmal genauer anschauen.
Mach doch bitte mal den folgenden Test:
In der Datei lib/lib.start_session.php die gesamte Funktion
own_setlocale() ausklammern und durch diese hier ersetzen:
1
function own_setlocale($category, $locale)
2
{
3
return (setlocale($category, "de_DE") !== false);
4
}
kommt so die Fehlermeldung immernoch?
Bezüglich dem Log:
Also erstens habe ich bei der Tabelle "parts" die Spalten
"datetime_added" und "last_modified" hinzugefügt. Es gibt aber in
Part-DB noch keine Möglichkeit, diese Angaben irgendwie zu nutzen.
Und zweitens ist es schon lange geplant, ein Log mit einzubauen, der
jede Änderung aufzeichnet. Dazu existiert bereits die Klasse "Log", die
auch schon in alle anderen Klassen mit eingebaut wurde. Es ist also
alles schon vorbereitet.
@Christopher
Also wenn du auch Änderungen an Datenblättern usw. sehen willst, geht
das (noch) nicht mit der Tabellenspalte "last_modified", weil dieses
Feld nicht aktualisiert wird wenn du ein Datenblatt hinzufügst o.ä.
Das wird aber noch geändert, so dass wirklich jede Änderung an einem
Bauteil das "last_modified" aktualisiert.
Würde es dir genügen, wenn du nur sehen würdest, welche Bauteile sich
verändert haben, oder musst du auch wissen was sich daran verändert
hat?
Ersteres wäre keine grosse Sache, das könnte man relativ einfach
realisieren. Zweiteres ist dann aber ein Fall für die Log-Klasse, das
gibt noch sehr sehr viel Arbeit.
mfg
Hi Urban.
Hab ich mir doch gedacht das sowas kommen wird. Seit ja erst bei v.0.3.0
- Nun also... mir persönlich würde es ausreichen das Bauteil zu sehen
welches sich verändert hat. (Inhaltlich muss "Ich" es dann mit meinen
Cad-Zeichnungen abgleichen und zb die Bestellnummer in der Zeichnung
gegen die neue ersetzen.)
Ich denke vorerst ist nicht relevant was sich verändert hat. So viele
Variablen sind es dann auch nicht. Das würde ich dann schon
herausfinden. Hatte ich auch so bei meiner alten db. Also "einfach" eine
normale Sortierfunktion....sozusagen. (Verändertes oder Neues Bauteil
von oben nach unten sortiert.)
- Natürlich wäre es genial auf einen Blick sehen zu können wer was und
wann verändert hat. Aber soweit mag ich noch nicht denken, weil das
wer gibts es ja noch nicht.. ;)
- Das "last_modified" noch nicht bei Dateblätter aktualisiert wird ist
mir noch gar nicht aufgefallen. Gut zu wissen. g
DANKE
Grüße aus Wien
Also ich habe den Code jetzt noch so angepasst, dass das "last_modified"
auch bei Änderungen an Einkaufsinformationen, Preisinformationen und
Dateianhängen aktualisiert wird. Ist dann im nächsten Release also mit
drin.
@Christopher
Damit du die letzten Änderungen möglichst schnell in phpMyAdmin anzeigen
kannst, gibt es folgende Möglichkeit:
Datenbank wählen --> Tabelle "parts" wählen --> Reiter "SQL" wählen.
Dort als Befehl folgendes eingeben:
1
SELECT id, name, description, last_modified
2
FROM `parts`
3
WHERE last_modified >= '/*[VARIABLE]*/'
4
ORDER BY last_modified DESC
Dann bei "SQL-Abfrage speichern:" irgend einen Namen eingeben und auf
"OK" klicken. Die Abfrage ist jetzt gespeichert, mit einem Platzhalter
für das Datum, und kann jederzeit wieder abgerufen werden.
Zum Abrufen gehst du so vor:
Wieder den Reiter "SQL" wählen und dann unten bei "Gespeicherte
SQL-Abfrage" die eben erstellte Abfrage wählen. Dann bei "Variable" das
Datum/Uhrzeit in dieser Form eingeben: "2013-07-01 00:00:00" (ohne "").
Auf "OK" klicken und es werden alle Bauteile aufgelistet, die nach dem
eingegebenen Datum verändert wurden.
mfg
Hallo Urban,
also habe den setlocale code wie beschrieben eingefügt. Der Fehler ist
aber nach wie vor aktuell.
hmm gibts dafür einen Workaround und warum ist das jetzt mit der neuen
Version plötzlich nötig. Die alte 021 hat es anscheinend nicht
interessiert welche Spracheinstellung verwendet werden.
kirk disen schrieb:> also habe den setlocale code wie beschrieben eingefügt. Der Fehler ist> aber nach wie vor aktuell.
hmm okay dein NAS hat wohl keine Sprachen installiert, die man mit
setlocale() nutzen kann.
aus http://forum.synology.com/enu/viewtopic.php?t=4232:
> There are no locales on the DS' system, so only the default "C" locale works.kirk disen schrieb:> hmm gibts dafür einen Workaround und warum ist das jetzt mit der neuen> Version plötzlich nötig. Die alte 021 hat es anscheinend nicht> interessiert welche Spracheinstellung verwendet werden.
Vorher war Part-DB eigentlich auch nur für die Verwendung in Deutschland
vorgesehen. Mit der Funktion setlocale() ist Part-DB aber auch in
anderen Ländern nutzbar, weil alle länderspezifischen Parameter direkt
vom Betriebssystem geholt werden können.
Zum Beispiel gibt es Länder, bei denen die Währung vor dem Betrag steht,
und Länder, bei denen zuerst der Betrag und dann die Währung geschrieben
wird. Dann gibt es Länder, bei denen der Punkt als Dezimalpunkt genommen
wird, bei anderen Ländern ist es das Komma. Oder auch das Datumsformat
ist je nach Land sehr unterschiedlich.
Dank der setlocale() Funktion müssen wir Entwickler uns nicht um solche
Sachen kümmern. Wir teilen einfach dem Betriebssystem mit, dass wir z.B.
"Deutsch (Deutschland)" oder "Englisch (USA)" nutzen möchten, und das
Betriebssystem liefert uns die Währungen und Datumsangaben direkt in der
jeweils lokalen Schreibweise.
Dass es aber so häufig zu Problemen kommt wegen dem setlocale() habe ich
natürlich nicht geahnt. Bei "normalen" Linux-Servern sollte es
eigentlich immer funktionieren. Bei Windows weiss man nicht so recht
welche Länderbezeichnung man nehmen muss, das ist sehr mühsam. Und jetzt
erfahre ich von dir, dass es wohl auf den Synology NAS gar keine locales
gibt...
Man könnte sich natürlich schon überlegen, all die Länderspezifischen
Parameter in Part-DB zu hinterlegen, z.B. für jedes Land eine Datei in
dem die Parameter aufgelistet sind. Das gibt zwar Arbeit, allerdings ist
man diesbezüglich nicht mehr vom Betriebssystem abhängig.
Vielleicht hat ja irgendwer bereits Erfahrung mit diesem Thema und kann
uns ein paar Tipps geben?
@ kirk disen
Da anscheinend der Ländercode "C" auf deinem NAS vorhanden sein sollte,
versuch doch mal diese own_setlocale():
ok Danke erstmal, mit dem letzten script der set locale hat es jetzt
geklappt die Setuproutine zu beenden. Allerdings kommt jetzt danach
nichts mehr, der Browser bleibt weiss ohne Fehlermeldung.
Zum glück kann ich das neben der alten 512er SVN betreiben, so ist das
System noch zugänglich auch wenn die neue 0.3.0 RC2 noch nicht
funktioniert.
kirk disen schrieb:> Allerdings kommt jetzt danach> nichts mehr, der Browser bleibt weiss ohne Fehlermeldung.
PHP >= 5.3 ist vorhanden, oder?
Dann könntest du mal die Seite http://server/part-db/system_debug.php
aufrufen um das Debugging zu aktivieren. Danach nochmal die Startseite
von Part-DB aufrufen und schauen was kommt. Durch das Debuggen sollten
die PHP Fehlermeldungen angezeigt werden, vorher wurden die unterdrückt,
deshalb die weisse Seite.
er fragt mich nun nach dem administrator passwort. Ich glaube das hatte
ich beim setup wohl vergessen einzugeben, kann ich das setup nochmals
aufrufen um dieses erneut einzugeben?
Das Administratorpasswort kann man eigentlich gar nicht vergessen
einzugeben, ohne dieses kann die Installation nicht fortgesetzt werden
;-)
Du kannst aber einfach die Datei "config.php" im Verzeichnis "data"
löschen, dann kommt der Installer wieder.
also habe gerade die config erneut ausgeführt, Admin pass neu gesetzt
Datenbank aktualisiert.
Danach aufs part-db und erneut White Screen.
Anschliessend das debugging aktiviert und in nem neuen Tab wieder die
Seite aufgerufen.
Debugging zeigt mir nichts an. Sehr komisch das ganze...
Irgendetwas läuft da schief.
Bei aktiviertem Debugging ist die Hauptseite immernoch weiss?
Keine PHP Fehlermeldungen zu sehen?
Dass im Debug-Log keine Fehler auftauchen, ist klar. Dort tauchen nur
Part-DB interne Fehler auf, keine PHP Fehler.
Vielleicht musst du bei deinem NAS erst irgendwas konfigurieren, damit
PHP die Fehlermeldungen ausgibt. Ich kenne die Synology NAS überhaupt
nicht, gibts da ein Webinterface bei dem man PHP konfigurieren, und
evtl. auch gleich die PHP Logs anschauen kann?
Normalerweise sollte das eigentlich nicht notwendig sein, da Part-DB
versucht, die PHP Fehlermeldungen selber zu aktivieren. Nur vielleicht
klappt das ja auf dem NAS nicht, keine Ahnung...
Übrigens, schonmal das NAS neu gestartet? Als ich noch intensiv an
Part-DB 0.3.0 programmiert habe, hat mein Server manchmal auch ganz
komische Sachen gemacht, ein Neustart (mindestens von Apache) hat ihn
dann jeweils wieder zur Vernunft gebracht ;-)
@kirk disen
Gibts Neuigkeiten bezüglich deinem Problem?
Wäre schon nicht schlecht wenn wird das Problem beheben könnten, es gibt
sicher noch andere Leute die Part-DB auf einem NAS installieren möchten.
@Alle
Da hier im Forum seit der RC2 praktisch keine Bugs mehr gemeldet wurden,
könnte man daher schon bald mal daran denken, die finale 0.3.0
rauszubringen. Ich habe in letzter Zeit noch ein paar kleinere Bugs
behoben die ich beim "rumspielen" gefunden habe. Leider brauche ich
persönlich Part-DB zur Zeit aber praktisch nicht, da ich grad keine
Elektronikprojekte am laufen habe.
Gibt es schon jemand der die RC2 im produktiven Einsatz hat und
berichten kann wie es läuft?
mfg
Hallo zusammen,
ich hab mir heute Part-db Version 0.3.0 RC2 auf einem Windows Server2008
(IIS 6) installiert und musste dabei folgendes anpassen:
Fehler auf jeder Seite:
1
PHP Notice: Undefined index: DOCUMENT_ROOT in C:\Inetpub\vhosts\orange-showtechnik.de\partdb\start_session.php on line 143 PHP Warning: mb_strpos(): Empty delimiter in C:\Inetpub\vhosts\orange-showtechnik.de\partdb\start_session.php on line 150
Lösung:
Unter Windows / IIS gibt es wohl die Variable DOCUMENT_ROOT nicht und
muss händisch nachgepflegt werden. In die start_session.php muss man
folgendes einfügen:
PHP Warning: implode(): Invalid arguments passed in C:\Inetpub\vhosts\orange-showtechnik.de\partdb\lib\lib.functions.php on line 129 PHP Warning: implode(): Invalid arguments passed in C:\Inetpub\vhosts\orange-showtechnik.de\partdb\lib\lib.functions.php on line 129 PHP Warning: implode(): Invalid arguments passed in C:\Inetpub\vhosts\orange-showtechnik.de\partdb\lib\lib.functions.php on line 129
Lösung:
Der Rückgabewert $value in der lib.functions.php muss als Array
deklariert werden:
Außerdem funktioniert bei mir die Anzeige des Artikelpreises nicht
korrekt, der Wert wird zwar gespeichert aber in der Übersicht und beim
Bestellen wird er nicht angezeigt.
Gruß Bernhard
Kurze Anmerkung noch für Mouser Besteller:
Beim abscannen der Mousertütchen tritt das Problem auf dass Bindestriche
gefolgt von Leerzeichen (also "- ") durch ein ß ersetzt werden.
Sprich aus 863- LM317MBDTRKG wird 863ßLM317MBDTRKG.
Dazu hab ich in der "edit_part_info.php" in Zeile 234 und 250 folgendes
eingefügt:
$new_supplierpartnr = str_replace("ß", "- ", $new_supplierpartnr);
Nun können Mousertütchen munter abgescannt werden :)
Gruß
Bernhard
Es sieht mir eher danach aus, als ob der Barcodescanner falsch
eingestellt ist. Einige der Codes sind verwandt, manche Codes oder
Varianten kennen kein Leerzeichen. Da ich nur im Büro auf einen
Barcodescanner zurückgreifen kann, kann ich leider dir nicht sagen,
welchen Code Mouser selbst verwendet.
Udo Neist schrieb:> Es sieht mir eher danach aus, als ob der Barcodescanner falsch> eingestellt ist. Einige der Codes sind verwandt, manche Codes oder> Varianten kennen kein Leerzeichen. Da ich nur im Büro auf einen> Barcodescanner zurückgreifen kann, kann ich leider dir nicht sagen,> welchen Code Mouser selbst verwendet.
Leider ist es ein ganz einfacher Scanner (CipherLAB 1000) zu dem es auch
keine Software oder Konfigurationseinstellungen gibt. Von dem her war
das jetzt für mich der einfachste Weg zum Ziel zu kommen. Eventuell
stehen andere User vor einem ähnlichen Problem und können sich durch die
zwei Zeilen Code einiges an Arbeit ersparen.
Deine zwei obrigen Codeschnipsel funktionieren bei mir übrigens leider
nicht :(
Eventuell müsste man für die Barcodescanner eine Korrekturfunktion
einbauen, die fehlerhafte Scans korrigiert. Vielleicht eine
produktbezogene Library, die eine entsprechende Funktion enthält.
Immer die leidigen Windows-Probleme... ;-)
@Borsty Bürste
Kannst du mal die angehängte start_session.php ausprobieren?
Bezüglich Barcode:
Momentan werden Barcodes ja noch gar nicht offiziell unterstützt von
Part-DB. Aber das kommt natürlich noch, K.J. hat ja schon damit
begonnen.
Was ich eigentlich sagen möchte: Das Feld für die Bestellnummer ist
dafür vermutlich nicht ideal - ich denke mal, es kann durchaus mal
Barcodes geben, die nicht mit der Bestellnummer übereinstimmen (?)
Ein zusätzliches Feld, extra für den Barcode, würde die ganze Sache
flexibler machen. Theoretisch ist dann auch das Problem mit fehlerhaften
Zeichen kein wirkliches Problem mehr, ob der Barcode nun ein falsches
Zeichen enthält ist völlig irrelevant, da es für den Menschen gar nicht
lesbar sein muss.
Diesen Barcode müsste man dann natürlich so wie die Bestellnummern, für
jede Einkaufsinformation (Klasse "Orderdetails") separat zuweisen
können.
Ausserdem wäre vermutlich ein zusätzliches Feld für einen Barcode
sinnvoll, welcher für ein ganzes Bauteil gültig ist. Damit kann man dann
persönliche Beschriftungen realisieren, also die Bauteile im eigenen
Lager mit eigenen Barcodes versehen.
mfg
Urban B. schrieb:> Ausserdem wäre vermutlich ein zusätzliches Feld für einen Barcode> sinnvoll, welcher für ein ganzes Bauteil gültig ist.
Man kann auch einen Artikel bei mehren Händlern bestellen, von daher
müsste es bei den Preisen oder zumindest Händlerabhängig gespeichert
sein.
Gerald *. schrieb:> Urban B. schrieb:>> Ausserdem wäre vermutlich ein zusätzliches Feld für einen Barcode>> sinnvoll, welcher für ein ganzes Bauteil gültig ist.>> Man kann auch einen Artikel bei mehren Händlern bestellen, von daher> müsste es bei den Preisen oder zumindest Händlerabhängig gespeichert> sein.
Ja, man beachte das Wort "zusätzlich" in meinem Satz :-)
Also für jede Einkaufsinformation einen Barcode, und zusätzlich für den
Artikel an sich einen Barcode.
Erstere(r) wird/werden verwendet um ein geliefertes Bauteil zu
identifizieren/einzubuchen. Zweiteres wird verwendet, um ein Bauteil aus
dem Lager zu identifizieren/abzubuchen (sofern man die eigenen Bauteile
mit eigenen Barcodes versehen möchte).
Aber alles zu seiner Zeit :-)
Urban B. schrieb:> Immer die leidigen Windows-Probleme... ;-)
Ja echt furchtbar, ich fands ja schon schrecklich im IIS PHP zum laufen
zu bekommen... als würde man das nicht brauchen... oO Naja aber der
Webserver ist nun mal da und somit verwend ich ihn auch.
> @Borsty Bürste> Kannst du mal die angehängte start_session.php ausprobieren?
Jop soeben probiert und funktioniert :)
Was ich übrigens etwas (furchtbar) umständlich finde ist die Zuweisung
der Footprints, sonst scheint das Tool echt einen ganz brauchbaren
Eindruck zu machen. Weiter so!
Vorallem ist es schön dass man auch mal selbst was anpassen kann. Bei
welchem Tool geht das denn heute noch so einfach?
Ist es eigentlich möglich die Bauteile je Kategorie unterschiedlich zu
sortieren?
Ich finde es vorallem bei den Widerständen etwas umständlich dass diese
nicht nach Zahlenwerten sortiert werden. Bei IC's mag das ja sinn machen
aber bei vielen Widerständen wird das schnell sehr unübersichtlich.
Sprich 220 Ohm sollte z.b. nach 39 Ohm kommen, da größer. Ich habs auch
schon probiert das Ohm wegzulassen und in der Spalte Name nur mit
Zahlenwerten zu arbeiten. Funktioniert leider auch nicht.
Wie lösen das andere?
abcdef schrieb:> Wann kommt endlich die Version 0.3.0?
Wenn sie fertig ist :-)
Aber du kannst ja die RC2 davon schonmal benutzen...
Borsty Bürste schrieb:>> @Borsty Bürste>> Kannst du mal die angehängte start_session.php ausprobieren?>> Jop soeben probiert und funktioniert :)
OK ich lads dann noch ins SVN, ebenso wie die Änderung in
money_format().
Borsty Bürste schrieb:> Was ich übrigens etwas (furchtbar) umständlich finde ist die Zuweisung> der Footprints
Jup, da stimme ich dir zu, das ist im Moment leider relativ mühsam.
Geplant ist halt, dass man die Bilddatei mit dem neuen Dateimanager von
Udo wählen kann, doch der ist noch nicht fertig.
> sonst scheint das Tool echt einen ganz brauchbaren> Eindruck zu machen. Weiter so!
Danke :-)
Borsty Bürste schrieb:> Ist es eigentlich möglich die Bauteile je Kategorie unterschiedlich zu> sortieren?
Nein, das ist zur Zeit nicht möglich.
Borsty Bürste schrieb:> Sprich 220 Ohm sollte z.b. nach 39 Ohm kommen, da größer. Ich habs auch> schon probiert das Ohm wegzulassen und in der Spalte Name nur mit> Zahlenwerten zu arbeiten. Funktioniert leider auch nicht.
Naja, das System erkennt natürlich nicht dass alle Bauteile in der
angezeigten Kategorie Zahlen als Namen haben. Und dass "1 MOhm" grösser
als "100 Ohm" ist, das merkt das System natürlich erst recht nicht ;-)
Urban B. schrieb:> Borsty Bürste schrieb:>> Was ich übrigens etwas (furchtbar) umständlich finde ist die Zuweisung>> der Footprints> Jup, da stimme ich dir zu, das ist im Moment leider relativ mühsam.> Geplant ist halt, dass man die Bilddatei mit dem neuen Dateimanager von> Udo wählen kann, doch der ist noch nicht fertig.
Das hängt immer noch an dem blöden Uploader für einige Browser :( Flash
will ich ja nicht einsetzen, so wird das für IE bis 10 und ein paar
andere bei Einzeluploads bleiben. FF und Chrome sind da deutlich besser.
Ansonsten ist der (Web-)Dateimanager nutzbar.
Leider muss ich nochmal mit einer "Kleinigkeit" kommen.
Ich bin grad am einpflegen meiner ganzen Artikel und jetzt ist mir
aufgefallen dass wenn ich ein Tütchen mit 5 x Widerstand 33 Ohm 0603
samt Einkaufsinformationen einpflege und darauf hin ein weiteres Tütchen
mit den selben Widerständen und den selben Einkaufsinformationen
eintrage mir part-db die Einkaufsinformationen vom ersten verwirft.
Sprich ich hab dann zwei mal Widerstand 33 Ohm 0603 mit je 5 Stück aber
nur einen Eintrag mit den Einkaufsinformationen.
Hier wäre es verdammt wichtig dass part-db die Einkaufsinformationen
prüft und bei dem selben Lieferanten die Stückzahl addiert und bei
unterschiedlichen Lieferanten den neuen mit der neuen Stückzahl
hinzufügt.
Beispiel:
Ich trage 4 x Attiny23 von Conrad mit Bestellnummer 423452 ein und eine
Woche später entscheid ich mich die Teile bei Mouser zu bestellen also
trag ich 6 x Attiny23 mit Bestellnummer von Mouser ein. Jetzt müsste es
einen einzigen Eintrag Attiny23 geben Stückzahl 10 und unter
Einkaufsinformationen stehen Conrad und Mouser.
So wie es jetzt ist kann es zu einem Katastrophalen Durcheinander führen
(siehe Anhang)... Ich muss jetzt nämlich nochmal alle Teile durchsehen
und prüfen wieviele 33 Ohm von welchen Lieferanten kamen und welche
davon obsolete sind.
Wie auf dem Screenshot zu sehen funktioniert wohl auch die Sortierung
nicht so wie sie sollte.
Borsty Bürste schrieb:> Ich bin grad am einpflegen meiner ganzen Artikel und jetzt ist mir> aufgefallen dass wenn ich ein Tütchen mit 5 x Widerstand 33 Ohm 0603> samt Einkaufsinformationen einpflege und darauf hin ein weiteres Tütchen> mit den selben Widerständen und den selben Einkaufsinformationen> eintrage mir part-db die Einkaufsinformationen vom ersten verwirft.>> Sprich ich hab dann zwei mal Widerstand 33 Ohm 0603 mit je 5 Stück aber> nur einen Eintrag mit den Einkaufsinformationen.>> Hier wäre es verdammt wichtig dass part-db die Einkaufsinformationen> prüft und bei dem selben Lieferanten die Stückzahl addiert und bei> unterschiedlichen Lieferanten den neuen mit der neuen Stückzahl> hinzufügt.
Moment mal - Ich bin mir nicht sicher ob ich das richtig verstanden
habe.
Also Schritt für Schritt:
Borsty Bürste schrieb:> wenn ich ein Tütchen mit 5 x Widerstand 33 Ohm 0603> samt Einkaufsinformationen einpflege und darauf hin ein weiteres Tütchen> mit den selben Widerständen und den selben Einkaufsinformationen> eintrage
Du legst also für jedes Tütchen einen separaten Artikel an? Wozu das?
Alle 10 Widerstände sind doch genau die selben, also brauchts dafür nur
einen Artikel in der Datenbank, mit der Menge 10Stk.
Borsty Bürste schrieb:> mir part-db die Einkaufsinformationen vom ersten verwirft.
Das kann ich nicht nachvollziehen. Kannst du das reproduzieren und mir
eine Schritt-für-Schritt Anleitung dazu geben?
Borsty Bürste schrieb:> Hier wäre es verdammt wichtig dass part-db die Einkaufsinformationen> prüft und bei dem selben Lieferanten die Stückzahl addiert und bei> unterschiedlichen Lieferanten den neuen mit der neuen Stückzahl> hinzufügt.
Auch hier verstehe ich dich nicht. Stückzahl und Lieferant sind zwei
völlig verschiedene Dinge. Ob in deinem Lager der selbe Widerstand von
sieben verschiedenen Herstellern stammt, ist völlig irrelevant. Wichtig
ist nur zu wissen, wieviel Stück du insgesamt an Lager hast. Woher die
kommen ist egal, schliesslich sind alle Widerstände identisch, auch wenn
sie von verschiedenen Lieferanten kommen.
Die Angabe der Lieferanten und Bestellnummern und Preise dient nur dazu,
dass man sich merkt wo man das Bauteil zu welchem Preis bekommt.
Borsty Bürste schrieb:> Ich trage 4 x Attiny23 von Conrad mit Bestellnummer 423452 ein und eine> Woche später entscheid ich mich die Teile bei Mouser zu bestellen also> trag ich 6 x Attiny23 mit Bestellnummer von Mouser ein.
Nein, du fügst dem alten Bauteil einfach eine neue Einkaufsinformation
für die Bestellung bei Mouser hinzu, und erhöhst den Lagerbestand des
ATTiny's um 6. Ergebnis: Einen Artikel "ATTiny" mit Lagerbestand "6" und
den zwei Einkaufsinformationen für Conrad und Mouser.
Borsty Bürste schrieb:> Wie auf dem Screenshot zu sehen funktioniert wohl auch die Sortierung> nicht so wie sie sollte.
Naja...er sortiert nach Name, und das ist ja korrekt :-) Aber ich füge
noch hinzu dass bei identischem Namen auch die Beschreibung zur
Sortierung benutzt wird.
Also:
Wenn ich dich richtig verstanden habe, hast du Part-DB falsch
verstanden ;-)
Oh ok anscheinend hab ich mich tatsächlich etwas wirr ausgedrückt -
bitte entschuldige!
Ich möchte natürlich nicht für jedes Tütchen einen eigenen Artikel
anlegen. Selbstverständlich soll part-db alle gleichen Artikel des
selben Herstellers zusammenwürfeln, ganz egal wo ich die gekauft habe.
Soweit schon klar :)
ABER: Wenn ich dussel nicht merk dass es diesen Artikel ja schon gibt
(was bei so vielen durchaus mal vorkommen kann) und ich leg den Artikel
nochmal an, mit den selben Einkaufsinformationen und dem selben
Hersteller wäre es schön wenn part-db meckern würde "Vorsicht den selben
Artikel von dem selben Hersteller hab ich doch schon!".
Aktuell ist es so dass er den Artikel nochmal anlegt und ich dann zwei
gleiche Artikel mit den gleichen Daten in der Datenbank habe. Genau das
soll ja nicht passieren ;-)
Entweder part-db merkt dass es den Artikel gibt und fügt die zwei gleich
zusammen oder es kommt einfach eine Fehlermeldung und lässt die Aktion
nicht zu. Bei letzterem hab ich dann die Möglichkeit den schon
vorhandenen Artikel zu finden und zu aktualisieren.
Ich denke das ist nun etwas verständlicher :)
Ach so, ja jetzt verstehe ich dich :-)
Grundsätzlich würde ich ja sagen, es ist Sache des Anwenders erstmal zu
schauen obs den entsprechenden Artikel schon gibt. Aber einen dezenten
Hinweis, dass es bereits einen Artikel mit dem selben Namen, selben
Hersteller und selben Footprint gibt, wäre sicher machbar und sinnvoll.
Aber wirklich nur wenn Name, Hersteller und Footprint exakt identisch
sind, sonst gibts ständig Fehlalarme wenn man ein ähnliches Bauteil wie
ein bereits existierendes anlegt, das nervt dann nur.
Ich nehme das einfach mal in die ToDo-Liste auf.
So langsam nimmt Part-DB richtig gute Konturen an :-) Auf solche
Kleinigkeiten kommen wir Entwickler auch nicht immer. Da ist es gut,
dass es auch engagierte Tester gibt, die uns ein Feedback geben.
Daumen hoch
Ich arbeite ja nun seit einigen Tagen mit Part-DB und mittlerweile 247
verschiedene Bauteile (laut Statistik, hihi) eingepflegt.
Was noch schön wäre:
- EDIT Funktion für mehrere Bauteile gleichzeitig (auch wäre es sinnvoll
mehrere Bauteile gleichzeitig in eine andere Kategorie/Unterkategorie
verschieben zu können) Aktuell mach ich das direkt in der Datenbank mit
SQL Phrasen, im Tool selbst ist das fast nicht möglich.
- Für jedes Bauteil sollte eine Art "Zustand" auswählbar sein der frei
definiert werden kann (z.b. Neuware, ausgelötet, Pins verbogen, zum
basteln, ...). Ich stell mir das über ein DropDown Menü vor.
- Was ich persönlich etwas nervig finde ist die Tatsache dass man beim
anlegen eines neuen Bauteiles (oder beim bearbeiten) keinen weiteren
Browsertab öffnen kann. Sehr umständlich um mal eben den Preis zu
checken oder die technischen Daten.... Ich verwende dazu aktuell einen
zweiten Browser, nervt aber.
- Export Funktion aller Bauteile für die Weiterverarbeitung in
(ex-)bom.ulp. (das werde ich aber vermutlich die kommenden Tage selbst
schreiben). Somit kann man dann die Eagle Projekte direkt mit Part-db
Verknüpfen. Einfache zu realisierendes Features was part-db richtig
"mächtig" macht.
- In der Listenansicht der Bauteile wäre es schön den Hersteller zu
sehen, eventuell als neue Spalte oder dafür z.b. die Spalte Dateianhänge
weglassen.
Wie werden die Bauteile eigentlich aus der Datenbank geholt? Ich wollte
mir die Sortierung der Teile selbst noch anpassen, hab aber in der
show_categorie_parts.php nur die dazugehörigen $REQUESTS gefunden,
jedoch nirgends einen Select aus der DB.
Ich hoffe das war nicht zuviel auf einmal xD
Gruß
Bernhard
@K.J.
Ich habe mal den RSS-Feed Parser auf der Startseite umgeschrieben, weil
vorher ja die Links nicht funktioniert haben. Allerdings funktioniert
das in der Online Demo nicht, es kommt nur eine weisse Seite. Könntest
du mal das Debugging aktivieren, damit hoffentlich ein paar nützliche
Fehlermeldungen angezeigt werden?
Borsty Bürste schrieb:> - EDIT Funktion für mehrere Bauteile gleichzeitig (auch wäre es sinnvoll> mehrere Bauteile gleichzeitig in eine andere Kategorie/Unterkategorie> verschieben zu können) Aktuell mach ich das direkt in der Datenbank mit> SQL Phrasen, im Tool selbst ist das fast nicht möglich.
Jo das wäre sicherlich nützlich, gibt aber sehr viel Arbeit ;-)
Wird also sicher noch länger dauern bis so eine Funktion kommt...
Borsty Bürste schrieb:> - Für jedes Bauteil sollte eine Art "Zustand" auswählbar sein der frei> definiert werden kann (z.b. Neuware, ausgelötet, Pins verbogen, zum> basteln, ...). Ich stell mir das über ein DropDown Menü vor.
Sowas ist schon geplant:
https://code.google.com/p/part-db/issues/detail?id=30Borsty Bürste schrieb:> - Was ich persönlich etwas nervig finde ist die Tatsache dass man beim> anlegen eines neuen Bauteiles (oder beim bearbeiten) keinen weiteren> Browsertab öffnen kann. Sehr umständlich um mal eben den Preis zu> checken oder die technischen Daten.... Ich verwende dazu aktuell einen> zweiten Browser, nervt aber.
Also erstens könntest du in der Konfiguration die Popups auf "nicht
modal" einstellen, dann kannst du den Browser weiterhin für andere
Sachen benutzen (das Popup geht dann einfach in den Hintergrund).
Und zweitens werden die Popups irgendwann vermutlich durch eine
JavaScript Lösung abgelöst, so dass gar kein neues Browserfenster mehr
geöffnet wird.
Borsty Bürste schrieb:> - Export Funktion aller Bauteile für die Weiterverarbeitung in> (ex-)bom.ulp. (das werde ich aber vermutlich die kommenden Tage selbst> schreiben). Somit kann man dann die Eagle Projekte direkt mit Part-db> Verknüpfen. Einfache zu realisierendes Features was part-db richtig> "mächtig" macht.
Hmm ich habe noch nie mit dem bom.ulp gearbeitet, könntest du mal kurz
erklären wie das genau abläuft? Wozu brauchst du dazu die gesamte
Datenbank zu exportieren, und in welchem Format?
Das wäre eine Sache, die man sicherlich mit relativ wenig Aufwand noch
einbauen könnte. Wobei ich mich frage, wie lange so ein Export dauert
wenn man mehrere (zehn)tausend Bauteile in der DB hat...
Dass man den Output vom bom.ulp (wenn ich das richtig verstanden habe)
direkt in eine Baugruppe importieren kann, hast du gesehen oder?
Borsty Bürste schrieb:> - In der Listenansicht der Bauteile wäre es schön den Hersteller zu> sehen, eventuell als neue Spalte oder dafür z.b. die Spalte Dateianhänge> weglassen.
Füge mal die folgende Zeile in deine config.php ein und staune :-)
Borsty Bürste schrieb:> Wie werden die Bauteile eigentlich aus der Datenbank geholt? Ich wollte> mir die Sortierung der Teile selbst noch anpassen, hab aber in der> show_categorie_parts.php nur die dazugehörigen $REQUESTS gefunden,> jedoch nirgends einen Select aus der DB.
Das ist alles nicht so ganz einfach, da Part-DB jetzt objektorientiert
programmiert ist. Die Datenbankabfragen sind also hauptsächlich in den
lib/class.*.php Dateien. In der Klasse "PartsContainingDBElement" werden
für jede anzuzeigende Kategorie die darin enthaltenen Teile aus der
Datenbank geholt (Funktion "get_parts()"). Da kannst du die Sortierung
anpassen. Doch wenn die Beiteile mehrerer Kategorien geholt werden
müssen, holt wieder jede Kategorie ihre eigenen Teile, und nachher wird
per PHP alles noch sortiert (Funktion "usort_compare()"). An diesen
beiden Stellen müsstest du also die Sortierung anpassen.
Dass die Artikelbeschreibung auch zur Sortierung herangezogen wird, ist
übrigens im nächsten Release mit drin, falls du dies haben wolltest ;-)
mfg
@Urban B. mach ich zeitlich ist das immernoch etwas knap bei mir aber
spätestens am we solte ich das machen können.
Übrigens nebenbei ist zu vermelden das mittlerweile 5 große Firmen (>1k
Mitarbeiter) die Part-db nutzen, Respekt an die momentanen Entwickler
ich mach den Support für die grade nebenbei mit.
> Übrigens nebenbei ist zu vermelden das mittlerweile 5 große Firmen (>1k> Mitarbeiter) die Part-db nutzen, Respekt an die momentanen Entwickler> ich mach den Support für die grade nebenbei mit.
Um es mit FB zu sagen: Gefällt mir :-)
Wenn es mir zeitlich möglich ist, werde ich am Wochenende mal das
Problem des Uploads für ältere Browser angehen. Damit das auch endlich
mal aus meiner ToDo-Liste raus ist.
K. J. schrieb:> @Urban B. mach ich zeitlich ist das immernoch etwas knap bei mir aber> spätestens am we solte ich das machen können.
OK kein Problem, nur kein Stress :-)
Also es geht übrigens nur darum, dass du hier das Administratorpasswort
eintippst: http://www.partdb.grautier.com/svn/system_debug.php
Danach sollte man hoffentlich die Fehlermeldungen auf der Startseite
sehen.
Ich kann den Fehler bei mir (leider?) nicht nachvollziehen, hier
funktioniert es tadellos...
K. J. schrieb:> Übrigens nebenbei ist zu vermelden das mittlerweile 5 große Firmen (>1k> Mitarbeiter) die Part-db nutzen, Respekt an die momentanen Entwickler> ich mach den Support für die grade nebenbei mit.
Wow, das ist doch mal eine gute Nachricht! Vielleicht kommt dadurch ja
auch mal die ein oder andere Spende zustande ;-)
@K.J. ich habe soeben den Fehler auf der Startseite gefunden, auf dem
Webspace meines Hosters wird nämlich eine Fehlermeldung angezeigt weil
ich direkt beim Funktionsaufruf auf ein Array-Element zugegriffen habe,
also sowas wie funktion()[0]. Auf meinem Ubuntu Server frisst er das
allerdings, drum habe ich es hier nicht gemerkt... naja, brauchst jetzt
das Debugging nicht mehr zu aktivieren :-)
Hallo, bin gerade auf dieses Projekt gestossen, ich muss zugeben ich
habe nicht alle 550 Kommentare gelesen, nur mal nach grratis und Hoster
gesucht, aber nichts brauchbares gefunden. Darum meine Frage ob es bei
irgendeinen freehoster laeuft? Habe bei Tripido mal einen Account
angelegt, und die part-DB hochgeladen, dort laeuft PHP 5.3 zum laufen
habe ich es allerding nicht bekommen. Geht das bei irgendeinen free
hoster?
@Arne M.
Ob Part-DB auf einem gratis Webspace läuft, kann ich dir nicht sagen.
Aber beschreib doch, was denn bei deinem aktuellen Hoster für Probleme
auftreten (Fehlermeldungen?). (wer/was ist eigentlich "Tripido"?)
Ausserdem würde ich dir sowieso empfehlen, einen richtigen Hoster zu
benutzen. Früher habe ich meine ersten Gehversuche auch mit freehostern
gemacht, aber glaub mir, das ist es nicht wert. Die paar Kröten, die ein
Webspace mit Domain kosten, sind gut investiert. Eigene Domain, keine
Werbung, kein Spam an deine E-Mail Adresse, >99,9% Uptime, kompetenter
Support, und, und, und.
Gratis Hoster brauchen immer wieder starke Nerven und sind nicht selten
mal für ein paar Stunden offline (selbst schon mehrfach erlebt).
Manche Hoster bieten auch z.B. 30 Tage kostenloses Ausprobieren an, so
kannst du auch prüfen ob der Hoster deine Ansprüche erfüllt, ohne dass
du Geld dafür ausgibst.
mfg
EDIT: Und falls du Part-DB nur von zu Hause aus erreichen musst,
brauchst du sowieso nicht zwingend einen Hoster sondern kannst deinen
eigenen Webserver aufsetzen.
@Urban B
Danke fuer deine Antwort hatte einfach nach free hostern geschaut, die
die benoetigte PHP Version haben. Dieser hat PHP 5.3
Auf lange sicht, wenn das gut laufen sollte sollte das auf meinen
Raspberry Pi laufen. Der hat wie der Zufall es will php und mysql, aber
bis es soweit ist,(momentan fehlendes Internet zuhause) wollte ich das
mal antesten und schonmal Bauteile anlegen und dann einfach nur
umsteigen.
Vorgegangen bin ich nach der Installationsanweisung.
1 eine Datenbank erstellt
2 den part-db in den www ordner kopiert und testweise alle rechte fuer
jeden gesetzt
Beim Aufrufen der Seite MEINNAME.tipido.net/part-db kommt dann :
Internal Server Error
The server encountered an internal error or misconfiguration and was
unable to complete your request.
Andere Fehlermeldungen seh ich gerade nicht. Ansonsten kann man mit
phpMyAdmin verwalten, kann man dort noch etwas tun? Vor einen
kostenpflichtigen schreck ich immer zurueck grad weil der was kostet und
ich erstmal das fur lau hinzubekommen.
Gruss
Arne
Arne M. schrieb:> Beim Aufrufen der Seite MEINNAME.tipido.net/part-db kommt dann :> Internal Server Error
Lösche testweise mal die .htaccess Datei im Hauptverzeichnis (oder
alle). Könnte sein, dass der Server irgendwas an diesen Dateien nicht
mag.
Ausserdem hat eine kurze Recherche im Internet ergeben, dass dein
Anbieter wohl die ini_set() Funktion verboten hat. Diese wird allerdings
in der start_session.php einmal aufgerufen. Entferne diese Codezeile
einfach mal. Wobei, eigentlich sollte das kein Problem darstellen, weil
bei gesperrter ini_set() die Funktion einfach "false" zurückliefern
müsste...
Arne M. schrieb:> Vor einen kostenpflichtigen schreck ich immer zurueck grad weil der> was kostet und ich erstmal das fur lau hinzubekommen.
Jo klar kostet das was, aber für was ganz einfaches bezahlt man
schätzungsweise so um die 2 Euro im Monat, mit eigener Domain noch ~1
Euro mehr. Das kann man sogar als Schüler noch problemlos verkraften :-)
Naja, musst selber wissen, wollte nur sagen dass (meiner Meinung nach)
die paar Euros gut investiert sind... ;-)
Ich könnte dir natürlich auch free-speicher.de anbieten. Bei dem Projekt
gehöre ich zu den technischen Admins. Du musst dich allerdings beim
Betreiber melden, denn wir nehmen nicht jeden. Für Fragen steht auch ein
Forum zur Verfügung. Allerdings steht da nur PHP 5.2 zur Verfügung. Ein
Update ist derzeit nicht geplant.
Urban B.
Danke hae die .htaccess entfernt und schon lief es! Danke dir als
Sprache konnte man putzigerweise nur us englisch angeben, aber denonch
alles auf deutsch :) Scheint alles zu gehen, grad updates gemacht!
Udo Neist
Danke dir fuer das Angebot ist sehr nett, doch die Voraussetzung ist
doch PHP 5.3 :) Andererseits einen Server im Netz zu haben kann ja auch
nie verkehrt sein!
Arne M. schrieb:> Danke hae die .htaccess entfernt und schon lief es!
Wenn bei deinem Server aber das Directory Listing aktiviert ist,
solltest du es nicht so sein lassen, sonst kann jeder all deine Dateien,
die auf dem Server liegen, anschauen. Überprüfen kannst du das indem du
versuchst z.B. das Verzeichnis img im Browser aufzurufen. Wenn dort
der Zugriff verweigert wird (also eine Fehlerseite kommt) ist alles OK.
Dir ist aber schon bewusst dass jetzt jeder an deiner Datenbank
rumpfuschen kann, oder? Mit einer .htaccess lässt sich dies vermeiden,
such einfach im Internet mal nach ".htaccess Zugriffsschutz" o.ä.
(allerdings ist fraglich ob das dein Hoster überhaupt zulässt, da
anscheinend ja schon das deaktivieren des Directory Listing zu einer
Fehlermeldung führt...Ausprobieren hilft!)
> Danke dir als Sprache konnte man putzigerweise nur us englisch angeben
Das liegt daran, dass dein Server wohl keine deutschen Sprachdateien
installiert hat. Somit hast du jetzt die Preise in GBP statt in Euro. Ab
dem nächsten Release kann man dann eine neutrale Sprache auswählen (für
den Fall dass der Server die gewünschte Sprache nicht zur Verfügung
stellt), dann muss man die Währung von Hand in die config.php eintragen.
Urban B. schrieb:> z.B. das Verzeichnis img im Browser aufzurufen. Wenn dort> der Zugriff verweigert wird (also eine Fehlerseite kommt) ist alles OK.
Kam eine Fehlermeldung.
Das jeder drin rumpfuschen kann ist mir schon klar. Ein kleiner Schutz
ist ja dass man den Seitennamen kennen muss und dann auch noch den
Ordnernamen. Ob das allein schon einer findet? Aber ist ja eh dort
wahrscheinlich nur temporaer. Bei meinen eigenen sollte es schon so
sein, dass nur ich rankann! Was .htaccess macht find ich deswegen noch
raus.
Hab Dollar da stehen, aber zum nachbestellen brauch ich das glaube ich
(noch) nicht dazu bin ich zu hobbymaessig.
Auf alle Faelle ein aufwendiges Programm, bei dem man sieht das sehr
viel Arbeit drin steckt, verdient meinen Respekt. Hab keine Ahnung was
meine normalen bedrahteten Widerstaende fuer eine Bauform haben :)
Urban B. schrieb:> Somit hast du jetzt die Preise in GBP statt in Euro.Arne M. schrieb:> Hab Dollar da stehen,
Ups, ich dachte ich hätte "England" gelesen (da wo "Englisch" steht),
USA hat natürlich Dollar xD (mein Allgemeinwissen ist zwar bescheiden,
aber das weiss ich gerade noch so...)
Arne M. schrieb:> Ein kleiner Schutz ist ja dass man den Seitennamen kennen muss und> dann auch noch den Ordnernamen.
Joah wenns nicht für ewig ist, kann man das natürlich so machen... ;-)
Die robots.txt sollte auch verhindern dass die Seite mit Suchmaschinen
gefunden werden kann.
Arne M. schrieb:> Hab keine Ahnung was> meine normalen bedrahteten Widerstaende fuer eine Bauform haben :)
Die "normalgrossen" haben die Bauform "0207", die etwas kleineren
"0204".
Ich habe mich heute mal mit dem Problem des Uploads per IFrame
auseinander gesetzt. Es funktioniert schon, aber leider nur Datei für
Datei. Wählt man mehrere aus und will diese dann in einem Rutsch
übergeben, gibt Firefox ein Security Alarm auf der Javascript-Konsole
aus. Ich kann keine Duplikate für input type="file" erstellen :(. Bevor
Fragen zu jQuery oder ähnliche Frameworks kommen: der Filemanager kommt
komplett ohne externe JS-Lib aus und das soll auch so bleiben. Die
meisten dieser Frameworks sind einfach zu groß für ein kleines Projekt
mit wenig Javascript.
Ich werde die IFrame-Lösung in den Filemanager als Fallback einbauen,
falls der Browser kein FormData-Objekt kennt.
Ich habe den Popup-Modus des Filemanagers überarbeitet. Anstatt den
eingebauten Viewer zu starten, wird in diesem Modus nur die zuvor
ausgewählte und im Infobereich angezeigte Datei dem aufrufenden Fenster
übergeben.
http://phpbookworm.singollo.de/project/part-db/
Auf der Testseite ist die Navigation im Hauptverzeichnis abgeschaltet
und erlaubt es nur in bestimmten Unterverzeichnissen im Popup. Die
Angabe der erlaubten Verzeichnisse im Hauptscript wird der nächste
Schritt sein, dann kommt die Integration des Fallbacks (siehe oben).
Hallo Udo,
keine Ahnung, ob das so beabsichtigt ist: Ich kann kein Verzeichnis
auswaehlen... Siehe Anhang. Der Screenshot wurde mit Kubuntu und dem
alten Firefox 11 gemacht, ich seh das gleiche aber auch mit Windows und
dem aktuellen Firefox.
Mach ich irgendwas falsch?
Viele Gruesse
Christoph
Das Phänomen sehe ich auch. Irgendein Bug schaltet die
Verzeichnisanzeige ab. Da es gestern lief, tippe ich auf einen Fehler
bei der Initialisierung. Mach mich gleich dran, damit dieser Fehler
behoben ist.
Fehler beseitigt. Beim Start soll in der nächsten Version eine Liste von
Verzeichnissen geladen werden. Die zugehörige Ajax-Funktion war bereits
aktiv, aber konnte vom PHP-Script nicht beantwortet werden. Daher wurde
die im Template vorgebene Liste überschrieben. Ich lager das erstmal
aus, so dass diese Funktion nur per Klick auf einen Link aktiv wird.
Hi,
in der "Gleiche Seite"-Version sehe ich drei Verzeichnisse:
Hauptverzeichnis/Grafik/Import. In der Popup-Version sieht man diese
nicht.
Bei zwei der Verzeichnissen kommt "Ein Fehler ist aufgetreten:
[Funktion: file_explorer::xhrGet]" wenn man sie anklickt, und die
Dateiauswahl geht noch nicht (getestet mit Firefox11).
Viele Gruesse
Christoph
Ist auch kein Wunder. Ich hab derzeit ein Problem mit der
Tokengenerierung für die Absicherung der Aktionen. Ich geb Bescheid,
wenn das Problem beseitigt ist und der Filemanager wieder läuft.
Ich habe die Tokenproblematik gelöst. Durch das asynchrone Nachladen des
Tokens (ist eine Sessionvariable) muss ich die Anzeige des Filemanagers
um einige Millisekunden verzögern. In beiden Modi sollten jetzt zwei
Verzeichnisse angezeigt werden.
Edit: Upload kann wieder verwendet werden.
habs grade erfolgreich getestet und als File mal den Screenshot von oben
hochgeladen. Sieht echt gut aus.
Was allerdings etwas irritierend ist, ist das Upload Fenster: Man waehlt
eine Datei aus, aber der Dateiname erscheint nicht im Auswahlfeld
(stattdessen geht der Zaehler hoch). Es waere gut, wenn zusaetzlich zum
Zaehler noch eine Liste aller ausgewaehlten Filenames erscheinen wuerde.
Viele Gruesse
Das mit dem Uploader ist mir bekannt. Es ist noch ein Überbleibsel der
Tests mit den verschiedenen Browser und daher noch nicht komplett. Die
Liste kann ich wieder einbauen.
@Udo
Sieht schonmal gut aus soweit!
Funktioniert das ganze auch schon wenn die angezeigten Ordner auch noch
Unterordner haben? Wäre interessant, wenn du mal z.B. den Ordner
"img/footprints" von Part-DB zu deinem Filemanager hinzufügen würdest
:-)
@ Alle Tester von der 0.3.0 RC2
Na, wie siehts aus, kann man das finale Release der 0.3.0 rausgeben? :-)
Ich glaube, eine RC3 ist nicht unbedingt nötig. So viel hat sich seit
der RC2 nicht mehr getan...
(zumindest keine "kritischen" Sachen. Die meisten Bugfixes bezüglich
Windows Server sind bereits in die RC2 reingeflossen. Der aktuelle Stand
der Part-DB sollte nun wirklich auf den allermeisten Servern, die die
Anforderungen erfüllen, laufen, und das ist ja das wichtigste. Kleine
Bugs kanns natürlich immer haben.)
Urban B. schrieb:> @Udo> Sieht schonmal gut aus soweit!> Funktioniert das ganze auch schon wenn die angezeigten Ordner auch noch> Unterordner haben? Wäre interessant, wenn du mal z.B. den Ordner> "img/footprints" von Part-DB zu deinem Filemanager hinzufügen würdest> :-)
Unterordner werden angezeigt und sind nutzbar, bis auf die Auswahl im
Dialog. Um ins übergeordnete Verzeichnis zu kommen, muss man sich
derzeit noch über die Verzeichnisauswahl links bemühen und kann nicht
direkt zurück.
Vorläufige ToDo-Liste:
- Wechsel in das übergeordnete Verzeichnis in der Fileliste ermöglichen
- Unterordner in der Verzeichnisliste des Dialogs aufnehmen
- Fallback für den Upload integrieren
Kleine Anmerkung: Da die Verzeichnisse in der config.php des
Filemanagers definiert werden können, kann man zu jeder Aktion die
mögliche Auswahl der Verzeichnisse vorgeben. Vom aktuellen Design her
sind 5 Verzeichnisangaben sinnvoll, wobei die Klartextnamen nicht zu
lange sein sollten.
Udo Neist schrieb:> Vorläufige ToDo-Liste:> - Wechsel in das übergeordnete Verzeichnis in der Fileliste ermöglichen
Sollte jetzt einwandfrei funktionieren. Läuft im Hauptverzeichnismodus
(gedacht für Admins) genauso wie bei definierten Verzeichnissen
(Normalfall).
> - Unterordner in der Verzeichnisliste des Dialogs aufnehmen
Unterverzeichnisse werden angezeigt, allerdings fehlt noch die
Einschränkung für definierte Verzeichnisse. Aktuell wird das
Hauptverzeichnis an oberster Stelle und alle weiteren mit
vorrangestellten "../" aufgelistet. Manchmal kommt es vor, dass die
Verzeichnisliste nicht gleich zur Verfügung steht. Diese Liste wird
immer (!) neu geladen, wenn ein entsprechender Dialog aufpoppt.
Nachteilig nur bei großen Verzeichnistiefen und vielen Einträgen.
So, ich habe jetzt grad nochmal den aktuellen Stand der Part-DB auf
verschiedenen Systemen (Apache [Ubuntu], XAMPP [Win7], FF8 [Win7], FF22
[Ubuntu], IE10 [Win7], Chromium 28 [Ubuntu]) ausprobiert. Sah soweit
ganz gut aus, nur ein ganz kleiner Bugfix bezüglich dem IE habe ich noch
ins SVN hochgeladen (r686).
Von meiner Seite würde ich jetzt das OK für das Release der 0.3.0 geben.
Wenn niemand was dagegen hat, würde ich das dann vielleicht morgen oder
übermorgen hochladen.
Wenn also jetzt noch jemand die RC2 NICHT auf seinem System getestet
hat, auf dem er nachher die 0.3.0 laufen lassen möchte, wäre jetzt der
letzte Zeitpunkt um dies zu tun. Nachher kanns wieder dauern bis das
nächste Release kommt ;-)
mfg
Hallo!
Ich warte immer noch, dass mal irgendwo eine Instanz installiert wird,
die ich benutzen kann. Aber dazu müsste man mehrere Nutzer anlegen
können.
Natürlich kann ich auch selbst eine anlegen, aber für mich allein lohnt
sich das m.E. nicht.
http://code.google.com/p/part-db/issues/detail?id=8 steht seit einem
Jahr im "Status: Started". Wie sieht's denn damit aus?
VG Torsten
Hallo Torsten,
Torsten C. schrieb:> Ich warte immer noch, dass mal irgendwo eine Instanz installiert wird,> die ich benutzen kann. Aber dazu müsste man mehrere Nutzer anlegen> können.
Da muss ich dich leider enttäuschen, das wird noch sehr lange dauern bis
das wirklich fertig ist... Bis jetzt lag der Schwerpunkt halt auf der
Version 0.3.0, und da war eigentlich schon lange klar dass hier noch
keine Benutzerverwaltung reinkommt, somit hätte es keinen Sinn gemacht
jetzt schon voll an der Benutzerverwaltung zu arbeiten.
Torsten C. schrieb:> http://code.google.com/p/part-db/issues/detail?id=8 steht seit einem> Jahr im "Status: Started". Wie sieht's denn damit aus?
Als ich die Part-DB auf objektorientierte Programmierung umgeschrieben
habe, habe ich mir natürlich schonmal ein paar Gedanken über die
Benutzerverwaltung gemacht. Es gibt in Part-DB bereits jetzt die Klassen
"User" und "Group", welche fest im OOP Design verankert sind. Heisst
konkret, alle möglichen Klassen und Funktionen haben bereits eine
Referenz zum angemeldeten Benutzer zur Verfügung. Damit ist quasi der
Grundstein gelegt, jetzt müssen "nur noch" die Klassen "User" und
"Group" ausgestattet werden, und alle anderen Funktionen müssen Gebrauch
davon machen indem Sie die Rechte vom angemeldeten Benutzer abfragen und
berücksichtigen.
Der Aufwand für eine "normale" Benutzerverwaltung (Lese-/Schreibrechte)
ist ja noch einigermassen überschaubar (gibt schon sehr viel Arbeit,
vieles ist aber nicht wahnsinnig kompliziert sondern eher Fleissarbeit).
Die Benutzerverwaltung für eine öffentliche Part-DB Installation, in der
alle Benutzer zwar auf die selben Teile zugreifen, aber unterschiedliche
Lagerbestände, Lagerorte, Baugruppen usw. haben, macht die ganze
Geschichte aber extrem kompliziert. Das wird echt nicht einfach, und
wird daher auch viel Zeit benötigen...
Ausserdem sollte es mMn schlussendlich möglichst nicht zweiverschiedene Benutzerverwaltungen geben, sondern eine
Benutzerverwaltung, die halt beides kann. Heisst dann also, wenn man
einen neuen Benutzer anlegt, muss man halt wählen ob dieser Benutzer
z.B. seine eigenen Lagerorte haben sollte, oder ob es die "allgemeinen"
Lagerorte verwenden soll. Ersteres wäre für die "Online-Part-DB für
jedermann", Zweiteres wäre z.B. für eine Firma.
Ich muss Urban beipflichten, denn der Code der 0.2.x war für die
Integration einer Benutzerverwaltung einfach nicht nutzbar. Ursprünglich
war die Part-DB ja nur ein kleines Hilfsmittel für zu Hause und nicht
für größere Gruppen oder sogar Firmen gedacht. Diese Möglichkeiten kamen
dann mit der Übernahme der Entwicklung durch ein neues Team und der
0.2er Version. Hier war der Code allerdings weiterhin ein wirres
Durcheinander und nur für Insider irgendwie wart- und erweiterbar. Die
Diskussion hatten wir ja auch schon geführt, wie die Weiterentwicklung
laufen sollte. Ich bin ja mit dem Ziel der Integration der
Benutzerverwaltung dazu gekommen, habe aber schnell gemeckert, dass ich
mit dem Code so nichts anfangen kann. Ich habe testweise einige der
Templates in meinen eigenen Branch erstellt und Urban hat den Code auf
OOP umgestellt. Bei der Zusammenführung der beiden Zweige wurde dann als
Ziel die funktionsgleiche Umschreibung von Part-DB ausgegeben. Ein paar
Neuerungen kamen mittlerweile auch dazu, die allerdings nur
"geringfügige" Änderungen im Code waren. Eine Benutzerverwaltung wäre
für dieses Umschreiben ein zu großer Eingriff gewesen. Daher steht das
für die nächste Version an. Wie genau diese dann implementiert wird, das
werden wir hier sicher in der nächsten Zeit diskutieren. Zudem wird das
alte Frame-Konzept dann durch moderne Ajax-Technik abgelöst. Die
Vorarbeiten dazu habe ich mit dem neuen Filemanager bereits gestartet.
Urban B. schrieb:> Da muss ich dich leider enttäuschen, das wird noch sehr lange dauern bis> das wirklich fertig ist...
Hallo Udo, hallo Urban,
danke für die ausführliche und verständliche Antwort. Ich muss mir nun
überlegen, wie ich kurzfristig damit umgehe. Ich habe heute z.B. gerade
festgestellt, dass ich auf die Lieferung von drei ICs gar nicht warten
muss, weil ich fünf pinkompatible noch auf dem Dachboden habe. Ich hätte
die drei gar nicht bestellen müssen. :-(
VG Torsten
So, habe soeben die finale Version 0.3.0 hochgeladen:
https://code.google.com/p/part-db/downloads/detail?name=Part-DB_0.3.0.tar.gz
Viel Spass damit! ;-)
Übrigens kann ich die nächsten 4 Wochen nicht viel an der Part-DB
arbeiten, da wiedermal Semesterprüfungen sind... Hier im Forum bin ich
aber immer für Fragen erreichbar, das ist kein Problem.
mfg
Der Filemanager dürfte jetzt weitgehends fertig sein. Der Upload wird
jetzt bei allen Browsern ohne FormData-Support durch ein IFrame
bewerkstelligt. Zumindest lief der Test mit dem IE8 unter WinXP
erfolgreich. Bitte testet es aus. Bei Auftreten eines Fehlers bitte ein
Screenshot (Bildformate beachten!) anfügen, eine Kurzbeschreibung der
Aktion und Infos zum Browser angeben.
http://phpbookworm.singollo.de/project/part-db/
Grüße
Udo
Edit: Beim Upload kann die Funktion "Zum Zielverzeichnis wechseln"
zusätzliche Files anzeigen, die nicht den erlaubten Typen des
Elternverzeichnisses entsprechen. Im Moment ist die durchgängige
Weitergabe von Typen noch nicht gegeben.
Folgende Fehler konnte ich entdecken:
Opera + FF:
Nutzt man "Nach Upload ins Zielverzeichnis wechseln" so wird nach dem
Upload bei keinem Bild ein Vorschaubild geladen oder auch Dateiinfos
angezeigt(siehe Opera).
Wechselt man jedoch direkt mittels "Filemanager (gleiche Seite)" in das
Verzeichnis werden die entsprechenden Daten jedoch angezeigt(siehe
Opera2)
IE:
"Filemanager (gleiche Seite)" führt zu einer "undefined" Meldung im
rechten Anzeigebereich (siehe IE_seite)
"Filemanager (per Popup)" führt zu einem leeren PopUp (siehe IE_popup)
"Inhalt löschen" zeigt nur einen leeren rechten Anzeigebereich (siehe
IE_loeschen)
Testumgebung:
Windows Vista 32 Bit
Opera 12.15
Firefox 22.0
Internet Explorer 9
Ich hatte heute endlich mal Zeit, die neue Version der part-db zu
installieren, nachdem die Alte doch etwas in die Jahre gekommen ist.
Leider ist die Installation auf Debian einfach nur zusammengewürfelter
Mist. Nach nun 3 Stunden und unendlichen
rm -rf part-db
su root
tar xfv Part.tar.gz
ist es mir nicht gelungen, die Abfrage der Dateirechte zu überwinden.
Bei mir läuft ein Confixx, so dass der Benutzer nicht zwangsläufig
www-data ist. Die Gruppe auf www-data zu belassen und den Benutzer
-nicht rekursiv- auf web0 zu setzen hat zumindest die Pfade der
Dokumentation aus der roten Liste verschwinden lassen, aber die Parts
sind hartnäckig.
Ich habe im Laufe der Zeit sicher mehr als 100 verschiedene
Web-Applikationen zum Laufen gebracht, aber so ein widerspenstiges Zeug
ist mir noch nicht untergekommen ...
Schade - hatte mich sehr darauf gefreut !
Gerald *. schrieb:> Folgende Fehler konnte ich entdecken:>> Opera + FF:> Nutzt man "Nach Upload ins Zielverzeichnis wechseln" so wird nach dem> Upload bei keinem Bild ein Vorschaubild geladen oder auch Dateiinfos> angezeigt(siehe Opera).> Wechselt man jedoch direkt mittels "Filemanager (gleiche Seite)" in das> Verzeichnis werden die entsprechenden Daten jedoch angezeigt(siehe> Opera2)
Das schaue ich mir mal an. Das diese Funktion nicht ganz sauber
funktioniert, hatte ich ja schon angedeutet. Vielleicht spinnt hier die
Tokenabsicherung.
> IE:> "Filemanager (gleiche Seite)" führt zu einer "undefined" Meldung im> rechten Anzeigebereich (siehe IE_seite)> "Filemanager (per Popup)" führt zu einem leeren PopUp (siehe IE_popup)> "Inhalt löschen" zeigt nur einen leeren rechten Anzeigebereich (siehe> IE_loeschen)>> Testumgebung:> Windows Vista 32 Bit> Opera 12.15> Firefox 22.0> Internet Explorer 9
Ich werde dann doch mal Win7 in Virtualbox installieren müssen. Ich
hatte mit IE8 getestet und es lief. Ist wohl wieder mal eine
JS-Inkompatibilität zu Javascript.
> Opera + FF:> Nutzt man "Nach Upload ins Zielverzeichnis wechseln" so wird nach dem> Upload bei keinem Bild ein Vorschaubild geladen oder auch Dateiinfos> angezeigt(siehe Opera).> Wechselt man jedoch direkt mittels "Filemanager (gleiche Seite)" in das> Verzeichnis werden die entsprechenden Daten jedoch angezeigt(siehe> Opera2)
Den Fehler konnte ich beheben. Es war ein Folgefehler der Umstellung der
Verzeichnisdarstellung in der Liste. Das übergebene Verzeichnis wurde
falsch zusammengebaut und daher versuchte das Script eine nicht
vorhandene Datei darzustellen. In diesem Zuge habe ich den dafür
ursprünglich angedachten 404-Fehler durch eine andere Meldung ersetzt.
Stefan --- schrieb:> Leider ist die Installation auf Debian einfach nur zusammengewürfelter> Mist. Nach nun 3 Stunden und unendlichen> rm -rf part-db> su root> tar xfv Part.tar.gz> ist es mir nicht gelungen, die Abfrage der Dateirechte zu überwinden.
Na na, also ich hab extra mal ein Debian in einer VM installiert und die
Installation streng nach der Doku durchgeführt. Bei mir klappte das
alles ohne Probleme ;-) Auch auf meinem gemieteten Webserver, auf dem
anscheinend Confixx läuft (was ich nicht kenne) läuft die Part-DB
einwandfrei (Dateien per FTP hochgeladen).
Mit "Abfrage der Dateirechte" meinst du die Meldung von Part-DB, oder?
1
Das Verzeichnis bzw. die Datei "xyz" hat nicht die richtigen Dateirechte! Benötigt werden "rw". Bitte manuell korrigieren.
Stefan --- schrieb:> Bei mir läuft ein Confixx, so dass der Benutzer nicht zwangsläufig> www-data ist. Die Gruppe auf www-data zu belassen und den Benutzer> -nicht rekursiv- auf web0 zu setzen hat zumindest die Pfade der> Dokumentation aus der roten Liste verschwinden lassen, aber die Parts> sind hartnäckig.
Es müsste eigentlich ganz einfach sein. Alle Dateien müssen demjenigen
Benutzer gehören, unter dem der Webserver läuft. Bei dir anscheinend
"web0" wenn ich dich richtig verstehe. Da muss nichts auf "www-data"
belassen werden, das ist im Archiv einfach so voreingestellt weil das
bei vielen Linux Distributionen halt der Benutzer ist, unter dem der
Webserver läuft.
Wenn du das Archiv mit dem Befehl aus der Doku extrahiert hast, müssten
jetzt auch schon die Dateirechte stimmen, da die im Archiv bereits
richtig gesetzt waren. Somit müsste Part-DB jetzt problemlos laufen.
Falls du die Dateirechte selber setzt (aus irgend einem Grund...) musst
du natürlich darauf achten, dass die immer rekursiv gesetzt werden. In
den Verzeichnissen "data" müssen alle Dateien auf 644, und alle
Verzeichnisse auf 755 gesetzt sein.
Du hast die Doku schon gelesen, oder?
http://www.partdb.grautier.com/svn/documentation/dokuwiki/doku.php
Da gibts sogar extra alle Befehle die man braucht, um die
Dateirechte/Besitzer manuell einzustellen. In deinem Fall müsstest du
nur noch das "www-data" durch "web0" ersetzen.
entpackt wird, ist das Ändern der Dateirechte überflüssig (es sei denn,
du entpackt die Dateien irgendwo hin, wo keine UNIX Dateirechte
unterstützt werden - das wäre auf einem Linux/UNIX aber sowieso nicht
sehr geschickt).
Stefan --- schrieb:> Ich habe im Laufe der Zeit sicher mehr als 100 verschiedene> Web-Applikationen zum Laufen gebracht, aber so ein widerspenstiges Zeug> ist mir noch nicht untergekommen ...
Das liegt vielleicht auch daran, dass viele Web-Applikationen sich nicht
für Dateirechte interessieren. Erst wenn dann wirklich mal das
Schreibrecht gebraucht wird, aber nicht vorhanden ist, wird eine Meldung
ausgegeben. Part-DB prüft halt bei jedem Aufruf schon ganz am Anfang, ob
die benötigten Rechte vorhanden sind. Ist aber ja kein Problem, wenn die
Rechte einmal eingestellt sind kommt diese Meldung nie wieder.
Ausserdem sind bei anderen Applikationen häufig die Dateirechte im
Archiv noch gar nicht richtig gesetzt - keine Ahnung warum, Ich dachte,
so ists doch einfacher und sicherer, wenn nach dem Entpacken schon alles
(Besitzer und Rechte) stimmt. So kann ein Laie nicht viel falsch
machen... Die Doku lesen ist bei Webapplikationen sowieso (mMn) immer
Pflicht (zumindest überfliegen), da jede Applikation wieder ganz anders
installiert werden möchte. Bei einigen steht in der Doku sogar, dass man
die Dateirechte noch auf XY einstellen muss, überprüft wird es nachher
aber nicht (OK mittlerweile ist das nicht mehr so schlimm wie früher).
So ist doch schon vorprogrammiert dass viele Leute die Dateirechte nicht
entsprechend setzen. Ist alles im Archiv schon richtig gesetzt, kann das
nicht passieren.
Ansonsten wüsste ich nicht, was an Part-DB widerspenstig sein
sollte...Ich habe die Installation von Part-DB jetzt schon über ein
Dutzend Mal und auf verschiedenen Servern installiert, und hatte nie
Probleme ;-)
Wenn du es immernoch nicht hinkriegst, erkläre Schritt für Schritt was
du machst (Terminal Befehle!), und was für Fehler auftreten
(Fehlermeldungen!). Bisher konnte ich nur raten, was dein Problem ist,
da die Informationen in deinem Beitrag leider etwas spärlich sind...
mfg
Vielen Dank für die Ausführlichen Infos und Kommentare.
Ich mache also Folgendes:
- Lade die letzte Version
https://code.google.com/p/part-db/downloads/detail?name=Part-DB_0.3.0.tar.gz
- benenne das Archiv um in part.tar.gz um und schiebe es via FTP in das
Verzeichnis www/web0/html/
- mit putty melde ich mich als web0 an, gehe in das html/ Verzeichnis
und entpacke das Archiv mit tar xfv part.tar.gz
- dann lösche ich die part-db/.htaccess, da ich sonst einen Servererror
500 bekomme. Erstelle den Verzeichnisschutz später selbst
- beim Aufruf von domain.de/part-db/ wird dann gequengelt, dass data/...
und dokumentation/... nicht die richtigen Rechte haben.
Alle Dateien haben als Besitzer www-data erhalten.
Ändere ich nun für 'Dokumentation' rekursiv den Besitzer auf web0, dann
verschwindet zumindest dieser Zweig aus der Liste.
Mache ich das Gleiche auch für 'data' verschwindet auch hier alles, bis
auf data selbst.
Nun lösche ich das ganze Verzeichnis und entpacke das Archiv noch einmal
als root. Wieder werden die gleichen Verzeichnisse angemahnt. Wieder das
gleiche Verhalten.
Der Aufruf der Dokumentation dauert eine ganze Weile und wirft dann
massenhaft Fehlermeldungen:
Creating directory
/var/www/web0/html/part-db/documentation/dokuwiki/data/cache/9 failed
Writing
/var/www/web0/html/part-db/documentation/dokuwiki/data/cache/9/9a18521c4
60d062d1e019fd5077a490b.i failed
Unable to save cache file. Hint: disk full; file permissions; safe_mode
setting.
Writing
/var/www/web0/html/part-db/documentation/dokuwiki/data/cache/9/9a18521c4
60d062d1e019fd5077a490b.metadata failed
Creating directory
/var/www/web0/html/part-db/documentation/dokuwiki/data/cache/c failed
installation
Creating directory
/var/www/web0/html/part-db/documentation/dokuwiki/data/cache/9 failed
Creating directory
/var/www/web0/html/part-db/documentation/dokuwiki/data/cache/9 failed
Creating directory
/var/www/web0/html/part-db/documentation/dokuwiki/data/cache/9 failed
Writing
/var/www/web0/html/part-db/documentation/dokuwiki/data/cache/9/9a18521c4
60d062d1e019fd5077a490b.i failed
Unable to save cache file. Hint: disk full; file permissions; safe_mode
setting.
Creating directory
/var/www/web0/html/part-db/documentation/dokuwiki/data/cache/c failed
Creating directory
/var/www/web0/html/part-db/documentation/dokuwiki/data/cache/c failed
Writing
/var/www/web0/html/part-db/documentation/dokuwiki/data/cache/c/c12087918
8ac7f402d954ad156659fe7.code failed
Creating directory
/var/www/web0/html/part-db/documentation/dokuwiki/data/cache/6 failed
Creating directory
/var/www/web0/html/part-db/documentation/dokuwiki/data/cache/6 failed
Writing
/var/www/web0/html/part-db/documentation/dokuwiki/data/cache/6/6099c0c3e
fb701c24e30c06a09512dd0.code failed
Creating directory
/var/www/web0/html/part-db/documentation/dokuwiki/data/cache/7 failed
Creating directory
/var/www/web0/html/part-db/documentation/dokuwiki/data/cache/7 failed
Writing
/var/www/web0/html/part-db/documentation/dokuwiki/data/cache/7/7d38b86b4
5418b4ce60728dcba6ed6ef.code failed
Creating directory
/var/www/web0/html/part-db/documentation/dokuwiki/data/cache/9 failed
Writing
/var/www/web0/html/part-db/documentation/dokuwiki/data/cache/9/9a18521c4
60d062d1e019fd5077a490b.xhtml failed
Setze ich den Besitzer nun als web0 für alle Dateien und Verzeichnisse,
sind data... und dokumentation... wieder rot !
Ich denke nicht, dass man eine solchen Installation Daten anvertrauen,
bzw. erst langwierig Daten einpflegen sollte. Was, wenn ein Update
erforderlich ist oder was läuft hier noch alles unrund, was evtl.
Anfangs nicht bemerkt wird !?
Okay also irgendwas geht da nicht auf. Hast du auch wirklich mal die
Terminal Befehle für das Setzen der Besiter/Gruppen/Rechte genau so
ausgeführt wie in der Doku beschrieben (einfach "www-data" vorher durch
"web0" ersetzt)?
Etwas verstehe ich aber nicht:
Bei deinem zweiten Versuch hat also Part-DB nicht mehr wegen
"/documentation/dokuwiki/data/cache/" gemeckert? Heisst dann also, dass
die Funktion is_writable() bei diesem Verzeichnis "true" lieferte.
Trotzdem meckerte nachher das DokuWiki, dass dort keine Schreibrechte
vorhanden sind?!
Vielleicht hilft folgender kleiner Test weiter:
Du erstellst eine Datei "test.php" auf dem Server, mit folgendem Inhalt:
Dann Besitzer/Gruppe auf "web0" und die Dateirechte auf "644" stellen:
1
chown web0:web0 test.php
2
chmod 644 test.php
Nun die Seite im Browser aufrufen und die Ausgabe hier posten.
Vielleicht sieht man da ja was auffälliges.
Ausserdem könntest du noch folgendes ausprobieren:
Zuerst ALLE Dateien/Verzeichnisse dem Besitzer und Gruppe "web0"
zuordnen und alle Rechte gemäss Doku korrekt setzen! Dann in der
start_session.php mal die Zeile
1
$messages = check_file_permissions();
durch diese hier ersetzen:
1
$messages = array();
Damit wird einfach die Überprüfung der Rechte abgeschaltet. Und dann
schau mal, ob du die Installation fortsetzen kannst (der Installer
reklamiert dann einfach wenn er zu wenig Schreibrechte hat um die
data/config.php zu erstellen).
Stefan --- schrieb:> Ich denke nicht, dass man eine solchen Installation Daten anvertrauen,> bzw. erst langwierig Daten einpflegen sollte. Was, wenn ein Update> erforderlich ist oder was läuft hier noch alles unrund, was evtl.> Anfangs nicht bemerkt wird !?
Es ist alleine dir überlassen, ob du Part-DB verwenden willst oder nicht
;-) Ausserdem ist keine Software auf dieser Welt fehlerfrei, deshalb
sollte man auch bei der besten Software regelmässig die Daten sichern.
Ich habe mir beim programmieren wirklich Mühe gegeben und habe sehr
viele Stunden investiert, um alle möglichen Konstellationen einmal
durchzutesten. Auf der von mir eingesetzten Infrastruktur konnte ich in
der Part-DB keine Fehler mehr finden, mehr kann ich auch nicht machen.
Ausserdem wurde die 0.3.0 RC2 laut Google Code insgesamt 57 Mal
runtergeladen, und keiner hat sich hier über solche
Installationsprobleme beschwert...
Scheint also bei den meisten Anwendern zu funktionieren ;-)
Nachtrag:
Da wir Entwickler nur eine beschränkte Infrastruktur zum Testen zur
Verfügung haben (wir können nicht alle auf der Welt erhältlichen
Webserver testen!), sind wir auch auf die Mithilfe von freiwilligen
Testern angewiesen. Deshalb gibt es ja auch die Release Kandidaten. Dank
den Rückmeldungen der Tester konnten wir seit der RC1 noch viele Fehler
beseitigen. Vielleicht gibt es in Part-DB tatsächlich ein Fehler, der
sich nur bei Installationen in Confixx (das ich nicht kenne) bemerkbar
macht. Wenn wir einen solchen Fehler finden können, fliesst der
natürlich direkt in das nächste Update von Part-DB, damit das Problem in
Zukunft nicht mehr auftritt.
Moment mal - Ich habe gerade deinen Beitrag nochmal gelesen und bin
jetzt noch verwirrter als vorher.
Urban B. schrieb:> Bei deinem zweiten Versuch hat also Part-DB nicht mehr wegen> "/documentation/dokuwiki/data/cache/" gemeckert?
Das hast du so ja gar nicht geschrieben, allerdings kam ich wohl wegen
diesem Satz auf diese Annahme:
Stefan --- schrieb:> Setze ich den Besitzer nun als web0 für alle Dateien und Verzeichnisse,> sind data... und dokumentation... wieder rot !
Das "wieder" würde ja bedeuten, dass diese Verzeichnisse vorher nicht
"rot" waren. Doch eigentlich hast du genau das Gegenteil geschrieben:
Stefan --- schrieb:> Nun lösche ich das ganze Verzeichnis und entpacke das Archiv noch einmal> als root. Wieder werden die gleichen Verzeichnisse angemahnt.
Wenn ich nicht schon wieder was falsch verstanden habe, sind das
widersprüchliche Aussagen deinerseits. Erst sagst du, der Rechte-Check
meckert, dann sagst du, wenn du den Besitzer der Dateien auf "web0"
änderst, fängt der Rechte-Check wieder an zu meckern (obwohl er nie
aufgehört hat damit). So ist die Fehlersuche nicht leicht für mich...
;-)
ist blöd und verwirrend - ich bin aus dem Verhalten auch nicht schlau
geworden. Ich ändere data/ rekursiv auf web0 und alle data/subs
verschwinden aus der Liste. Ändere ich dokumentation/ rekursiv auf web0
und dokumentation verschwindet komplett. Setze ich das komplette
Verzeichnis part-db auf web0, sind wieder alle, also data und
dokumentation rot.
Hier die Ausgabe nachdem ich die test.php über FTP geschoben habe:
Prozess-Benutzer: 133 (www-data)
Besitzer: 647 (web0)
Leserechte : true
Schreibrechte: false
Dateirechte: 0644
Du magst nicht mal auf den Server schauen ?
Stefan --- schrieb:> Hier die Ausgabe nachdem ich die test.php über FTP geschoben habe:> Prozess-Benutzer: 133 (www-data)
Das ist interessant. Dein Webserver läuft also NICHT unter dem Benutzer
"web0", sondern unter "www-data"! Daher kommt dann das hier:
Stefan --- schrieb:> Schreibrechte: false
Jetzt könntest du natürlich mal versuchen, den Besitzer der test.php
nach "www-data" zu ändern:
1
sudo chown www-data:www-data test.php
Danach sollte der Webserver theoretisch Schreibrechte an dieser Datei
haben. Genau so sollte es sich eigentlich auch bei Part-DB verhalten.
Stefan --- schrieb:> Du magst nicht mal auf den Server schauen ?
Doch kann ich machen, schick mir einfach mal eine PN dann können wir per
Mail weiter kommunizieren, statt hier den Thread zu "belästigen".
Leider kenne ich die Infrastruktur von Hostern nicht wirklich, ich weiss
nicht wie die sich das vorstellen wie das funktionieren soll. Wenn der
Webserver unter dem gleichen Benutzer läuft wie der FTP-Upload (so ist
es bei meinem Hoster), ist alles klar, dann genügen die Dateirechte 644
damit ein PHP Skript eine andere Datei beschreiben kann. Läuft jedoch
beides auf unterschiedlichen Benutzern, genügen 644 ja nicht mehr, dann
brauchts je nachdem entweder 664 oder sogar 666, damit der Webserver
Schreibrechte erhält. Anscheinend soll es ja Hoster geben, bei denen das
so ist (?). Allerdings müsste man dann ja alle "data" Verzeichnisse
(egal ob von Part-DB, irgendeinem CMS oder sonstwas) auf 777 stellen
damit die Applikation richtig läuft, doch sicherheitstechnisch ist das
doch alles andere als ideal...Naja, vielleicht taucht hier ja mal jemand
auf der sich damit auskennt und uns aufklären kann :-)
Manchmal reicht es auch, anstelle des Users www-data die entsprechende
Gruppe und dementsprechende Rechte zu vergeben. Da ich selbst kein
Debian verwende - ich nutze openSUSE - kann ich leider nicht sagen, wie
die Gruppe heißt. Steht das nicht irgendwo in der Hilfe für den
Webspace? Aber eigentlich müsste das auch im FTP angezeigt werden.
PS: Der Upload im Filemanager läuft auch im IE10. Der hatte sich noch
über overrideMimeType beschwert.
OK also wir konnten die Ursache finden. Und zwar war das Problem, dass
die PHP Funktion is_executable() anscheinend bei Verzeichnissen immer
"false" lieferte, auch wenn das executable bit gesetzt war.
In der offiziellen Doku wird davon leider nichts erwähnt. Leider habe
ich aber nicht gesehen, dass dort ein User einen interessanten Kommentar
geschrieben hat:
> The change doesn't appear to be documented, so I thought I would mention> it. In php5, as opposed to php4, you can no longer rely on is_executable> to check the executable bit on a directory in 'nix. You can still use> the first note's method to check if a directory is traversable:> @file_exists("adirectory/.");
sieht zwar irgendwie mehr nach einem Workaround aus, aber wenns
funktioniert^^
Ich frage mich allerdings, ob es sich lohnt dafür eine neue Version
0.3.1 rauszugeben. Bisher hat sich ja noch niemand über dieses Problem
beschwert, bei den meisten PHP Installationen scheint is_executable()
also nach wie vor auch mit Verzeichnissen zu funktionieren...
Ich würde jetzt keine neue Version herausbringen, sondern eine passende
Lösung z.B. mit is_dir() oder is_file() in den 0.3er Zweig einbauen und
als neue Revision freigeben. Es ist bleibt wohl ein Sonderfall und ist
meiner Meinung nach nicht wichtig genug für ein Bugfix. Am besten
sammeln wir bis Ende August alle Meldungen und entscheiden dann, ob eine
neue Revision notwendig wird. Dann könnten wir die weitere Entwicklung
starten und die aktuelle Version als 0.3er Branch weiter führen. Das
käme mir auch zu Gute, denn ich hab diesen Monat eine andere Webseite
umzustellen und könnte da zumindest den Ajax- und DOM-Teil des
Javascript-Framework des Filemanagers ausgiebig testen :)
Edit: is_writable() zum Prüfen, ob das Verzeichnis beschreibbar ist, ist
auch sinnvoll ;) Allerdings scheinen die Datei-/Verzeichnisoperationen
teilweise völlig unterschiedliche Ergebnisse unter *nix und Windows zu
bringen, obwohl das nicht wirklich sinnig ist.
http://stackoverflow.com/questions/109188/how-do-i-check-if-a-directory-is-writeable-in-php
Udo Neist schrieb:> Ich würde jetzt keine neue Version herausbringen, sondern eine passende> Lösung z.B. mit is_dir() oder is_file() in den 0.3er Zweig einbauen und> als neue Revision freigeben. Es ist bleibt wohl ein Sonderfall und ist> meiner Meinung nach nicht wichtig genug für ein Bugfix.
Jo, sehe ich momentan auch so. Falls sich noch mehr Leute mit dem selben
Problem melden, können wir immernoch ein offizielles Update rausgeben.
Udo Neist schrieb:> Edit: is_writable() zum Prüfen, ob das Verzeichnis beschreibbar ist, ist> auch sinnvoll ;)
Schreibrechte alleine genügen aber nicht, um Dateien in einem
Verzeichnis zu erstellen/bearbeiten. Dazu ist immer auch das "executable
bit" nötig, also die Ausführrechte (die bei Verzeichnissen eine andere
Funktion haben als bei Dateien). Es macht also schon Sinn, die
Ausführrechte zu prüfen. Was hingegen keinen Sinn macht, ist das
kastrieren der is_executable() Funktion, so dass diese nur noch mit
Dateien funktioniert... ;-) Was die sich dabei wohl überlegt haben?!
Übrigens bezüglich Branches hätte ich das folgendermassen gedacht:
- Die finale 0.3.0 liegt als Kopie in tags/ und bleibt dort unangetastet
- Die weitere Entwicklung an der 0.3.0 findet wie gewohnt im trunk statt
- Es kommen grundsätzlich erstmal KEINE grossen Neuerungen (z.B.
Benutzerverwaltung, Barcode-Tools, Filemanager) in den trunk. Jedes
dieser Features soll seinen eigenen Branch kriegen, der vom trunk
abgeleitet wird. Erst wenn ein solches Feature bereit zum testen ist
(funktionierend, kann aber ruhig noch Fehler enthalten) wird es in den
trunk übernommen. Sobald im trunk dann die neuen Features als stabil
betrachtet werden können, kann ein neues Release herausgegeben werden.
- Ich werde gleich noch einen Branch für den Zweig "0.3.x" erstellen.
Wenn es später mal Updates für die 0.3.0 geben soll (nur Bugfixes!),
sollen die Bugfixes erst in den trunk aufgenommen, und vom trunk dann in
den "0.3.x" Branch übernommen werden. So ist immer ein Branch bereit, um
ein Update für die 0.3er Versionen zu erstellen (der trunk ist dafür ja
nicht brauchbar, da dieser nicht immer stabil ist).
mfg
> Udo Neist schrieb:>> Edit: is_writable() zum Prüfen, ob das Verzeichnis beschreibbar ist, ist>> auch sinnvoll ;)> Schreibrechte alleine genügen aber nicht, um Dateien in einem> Verzeichnis zu erstellen/bearbeiten. Dazu ist immer auch das "executable> bit" nötig, also die Ausführrechte (die bei Verzeichnissen eine andere> Funktion haben als bei Dateien). Es macht also schon Sinn, die> Ausführrechte zu prüfen. Was hingegen keinen Sinn macht, ist das> kastrieren der is_executable() Funktion, so dass diese nur noch mit> Dateien funktioniert... ;-) Was die sich dabei wohl überlegt haben?!
Obwohl ich Linux seit Jahren benutze, denk ich an sowas manchmal gar
nicht mehr. Stimmt schon, es muss wenigstens wx gesetzt sein, damit man
schreiben kann. Also muss man wohl einen Wrapper dafür schreiben.
> Übrigens bezüglich Branches hätte ich das folgendermassen gedacht:> - Die finale 0.3.0 liegt als Kopie in tags/ und bleibt dort unangetastet> - Die weitere Entwicklung an der 0.3.0 findet wie gewohnt im trunk statt> - Es kommen grundsätzlich erstmal KEINE grossen Neuerungen (z.B.> Benutzerverwaltung, Barcode-Tools, Filemanager) in den trunk. Jedes> dieser Features soll seinen eigenen Branch kriegen, der vom trunk> abgeleitet wird. Erst wenn ein solches Feature bereit zum testen ist> (funktionierend, kann aber ruhig noch Fehler enthalten) wird es in den> trunk übernommen. Sobald im trunk dann die neuen Features als stabil> betrachtet werden können, kann ein neues Release herausgegeben werden.
Im Grunde das gleiche wie ich es mir gedacht habe. Ich kopieren mir dann
den aktuellen Stand in meinen Branch und fange zwischenzeitlich mal an,
die Frames zu entfernen und auf Ajax/DOM umzustellen.
Verdammt! Ich habe wiedermal Mist gebaut im SVN Repository^^
Anscheinend habe ich die Änderung r689 im falschen Verzeichnis gemacht,
das hätte eigentlich nicht im trunk sondern im tags geändert werden
müssen...Vermutlich habe ich den falschen Ordner erwischt beim hochladen
ins SVN...
Ich versuchs dann mal wieder hinzubiegen ;-) Sorry!
Fehler passieren ;-) SVN wollte den Trunk nicht in mein Branch kopieren,
also erst einmal meinen alten Branch löschen und einen neuen
"part-db-uneist" erstellen.
lol OK ich habe grad den Fehler gefunden, ich habe meine lokale Kopie
von tag "Part-DB-0.3.0" aus dem trunk gezogen...schon klar landen dann
die Änderungen nicht dort wo sie sollten -.-
Glücklicherweise habe ich aber das Release-Paket dann auch aus dem Trunk
erstellt, und nicht aus dem tags/Part-DB-0.3.0 ;-)
Zwei Fehler nacheinander heben sich halt wieder auf xD
Also ich bins grad wieder am korrigieren, es sind nur ein paar Dateien
die ich damals gelöscht habe, die kann ich aber wieder herstellen.
Hehe... So lösen sich die Probleme langsam auf.
Ich hab mir mal die paar Javascriptdateien angeschaut. Ein paar der
Funktionen hab ich in meiner dom.js bereits drin bzw. sind sehr ähnlich,
andere könnte ich übernehmen. Man müsste auch schauen, ob die Funktionen
überhaupt noch gebraucht werden oder ob sie ersetzt werden könnten.
Einheitlicher wäre hier auch besser :-)
So, jetzt sollte alles wieder im Butter sein (r696).
Udo Neist schrieb:> Ich hab mir mal die paar Javascriptdateien angeschaut. Ein paar der> Funktionen hab ich in meiner dom.js bereits drin bzw. sind sehr ähnlich,> andere könnte ich übernehmen. Man müsste auch schauen, ob die Funktionen> überhaupt noch gebraucht werden oder ob sie ersetzt werden könnten.> Einheitlicher wäre hier auch besser :-)
Ja, das kannst du natürlich machen. Ich habe da übrigens auch nicht so
der Überblick, das meiste vom JavaScript-Kram stammt unverändert aus der
0.2.2.
Eine Tolle Software, nachdem ich in meiner Testbank einiges eingegeben
habe. Praktisch alle Infos an einen Ort zu haben.
Drei kleine Fragen hab ich noch:
1) Um 3.0 zu installieren einfach ueber RC2 drueberkopieren?
2) Da ich ja irgendwann auf den Heimserver mit der DB ziehen will, kann
man irgendwo nicht eine export/backup Funktion einbauen, die einen
direkt eine wieder einlesbare XML aus der DB erzeugt?
3) Auf der Startseite steht etwas mit Reichelt Preissuche. Wie/Wo kann
man das nutzen?
Danke und Gruss
Arne
Arne M. schrieb:> Eine Tolle Software, nachdem ich in meiner Testbank einiges eingegeben> habe. Praktisch alle Infos an einen Ort zu haben.
Danke :-)
> Drei kleine Fragen hab ich noch:> 1) Um 3.0 zu installieren einfach ueber RC2 drueberkopieren?
Du meinst sicher 0.3.0? Ja, einfach aktualisieren, da sich in der DB
nichts mehr geändert hat. Die Konfiguration bleibt.
> 2) Da ich ja irgendwann auf den Heimserver mit der DB ziehen will, kann> man irgendwo nicht eine export/backup Funktion einbauen, die einen> direkt eine wieder einlesbare XML aus der DB erzeugt?
Wenn du MySQLDumper installiert hast, könntest du das direkt aus Part-DB
aufrufen. Sonst bleibt dir nur der Umweg über MySQL-Konsole/mysqldump
oder phpMyAdmin.
> 3) Auf der Startseite steht etwas mit Reichelt Preissuche. Wie/Wo kann> man das nutzen?
Soviel ich weiß ist das Preissuchscript selbst in der 0.2er Version von
Part-DB veraltet, da sich zwischenzeitlich die Homepage von Reichelt
geändert hat. Wann wir wieder ein passendes Script haben, kann ich nicht
sagen.
@Urban: Die Meldung "SVN-Revision konnte nicht aus "/.svn/wc.db" gelesen
werden! $result ist NULL" ist in einem Release sinnlos. Daran hätten wir
denken sollen ;)
Udo Neist schrieb:> @Urban: Die Meldung "SVN-Revision konnte nicht aus "/.svn/wc.db" gelesen> werden! $result ist NULL" ist in einem Release sinnlos. Daran hätten wir> denken sollen ;)
Diese Fehlermeldung kann aber nur geworfen werden, wenn die Datei
"/.svn/wc.db" existiert (siehe voranstehendes "if file_exists()"). Da
diese Datei in einem Release aber nicht existiert, kann die
Fehlermeldung gar nie auftreten. Es wäre also sinnlos, für die Releases
hier irgendwas zu ändern, da es keinen Unterschied macht ;-)
Udo Neist schrieb:> Wenn $result NULL ist, dann braucht man das auch nicht wirklich> auszugeben, oder?
Ich verstehe dich nicht ganz. Die Funktion "get_svn_revision()" prüft,
ob die aktuelle Installation per SVN installiert wurde (".svn"
Verzeichnis vorhanden) oder nicht. Bei einer SVN-Installation gibt die
Funktion die SVN Revisionsnummer zurück, bei einer
Nicht-SVN-Installation gibt die Funktion NULL zurück.
Siehst denn du irgendwo die von dir genannte Fehlermeldung, also wird
die irgendwo ausgespuckt? Das sollte eigentlich nicht der Fall sein.
Ach so, jetzt verstehe ich es :-)
Aber ich wüsste nicht, warum man diesen Fehler bei einer stabilen
Version unterbinden sollte.
Erstens ist das schlussendlich ja ein "normaler" Fehler, wie jeder
andere auch, und die anderen Fehler bekommen ja auch keine
Sonderbehandlung.
Und zweitens sind SVN-Installationen nach wie vor grundsätzlich nur für
Entwickler gedacht. Natürlich darf man seine Part-DB auch als
Nicht-Entwicker per SVN installieren, allerdings geschieht dies auf
eigenes Risiko. Für die Endanwender schnüren wir ja extra die Pakete,
die dann eben auch den ".svn" Ordner nicht enthalten und somit die
genannte Fehlermeldung gar nicht erst auftauchen kann. Auch der
"development" Ordner hat beim Endanwender grundsätzlich nichts zu suchen
und wird daher in den Release-Archiven entfernt. Im SVN ist dieser
Ordner allerdings vorhanden, da man den als Entwickler halt braucht (vor
allem um die Archive zu schnüren).
- soweit meine Meinung ;-)
Was den Fehler bei dir verursacht, müsste man mal untersuchen. Kannst du
das selber übernehmen? Ich kann den Fehler hier nicht nachvollziehen.
Es ist zwar ein Schönheitsfehler und stört die normale Funktionsweise
nicht, aber sowas müsste nicht sein.
Ich habe get_svn_revision() so umgeschrieben, dass entweder eine
Revisionsnummer oder false für unbekannte Revision oder NULL
zurückgegeben wird. Die Fehlermeldung ist weg, stattdessen wird
"Version: 0.3.0 (stable), SVN-Revision: unbekannt" angezeigt.
lib.php (Zeile 65ff):
1
/**
2
* @brief Get the SVN Revision number of the installed system
3
*
4
* @retval integer The SVN revision number
5
* @retval false No revision number is found
6
* @retval NULL If this is no SVN installation
7
*/
8
function get_svn_revision()
9
{
10
// New SVN format
11
if (file_exists(BASE.'/.svn/wc.db'))
12
{
13
$svn = 0;
14
$pdo = new PDO('sqlite:'.BASE.'/.svn/wc.db');
15
$result = $pdo->query('SELECT MAX(revision) AS rev FROM nodes');
Wenn ich allerdings wc.db mit dem FF Addon SQLite Manager öffne und den
SQL-Befehl ausführen lasse, bekomme ich den Wert 691 zurück, was der
Revision entspricht.
Der Codeschnippsel
1
$pdo = new PDO('sqlite:'.BASE.'/.svn/wc.db');
2
$result = $pdo->query('SELECT MAX(revision) AS rev FROM nodes');
liefert false zurück. Dann kann auch keine Revision ausgelesen werden.
sqlite3 macht dagegen auf der Konsole Probleme.
Naja, solange diese Funktion nur für die Anzeige der Revisionsnummer auf
der Startseite verwendet wird, mag das ja egal sein wenn trotz
Fehlerfall keine Exception geworfen wird.
Allerdings wäre es durchaus denkbar, dass diese Funktion später auch mal
für andere, wichtigere Dinge genutzt wird, z.B. für das automatische
Systemupdate das noch auf der ToDo-Liste steht. Dort ist es sicherlich
nötig, zu schauen ob es eine SVN Installation, und wenn ja welche
Revision, ist. Vergisst man dort, zwischen "NULL" und "false" zu
unterscheiden (schnell passiert), kann dies evtl. zu einem fehlerhaften
Update führen. Wird eine Exception geworfen, kann das nicht passieren,
da man eine Exception nicht aus versehen ignorieren kann, da muss man
den Code mit Absicht so schreiben, dass eine Exception ignoriert wird.
Genau für solche Dinge sind Exceptions ja erfunden worden :-)
Dass die Fehlermeldung auf der Startseite unterdrückt wird, damit bin
ich einverstanden (stattdessen kann die Meldung ja in den Debug-Log
geschrieben werden). Das macht man aber besser, indem man in der
startup.php einfach den Aufruf von "get_svn_revision()" in einen
try/catch Block packt um die Exception zu verwerfen. Das wäre eine
saubere Lösung.
> SQL error: malformed database schema (nodes_update_checksum_trigger) -> near "OLD": syntax error
Das nennt man dann wohl "Ausnahmefall", oder auf Englisch "Exception"
:-D
Arne M. schrieb:> Waere es auch nicht toll zur Feier einen neuen Thread mit 0.3.0 zu> erstellen? 600 Beitraege werden auf dem Handy doch arg viel :)
Keine schlechte Idee :-)
Ich habe grad vor ein paar Tagen gedacht dass hier irgendwie ein
bisschen ein Durcheinander herrscht, da dieser Thread einerseits für den
Austausch zwischen Anwendern und Entwicklern, andererseits aber auch
zwischen den Entwicklern untereinander genutzt wird. Das macht es gerade
für etwas weniger aktive Entwickler sehr schwierig, am Ball zu bleiben
weil pro Woche manchmal vermutlich über 50 Beiträge geschrieben werden.
Es gibt bestimmt einige Möglichkeiten, das zu verbessern.
- Zwei Threads, z.B. "Part-DB 0.3.x Support" und "Part-DB Entwickler"
- Nur den Support Thread hier, Entwickler-Diskussion auslagern (wohin?)
- Ein eigenes kleines Forum für Part-DB mit mehreren Unterforen (nach
Themengebieten), ein Unterforum nur für Entwickler (übertrieben?)
- andere Vorschläge? :-)
Der Code ist ja nur ein Beispiel wie man das ganze umgehen kann. Ich
habs ja nicht hochgeladen. Ich lade mal eine saubere Version vom Server
und schieb das Problem in einen anderen Ordner. svn status meckert mir
über meine Arbeitskopie, vielleicht ist deswegen der Fehler.
Ich habe einen neuen Thread zur Version 0.3+ gestartet. Alles zu dieser
Version nur noch dort reinschreiben, da es einfach übersichtlicher wird
:-)
Beitrag "Lagerverwaltung Part-DB V0.3+"
Grüße
Udo
Hi,
wie oben steht, jetzt gibt es die Version 0.3+ in einem separaten
Thread:
Beitrag "Lagerverwaltung Part-DB V0.3+"
@Moderator: Bitte ein "Vorhaengeschoss" an diesen Thread machen.
vg
Moin Moin,
Hier wurde ja schon lange nix mehr geschrieben, ist das Forum um die
Lagerverwaltung noch aktiv???
Ich möchte anhand des Lagerortes eine Liste erstellen und diese dann
ausdrucken.. Wie kann man das realisieren?
gruss
Tom L. schrieb:> Moin Moin,>> Hier wurde ja schon lange nix mehr geschrieben, ist das Forum um die> Lagerverwaltung noch aktiv???>>> Ich möchte anhand des Lagerortes eine Liste erstellen und diese dann> ausdrucken.. Wie kann man das realisieren?>> gruss
Es gibt mittlerweile eine neue Version (0.4 bzw 0.5 ist in Entwicklung):
Beitrag "Lagerverwaltung Part-DB V0.4.x"
Neben einem verbesserten Design, und einer Benutzer und
Rechteverwaltung, gibt es auch die Möglichkeit sich alle Teile in einem
bestimmten Lagerort auflisten zu lassen. Das kann man dann vermutlich
auch ausdrucken, dass dürfte dem was du haben willst ziemlich nahe
kommen.
Hier gibt es eine Demo Installation der aktuellen Version:
http://part-db.bplaced.net
Thread beobachten
Seitenaufteilung abschalten
