mikrocontroller.net

Forum: Projekte & Code Lagerverwaltung Part-DB V0.2.2


Autor: b.r (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Hallo Forum!

Part-DB ist eine kleine webbasierte Lagerverwaltung für elektronische 
Bauteile.

Ursprünglich von C. Lechner entwickelt 
(http://www.cl-projects.de/projects/part-db/)  findet die aktuelle 
Entwicklung auf Google Code statt: http://code.google.com/p/part-db/

Zum Ausprobieren gibt es momentan zwei Demo-Seiten:
http://partdb.grautier.com/    ("offiziell")
http://weinbauer73.myparts.info/   (Test-Branch)

In diesem Thread soll es um die Weiterentwicklungen innerhalb der 
Lagerverwaltung Part-DB gehen.


Der Ursprungsthread findet sich hier:
Beitrag "PART-DB RW 1.2"

Grüße
b.r

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)
#! /bin/bash
FILES=`find . -type f -name "*php" -o -name "*tmpl"`

for FILE in $FILES
do
    echo "bearbeite $FILE..."
    mv "$FILE" "$FILE".bak
    expand -t4 "$FILE".bak > "$FILE"
    rm -f "$FILE".bak
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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab mal die database.php in meinen Branch übernommen und werde damit 
etwas "spielen" :-)

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
if ($befehl=='copy') $system->interpreter->copy()
if ($befehl=='rename') $system->interpreter->rename()
if ($befehl=='sql') $system->interpreter->sql()

Käme Perl nahe ;-)

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Torsten C. (torsten_c) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: b.r (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Torsten C. (torsten_c) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: b.r (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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=8

Torsten 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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/br...

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

Autor: b.r (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: b.r (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: K. J. (theborg0815) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: K. J. (theborg0815) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: M. K. (avr-frickler) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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 
:-)

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/referenziere...

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

Autor: K. J. (theborg0815) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Urban B. schrieb:
>
> Jetzt werden also absolute Pfade ausgehend vom DOCUMENT_ROOT verwendet,
> so wie hier beschrieben:
> http://de.selfhtml.org/html/allgemein/referenziere...

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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: K. J. (theborg0815) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/

Autor: K. J. (theborg0815) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
// table "pictures" will now be changed to "files"
$updateSteps[] = "ALTER TABLE `pictures` RENAME `files`";
$updateSteps[] = "ALTER TABLE `files` CHANGE `part_id` `element_id` INT(11) NOT NULL";
$updateSteps[] = "DROP INDEX `pict_type` ON `files`";
$updateSteps[] = "ALTER TABLE `files` CHANGE `pict_fname` `filename` MEDIUMTEXT NOT NULL";
$updateSteps[] = "ALTER TABLE `files` DROP COLUMN `pict_width`";
$updateSteps[] = "ALTER TABLE `files` DROP COLUMN `pict_height`";
$updateSteps[] = "ALTER TABLE `files` DROP COLUMN `pict_type`";
$updateSteps[] = "ALTER TABLE `files` DROP COLUMN `tn_obsolete`";
$updateSteps[] = "ALTER TABLE `files` DROP COLUMN `tn_t`";
$updateSteps[] = "ALTER TABLE `files` DROP COLUMN `tn_pictid`";
$updateSteps[] = "ALTER TABLE `files` CHANGE `pict_masterpict` `is_master` BOOLEAN NOT NULL DEFAULT FALSE";
$updateSteps[] = "ALTER TABLE `files` ADD `name` TINYTEXT NOT NULL AFTER `id`";
$updateSteps[] = "ALTER TABLE `files` ADD `class_name` TINYTEXT NOT NULL AFTER `name`";
$updateSteps[] = "ALTER TABLE `files` ADD `type_id` INT(11) NOT NULL AFTER `element_id`";
$updateSteps[] = "UPDATE `files` SET name=filename";
$updateSteps[] = "UPDATE `files` SET type_id='1'";
$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.

Autor: K. J. (theborg0815) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: K. J. (theborg0815) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: K. J. (theborg0815) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
WoW sieht echt gut aus !!!

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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).

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: K. J. (theborg0815) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/documentat...

Oder für die Klasse "DBElement" hat Doxygen dieses coole Klassendiagramm 
erstellt: 
http://partdb.grautier.com/uneistkami89/documentat...

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" :-)

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :(

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: b.r (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marvin Hohlfeld (hohli)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Sandboxgangster (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marvin Hohlfeld (hohli)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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..? :-)

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nimm mal 
http://code.google.com/p/part-db/source/browse/bra.... 
Dieses SQL-Script sollte die komplette, leere Datenbank in Version 12 
enthalten.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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'].

Autor: K. J. (theborg0815) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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 ;-(

Autor: Urban B. (kami89)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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_...

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

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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:
<div class="outer">
    <h2>Teile in der Kategorie "{TMPL_VAR NAME="category_name"}"</h2>
    <div class="inner">
        <table>
            {TMPL_LOOP NAME="table"}
                {TMPL_INCLUDE FILE="../vlib_table.tmpl"}
            {/TMPL_LOOP}
        </table>
    </div>
</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

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: K. J. (theborg0815) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: Christian R. (holle)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gut, dann werde ich mal nach dem Uploader schauen :-)

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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^^)

Autor: b.r (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.php

http://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.

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Maxim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Also eine (teilweise veraltete) Anleitung gibt es hier: 
http://www.mikrocontroller.net/articles/Part-DB_RW...

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

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/bra...
http://code.google.com/p/part-db/source/browse/bra...

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.

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christoph B. (christoph_b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christoph B. (christoph_b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
keiner eine Idee?

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christoph B. (christoph_b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christoph B. (christoph_b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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? :-)

Autor: K. J. (theborg0815) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christoph B. (christoph_b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

mfg

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: K. J. (theborg0815) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok ist gefixt

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: K. J. (theborg0815) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Kühne (tommes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/br...

Letztere beide gibts auch als Online-Demo: http://partdb.grautier.com/

Gruss
Urban

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
  include('../lib.php');
  partdb_init();
?>
<?
  //include('stats.php');
?>

Die letzten 3 Zeilen können ersatzlos raus.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sind die Funktionen unter "Lagerorte umbenennen/löschen/sortieren" 
irgendwo beschrieben, insbesondere was die Kästchen "voll" und "noch 
Platz" bewirken?

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dokuwiki ist ein ähnliches Kaliber, wie MoinMoin. Vorteil im 
vorliegenden Fall ist, daß es in PHP geschrieben ist.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christoph B. (christoph_b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Thomas Kühne (tommes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marco tom Suden (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/#s...

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:
svn checkout http://part-db.googlecode.com/svn/branches/uneist_kami89/ part-db-uneist_kami89
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.

Autor: Marco tom Suden (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marco tom Suden (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
error_reporting = E_ALL & ~(E_STRICT | E_DEPRECATED)

Falls es noch Probleme gibt, lösche mal die config.php im 
Hauptverzeichnis von Part-DB (falls sie schon existiert).

Autor: Marco tom Suden (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Okay also wenn ich das alles richtig verstanden habe, genügt ja für jede 
Tabelle ein einziger, kleiner Befehl:
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.

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marco tom Suden (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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.

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
if (is_array(vlibIni::vlibTemplate()))
{
   foreach (vlibIni::vlibTemplate() as $name => $val)
   {
      $this->OPTIONS[$name] = $val;
   }
}

durch die ältere Methode
$vlibIni = new vlibIni;
if (is_array($array = $vlibIni -> vlibTemplate()))
{
   foreach ($array as $name => $val)
   {
      $this->OPTIONS[$name] = $val;
   }
}

ersetzt. Ich hoffe, dass damit der Fehler behoben ist.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
error_reporting(E_ERROR);
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?! ;-)

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Marco tom Suden (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marco tom Suden (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!^^).

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gute Idee :) Dann werde ich diesen Dump mal einspielen.

Autor: Marco tom Suden (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Marco tom Suden (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich gehe mal stark davon aus, dass
 define('BASE', dirname(__FILE__));
 define('DOCUMENT_ROOT', rtrim($_SERVER['DOCUMENT_ROOT'], '/'));
 define('BASE_RELATIVE', str_replace(DOCUMENT_ROOT, '', BASE.'/'));
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.

Autor: Marco tom Suden (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marco tom Suden (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Udo Neist (weinbauer73)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Marco tom Suden

Könntest du mal die folgenden Zeilen ganz am Anfang in die 
start_session.php schreiben, und dann die Ausgaben hier reinstellen?
print 'dirname='.dirname(__FILE__).'<br>';
print 'docroot='.$_SERVER['DOCUMENT_ROOT'].'<br>';

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?
define('BASE_RELATIVE', str_replace(DOCUMENT_ROOT, '', BASE.DIRECTORY_SEPARATOR));

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Keine Ursache, Urban :-) Hauptsache man kann wieder einen Bug mehr von 
der Liste streichen.

Autor: Marco tom Suden (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/wikifi...

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.

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marco tom Suden (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
define('BASE', dirname(__FILE__));
define('DOCUMENT_ROOT', rtrim($_SERVER['DOCUMENT_ROOT'], '/\ '));
define('BASE_RELATIVE', str_replace(DOCUMENT_ROOT, '', BASE.DIRECTORY_SEPARATOR));

mfg

Autor: Marco tom Suden (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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));

Wenn das immer noch nicht funktioniert, dann setz BASE_RELATIVE mal von 
Hand. Welche dieser beiden Varianten funktioniert?
define('BASE_RELATIVE', '/part-db-0.3.0/');
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.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...
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.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Marco tom Suden (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Udo Neist (weinbauer73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 Skript 
auszufü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.

Autor: Marco tom Suden (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uhu Uhuhu schrieb:
> Warum sicherst du in eine SQLite DB?

Hier in der Doku ist das ganze beschrieben:
http://www.mmvisual.de/Hilfe/EleLa/ExtraExp.htm

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
INSERT INTO tabelle SET key=value
Das hier funktionier hingegen bei SQLite und MySQL:
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

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Marco tom Suden (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 (&auml;). 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 &auml; 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.

Autor: Marco tom Suden (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-).

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 &auml; 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.

Autor: Marco tom Suden (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Christoph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
CREATE DATABASE IF NOT EXISTS <######> DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci

Autor: Urban B. (kami89)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 Datumsfel