b.r schrieb im Beitrag #2813490:
> Hallo an alle Mitentwickler!
>
> 1. Es wäre mal an der Zeit einen neuen Thread aufzumachen. Zwecks
> besserer Ladezeiten und vielleicht auch einem aussagekräftigeren
> Threadtitel?

Stimme ich zu :-)

> 2. Das mit den 4 Leerzeichen scheint ja nun Konsens zu sein und findet
> meine vollste Zustimmung. Gibt es schon einen guten Platz/Link für die
> Coding Guidelines?

Ich habe die Coding Guidelines schon angepasst. Wenn gewünscht, stelle 
ich sie bei Google Code ins Wiki.

> 3. Debuglog bzw. SQL-Transaction-Log finde ich eine tolle Sache, hatte
> ich auch schonmal im Hinterkopf.

Hatte ich auch schon auf meiner Liste. Wie gut, das ich das streichen 
kann.

> 5. Momentan haben wir - so wie ich das sehe - zwei Entwicklungen:
> Templates und OOP. Jedes neue Feature macht daher doppelt Arbeit
> (entweder für den Einpfleger, oder für den Entwickler). Wir sollten uns
> vielleicht erstmal auf eine Sache konzentrieren.

Sobald ich die Templates fertig habe, werden wir beide Zweige 
zusammenbauen. Es wäre ein durcheinander, wenn wir das recht früh 
gemacht hätten.

> 6. SVN-Nutzung:
> Die zwei Entwicklungsrichtungen spiegeln sich ja in den beiden
> User-Branches wieder.
> Ich würde mal folgenden Vorschlag machen:
> Im TRUNK liegt die Stable-Version, auf der nur kleine Bug-fixes gemacht
> werden. Neue Sachen werden in einem testing-Branch ausprobiert.
> Ungefähr alle drei Monate wird unstable zu stable gemacht und ein
> hübsches Download-Paket geschnürt.

Das beide Branches wieder zusammen kommen müssen, das ist uns klar. Ich 
denke, sobald ich die Templates fertig habe, kann ich die OOP-Sachen von 
Urban einbinden. Ich beführchte allerdings, da wird es noch einiges an 
Diskussionsbedarf geben. Im Moment sehe ich eine 1:1-Übersetzung der 
lib.php in Klassen. Es wäre in meinem Augen sinnvoller, einige Klassen 
nur mit Basis-Funktionen zu versehen, die dann von anderen Funktionen 
aufgerufen wird. Die Anzahl der Dateien steigt zwar damit, aber die 
Übersichtlichkeit ist besser.

> 7. Bei größeren Versionssprüngen, wenn z.B. Version 0.3 mit templates &
> oop fertig ist, wird die Datenbankversion auf 100 gesetzt und alle
> Datenbankupdates aus dem Code entfernt bzw. in ein manuelles Skript
> verschoben.

Ist schon geplant. Das Update-System wird komplett erneuert. Nur welche 
Variante, das ist noch nicht klar. Ich habe ein Interpreter für 
Update-Scripts geschrieben, der auch für Installationen und Reparatueren 
taugt. Urban geht einen anderen Ansatz und will für jedes Update ein 
neues PHP-Script schreiben.

b.r schrieb im Beitrag #2813502:
> 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 im Beitrag #2813490:
> 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 im Beitrag #2813490:
> 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 im Beitrag #2813490:
> 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 im Beitrag #2813490:
> 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 im Beitrag #2813449:
> 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 im Beitrag #2813449:
> 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 im Beitrag #2813449:
> 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 im Beitrag #2813449:
> 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.

http://code.google.com/p/part-db/wiki/Coding_Guidelines

Udo Neist schrieb:
> http://code.google.com/p/part-db/wiki/Coding_Guidelines

Sehr schön!

Mein Branch ist nun aktuell, da kannst du mal das Debug-Zeugs anschauen.

Den Debug-Log verwenden wir aber schon nur für Fehlermeldungen oder? 
Also nicht für irgendwelche "Bestätigungs-Meldungen" wie z.B. 
"__construct(): Objekt erfolgreich angelegt" usw.

Ansonsten könnte man auch noch ein Logging-Level einbauen, dann kann man 
auch solche unwichtigen Bestätigungen mitloggen, aber mit tiefer 
Priorität. Beim Betrachten der Logs kann man dann wählen welche Logs 
überhaupt ausgegeben werden, damit man solche unwichtigen Meldungen 
unterdrücken kann.

Ich denke das würde Sinn machen. Vielleicht ein Level von 0 bis 5 
definieren oder so? 0 = "total unwichtig", 5 = "ultraschlimmer fehler, 
fast wäre der server abgeraucht"

Oder aber mit Strings, so wie ich es jetzt gemacht habe. Also z.B. 
"warning", "error", "info". Und dann beim Viewer für jedes Attribut eine 
Checkbox die man einzeln an-/abwählen kann.

Was meint ihr?

Urban B. schrieb:
> Naja Klassen und Templates sind ansich ja zwei komplett verschiedene
> (unabhängige) Dinge, da kann man relativ gut parallel arbeiten. Das
> Zusammenführen nachher gibt dann natürlich etwas Arbeit, das ist klar.
> Aber die kann ich gerne übernehmen (ich bin ja der Einzige, der weiss
> wie man die Klassen "anspricht" und richtig einsetzt).
> Aber bis zum Zusammenführen werden meine Klassen nur mal so grob
> funktionieren. Um alles richtig austesten zu können brauche ich auch
> Seiten, die die Klassen richtig verwenden (z.B. in der editpartinfo.php
> usw.). Damit wir die nicht doppelt machen müssen (einmal ich zum testen
> und einmal Udo für die Templates) warte ich auf die Templates und fange
> erst danach richtig an die Klassen zu testen.

Du musst nicht alles übernehmen. Wir können uns auch die Arbeit teilen. 
Dazu sollten wir aber erstmal mit unseren Arbeiten fertig werden und 
dann anschauen, was der andere gemacht hat. Vielleicht gibt es ja auch 
noch ein paar Änderungen, die dann in die neue Version einfliessen 
werden.

> Udo Neist schrieb im Beitrag #2813449:
>> 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 im Beitrag #2813449:
>> 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 im Beitrag #2813449:
>> Das du das "Logfile" bereits umgesetzt hast, das ist löblich :-) Erspart
>> mir zumindest eine weitere Baustelle. Wenn du es hochgeladen hast, kann
>> ich das ja auch bei mir schon einbauen. Das xhr-Teil schreibe ich dann.
>
> Ich aktualisiere nachher gleich mal meinen Branch, dann kannst du es dir
> anschauen. In "db_update_steps.php" siehst du wie die Tabelle aussieht
> (case-Nr. 20). Falls du noch Vorschläge hast, was man zusätzlich noch
> für Spalten gebrauchen könnte, gib Bescheid. Dann habe ich noch die
> beiden Klassen "debug_log.php" und "debug_log_element.php" erstellt. In
> "debug.php" siehst du wie die Klasse eingesetzt wird, und wie die
> Ausgabe des Logs aussieht.

Mach ich. Dann kann ich das auch gleich schon einbauen. Das Update wäre 
auch was für mein Update-System zum Testen ;-)

> Vieles ist aber noch sehr provisorisch. Fehlerbehandlungen gibts bisher
> noch praktisch keine in eigentlich all meinen Klassen. Das rüste ich
> dann erst später nach (mit exceptions).

Du kannst es in meiner class/html.php sehen, wie ich eine 
Fehlerbehandlung durchführe.

> Eine 1:1 Übersetzung ist es natürlich nicht, sonst würde OOP nicht viel
> Sinn machen. Funktionen, die direkt Antworten auf SQL-Querys
> durchführen, gibt es nicht mehr. SQL Querys werden allgemein viel
> weniger verwendet, das meiste wird direkt durch "ein geschicktes
> OOP-Design" erledigt. Nur noch "auf unterster Ebene" werden noch SQL
> Querys eingesetzt.

Ich hab nicht alle Klassen durchgeschaut. Du hast einige Funktionen in 
der Datenbankklasse drin, die ich persönlich da nicht reingebaut hätte. 
Alles rund um die Updates gehören in eine andere Klasse, die nur für die 
Updates zuständig ist. Ansonsten sehen die Klassen schon richtig gut aus 
:-) Nur noch die Templates dazu, ein bisschen aufräumen und unsere 0.3 
wäre fertig.

Udo Neist schrieb:
> Ich hab nicht alle Klassen durchgeschaut. Du hast einige Funktionen in
> der Datenbankklasse drin, die ich persönlich da nicht reingebaut hätte.
> Alles rund um die Updates gehören in eine andere Klasse, die nur für die
> Updates zuständig ist.

Das Updatesystem, das bisher in meinem Branch lag, war ja auch noch nach 
dem alten Prinzip. Heisst, es wird nur die Datenbank aktualisiert, 
deshalb ist die Updatefunktion auch in der Datenbankklasse.

Jetzt sind schon erste Funktionen vorhanden für das neue Updatesystem, 
da habe ich einfach mal ein bisschen rumprobiert. Diese Funktionen sind 
dann in der Klasse "System", weil sie das System updaten :-) Eine eigene 
Update Klasse finde ich irgendwie komisch. Ein Update ist kein "Ding", 
also kein Objekt. Ein Update aktualisiert das System und müsste von der 
Logik her eine Methode der System-Klasse sein.

Ist aber ein stückweit auch Ansichts-/Geschmackssache ;-)

> Ansonsten sehen die Klassen schon richtig gut aus
> :-) Nur noch die Templates dazu, ein bisschen aufräumen und unsere 0.3
> wäre fertig.

xD das hört sich ja ganz einfach an :-)

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

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 ;-)

@Udo
Ich wäre jetzt an der Stelle, wo ich das Lieferantensystem umbauen will 
(damit man einem Bauteil mehrere Lieferanten zuordnen kann). Nur fehlt 
da noch das entsprechende Datenbankupdate...
Darf ich dich nochmal auf diesen 
Beitrag "Re: PART-DB RW 1.2" aufmerksam machen? 
:-)
Hättest du grad Zeit dich mal daran zu versuchen?

mfg

Hallo!

Die Part-DB RW - Lagerverwaltung ist ziemlich genau das, was ich mir 
für meine Teileverwaltung vorstelle.

Aber macht es denn Sinn, dass jeder einzelne Nutzer einen Webserver mit 
PHP und Mysql Datenbank betreiben muß?

Ich habe daher einen Verbesserungsvorschlag, den ich in der TODO-Liste 
nicht gefunden habe.
http://code.google.com/p/part-db/issues/list

Vergleichbar mit Wordpress könnte man auch eine gemeinsame Instanz 
benutzen. Man kann sich Wordpress entweder selbst installieren oder 
unter der gemeinsam genutzten Instanz Wordpress.com einfach ein neues 
Blog oder einen neuen Nutzer hinzufügen.

Ich würde daher auch die Part-db Lagerverwaltung am liebsten irgendwo 
installieren, wo sich jeder mit seinem Login anmelden und seine Teile 
verwalten kann. Die "Stammdaten" müßte dann nicht jeder einzeln pflegen. 
Das Thema wurde schon mal angesprochen (s.u.).

Im Moment sehe ich das so, dass ich die aktuelle Version dazu um 
Benutzerkonten erweitern müßte.

Wären denn noch mehr Interessenten an so einer gemeinsamen Pflege der 
"Stammdaten" interessiert? Ich fände es schade, wenn dadurch ein 
"SW-Branch" entsteht.

Der Gedanke wurde schon mal angesprochen:

Bauteilegucker schrieb im Beitrag #1278156:
> 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 im Beitrag #1339561:
> Und irgendwie wäre es schön, wenn man Datensätze mit anderen Usern
> tauschen könnte, …

Georg schrieb im Beitrag #1504563:
> 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 im Beitrag #1278648:
> 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 im Beitrag #1624860:
> 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 im Beitrag #1278138:
> Sogar die jeweiligen
> Eagle/KICAD/...-libs könnte man gleich mit integrieren, …

Den Sinn/Vorteil habe ich noch nicht ganz verstanden.

Torsten C. schrieb:
> Ich habe daher einen Verbesserungsvorschlag, den ich in der TODO-Liste
> nicht gefunden habe.

b.r schrieb:
> … daran wir gearbeitet: Eine Multiuser-Version auf einem
> zentralen Webspace

Wird die Liste denn noch gepflegt, oder gibt es noch mehr Listen?

b.r schrieb:
> Damit würde die aufwändige, unkomfortable Suche nach dem passenden
> Bauteil in der entsprechenden PCB-Software entfallen.

Und wie genau geht das dann weiter, z.B. in Eagle? Im Lib-Browser muß 
ich das Bauteil doch eh suchen, oder kann man das Bauteil per Drag&Drop 
aus der Part-DB in den Schaltplan schieben?

Torsten C. schrieb im Beitrag #2814382:
> 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 im Beitrag #2814382:
> 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.

@Udo
Du hast ja noch was bezüglich der Währung geschrieben. Eigentlich wäre 
es schlussendlich ja am besten, wenn man bei jedem Bauteil bzw. bei 
jedem Preis eines Bauteiles die Währung separat angeben kann. Dann kann 
man Teile, die man im Ausland (wo eine andere Währung gilt) kauft, in 
der tatsächlichen Währung erfassen, und muss es nicht selber umrechnen.

Irgendwie könnte man dann bestimmt auch noch die aktuellen Wechselkurse 
aus dem Internet holen um Preise in fremden Währungen zusätzlich auch 
noch in der eigenen Währung anzeigen zu lassen (oder man gibt die 
Wechselkurse alternativ auch manuell ein).

Wir könnten dann eine currencymgr.php erstellen, wo man all seine 
verwendeten Währungen inkl. Wechselkurs (bzw. URL wo man den Wechselkurs 
bekommt) verwalten kann. Dort kann man dann auch gleich die 
Standardwährung wählen, die halt vorzugsweise verwendet werden soll.

Ich als Schweizer habe schon ein paarmal in DE eingekauft und würde 
diese Funktion natürlich sehr begrüssen :-) Dann sehe ich auch wie die 
Teile aus DE immer günstiger werden mit der Zeit (der Eurokrise sei 
dank)^^

Wenn da niemand was dagegen einzuwenden hat, schreibe ich das noch in 
unsere Issues.

Bezüglich des Debug-Logs bin ich mir mittlerweile nicht mehr sicher ob 
es wirklich vorteilhaft ist wenn die Meldungen in der Datenbank abgelegt 
werden. Bei Problemen mit der Datenbank gibts dann nämlich auch kein 
Debugging mehr, was relativ unpassend ist :-)
Ausserdem müsste man aktiv Endlosschleifen bekämpfen wenn es 
Datenbankprobleme gibt. Meldet eine Funktion (die etwas mit der 
Datenbank machen will) ein Fehler, kommt die Log-Funktion, die natürlich 
ebenfalls auf die Datenbank zugreifen will, dieser Zugriff führt dann 
aber wieder zu einer neuen Fehlermeldung, die geloggt werden will, und 
so dreht sich das System dann im Kreis :-)

Der ganze Debug-Kram sollte daher eigentlich möglichst unabhängig vom 
ganzen Rest des Systems funktionieren. Um die Logs zu speichern wäre die 
einzige Möglichkeit dann wohl nur noch mit Dateien. Vielleicht könnte 
man dazu eine XML-Datei verwenden, damit man trotzdem noch einigermassen 
vernünftig mit Attributen usw. arbeiten kann.

Klar, wenn die Schreibrechte fehlen funktioniert auch dieses System 
nicht. Allerdings kann man die Schreibrechte prüfen, und bei der Ausgabe 
der Logs dann eine Meldung bringen "Sie haben keine Schreibrechte, es 
können keine Meldungen geloggt werden", dann weiss man direkt wo das 
Problem liegt.

Ich habe jetzt mal eine dateibasierte Version des Debug-Systems in 
meinen Branch hochgeladen. Die Klasse heisst "debug_log.php" und die 
Debug-Seite ist "debug.php".

Das Ganze funktioniert so:
Existiert eine Datei "log/debug_log.xml", heisst das, dass das Logging 
aktiv ist, und neue Meldungen landen in dieser Datei. Existiert keine 
solche Datei, gilt das Logging automatisch als deaktiviert.

Damit später (wenn es die Benutzerverwaltung gibt) die einfachen 
Benutzer keinen Zugriff aufs Debug-System haben, habe ich einen 
Passwortschutz eingebaut. In der Datei "log/debug_log_password.txt" 
speichert man einfach den MD5-Hash des gewünschten Passwortes ab. Ich 
habe es bewusst so "steinzeitmässig" gemacht, damit die Debugklasse 
keinen Zugriff auf die Datenbank braucht (um Admin-Berechtigungen zu 
prüfen), aber trotzdem gewissermassen geschützt ist. Ist das Logging 
aktiv, können zwar die Benutzer theoretisch ebenfalls die Meldungen 
anschauen und das Logging deaktivieren. Es liegt dann halt beim 
Administrator, dass er das Debugging auch wieder deaktiviert (und damit 
automatisch auch alle Logs löscht, weil die Datei dann weg ist). 
Aktivieren kann man das Logging nur mit dem oben genannten Passwort.

Tauchen in der Debugklasse selber Fehler auf, werden diese ebenfalls 
erfasst und können per Klassenmethode get_class_errors() geholt werden.

Funktionieren tuts soweit schonmal ziemlich gut. Aber wie immer bei mir 
gilt: Es ist erstmal nur ein Test, es kann sich noch einiges ändern :-)

So, nach langem Rumprobieren scheint jetzt das Datenbankupdate für das 
neue Lieferantensystem zu funktionieren (Tabelle "orderdetails"). Ich 
hoffe das passt so. Ausserdem werden die Tabellen "datasheets" und 
"pictures" zu einer einzigen Tabelle "files" zusammengefasst.

https://code.google.com/p/part-db/source/browse/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

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

b.r schrieb:
> Urban B. schrieb:
>> Ne also ohne Klassen läuft eigentlich überhaupt nichts aus meinem
>> Branch. Man müsste extra neue Funktionen schreiben um diese Features in
>> den Trunk übernehmen zu können.
> Na dann wird es Zeit, die Klassen in den Trunk zu holen, oder?!

Das kommt schon noch, aber das braucht schon seine Zeit bis auch 
wirklich alles vernünftig läuft :-)
Ich habe jetzt einen neuen Branch "uneist_kami89" angelegt, in dem die 
beiden Branches "uneist" und "kami89" verschmolzen werden.

mfg

Hi, hab grade mal versuch den Brunch "uneist_kami89" zu installieren 
kann das sein das es ein Pfade Problem gibt ?

Jedenfalls wen es nicht im Hauptordner liegt das hat mich auch schon 
immer bei der org. Version gestört gehabt das man bei keine Absoluten 
Pfade angeben konnte, wehre noch was für die ToDo liste ebenso wie 
absolute WEB Pfade das würde auch viele Probleme Lösen z.b. bei der 
Mobile Version ist mir das schon sehr unangenehm aufgefallen(die Mobile 
Version wehre mit den Brunch eh obsolet da das über das neue 
Templatesystem gut umzusetzen wehre).



Ansonsten schon mal ein Fettes LOB an kami und die anderen.

K. J. schrieb:
> Hi, hab grade mal versuch den Brunch "uneist_kami89" zu installieren
> kann das sein das es ein Pfade Problem gibt ?

Hallo K.J.!
Meinst du die Pfade der include-Anweisungen? Oder welche Pfade meinst 
du?
Ich kann hier grad kein Pfade-Problem feststellen, bräuchte also mehr 
Informationen von dir um das nachvollziehen zu können.

K. J. schrieb:
> Jedenfalls wen es nicht im Hauptordner liegt das hat mich auch schon
> immer bei der org. Version gestört gehabt das man bei keine Absoluten
> Pfade angeben konnte, wehre noch was für die ToDo liste ebenso wie
> absolute WEB Pfade das würde auch viele Probleme Lösen

Hmm meinst du die Pfade für Bilddateien/Datenblätter? :-)
Da dachte ich, dass man nur den zum Hauptordner relativen Pfad verwenden 
soll. Nur für Dateien ausserhalb des Hauptordners sollen über den ganzen 
Pfad angesprochen werden.

K. J. schrieb:
> z.b. bei der
> Mobile Version ist mir das schon sehr unangenehm aufgefallen(die Mobile
> Version wehre mit den Brunch eh obsolet da das über das neue
> Templatesystem gut umzusetzen wehre).

Jup, ich denke mal für eine mobile Version wird es dann ein extra 
Template geben.

K. J. schrieb:
> Ansonsten schon mal ein Fettes LOB an kami und die anderen.

Dankeschön :-)

P.S.
Ich habe gleich nochmal eine neue Version ins SVN geladen mit einigen 
Änderungen.

So, ich habe jetzt (r533) noch ein System eingebaut, um auf jeder Seite 
möglichst einheitlich und einfach Fehlermeldungen/Bestätigungsmeldungen 
und Sicherheitsnachfragen (z.B. beim Löschen) ausgeben zu können.

In der Datei supmgr.php ist dies sehr schön zu sehen (es handelt sich um 
das Array $messages). Beim Anlegen und Bearbeiten von Lieferanten 
erscheinen Bestätigunsmeldungen bzw. Fehlermeldungen am oberen Rand, 
beim Löschen erscheint die Sicherheitsnachfrage in dieser Box.

(Durch die ganzen Exceptionhandler wirkt die supmgr.php leider schon 
langsam etwas unübersichtlich. Vielleicht lässt sich da noch was 
verbessern...)

Falls schwerwiegende Fehler im Skript auftreten, so wird nur diese Box 
mit den Fehlermeldungen ausgegeben, der Rest der Seite wird dann nicht 
angezeigt (es folgt aber noch ein "Reload"-Button um wieder zur 
vollständigen Seite zu kommen falls der Fehler z.B. durch eine per 
POST/GET übermittelte Variable entstanden ist).

Ich denke, das Ziel wären schlussendlich dann mal schöne JavaScript 
Dialoge, die auch optisch was hermachen. Aber mit JavaScript kenne ich 
mich zu wenig aus, und irgendwann muss die neue Version ja auch mal 
fertig werden :-)

Auch habe ich das "Bedienkonzept" der supmgr.php etwas abgeändert. Am 
besten schaut ihr es euch selbst an, der Branch müsste eigentlich so 
Funktionieren (voraussetzung ist aber eine Datenbank der Version 12!). 
Ich hoffe ihr seit damit einverstanden :-)

So und jetzt ab ins Bett xD

Urban B. schrieb:
> K. J. schrieb:
>> Hi, hab grade mal versuch den Brunch "uneist_kami89" zu installieren
>> kann das sein das es ein Pfade Problem gibt ?
>
> Hallo K.J.!
> Meinst du die Pfade der include-Anweisungen? Oder welche Pfade meinst
> du?
> Ich kann hier grad kein Pfade-Problem feststellen, bräuchte also mehr
> Informationen von dir um das nachvollziehen zu können.
>
Naja wir haben ja immer Dateipfade Relativ angegeben also z.b. 
img/blablub.png,  sinnvoller ist es dieses in der Config zu erweitern 
z.b. bei Bineren Dateien oder Uploadordnern ...:

${Pfaddateisystem}/blablub.png  = /var/www/...../blablub.png

Bei PHP Dateien den webpfad:

${Relativerpfad}/start.php = http://example.com/...../start.php

Warum ist auch eigentlich klar bei den Brunch wird das sichtbar mal 
greift z.b. die nav.php auf templates... zu mal ist es andersrum da 
greift das Template auf Dateien im Hauptordner von der Partdb zu da 
klappt das mit den Relativen Pfaden nicht mehr.

Ich hoffen das war jetzt verständlich.

Ich hab das nie gemacht gehabt weil ich nie gedacht hätte das es so 
viele Leute nutzen würden das würde auch eine ganze mänge Probleme 
anderer USER Lösen.

http://partdb.grautier.com/uneistkami89/ wehre nen beispiel das es nicht 
geht so wie es ist sieht man im html Quellcode recht gut wen die 
Installation im Hauptordner der subdomain wehre würde es gehen im 
unterordner nicht.

b.r schrieb:
> Torsten C. schrieb:
>> Wird die Liste denn noch gepflegt,
> Ja.
>
>> oder gibt es noch mehr Listen?
> Nein.
>
>> b.r schrieb:
>>> Damit würde die aufwändige, unkomfortable Suche nach dem passenden
>>> Bauteil in der entsprechenden PCB-Software entfallen.
>> Und wie genau geht das dann weiter, z.B. in Eagle? Im Lib-Browser muß
>> ich das Bauteil doch eh suchen, oder kann man das Bauteil per Drag&Drop
>> aus der Part-DB in den Schaltplan schieben?
> Ich könnte mir vorstellen, das man die benötigten Teile als Lib aus
> part-db exportiert und dann alles an einem Platz hat.
>
> Grüße
> b.r

Dazu habe ich noch eine Idee, wir haben hier in der Firma das Problem 
das 2 Entwickler jeweils eine eigene Bauteil-bibliothek aufgebaut haben.

Ich habe jetzt mal angefangen die Bibliotheken zusammenzufassen, dabei 
habe ich einen SVN-Server aufgesetzt. Dadurch das Eagle 6 jetzt 
XML-Dateien einsetzt geht das ziemlich gut.

Ich ahbe das ganze so eingerichtet das es einen trunk gibt in dem alle 
Bibliotheken gepflegt werden und jeder Entwickler einen eigenen brunch 
hat in dem er seine eigene Bibliothek pflegen kann, so kann es nicht 
passieren, dass wenn Entwickler A eine Änderung an einem Bauteil macht 
Entwickler B ebenfalls betroffen ist.

Weiter geplant ist dann, das die Entwickler einmal im Monat einen tag 
ihres branches anlegen und diese wieder in den trunk übernommen werden.

Wenn man ein SVN im Netz aufsetzen möchte reicht es wahrscheinlich aus 
wenn man einen trunk anlegt wo nur wenige Leute Schreibzugriff haben 
aber jeder Lesezugriff und einen bruch wo jeder dann Bibliotheken 
einreichen kann. Ein paar Freiwillige pflegen die Bauteile dann in den 
trunk ein.

Wenn man sowas in Angriff nimmt sollte man sich aber ein paar Gedanken 
über 'Guidlines' machen, sonst findet man in der Bibliothek kaum etwas.
Ich habe mal eine Bibliothek angehangen wie ich das bei uns umgesetzt 
habe.

Ich habe mal noch ein Bild von ein paar Bauteilen angehangen wie das in 
3D aussieht, die können zwar nicht mir Eagle3D oder EagleUP mithalten, 
können dafür aber von einem Gehäuse-Designer im CAD-Programm verwendet 
werden.

Wer Interesse hat sowas aufzubauen, kann sich mal melden. Ich hätte da 
sogar noch einen kleinen V-Server zum testen mit der Domain pcb-parts.de 
:-)

K. J. schrieb:
> Naja wir haben ja immer Dateipfade Relativ angegeben also z.b.
> img/blablub.png,  sinnvoller ist es dieses in der Config zu erweitern
> z.b. bei Bineren Dateien oder Uploadordnern ...:
>
> ${Pfaddateisystem}/blablub.png  = /var/www/...../blablub.png

Ja, intern wird jetzt eigentlich auch mit absoluten Pfaden gearbeitet, 
dazu gibt es die Konstante BASE, die in der start_session.php definiert 
wird, und zwar mit dirname(_FILE_). Ich denke das sollte eigentlich 
ein gutes System sein, da _FILE_ ja immer den kompletten Pfad zur 
start_session.php liefert, also müsste dirname(_FILE_) dann den Pfad 
der Part-DB Installation sein. Und _FILE_ ist auch unabhängig davon, 
aus welcher Datei heraus nun die start_session.php included wurde, es 
liefert immer den Pfad zur start_session.php.

Für die HTML-Ausgabe denke ich aber es ist besser wenn das 
Serververzeichnis (z.B. "/var/www/") wieder entfernt wird. Ich finde es 
geht niemeanden was an, in welchem Ordner Part-DB installiert ist.

Fürs HTML sollte es da doch keine Probleme geben, wenn man für 
Dateipfade immer alles nach dem "var/www" verwendet, also z.B. 
"/part-db/img/partdb/favicon.ico" für die Favicon-Deklaration im 
HTML-Header, oder liege ich da falsch? (Der komplete Pfad der Datei wäre 
dann "/var/www/part-db/img/partdb/favicon.ico")

K. J. schrieb:
> Warum ist auch eigentlich klar bei den Brunch wird das sichtbar mal
> greift z.b. die nav.php auf templates... zu mal ist es andersrum da
> greift das Template auf Dateien im Hauptordner von der Partdb zu da
> klappt das mit den Relativen Pfaden nicht mehr.

Nein, in PHP wird es nicht zu Problemen führen, da immer mit der 
BASE-Konstante gearbeitet wird bei den includes, also z.B. 
include_once(BASE.'/lib/class.HTML.php');
Es gibt allerdings eine einzige Ausnahme, und das ist die 
start_session.php, weil vor dem Includen dieser Datei die BASE-Konstante 
ja noch nicht existiert. Aber da man in jeder PHP-Datei ja weiss, wo die 
start_session.php (relativ zur ausgeführten Datei) liegt, kann man diese 
auch ohne Probleme mit dem relativen Pfad einbinden.

K. J. schrieb:
> http://partdb.grautier.com/uneistkami89/ wehre nen beispiel das es nicht
> geht so wie es ist sieht man im html Quellcode recht gut wen die
> Installation im Hauptordner der subdomain wehre würde es gehen im
> unterordner nicht.

OK da scheint aber das Problem zu sein, dass in den Pfaden im Header der 
beginnende Slash fehlt. Ich habe mal eine neue Revision hochgeladen, 
probier die mal aus, ich hoffe dann funktionierts.

Ich werde wohl in der start_session.php noch eine Konstante 
DOCUMENT_ROOT anlegen, die dann immer den Pfad nach z.B. "/var/www/" 
beinhaltet. Ich vermute nämlich, dass bei dir $_SERVER['DOCUMENT_ROOT'] 
keinen Slash am Ende hat, bei mir aber schon. Deshalb würde es Sinn 
machen, eine Konstante DOCUMENT_ROOT anzulegen, die dann immer 
definierte Slashes hat, damit man sich in den Skripten nicht mehr darum 
kümmern muss.

So, jetzt ist das Pfade-Problem in der Online Demo behoben, scheint wohl 
wirklich an der Inkonsistenz der Variable $_SERVER['DOCUMENT_ROOT'] 
gelegen haben.

Jetzt werden also absolute Pfade ausgehend vom DOCUMENT_ROOT verwendet, 
so wie hier beschrieben: 
http://de.selfhtml.org/html/allgemein/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

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.

K. J. schrieb:
> Jup hab das alles noch nicht ganz fertig wollte am Anfang beim aufrufen
> eine Auswahlseite machen in der man die normale oder den Brunch zum
> testen ausmehlen kann.

OK, super!

> So langsam wirds werde mich die tage mal in das neue System reinleasen
> sieht jedenfalls ziemlich gut aus bis jetzt.

Du wirst nicht mehr viel von den alten Funktionen wiedererkennen, soviel 
kann ich dir schonmal sagen :-)
Als "Musterbeispiel" um zu schauen wie die Klassen verwendet werden, 
empfehle ich die supmgr.php, die sieht jetzt etwa so aus wie ich mir das 
vorgestellt habe.

Wird jetzt beim Demoserver eigentlich auch schon täglich eine neue 
Datenbank eingespielt?

Urban B. schrieb:
> K. J. schrieb:
>
> Wird jetzt beim Demoserver eigentlich auch schon täglich eine neue
> Datenbank eingespielt?

Nein noch nicht bin in MYSQL noch nicht so fit bin aber dabei.

hab die Startseite fertig vielleicht hat ja einer noch eine 
Verbesserungs Idee

http://partdb.grautier.com/

Aso fast vergessen zur fehlenden Tabelle hab mal in die DB geschaut 
"name" gibt es nicht als ROW aber "filename" ? ist das vielleicht das 
Problem ?

EDIT: Jup dadran lag es

K. J. schrieb:
> Nein noch nicht bin in MYSQL noch nicht so fit bin aber dabei.

OK alles klar.

> hab die Startseite fertig vielleicht hat ja einer noch eine
> Verbesserungs Idee
>
> http://partdb.grautier.com/

Cool! Aber irgendwie scheint es ein Problem mit dem Zeichensatz zu 
geben, bei mir werden ä, ö, ü nicht richtig angezeigt...

K. J. schrieb:
> Aso fast vergessen zur fehlenden Tabelle hab mal in die DB geschaut
> "name" gibt es nicht als ROW aber "filename" ? ist das vielleicht das
> Problem ?

ne es müsste eigentlich beides geben, "name" und "filename". Mit "name" 
kann man dann nämlich den Dateien auch gescheite Namen geben wie z.B. 
"AVR AppNote AN123" oder "Anschlussschema" usw.

In der db_update_steps.php sieht die entsprechende Stelle so aus:

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

Ok so geht das danke.


Werde mich eh nochmal mit Mysql rumschlagen müssen man kommt neuerdings 
an die komplette Reichelt Datenbank ran ich schaue mir das ganze grade 
an ob man die vielleicht sinnvoll Parsen und bereitstellen kann leider 
ist das ganze in einem recht großen SQLLite File ich wandel das grade um 
aber das wird ne kleine Ewigkeit dauern das ganze in eine Mysql DB zu 
Quetschen b.z.w. vorher nur das wichtige rauszufiltern da da z.b. Bilder 
als Binery Blob drinnen sind.

Wehre noch mit Reichelt abzuklären ob das erlaubt ist, entweder die User 
müssen die Datei selber runterladen, oder Reichelt erlaubt das 
bearbeiten dann würde ich das ganze in eine Mysql DB stopfen als Mirror 
bereitstellen müsste man wen es was wird halt mal erfragen.

Hmm ja wäre cool wenn man dann direkt Teile aus der Reichelt Datenbank 
in die eigene Part-DB importieren könnte.

Ich habe grad noch den Branch aktualisiert, jetzt werden noch zwei 
zusätzliche Konstanten in der config.php verlangt. Und zwar die Befehle 
bzw. Pfade zu "mysqldump" und "mysql", welche dann per exec() für die 
Datenbankbackups und -wiederherstellung verwendet werden können.

Könntest du diese beiden Konstanten noch in die config.php des 
Demo-Servers aufnehmen? Eine Vorlage gibts wie immer in der 
config.php_template. Und könntest du eine Datenbank der Version 12 in 
den backup-Ordner legen? Wenn dann die Backup/Restore Funktion 
funktioniert, kann ich auch selber die Datenbank der Demo wieder auf die 
Version 12 zurücksetzen wenn es mal nötig ist oder ich was ausprobieren 
möchte. Dann brauchen wir die tägliche Datenbankwiederherstellung 
eigentlich gar nicht, wenn ich es manuell machen kann ist das sogar noch 
besser :-)

Gescheite Fehlermeldungen von den exec() Befehlen gibt es übriegens noch 
nicht, das kommt später noch. Aber immerhin sollte zuverlässig erkannt 
werden ob es erfolgreich war oder nicht :-) Dann sollten wenigstens 
keine leeren Backup-Dateien mehr entstehen, was vorher ziemlich 
"gefährlich" war.

EDIT:
Der Fehler in der "files" Tabelle war übrigens nicht der einzige Fehler. 
Auch "id_manufacturers" fehlt in der Tabelle "parts"...

EDIT2:
Übrigens muss nach dem nächsten SVN Update sowieso wieder eine Datenbank 
der Version 12 eingespielt werden. Falls die Backup/Restore Funktion 
nicht funktioniert, wäre ich froh wenn du noch von Hand schnell eine 
neue (bzw. alte) Datenbank einspielen könntest :-)

Hi,

Das mit den EXEC geht nicht bei mir das auch aus Gutten Grund es ist ein 
echter Server da ist das nicht sinig.

ich könnte dir mysqldumper aufsetzen für die DemoDBs wen du möchtest.

hm vielleicht sollte ich DB noch mal komplett neu einspielen und schauen 
wo der Fehler liegt.

Ansonsten hab ich hier noch dayli Backups der letzten 5 jahre ;-)

Zur DB von reichelt es ist etwas schwerer als gedacht die sqllite DB ist 
AES Verschlüsselt, stehe aber grade mit Reichelt im Kontakt der 
FB-Zuständige sagte das es da wohl ne API für gibt, die frage ist halt 
ob wir daran dürfen und in welcher form.

> Das mit den EXEC geht nicht bei mir das auch aus Gutten Grund es ist ein
> echter Server da ist das nicht sinig.

Ach so okay :-)

> ich könnte dir mysqldumper aufsetzen für die DemoDBs wen du möchtest.

Eigentlich könnten wir doch mysqldumper auch gleich in Part-DB mit 
einbauen oder? Ich schaue mir das mal an wie das so funktioniert.

> hm vielleicht sollte ich DB noch mal komplett neu einspielen und schauen
> wo der Fehler liegt.

Jo ich denke mal nach dem Einspielen einer neuen Datenbank sollte das 
Problem behoben sein. Ich mache halt nicht für jedes Datenbankupdate ein 
neues "case" in die Updatefunktion weil es sonst schnell sehr viele 
"cases" geben würde :-) Deshalb muss man dann halt von Zeit zu Zeit 
wieder eine Datenbank der Version 12 einspielen...

> Ansonsten hab ich hier noch dayli Backups der letzten 5 jahre ;-)

Hehe ja ich denke darin sollten wir was passendes finde :-)

> Zur DB von reichelt es ist etwas schwerer als gedacht die sqllite DB ist
> AES Verschlüsselt, stehe aber grade mit Reichelt im Kontakt der
> FB-Zuständige sagte das es da wohl ne API für gibt, die frage ist halt
> ob wir daran dürfen und in welcher form.

Okay, bin gespannt was da noch rauskommt.

mfg

Hmm MySQLDumper ist ja ein ganz geiles Ding! Es in Part-DB einzubinden 
macht aber eher wenig Sinn da es ja was komplett eigenständiges ist.

Allerdings sollte es später, wenn es Systemupdates für Part-DB gibt, 
auch direkt aus Part-DB heraus aufgerufen werden können. Denn immer vor 
einem Systemupdate sollte die Datenbank automatisch gesichert, und bei 
einem misslungenen Update wiederhergestellt werden.

Ich habe im MySQLDumper Forum gelesen dass es ab der Version 2 auch eine 
API für einen solchen externen Aufruf geben soll, das wäre dann 
natürlich super. Vielleicht kommt die Version 2 ja heraus bevor unser 
Updatesystem fertig ist, dann hat sich das Problem auch erledigt :-D

Ich denke also, dann werden wir die Backup/Restore Funktion komplett aus 
Part-DB entfernen, und stattdessen vielleicht irgendwo einen Hinweis 
platzieren dass man dafür MySQLDumper benutzen kann.

Dann bräuchten wir also doch noch etwas für den Demo Server, um alte 
Datenbanken wiederherzustellen.

So, ich habe jetzt die config.php nochmal etwas verändert. Die 
Einstellungen werden nun nicht mehr in der Datenbank gespeichert, 
sondern in einem Array, das in der config.php liegt.

Der Grund dafür ist, dass es einfach ein paar Einstellungen gibt, die 
auch funktionieren sollen wenn die Datenbank aufgrund eines Fehlers 
nicht gelesen werden kann. Der Nachteil ist halt, dass nun die 
Einstellungen bei einem Datenbankbackup nicht mitgesichert werden. Aber 
so wirklich wichtig sind diese Einstellungen eh nicht, die hätte man 
schnell wieder eingestellt wenn sie wirklich mal verloren gehen 
würden...

@K.J. könntest du bitte bei Gelegenheit eine neue config.php erstellen 
(Vorlage gibts wie immer in der config.php_template)? Nachher kann man 
übrigens auch die Datenbank-Verbindungsparameter bequem über Part-DB 
einstellen, was ich aber noch mit einem Passwortschutz versehe weil 
sonst ja jeder die Online Demo lahmlegen könnte^^ Daher solltest du in 
$config['admin']['password'] ein MD5-Hash eines Passwortes abspeichern 
(oder einfach irgendwas reinschreiben damit es komplett gesperrt wird).

mfg

@K.J.

Wie ich sehe, hast du den Menüeintrag "System" nun entfernt in der 
Online Demo. Ich vermute mal du willst nicht, dass man die 
Datenbank-Verbindungsparameter sehen kann :-)

Dazu habe ich jetzt noch einen neuen Parameter in der config.php 
hinzugefügt. Stellt man $config['is_online_demo'] auf 'true', dann 
werden die Verbindungsparameter ausgeblendet, der "Übernehmen" Button 
ist deaktiviert (und in der php ist nochmals ein Schutz damit keine 
neuen Werte übernommen werden können), und in der Systemkonfiguration 
wird die PHP-Version ausgeblendet.

Alle anderen Einstellungen sind unbedenklich, da dürfen die Leute auch 
ruhig dran rumschrauben. Auch auf der Debug-Seite kann man eigentlich 
kein Unfug treiben.

Ich finde es in den Online-Demos immer schade wenn die 
Konfigurationsseiten ausgeblendet werden, ich jedenfalls interessiere 
mich immer dafür, was man denn alles so einstellen kann :-)

Wäre das so in Ordnung für dich? Dann müsstest du einfach noch den 
entsprechenden Parameter in der config.php auf 'true' stellen. Sorry 
dass ich immer an der config.php rumschraube ;-)

Das entsprechende Update lade ich heute noch ins SVN. Übrigens habe ich 
die config.php_template etwas umgebaut. Und zwar heisst die jetzt 
config_defaults.php, wo alle Parameter auf Standardwerte gesetzt werden. 
Diese wird direkt vor der config.php included, somit beinhalten alle 
Parameter, die in der config.php nicht existieren, automatisch die 
Standardwerte. Auch muss man die config.php gar nicht mehr von Hand 
anlegen beim Installieren von Part-DB. Beim ersten Start sind einfach 
die Standardeinstellungen aktiv, was sicherstellt, dass das Skript 
vollumfänglich funktioniert, bis auf die Datenbankverbindung natürlich. 
Dann stellt man einfach über "System" -> "Datenbank" die 
Verbindungsparameter und über "System" -> "Konfiguration" die anderen 
Einstellungen ein, und die config.php wird automatisch angelegt.

mfg

WoW sieht echt gut aus !!!

K. J. schrieb:
> WoW sieht echt gut aus !!!

Danke :-)

Wie soll eigentlich die neue Version heissen, was meint ihr?
0.2.3? 0.5.0? 1.0.0? sonstwie? (wobei dann zuerst aber mal release 
kandidaten erscheinen, also z.B. als "1.0.0 RC1" veröffentlicht werden 
würden)

Ich kann mich nicht entscheiden :-)

Zurück aus meinem Mini-Urlaub ;-) Ich werde mir die nächsten Tage mal 
den gemeinsamen Branch vornehmen und dort weiter machen.

Nach meiner Meinung wäre wohl eine Versionbezeichung 0.3.x besser 
geeignet, denn ausser einem Rewrite ist ja praktisch nichts neues 
hinzugekommen. Wenn die Benutzerverwaltung und ein paar andere Wünsche 
eingebaut sind, wäre der Sprung auf eine 1er Version sinvoll.

Grüße
Udo

Udo Neist schrieb:
> Zurück aus meinem Mini-Urlaub ;-) Ich werde mir die nächsten Tage mal
> den gemeinsamen Branch vornehmen und dort weiter machen.

Na dann willkommen zurück :-)
Bei einigen Seiten habe ich die Templates gleich selber angelegt, nach 
etwas Einarbeiten in die von dir erstellten Seiten ging das ganz gut :-)

> Nach meiner Meinung wäre wohl eine Versionbezeichung 0.3.x besser
> geeignet, denn ausser einem Rewrite ist ja praktisch nichts neues
> hinzugekommen. Wenn die Benutzerverwaltung und ein paar andere Wünsche
> eingebaut sind, wäre der Sprung auf eine 1er Version sinvoll.

Jo, macht Sinn. Ich nehme mal "0.3.0 RC1" für die erste neue Version 
wenn da niemand was dagegen einzuwenden hat.

Ach ja, ich lade jetzt eigentlich täglich meine Änderungen ins SVN hoch. 
Wäre gut wenn du das auch tun würdest wenn du weiter an unserem Branch 
arbeitest, damit wir kein Durcheinander bekommen.
Und unsere beiden alten Branches sind nun zwar völlig nicht mehr 
aktuell, aber ich würde da nichts löschen weil es dort noch Dateien 
gibt, die ich (noch) nicht in den neuen Branch übernommen habe. Also 
wenn du im neuen Branch etwas vermisst, dann schau mal im alten Branch 
nach :-)

mfg

EDIT:
Übrigens, wozu haben wir eigentlich in der get_svn_revision() eine 
Variante mit shell_exec() und eine, die die SVN Dateien ausliest? 
Zweiteres müsste doch eigentlich immer funktionieren, und könnte deshalb 
doch gleich immer verwendet werden, oder?

> Na dann willkommen zurück :-)
> Bei einigen Seiten habe ich die Templates gleich selber angelegt, nach
> etwas Einarbeiten in die von dir erstellten Seiten ging das ganz gut :-)

So schwer ist die Template-Engine ja nicht zu verstehen :-) Smarty & Co 
sind schwerer.

> Jo, macht Sinn. Ich nehme mal "0.3.0 RC1" für die erste neue Version
> wenn da niemand was dagegen einzuwenden hat.

Ok.

> Ach ja, ich lade jetzt eigentlich täglich meine Änderungen ins SVN hoch.
> Wäre gut wenn du das auch tun würdest wenn du weiter an unserem Branch
> arbeitest, damit wir kein Durcheinander bekommen.
> Und unsere beiden alten Branches sind nun zwar völlig nicht mehr
> aktuell, aber ich würde da nichts löschen weil es dort noch Dateien
> gibt, die ich (noch) nicht in den neuen Branch übernommen habe. Also
> wenn du im neuen Branch etwas vermisst, dann schau mal im alten Branch
> nach :-)

Ich hab unsere beiden, den gemeinsamen und den offiziellen Teil hier 
vorliegen. Man muss ja auch mal schauen, was man selbst für einen Mist 
gebaut hat, wenn eine Funktion nicht mehr will.

> EDIT:
> Übrigens, wozu haben wir eigentlich in der get_svn_revision() eine
> Variante mit shell_exec() und eine, die die SVN Dateien ausliest?
> Zweiteres müsste doch eigentlich immer funktionieren, und könnte deshalb
> doch gleich immer verwendet werden, oder?

Es würde die direkte Variante ausreichen, aber mit diesem Code wollte 
ich auch zeigen, dass man shell_exec() nicht ungeprüft verwenden kann. 
Nicht überall kann man auf diese oder ähnliche Funktionen zurückgreifen 
(Sicherheit).

Udo Neist schrieb:
> Es würde die direkte Variante ausreichen, aber mit diesem Code wollte
> ich auch zeigen, dass man shell_exec() nicht ungeprüft verwenden kann.
> Nicht überall kann man auf diese oder ähnliche Funktionen zurückgreifen
> (Sicherheit).

hm?
Eben genau deshalb meine ich ja, dass man die shell_exec auch gleich 
komplett entfernen könnte. Das Auslesen der SVN-Dateien sollte hingegen 
eigentlich doch IMMER funktionieren (oder zumindest nicht weniger häufig 
als shell_exec). Und wenn eine der beiden Varianten IMMER funktioniert, 
dann macht eine Fallunterscheidung ja gar keinen Sinn, dann kann man 
auch gleich die zuverlässigere der beiden nehmen.

In der eigentlichen Diskussion ging es ja nicht nur um 
get_svn_revision(), sondern eher um ein paar Stellen im Code, die 
ungeprüft solche Funktionen wie shell_execute() ausführen. Hab ja auch 
noch eine andere Funktion gefunden, die nicht überall anzutreffen ist 
und daher nachgebildet werden muss. Sowas steht oft nur in den 
Anmerkungen oder findet man in den Kommentaren.

Wo es sinnvoll ist, würde ich immer die direkte, über PHP nutzbare 
Version nehmen, bevor ich auf die Shell zurückgreifen muss. Schmeiß` 
also den Teil mit shell_execute() raus :-)

Udo Neist schrieb:
> In der eigentlichen Diskussion ging es ja nicht nur um
> get_svn_revision(), sondern eher um ein paar Stellen im Code, die
> ungeprüft solche Funktionen wie shell_execute() ausführen. Hab ja auch
> noch eine andere Funktion gefunden, die nicht überall anzutreffen ist
> und daher nachgebildet werden muss. Sowas steht oft nur in den
> Anmerkungen oder findet man in den Kommentaren.

Jup, das stimmt. Ich werde für solche Funktionen gleich noch eine eigene 
Datei "lib.functions.php" anlegen. Aber auch wenn jetzt noch an ein paar 
Stellen solche "problematischen" Funktionen genutzt werden würden, davon 
geht die Welt nicht unter :-) Für solche Dinge gibt es ja die 
Möglichkeit, dass die User hier im Forum Feedback geben können :-)

> Wo es sinnvoll ist, würde ich immer die direkte, über PHP nutzbare
> Version nehmen, bevor ich auf die Shell zurückgreifen muss. Schmeiß`
> also den Teil mit shell_execute() raus :-)

Schon geschehen :-)

Urban B. schrieb:
>
>> Nach meiner Meinung wäre wohl eine Versionbezeichung 0.3.x besser
>> geeignet, denn ausser einem Rewrite ist ja praktisch nichts neues
>> hinzugekommen. Wenn die Benutzerverwaltung und ein paar andere Wünsche
>> eingebaut sind, wäre der Sprung auf eine 1er Version sinvoll.
>
> Jo, macht Sinn. Ich nehme mal "0.3.0 RC1" für die erste neue Version
> wenn da niemand was dagegen einzuwenden hat.
>

Hi Ja ich wehre auch für 0.3.x.x denke die 1.x.x.x sollten wir uns für 
sehr stabiele Versionen aufbewahren.

So, ich habe jetzt mal angefangen den Source Code mit Doxygen 
Kommentaren zu kommentieren, um mal zu schauen ob da eine nützliche 
Dokumentation bei rauskommt. Denn bei den vielen Klassen verliert man 
schnell mal den Überblick welche Methoden/Attribute nun von welcher 
Klasse geerbt werden usw. Und das manuelle Zeichnen der Klassendiagramme 
bringts ja nicht wirklich, das ist viel zu aufwändig um die Diagramme 
aktuell zu halten.

Ein Beispiel, wo ich mit dem Kommentieren fertig bin, is die Klasse 
"Category". Hier ist die Dokumentation, die Doxygen erstellt hat: 
http://partdb.grautier.com/uneistkami89/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" :-)

Auch wenn ich noch nicht ganz hinter den neuen OOP-Code gestiegen bin, 
hab ich mal angefangen show_obsolete_parts.php auf Templates 
umzuschreiben. Desweiteren hatte ich noch einen Fehler in 
get_svn_revision() beseitigt. Es sollte settype($revision, 'integer') 
statt settype($svn, 'integer') heißen.

[Edit]
Fehler beim Upload. Ich muss die Änderungen nochmal einschecken :(

Revision 564 eingescheckt :-)

Zwei zusätzliche Dateien:

- apache2-part-db.conf ist für das Modul mod_xsendfile gedacht. Es ist 
für die schnellere Auslieferung von Dateien per X-SENDFILE-Header 
nützlich.

- Ich habe noch das Shell-Script svn.sh dazugepackt, die ein paar 
svn-Kommandos zusammenfasst. Wird später in ein neues Unterverzeichnis 
"development" verschoben, welches Tools für die Entwicklung aufnehmen 
soll. Im Release sollte man dieses Verzeichnis herausnehmen.

Udo Neist schrieb:
> Auch wenn ich noch nicht ganz hinter den neuen OOP-Code gestiegen bin,
> hab ich mal angefangen show_obsolete_parts.php auf Templates
> umzuschreiben.

Auf den ersten Blick wird man ein bisschen von den ganzen Klassen 
erschlagen, ich weiss :-) Aber dafür ist alles sehr strukturiert 
aufgebaut, es ist nichts mehr doppelt vorhanden usw. Nach ein bisschen 
Einarbeiten sollte es gut verständlich sein denke ich.

Um die Klassen besser zu verstehen, ist auch die Doxygen-Doku sehr 
geeignet, die auch die ganzen Klassendiagramme inkl. Vererbung zeigt.

Sehr zentral ist auf jeden Fall die Klasse "DBElement" mit den Methoden 
"set_attributes()", "check_values_validity()" und "add()". Die sollte 
man verstanden haben damit man auch den Rest versteht. Mit 
"check_values_validity()" werden alle Werte, die in die Datenbank 
geschrieben werden (beim Anlegen oder Bearbeiten eines Datensatzes) auf 
Gültigkeit überprüft und ggf. noch leicht angepasst. Jede Klasse lässt 
zuerst alle seine Elternklassen die Werte überprüfen, danach werden die 
Klassenbezogenen Werte überprüft.

Falls du etwas nicht verstehst helfe ich natürlich gerne weiter.

Udo Neist schrieb:
> - apache2-part-db.conf ist für das Modul mod_xsendfile gedacht. Es ist
> für die schnellere Auslieferung von Dateien per X-SENDFILE-Header
> nützlich.

Ah okay, und wird die Datei automatisch geladen oder muss die noch 
irgendwie eingebunden werden?

Udo Neist schrieb:
> - Ich habe noch das Shell-Script svn.sh dazugepackt, die ein paar
> svn-Kommandos zusammenfasst.

Ich frage mich, obs das wirklich braucht.
 - Tabs durch Leerzeichen ersetzen kann doch jeder (Quelltext-)Editor 
automatisch?
 - Dateien mit Tildezeichen gibt bei mir auch, werden aber von SVN nicht 
berücksichtigt. Ich vermute mal, das könnte man also irgendwie so 
einstellen dass solche Dateien ignoriert werden?

Bei deiner letzten Änderung wurden in Google Code einen Haufen Dateien, 
die du gar nicht bearbeitet hast, als bearbeitet markiert. Weisst du 
woher das kommt? Könnte es sein, dass dein Shell-Skript irgendwie etwas 
an den Dateien verändert hat?

> Wird später in ein neues Unterverzeichnis
> "development" verschoben, welches Tools für die Entwicklung aufnehmen
> soll. Im Release sollte man dieses Verzeichnis herausnehmen.

Jup, gute Idee!

mfg

Urban B. schrieb:

> Sehr zentral ist auf jeden Fall die Klasse "DBElement" mit den Methoden
> "set_attributes()", "check_values_validity()" und "add()". Die sollte
> man verstanden haben damit man auch den Rest versteht. Mit
> "check_values_validity()" werden alle Werte, die in die Datenbank
> geschrieben werden (beim Anlegen oder Bearbeiten eines Datensatzes) auf
> Gültigkeit überprüft und ggf. noch leicht angepasst. Jede Klasse lässt
> zuerst alle seine Elternklassen die Werte überprüfen, danach werden die
> Klassenbezogenen Werte überprüft.
>
> Falls du etwas nicht verstehst helfe ich natürlich gerne weiter.

Ich werde mich damit mal beschäftigen. Eigenen Code versteht man 
schneller, bei fremden dauert das ja immer ne Weile ;-)

> Udo Neist schrieb:
>> - apache2-part-db.conf ist für das Modul mod_xsendfile gedacht. Es ist
>> für die schnellere Auslieferung von Dateien per X-SENDFILE-Header
>> nützlich.
>
> Ah okay, und wird die Datei automatisch geladen oder muss die noch
> irgendwie eingebunden werden?

Ne, der gehört zum Apache-Webserver. Ich werde das wohl mal komplett 
fertig schreiben, damit man es in die Konfiguration des Webserver 
leichter einfügen kann.

> Udo Neist schrieb:
>> - Ich habe noch das Shell-Script svn.sh dazugepackt, die ein paar
>> svn-Kommandos zusammenfasst.
>
> Ich frage mich, obs das wirklich braucht.

Programmierer sind faul ;-) Immer wiederkehrende Aktionen werden halt in 
kleine Scripte ausgelagert. So ist halt svn.sh entstanden.

>  - Tabs durch Leerzeichen ersetzen kann doch jeder (Quelltext-)Editor
> automatisch?

Die meisten können das. Ich hab das allerdings hinzugefügt, um auch 
externen Code entsprechend anzupassen.

>  - Dateien mit Tildezeichen gibt bei mir auch, werden aber von SVN nicht
> berücksichtigt. Ich vermute mal, das könnte man also irgendwie so
> einstellen dass solche Dateien ignoriert werden?

Bei mir hat SVN auch schon mal diese Dateien hinzugefügt. Kommt auch 
darauf an, mit was man da arbeitet. Ich nutze hier nur die Konsole.

> Bei deiner letzten Änderung wurden in Google Code einen Haufen Dateien,
> die du gar nicht bearbeitet hast, als bearbeitet markiert. Weisst du
> woher das kommt? Könnte es sein, dass dein Shell-Skript irgendwie etwas
> an den Dateien verändert hat?

Es verändert nur PHP und Templates. Es werden ja nicht nur Tabs ersetzt, 
sondern auch die Leerzeichen von Leerzeilen gelöscht. In meinem Editor 
werden die Leerzeichen dann durch Punkte dargestellt, was etwas stört. 
Ich arbeite halt nicht mit Netbeans oder Eclipse, sondern mit dem schon 
etwas betagtem Quanta+.

>> Wird später in ein neues Unterverzeichnis
>> "development" verschoben, welches Tools für die Entwicklung aufnehmen
>> soll. Im Release sollte man dieses Verzeichnis herausnehmen.
>
> Jup, gute Idee!

Hab ich bei mir schon umgesetzt. Da drin ist auch die install.sh, die 
die Installation per Shell ermöglicht.

SVN merkt sich in der Datei schon, ob was modifiziert wurde. Es wird 
dann ein "M" angehängt. svnversion macht auch nicht viel anderes, als 
den Status zu interpretieren.

Hallo!

Kann es sein, dass das fertig gepackte Release-Paket nicht ganz aktuell 
ist?

Folgendes Paket habe ich geladen: PartDB-0.2.2.tar.gz vom Samstag, 2. 
Juni 2012 10:56

Trotz 0.2.2 im Dateinamen, erscheint in der Oberfläche nach der 
Installation die Version 0.2.1

So fehlt bei der Footprintverwaltung z.B. die Bilderzuordnung...

Die SVN-Version läuft leider auch nicht mit dem darin enthaltenen 
0.2.1er SQL-Init-Script aus readme/

Könnte jemand mal die aktuelle Version vom Demoserver zur Verfügung 
stellen oder zumindest ein SQL-Init-Script für den SVN-Versionsstand?

Danke!

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..? :-)

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

Hallo Leute,

Soeben habe ich eine neue Version hochgeladen (r567). Jetzt ist es auch 
möglich die Preise auf eine bestimmte Menge zu beziehen (z.B. 10Euro / 
100Stk.), was z.B. für Kabelschuhe, bei denen die Lieferanten die Preise 
häufig auf 10 oder 100 Stk. beziehen, nützlich ist. Dann ist man auch 
nicht mehr auf die Genauigkeit von 0,01 beschränkt, was vorher der Fall 
war. Das entsprechende Attribut heisst "price_related_quantity".

Und dann gibt es noch das Attribut "min_discount_quantity". Damit lassen 
sich verschiedene Preise für verschiedene Bestellmengen definieren 
(Stichwort Mengenrabatt).

Kleine Zusammenfassung wie das Lieferanten-/Preissystem aufgebaut ist:
- Jedes Bauteil kann 0+ Einkaufsinformationen ("Orderdetails") enthalten
- Jede Einkaufsinformation enthält genau einen Lieferanten, eine 
Bestellnummer (kann auch leer sein) und 0+ Preisinformationen 
("Pricedetails")
- Alle Einkaufsinformationen eines Bauteiles haben unterschiedliche 
Lieferanten (pro Lieferant maximal eine Einkaufsinformation)
- Hat eine Einkaufsinformation mindestens eine Preisinformation, so muss 
mindestens bei einer davon "min_discount_quantity = 1" sein

@K.J.
Wegen dem überarbeiteten Preissystem ist wieder eine Änderung der 
Datenbank nötig. Da es etwas "tiefergreifende" Änderungen sind, habe ich 
nicht einen neuen Updateschritt ("case") hinzugefügt, sondern das Update 
von v12 auf v13 entsprechend angepasst (ist sauberer so). Das bedeutet 
dann aber, dass man bei der Online Demo wiedermal eine 12er Datenbank 
einspielen müsste.

Übrigens habe ich in die "config_defaults.php" die zwei neuen Variablen 
$config['db']['backup']['name'] und $config['db']['backup']['url'] 
eingefügt, welche man z.B. für MySQLDumper verwenden kann. Kopiert man 
die entsprechenden beiden Zeilen in die config.php und gibt eine URL für 
MySQLDUmper ein, wird im Menü von Part-DB direkt ein Link zu MySQLDumper 
angezeigt.

Ah ja, wo wir grad beim Menü sind, für was war das Update r566 gedacht? 
:-) Jetzt erscheint die Doku als Untermenü von "Zu bestellende Teile"?! 
xD

mfg

Urban B. schrieb:
> Ah ja, wo wir grad beim Menü sind, für was war das Update r566 gedacht?
> :-) Jetzt erscheint die Doku als Untermenü von "Zu bestellende Teile"?!
> xD

Ups, habe nichts gesagt...Habs zu wenig genau angeschaut, da ist mir 
nicht aufgefallen dass mit der Revision 566 der Fehler aus der Revision 
565 behoben wurde ;-)

mfg

Da ja die Umstellung auf Templates dank Urban fast fertig ist, wäre es 
vielleicht sinnvoll, die Templates mehrsprachig auszuführen? Mir schwebt 
eine Ergänzung der class.HTML.php in der Art vor, das man beim Setzen 
einer Template-Variable prüft, ob es ein String ist und ob dafür eine 
Übersetzung existiert. Statische Texte werden natürlich auch 
berücksichtigt. Basis ist dabei die Variable $config['language'].

@Urban weist du ungefähr nen datum wo die 12er DB mal in der normalen 
PartDB Aktuell war ? Die DBs die ich rumliegen habe gehen alle nicht, 
sonst müste ich dummerweise stundenlang DB Backups ausprobieren um ne 
passende zu finden ;-(

Udo Neist schrieb:
> Da ja die Umstellung auf Templates dank Urban fast fertig ist, wäre es
> vielleicht sinnvoll, die Templates mehrsprachig auszuführen?

Ich finde dafür ist es noch zu früh. Ein Uploadmanager wäre momentan 
viel wichtiger, denn ohne den funktioniert das neue Konzept mit den 
Dateianhängen nicht wirklich gescheit.

K. J. schrieb:
> @Urban weist du ungefähr nen datum wo die 12er DB mal in der normalen
> PartDB Aktuell war ? Die DBs die ich rumliegen habe gehen alle nicht,
> sonst müste ich dummerweise stundenlang DB Backups ausprobieren um ne
> passende zu finden ;-(

Naja, die aktuellste Version aus dem SVN Trunk hat die Version 12, mit 
so einer müsste es gehen. Ich habe mal eine solche Datenbank hier 
angehängt, bei mir funktioniert diese einwandfrei.

mfg

Ah, jetzt scheint die Demo zu funktionieren, super!

Ich habe mal dem Bauteil "GS 14P" in der Kategorie "IC-Sockel" ein paar 
Einkaufsinformationen und Preise hinzugefügt, damit man die 
Möglichkeiten des neuen Preissystems sehen kann: 
http://partdb.grautier.com/uneistkami89/show_part_...

Was meint iht dazu? Verbesserungsvorschläge? Klar, das Bearbeiten dieser 
Einkaufsinformationen könnte man grafisch sicher noch etwas 
ansprechender gestalten. Falls jemand mal nicht weiss was er mit seiner 
Zeit machen will... :-D

Bei der Berechnung des Durchschnittspreises ist glaub noch ein Fehler in 
der Datenbankabfrage, also nicht wundern wenns mal nicht stimmt... ;-)

mfg

@K.J.
Hmm irgend etwas stimmt aber mit der Datenbank der Demo immernoch 
nicht... Kann es sein dass es in der Tabelle "parts" noch eine Spalte 
"id_supplier" gibt? Eigentlich hätte die beim Update von v12 auf v13 
gelöscht werden müssen, aber ich habe in der online Demo einen Fehler 
entdeckt der darauf hinweist, dass es diese Spalte noch gibt in der 
Tabelle "parts".
Könnte es vielleicht sein dass der Benutzer einfach zu wenige Rechte 
hat, z.B. um eine Tabellenspalte zu löschen?

@Udo Neist
Ich hänge gerade an einem "Problem" mit den Templates. Und zwar bin ich 
die Erzeugung der Tabellen am umgestalten, um sie universell einsetzen 
zu können (in der vlib_table.tmpl sollen die Tabellen für 
show_category_parts.php, show_device_parts.php, show_order_parts.php 
usw. generiert werden, aber halt mit unterschiedlichen Tabellenspalten.)

Das ist ansich eigentlich noch kein Problem. Aber sobald auf der 
gleichen Seite mehrere Tabellen gbraucht werden, funktioniert das nicht 
mehr so, weil der Name des Loops ja in der vlib_table.tmpl "hardgecoded" 
ist, man aber mehrere verschiedene solche Loops brauchen würde. z.B. für 
die Suchfunktion wäre es notwendig, damit man für jede Kategorie eine 
separate Tabelle zeichen kann. Oder in der show_device_parts.php werden 
auch zwei Tabellen gezeichnet wenn man nach einem Bauteil gesucht hat 
("Teile per Name zuordnen") und die Suchergebnisse aufgelistet werden.

Als erstes kam ich auf die Idee, einfach die erste und die letzte Zeile 
von vlib_table.tmpl in die aufrufende *.tmpl Datei auszulagern, um den 
Loops verschiedene Namen geben zu können. In diesen Dateien hätte dann 
der Aufruf etwa so ausgesehen:

<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

Möglichkeit 1: Lad das Template als String, ersetze den Namen des Loops 
und füttere den String an vlibTemplate. Man muss nicht unbedingt eine 
Datei übergeben.

Möglichkeit 2: Mach doch einfach einen 
TMPL_IF/TMPL_ELSEIF/TMPL_ELSE-Konstruktion daraus.

Grüße
Udo

Urban B. schrieb:
> @K.J.
> Hmm irgend etwas stimmt aber mit der Datenbank der Demo immernoch
> nicht... Kann es sein dass es in der Tabelle "parts" noch eine Spalte
> "id_supplier" gibt? Eigentlich hätte die beim Update von v12 auf v13
> gelöscht werden müssen, aber ich habe in der online Demo einen Fehler
> entdeckt der darauf hinweist, dass es diese Spalte noch gibt in der
> Tabelle "parts".
> Könnte es vielleicht sein dass der Benutzer einfach zu wenige Rechte
> hat, z.B. um eine Tabellenspalte zu löschen?
>

Jup stimmt ich werde das alles mal Manuell machen müssen wollte meine 
Daten in der DB lassen, aber das geht nicht weil das wohl irgendeine 
Buggy DB aus irgendeiner ... Version ist ;-)

Sorry, ich war hier einige Wochen nicht mehr aktiv. Bevor ich nun alle 
Threads der letzten Wochen lese, kann mir jemand sagen wie weit die 
Benutzerverwaltung ist (für myparts.info) ?
Apropos, anscheinend wird myparts.info nicht wirklich benutzt. Sollte 
das an verloren gegangenen Zugangsdaten usw. liegen, dann lasst es mich 
wissen.

Für alle die mit "myparts.info" nichts anfangen können, hier ist eine 
kurze Erklärung:
Ich habe die Domain myparts.info registriert, um damit jeden User die 
Möglichkeit zu geben Part-DB zu nutzen (selbstverständlich kostenlos).
Derzeit ist man einem Webspace abhängig.
Der eigentliche Vorteil von myparts.info ist jedoch der, dass man nicht 
alle Daten immer wieder von neuem eingeben muss, sondern dass man von 
den Daten der anderen Benutzer profitiert. Wenn z.B. Conrad den Preis 
für ein Bauteil anpasst und ein User diesen aktualisiert sehen alle User 
den aktuellen Preis. Das gleiche gilt für die Gehäuseformen, 
Datenblätter, usw.

...und falls einer der Entwickler es nicht mitbekommen haben sollte. Ich 
stelle jedem Entwickler Webspace und Datenbank zur Verfügung, welche zu 
Test- und Präsentations-Zwecken genutzt werden können (oder auch für 
anderes, wie FTP, usw.). Einfach eine PN an mich dann richte ich euch 
einen Account auf myparts.info ein.

Die Benutzerverwaltung ist, wenn überhaupt, nur ziemlich rudimentär 
vorhanden. Erstmal macht Urban die Umsetzung auf OOP fertig, bevor wir 
dann die Benutzerverwaltung integrieren. Ziel ist es, eine 
funktionsgleiche oder leicht erweiterte Version 0.3.0 als neue stabile 
Version zu veröffentlichen.

Udo Neist schrieb:
> Möglichkeit 1: Lad das Template als String, ersetze den Namen des Loops
> und füttere den String an vlibTemplate. Man muss nicht unbedingt eine
> Datei übergeben.

Das kann ich aber ja nicht innerhalb einer *.tmpl Datei machen, kann 
dann also auch nicht mehrere Tabellen innerhalb einer Template-Datei 
haben.

> Möglichkeit 2: Mach doch einfach einen
> TMPL_IF/TMPL_ELSEIF/TMPL_ELSE-Konstruktion daraus.

Hmm ich verstehe nicht, wie ich dann mehrere Tabellen in einer 
Template-Datei verwenden kann?

Ich habe es jetzt aber mal so gelöst, dass die Template-Dateien 
aufgeteilt werden. Pro Template-Datei ist dann zwar immernoch nur 
maximal eine Tabelle möglich, aber wenn mehrere Tabellen auf der 
gleichen Seite benötigt werden kann dann einfach die jeweilige 
Template-Datei mehrmals ausgegeben werden, halt jedesmal mit einem 
anderen Loop für die Tabelle. Ich vermute mal damit können wir leben...

K. J. schrieb:
> Jup stimmt ich werde das alles mal Manuell machen müssen wollte meine
> Daten in der DB lassen, aber das geht nicht weil das wohl irgendeine
> Buggy DB aus irgendeiner ... Version ist ;-)

Habe vorher grad noch gemerkt dass meine Datenbank, die ich hier 
gepostet habe, auch noch einen Bug enthält. Ein paar Teile haben nämlich 
einen Footprint zugeordnet, der gar nicht existiert. Kommt wohl daher 
dass es mal diese "gefährlichen" Checkboxen bei den Footprints gab, mit 
denen man ruck zuck ein paar Footprints löschen konnte xD Jetzt mit den 
Klassen fällt das auf, da die Klassen eine Exception werfen wenn so ein 
Fall eintritt...(was auch so gewollt ist)

@Christian R.
Wie Udo schon geschrieben hat wird erstmal der gesamte Code auf OOP 
umprogrammiert, und das dauert eben seine Zeit. Klingt relativ 
unspektakulär, aber mal in Zahlen ausgedrückt sind das ca. 8'000 (!) 
Codezeilen, die bisher neu geschrieben wurden.

Die Benutzerverwaltung existiert momentan nur so als "Dummy", also als 
eine Klasse die noch nichts macht. Einfach so als Vorbereitung, damit 
der spätere Ausbau dann einfacher wird. Die Version 0.3.0 wird wohl noch 
gänzlich ohne Benutzerverwaltung daherkommen.

Was aber bereits kommen wird, ist ein komplett neues Preissystem :-) 
Siehe Online-Demo -> Kategorie "IC-Sockel" -> Bauteil "GS 14P"

mfg

Urban B. schrieb:
>> Möglichkeit 2: Mach doch einfach einen
>> TMPL_IF/TMPL_ELSEIF/TMPL_ELSE-Konstruktion daraus.
>
> Hmm ich verstehe nicht, wie ich dann mehrere Tabellen in einer
> Template-Datei verwenden kann?

Mal kurz in Pseudocode geschrieben:

if loop3 then
   table-konstrukt 3
else if loop 2 then
   table-konstrukt 2
else if loop 1 then
   table-konstrukt 1
end if

Also man geht von der größten zur kleinsten Tabelle rückwärts.

> Ich habe es jetzt aber mal so gelöst, dass die Template-Dateien
> aufgeteilt werden. Pro Template-Datei ist dann zwar immernoch nur
> maximal eine Tabelle möglich, aber wenn mehrere Tabellen auf der
> gleichen Seite benötigt werden kann dann einfach die jeweilige
> Template-Datei mehrmals ausgegeben werden, halt jedesmal mit einem
> anderen Loop für die Tabelle. Ich vermute mal damit können wir leben...

Ist die bessere Alternative :-) Auf die Mehrfachnutzung könnte man 
eventuell noch mit einem (HTML-)Kommentar im Template hinweisen, damit 
man nicht gleich in andere Fehler rennt.

Grüße
Udo

Udo Neist schrieb:
> Mal kurz in Pseudocode geschrieben:
>
> if loop3 then
>    table-konstrukt 3
> else if loop 2 then
>    table-konstrukt 2
> else if loop 1 then
>    table-konstrukt 1
> end if

Wenn die drei table-konstrukte alle dieselben sind, funktioniert das 
aber nicht, da der Name des Loops ja dort drin hardgecodet ist. Und 
falls es drei verschiedene Konstrukte sind, dann wars das mit den 
Flexiblen Tabellen :-)

Aber das hat sich jetzt ja eigentlich erledigt, ich glaub das passt so 
wie ich es jetzt gemacht habe (z.B. für show_device_parts.php oder 
show_search_parts.php).

Übrigens, er Upload-Manager bereitet mir immernoch Kopfschmerzen :-)
Falls du Zeit und Lust hast, wäre ich echt froh wenn du dich um diesen 
kümmern könntest. Klar - es hat noch Zeit, der Rest ist auch noch nicht 
so schnell fertig. Aber so langsam sollte man schon mal mit dem Teil 
anfangen...

Greez

Gut, dann werde ich mal nach dem Uploader schauen :-)

Udo Neist schrieb:
> Gut, dann werde ich mal nach dem Uploader schauen :-)

OK super! :-)

Ein paar Infos dazu gibt es ja in unseren Issues auf Google Code (wobei 
nicht jeder dort aufgeführten Punkte zwingend berücksichtigt werden 
muss, nicht alles ist sinnvoll^^)

Urban B. schrieb:
> 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.

Ich habe den File-Uploader umgeschrieben. Die Verzeichnisrechte werden 
jetzt direkt per fileperms() ermittelt. Die (optionalen) 
Zielverzeichnisse werden direkt über ein Array mit Mimetyp => 
Verzeichnis bestimmt und liegen unterhalb des in ajax->UploadDir 
gespeicherten Verzeichnisses.

Der Aufruf lautet jetzt http://weinbauer73.myparts.info/ajax/index.php, 
da ajax.php nur noch die Verabeitung übernimmt. Das Archiv habe ich 
upgedatet.

Hmm warum heisst die Klasse eigentlich "ajax"? Das hat irgendwie ja so 
gut wie nichts mit dem Uploader zu tun ;-)

Und dann bin ich mir nicht sicher ob du mich richtig verstanden hast, 
deshalb eine kurze Zusammenfassung:
Der Uploadmanager soll nicht nur Dateien hochladen können, sondern man 
soll auch die Dateien, die sich bereits auf dem Server befinden, 
durchsuchen ("browsen"), umbenennen, löschen und verschieben können. 
Halt alles was man auch mit lokalen Dateien machen kann. Und man soll 
z.B. für Dateianhänge von Teilen auch Dateien auswählen können, die sich 
bereits auf dem Server befinden (also ohne eine Datei hochladen zu 
müssen).

Vielleicht wäre "Dateimanager" (bzw. "Filemanager") ein geeigneter Name 
für das "Ding". "Uploadmanager" bringt irgendwie nicht so richtig die 
Möglichkeiten dieses Dinges zur Geltung... :-)

Beispiel:
Ich lege das Bauteil ATMega8-16PU an. Dann klicke ich auf "Dateianhang 
hinzufügen" (o.ä.), und es öffnet sich der Manager. Da das Datenblatt, 
das ich anhängen will, noch nicht auf dem Server existiert, wähle ich im 
Manager das Zielverzeichnis, die hochzuladene Datei (lokaler Dateiname 
od. Internet-URL) und lasse die Datei hochladen. Dann markiere ich sie 
und klicke auf "OK". Nun wird das Datenblatt zum ATMega8-16PU 
hinzugefügt.

Dann lege ich das Bauteil ATMega8-16AU an, das natürlich genau das selbe 
Datenblatt besitzt wie die DIP-Version. Ich klicke also wieder auf 
"Dateianhang hinzufügen". Im nun eingeblendeten Manager suche ich nun 
einfach nach dem bereits existierenden Datenblatt für den Mega8, wähle 
es aus und klicke auf "OK".

Dateien, die hochgeladen werden, dürfen nur im Unterverzeichnis "media/" 
gespeichert werden. Um Dateien auszuwählen, muss aber auch das 
Verzeichnis "img/" zur Verfügung stehen, um z.B. einem Footprint ein 
Bild aus "/img/footprints/" zuweisen zu können.

Ein Vorschlag, wie der Dialog ungefähr aussehen könnte, habe ich hier 
mal gepostet: Beitrag "Re: PART-DB RW 1.2"

mfg

Ajax ist ne Abkürzung für "Asynchronous JavaScript and XML", daher der 
Name.

Wikipedia: Es bezeichnet ein Konzept der asynchronen Datenübertragung 
zwischen einem Browser und dem Server. Dieses ermöglicht es, 
HTTP-Anfragen durchzuführen, während eine HTML-Seite angezeigt wird, und 
die Seite zu verändern, ohne sie komplett neu zu laden.

Zum Script: Im Moment ist es ein reiner Uploader. Um Dateien 
manipulieren zu können, müsste ich nur ein paar grundlegende Funktionen 
wie Copy, Move, Delete und Rename sowie ein Dateiauswahlfeld hinzufügen. 
Bis auf den Dateiexplorer (also das Dateiauswahlfeld) ist das andere 
recht schnell erledigt. Bei den Klassen werde ich allerdings Ajax (hier 
XMLHttpRequest) als eigenständige Klasse belassen und den Rest in eine 
andere einbauen.

Warum Ajax? Das ganze muss mehr oder weniger asynchron ablaufen, sonst 
wäre das ganze ziemlich aufwendig oder langsam.

Udo Neist schrieb:
> Ajax ist ne Abkürzung für "Asynchronous JavaScript and XML", daher der
> Name.

Jo, das ist schon klar, aber wenn ich mir die Klasse so anschaue, fällt 
mir auf, dass in jedem Methodennamen das Wort "Upload" vorkommt. Die 
ganze Klasse scheint also für den Upload von Dateien zuständig zu sein. 
Ob das nun mit Ajax oder mit sonstwas geschieht, ist Nebensache. Ein 
Klassenname soll schliesslich die Funktion der Klasse repräsentieren, 
und nicht die Art und Weise, wie sie funktioniert.

Ausserdem ist das eigentliche Ajax ja viel mehr in der *.js Datei.

Das ganze ist in zwei Tagen im Büro neben der Arbeit entstanden und 
hatte erstmal den reinen Upload zum Ziel. Zudem hab ich in den Issues 
nur was von Upload-Manager gelesen. Alles andere kommt noch :)

Udo Neist schrieb:
> Das ganze ist in zwei Tagen im Büro neben der Arbeit entstanden und
> hatte erstmal den reinen Upload zum Ziel. Zudem hab ich in den Issues
> nur was von Upload-Manager gelesen. Alles andere kommt noch :)

OK alles klar :-)
Ich wusste nicht so richtig wie ich deine letzten Posts einordnen soll 
(Man hätte es z.B. so interpretieren können, als wäre der Uploadmanager 
deiner Meinung nach schon fast fertig :-)
Daher wollte ich nochmal nachfragen, nicht dass wir uns irgendwie total 
falsch verstanden haben.
Aber jetzt ist das ja geklärt, alles in Ordnung xD

mfg

Hallo,

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

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.

Urban B. schrieb:
> Dort setzt du einen Webserver auf, kopierst das Archiv von Part-DB nach
> /var/www/

Nicht jedes Linux nutzt /var/www. Nach FHS wäre /srv/www (nutzt z.B. 
openSUSE) der bessere Ort dafür. Das richtige Zielverzeichnis kann man 
in der Konfiguration des jeweiligen Webservers nachschauen. Einfach nach 
"DocumentRoot" schauen :-)

Udo Neist schrieb:
> Urban B. schrieb:
>> Dort setzt du einen Webserver auf, kopierst das Archiv von Part-DB nach
>> /var/www/
>
> Nicht jedes Linux nutzt /var/www.

Jo ich weiss, war auch auf den Vorschlag "Ubuntu" bezogen. Ist aber 
nicht richtig klar wenn man es liest, da hast du recht :-)

mfg

Hallo

Ich habe die Part-db mal Testweise auf einem Xampp installiert und die 
Footprints hineinkopiert. Leider kann ich bei neu erstellen Bauteilen 
erst die Footprints auswählen wenn ich bei den Footprints die Checkbox 
aktiviere.

Gibs da ein Script oder ist das ein Bug? Ich habe nich Lust mehrer 
hundert Checkboxen anzuklicken ;-)

Gruß Christoph

keiner eine Idee?

Hast du auch das Update der Datenbank durchgeführt? Damit sollten die 
Infos zu den Footprints eingespielt werden. Die SQL-Datei zur 
Installation enthält nur die Struktur und die Versionsnummer.

Christoph B. schrieb:
> Hallo
>
> Ich habe die Part-db mal Testweise auf einem Xampp installiert und die
> Footprints hineinkopiert. Leider kann ich bei neu erstellen Bauteilen
> erst die Footprints auswählen wenn ich bei den Footprints die Checkbox
> aktiviere.
>
> Gibs da ein Script oder ist das ein Bug? Ich habe nich Lust mehrer
> hundert Checkboxen anzuklicken ;-)
>
> Gruß Christoph

Das ist kein Bug, sondern ein Feature :-)

Es stehen nur diejenigen Footprints zur Auswahl, die man auch selber 
hinzugefügt hat (unter Bearbeiten -> Footprints, oder mit den Checkboxen 
die du ja schon gefunden hast).

Der Grund dafür ist, dass die meisten Leute ein eher kleines Sortiment, 
mit vielleicht so 50 verschiedenen Footprints haben. Würden alle 
vorhandenen Footprints automatisch zur Verfügung stehen, wären die ca. 
1700 Footprints extrem unübersichtlich.

Ausserdem ist vielen nicht klar, dass die Footprint-Bilder von den 
Footprints ansich unabhängig sind. Man kann auch Footprints anlegen, die 
kein Bild haben! Die Bilder sind also quasi nur optional.

Von mir aus könnten wir mal ein "Standardpaket" von Footprints bereits 
in die Installation integrieren, dass zumindest die gebräuchligsten 
Footprints bereits im System drin sind...

mfg

danke für die Antwort

Gibt es einen einfacher Weg als die 1700 Footprints von Hand einzeln 
hinzuzufügen?

Wenn ich z.B eine Diode hinzufüge muss ich immer erst in 
Tools/Footprints den Haken setzen bevor er der Footprint unter 
Bearbeiten/Footprints zur Verfügung steht.

Christoph B. schrieb:
> Gibt es einen einfacher Weg als die 1700 Footprints von Hand einzeln
> hinzuzufügen?

Bisher nicht. Aber ich frage mich, wozu man alle 1700 Footprints 
wirklich im System haben will, das wird doch nur extrem unübersichtlich? 
Und ein sehr grosser Teil von den Bildern sind eh nur Steckverbinder, 
die kaum einer jemals gekauft hat...

Christoph B. schrieb:
> Wenn ich z.B eine Diode hinzufüge muss ich immer erst in
> Tools/Footprints den Haken setzen bevor er der Footprint unter
> Bearbeiten/Footprints zur Verfügung steht.

Dazu gibt es doch extra das Eingabefeld "Direkteingabe/Neu". Da kann man 
direkt beim Anlegen eines neuen Bauteiles auch gleich noch einen neuen 
Footprint anlegen, ohne den Umweg über Bearbeiten -> Footprints.

mfg

Habe nun alles getestet und mir sind 2 Sachen aufgefallen die man 
vieleicht verbessern könnte.

Beim Hinzufügen von Bauteilen aktiviere ich die Checkbox "Weitere 
Bauteile erfassen:"

In der neuen Eingabenmaske bleibt der Lagerstand stehen doch der Name 
wird automatisch um 1 Hinaufgezählt. So wird beim nächsten Bauteil aus 
75 Ohm --> 75 Ohn.

Des weiteren wäres es vieleicht noch fein dann auch noch der Footprint 
und der Lagerort automatisch vom vorigen Bauteil übernommer wird.

Gruß Christoph

Hallo Christoph,

All deine genannten Sachen sind in der aktuellen SVN-Version bereits 
umgesetzt. Um diese Version zu installieren benötigst du einen SVN 
(Subversion) Client. Die Download-URL (bzw. den ganzen Befehl) findest 
du hier: https://code.google.com/p/part-db/source/checkout

Falls du (wie [verständlicherweise] einige Andere auch) nicht verstehst 
wie man es installiert kriegt, such mal im Internet nach Anleitungen, da 
solltest du fündig werden.
Falls du konkrete Fragen dazu hast, frag einfach hier nach. Aber eine 
komplette Anleitung für SVN werde ich nicht schreiben ;-)

mfg

@Christoph
Und, hat's geklappt mit der Installation der aktuellen SVN-Revision?

@all
Ich überlege gerade ob es das Attribut "obsolete" für die Bauteile 
überhaupt noch braucht. Zuerst dachte ich, wir sollten es einfach vom 
Bauteil "ablösen" und in die Einkaufsinformationen (Klasse 
"Orderdetails") verschieben, da dieses Attribut ja immer auf einen 
bestimmten Artikel eines Lieferantes bezogen ist, und nicht auf das 
Bauteil ansich.

Dann kam ich aber auf die Idee, dass man bei einem nicht mehr 
erhältlichen Bauteil einfach die entsprechenden Einkaufsinformationen 
löschen könnte. Ein Bauteil würde dann als "obsolete" gelten, sobald es 
keine einzige Einkaufinformation mehr gibt zu diesem Teil.

Einziger Nachteil wäre dann halt, dass die Bestellnummern und die Preise 
auch gelöscht werden, und somit später nicht mehr vorhanden sind falls 
man sie mal noch brauchen könnte.

Ich würde jetzt sagen, dieser Nachteil ist ziemlich irrelevant, und 
diese Lösung daher vorzuziehen. Ich würde aber trotzdem gerne mal eure 
Meinung dazu hören.

Also, was meint ihr, wie soll das Attribut "obsolete" gehandhabt werden?

mfg

P.S. @K.J.
Ich werde heute noch eine neue Version in unseren Branch hochladen. 
Wegen Änderungen am Datenbankupdate v12 -> v13 müsste wieder eine 
Datenbank der Version 12 geladen werden, sonst gibts hübsche 
Fehlermeldungen :-)

Ach ja, warum ist in der Online-Demo eigentlich der Menüeintrag "System" 
wieder verschwunden? :-)

Urban B. schrieb:

> P.S. @K.J.
> Ich werde heute noch eine neue Version in unseren Branch hochladen.
> Wegen Änderungen am Datenbankupdate v12 -> v13 müsste wieder eine
> Datenbank der Version 12 geladen werden, sonst gibts hübsche
> Fehlermeldungen :-)
>
> Ach ja, warum ist in der Online-Demo eigentlich der Menüeintrag "System"
> wieder verschwunden? :-)

Ah ka. hatte gestern die DB gefixt aber an der config war ich nicht bei, 
mal schauen, jo ich werde da mal ne saubere DB einspielen und einfach 
nur einige Testeinträge machen.

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 ;-)

Christoph B. schrieb:
> Hallo
>
> Ich habe nun die Version 0.2.2 am Laufen, da mir die Beta zu unsicher
> ist. Will nicht nochmals mehrere 100 Bautteile eintragen ;-)

Okay, aber die Bauteile müsstest du natürlich nicht nochmals eintragen, 
deine Datenbank mit allen Bauteilen usw. wird übernommen (wobei ein 
Backup vor der Installation sicher trotzdem angebracht ist, da die 
Datenbankstruktur aktualisiert wird und ein "Downgrade" nicht mehr 
möglich ist).
Und unsicher würde ich die momentane SVN-Revision nicht nennen, es sind 
eigentlich keine gröberen Bugs bekannt.

Aber wenn du mit der stabilen 0.2.2 zufrieden bist, spricht natürlich 
nichts dagegen, bei dieser zu bleiben.

mfg

K. J. schrieb:
> Ah ka. hatte gestern die DB gefixt aber an der config war ich nicht bei,
> mal schauen, jo ich werde da mal ne saubere DB einspielen und einfach
> nur einige Testeinträge machen.

Gibts denn jetzt mit deiner 12er Datenbank immernoch Probleme? In der 
Demo scheint jetzt eigentlich alles zu funktionieren habe ich das 
Gefühl, ich konnte jedenfalls keinen Datenbankfehler mehr finden.

Übrigens habe ich im 0.3.0-Branch eine Datenbank der Version 12 
abgelegt, diese könntest du natürlich auch für die Online-Demo 
verwenden, die sollte problemlos laufen und hat auch ein paar hübsche 
Baugruppen wo man ein bisschen was sehen kann :-)
Sie befindet sich hier: 
https://part-db.googlecode.com/svn/branches/uneist...

mfg

Urban B. schrieb:
> In der
> Demo scheint jetzt eigentlich alles zu funktionieren habe ich das
> Gefühl, ich konnte jedenfalls keinen Datenbankfehler mehr finden.

OK hab nichts gesagt, beim Erfassen von neuen Bauteilen gibts einen 
Fehler weil vermutlich eine Datenbankspalte fehlt...

Übrigens habe ich jetzt (r581) noch etwas geändert, damit bei 
Datenbankfehlern eine aussagekräftigere Meldung im Debug-Log erscheint 
(die bisherigen Meldungen waren nicht sehr aussagekräftig). Falls es 
beim Datenbankupdate zu Problemen kommen sollte, würde man nun 
vielleicht im Debug-Log noch weitere Hinweise auf die Fehlerursache 
finden.

Und den Menüeintrag "System" habe ich in der Online Demo wieder 
aktiviert, vermutlich hat einfach jemand an der Konfiguration 
rumgespielt und diesen Eintrag deaktiviert. Ich werde wohl noch eine 
Sicherung einbauen dass man dies bei der Online Demo nicht deaktivieren 
kann.

Ok ist gefixt

K. J. schrieb:
> Ok ist gefixt

Wunderbar, funktioniert :-)

Urban B. schrieb:
> Also, was meint ihr, wie soll das Attribut "obsolete" gehandhabt werden?

Will sich dazu keiner äussern? :-)

Ausserdem habe ich gleich noch eine andere Frage. Ich bin nämlich grad 
an der Importfunktion dran, und da frage ich mich, ob der Import von 
bestehenden Bauteilen in bestehende Baugruppen überhaupt Sinn macht.

Man muss dazu ja bereits alle IDs der Bauteile kennen, was aber nicht 
der Fall ist, wenn man bisher seine Baugruppen in Excel o.ä. verwaltet 
hat. Für diesen Fall ist also diese Importfunktion sowieso nicht zu 
gebrauchen.

Ich wüsste nicht, wofür dann diese Importfunktion zu gebrauchen wäre. 
Hat jemand von euch einen guten Grund, warum wir diese Funktion nicht 
einfach rauswerfen sollen?

Der Import von Bauteilen würde natürlich weiterhin bestehen bleiben, 
dort ist der Sinn relativ einfach zu erkennen xD

mfg

Na, will sich denn keiner äussern? :-D

Die Baugruppen-Importfunktion fliegt einfach raus wenn niemand weiss 
wozu man die gebrauchen kann ;-)

Bezüglich "obsolete" Attribut kann ich mich nicht entscheiden wie ich es 
machen soll, mir persönlich ist es relativ egal wie es gemacht wird. 
Daher wäre ich froh mal eure Meinungen zu hören...

mfg
Urban

Urban B. schrieb:
> K. J. schrieb:
>> Ok ist gefixt
>
> Wunderbar, funktioniert :-)
>
> Urban B. schrieb:
>> Also, was meint ihr, wie soll das Attribut "obsolete" gehandhabt werden?
>
> Will sich dazu keiner äussern? :-)
>

Könnte ich jetzt so nicht da ich das nicht nutze.

> Ausserdem habe ich gleich noch eine andere Frage. Ich bin nämlich grad
> an der Importfunktion dran, und da frage ich mich, ob der Import von
> bestehenden Bauteilen in bestehende Baugruppen überhaupt Sinn macht.
>
>
> Der Import von Bauteilen würde natürlich weiterhin bestehen bleiben,
> dort ist der Sinn relativ einfach zu erkennen xD
>
> mfg

Jup stimme ich dir zu.

> Ausserdem habe ich gleich noch eine andere Frage. Ich bin nämlich grad
> an der Importfunktion dran, und da frage ich mich, ob der Import von
> bestehenden Bauteilen in bestehende Baugruppen überhaupt Sinn macht.
>
>
> Der Import von Bauteilen würde natürlich weiterhin bestehen bleiben,
> dort ist der Sinn relativ einfach zu erkennen xD

Also ich setze bzw. plane die part-db bei uns in der Firma bzw. für mich 
als Arbeitsmittel einzusetzen. Ich find die die Baugruppen Import 
Funktion schon praktisch. Ich setze als Leiterplatten Tool Eagle und als 
BOM Skript das bom-ex ULP ein. Bei dem Skript kann man sich eine 
Datenbank mit der Zuordnung von Bauteilen und verschiedenen 
Eigenschaften (wie z.B. die part-dB ID) anlegen. Wenn ich dann meine BOM 
exportiere kann ich mir eine CSV Datei erzeugen lassen, welche ich in 
die part-db importieren kann. Darüber kann man dann Baugruppen erstellen 
ohne jedes Teil extra eingeben zu müssen (bei Leiterplatten >100 Teile 
macht das doch niemand von Hand, oder?).

Super praktisch wäre natürlich eine Kombination aus Baugruppen und 
Bauteil Import. Sprich, wenn Bauteile noch keine part-db ID haben, 
werden sie neu angelegt.

Grüße
Thomas

Thomas Kühne schrieb:
> Wenn ich dann meine BOM
> exportiere kann ich mir eine CSV Datei erzeugen lassen, welche ich in
> die part-db importieren kann.

Ah cool, auf die Idee bin ich noch gar nie gekommen :-)
Das ist natürlich ein Argument für die Baugruppen-Importfunktion. Dann 
bleibt die also drin ;-)

Danke für diesen Input!

Thomas Kühne schrieb:
> Super praktisch wäre natürlich eine Kombination aus Baugruppen und
> Bauteil Import. Sprich, wenn Bauteile noch keine part-db ID haben,
> werden sie neu angelegt.

Hmm ich denke, das lässt sich einbauen.

Uhu Uhuhu schrieb im Beitrag #2917976:
> 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

Ich habe eine Uraltversion in einer VM laufen, bei der aber mittlerweile 
der aufklappbare Kategorienbaum nicht mehr funktioniert.

Deswegen würde ich gerne auf eine aktuelle umstellen. Wie sieht es denn 
mit Datenkompatibilität aus?

Uhu Uhuhu schrieb:
> Ich habe eine Uraltversion in einer VM laufen, bei der aber mittlerweile
> der aufklappbare Kategorienbaum nicht mehr funktioniert.

Hatte ich auch schon, war irgend ein Fehler meinerseits, ich glaube es 
waren falsche Dateirechte oder sowas...

Uhu Uhuhu schrieb:
> Deswegen würde ich gerne auf eine aktuelle umstellen. Wie sieht es denn
> mit Datenkompatibilität aus?

Sollte kein Problem sein, die Datenbankstruktur wird automatisch (bzw. 
per Button-Klick) angepasst. Einfach vorher ein Backup der Datenbank 
machen, damit man bei einem Fehler auch wieder problemlos "Downgraden" 
kann. Ansonsten ist (übrigens auch bei erfolgreichem Update) kein 
Downgrade mehr möglich.

mfg

Urban B. schrieb:
> Hatte ich auch schon, war irgend ein Fehler meinerseits, ich glaube es
> waren falsche Dateirechte oder sowas...

Das kann eigentlich nicht sein, denn das Teil läuft bei mir in einer VM, 
die ich - außer über den Browser - schon lange nicht mehr angefaßt habe.

Urban B. schrieb:
> Sollte kein Problem sein, die Datenbankstruktur wird automatisch (bzw.
> per Button-Klick) angepasst.

So einfach scheint es doch nicht zu sein.

Ich habe das alte part-db-Verzeichnis umbenannt und den Code unter truc 
in ein neues part-db-Verzeichnis kopiert und config.php an meine alte DB 
angepaßt.

Der Server startet die neue Part-db, der Kategoriebaum wird korrekt 
angezeigt, aber das Anzeigen der Daten im rechten Bereich klappt nicht. 
Direkt nach dem Start bekomme ich dort nur eine Meldung

  Unknown column 'filename' in 'field list'

Wenn ich eine Kategorie anklicke, gibts eine rudimentäre Seite mit 
folgender Meldung:

   Unknown column 'parts.description' in 'field list'

Sieht also stark danach aus, daß die neue part-db andere Vorstellungen 
von der DB hat, als mysql.

Leider finde ich mit grep keine Datei, die den String 'Unknown column' 
enthält.

Hmm welche Version hattest du denn vorher installiert?

Im Menü von Part-DB aus dem Trunk sollte es einen Eintrag "Datenbank" 
geben, was steht da welche Datenbankversion installiert ist?
Auf dieser Seite solltest du eigentlich auch das Datenbankupdate machen 
können falls es nicht schon automatisch gemacht wurde.

Ich bin noch nicht allzu lange hier bei Part-DB, die Versionen vor 0.2.2 
habe ich noch nie gesehen, daher kann ich dazu leider nicht viel sagen.

Uhu Uhuhu schrieb:
> Leider finde ich mit grep keine Datei, die den String 'Unknown column'
> enthält.

Die Fehlermeldung kommt auch nicht von Part-DB selbst, sondern von 
MySQL.

Falls du es nicht hinkriegst kannst du mir auch gerne mal die alte 
Datenbank per PN schicken, dann kann ich es mir mal anschauen.

mfg

Urban B. schrieb:
> Hmm welche Version hattest du denn vorher installiert?

Das war eine Version 0.1, aber theborg ging etwas schlampig mit 
führenden Nullen um...

> Im Menü von Part-DB aus dem Trunk sollte es einen Eintrag "Datenbank"
> geben, was steht da welche Datenbankversion installiert ist?

Es ist Version 1. Nachdem ich dem user einige zusätzliche Permissions 
gegeben hatte, lief der Update glatt durch.

Uhu Uhuhu schrieb:
> Das war eine Version 0.1, aber theborg ging etwas schlampig mit
> führenden Nullen um...

OK bei so alten Versionen kenne ich mich nicht aus, aber ich schätze mal 
das Update sollte trotzdem funktionieren.
Übrigens hat die Version von Part-DB (die Dateien an sich) nichts mit 
der Datenbankversion (1 bis 12) zu tun, das kann anfangs etwas verwirren 
;-)

Uhu Uhuhu schrieb:
> CREATE command denied to user 'part-db'@'localhost' for table 'internal'

Hier ist auch schon der Hund begraben. Der Datenbankbenutzer hat nicht 
genügend Rechte um eine neue Tabelle anzulegen. Am besten gibst du (z.B. 
per phpMyAdmin) einfach alle Rechte für die entsprechende Datenbank, 
dann gibts deswegen sicher nie mehr Probleme.

Nach einem misslungenen Update empfiehlt es sich übrigens, für den 
nächsten Versuch wieder die alte Datenbank einzuspielen weil sonst 
diverse Befehle mehrfach ausgeführt werden, und so zu neuen Fehlern 
führen können.

Heisst also:
- Zuerst die Rechte des Benutzers anpassen
- Wieder die alte Datenbank einspielen (vorher die aktuelle komplett 
löschen!!)
- Nochmal das Update starten, dies sollte nun ohne Fehler durchlaufen

mfg

Ja, da fehlten 3 Permissions - die hat er jetzt und der Update auf 
Version 2 lief glatt durch. Jetzt fehlen wohl nur noch 10 Updates...

Nein, da wurde nur Version 2 abgezeigt, obwohl er Version 12 hat.

Jetzt scheints zu funktionieren - vielen Dank für die Nachhilfe.

Uhu Uhuhu schrieb:
> Ja, da fehlten 3 Permissions - die hat er jetzt und der Update auf
> Version 2 lief glatt durch. Jetzt fehlen wohl nur noch 10 Updates...

OK das ist ja schonmal was. Aber jetzt macht er bei den Updates nicht 
weiter? Theoretisch sollten alle Updates bis Version 12 in einem Rutsch 
durchlaufen.

Gibts Fehlermeldungen o. ä.?

Uhu Uhuhu schrieb:
> Jetzt scheints zu funktionieren - vielen Dank für die Nachhilfe.

Ah, schon wieder zu schnell geantwortet^^
Super dass es jetzt auch noch geklappt hat, ich hoffe Part-DB gefällt 
dir :-)

Ein alter Fehler ist noch immer drin: Wenn man mehrere Datenblätter 
speichert, ist nur eins aus der Teleliste heraus zugreifbar.

Ganz früher wurde für jedes hinterlegte Datenblatt ein Link angezeigt. 
Irgend jemand hat das dann rausgeschmissen.

Uhu Uhuhu schrieb:
> Ein alter Fehler ist noch immer drin: Wenn man mehrere Datenblätter
> speichert, ist nur eins aus der Teleliste heraus zugreifbar.
>
> Ganz früher wurde für jedes hinterlegte Datenblatt ein Link angezeigt.
> Irgend jemand hat das dann rausgeschmissen.

Ist ab der Version 0.3.0 wieder drin, brauchst nur noch ein wenig Geduld 
bis die fertig ist :-)

Prima.

In den Quellen ist auch eine Datei open/openlist.php, die eine 
Lagerliste erzeugt. Die könnte man unter tools einbinden. Damit sie 
funktioniert sind ab Zeile 25 folgende Änderungen nötig:

  include('../lib.php');
  partdb_init();
?>
<?
  //include('stats.php');
?>

Die letzten 3 Zeilen können ersatzlos raus.

Hallo zusammen,

Sorry dass sich im Moment nicht viel tut im Entwicklerbranch. Ich habe 
momentan leider nicht so viel Zeit zum programmieren, da ich noch an 
anderen Projekten arbeite und auch das Studium seine Zeit braucht. Ich 
werde aber versuchen wieder ein bisschen an Part-DB weiterzuarbeiten.

@Udo
Wie sieht es mit dem Upload-Manager aus, bist du da weitergekommen?

mfg
Urban

@Urban

Leider nicht, bin auch zeitlich im Beruf ziemlich ausgelastet. Musste 
auch noch recht kurzfristig ein anderes Projekt auf die Beine bringen. 
Und vor Weihnachten stapelt sich ja auch privat so manches. Sobald ich 
wieder Zeit habe, geht es weiter.

Aktuell sind verschiedene Befehle schon implementiert (ein Glück hatte 
ich sowas ja schon in meiner Update-Klasse drin), aber es ist noch keine 
UI vorhanden.

Okay, dann muss die Version 0.3.0 halt noch etwas länger warten bis sie 
fertiggestellt wird...

Im Grossen und Ganzen ist sie aber eigentlich ja schon ziemlich weit, 
neben dem Uploadmanager und der Import/Export-Funktionen sind es 
mehrheitlich nur noch Kleinigkeiten, die noch gemacht werden müssen.

Wie heisst es gleich nochmal, "Gut Ding will Weile haben"? :-D

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

Uhu Uhuhu schrieb:
> Sind die Funktionen unter "Lagerorte umbenennen/löschen/sortieren"
> irgendwo beschrieben, insbesondere was die Kästchen "voll" und "noch
> Platz" bewirken?

Beschrieben sind die nirgens (die Doku ist noch ziemlich bescheiden ;-).

Mit dem Kästchen "voll" kannst du einfach den Lagerort als voll 
markieren, damit du siehst dass dort kein Platz mehr ist. Intern hat 
dieses Attribut aber keine Funktion, es dient nur zur Kennzeichnung.
Mit dem Kästchen "noch Platz" lässt sich einfach das Kreuz im Kästchen 
"voll" wieder entfernen, das ist irgendwie etwas unglücklich gelöst. 
Aber wie immer: In Version 0.3.0 wird auch das etwas besser :-)

Danke für die Erläuterung.

Habt ihr schon irgendwas ausgemacht, wie die Doku aussehen soll? Ich 
denke, ich kann brauchbare Anleitungen verfassen und würde mich damit am 
Projekt beteiligen, wenn das erwünscht ist.

Uhu Uhuhu schrieb:
> Danke für die Erläuterung.
Kein Problem :-)

> Habt ihr schon irgendwas ausgemacht, wie die Doku aussehen soll? Ich
> denke, ich kann brauchbare Anleitungen verfassen und würde mich damit am
> Projekt beteiligen, wenn das erwünscht ist.

Cool, also von meiner Seite wäre das sogar sehr erwünscht, und ich denke 
mal da hätte auch sonst niemand was dagegen.

Ich denke, die Doku müsste auf jeden Fall direkt im Browser benutzbar 
sein, sonst macht sie nicht viel Sinn. Eine Suchfunktion wäre natürlich 
auch nicht schlecht.

Kennst du ein gescheites Tool um solche Hilfeseiten zu erstellen? Oder 
besser selber was kleines Bauen?

Urban B. schrieb:
> Kennst du ein gescheites Tool um solche Hilfeseiten zu erstellen? Oder
> besser selber was kleines Bauen?

Darüber habe ich mir bisher keine Gedanken gemacht. Was mir spontan 
einfällt, wäre ein MoinMoin-Wiki, das man parallel zum part-db Server 
installiert. Das hätte den Vorteil, daß man es leicht pflegen kann, der 
Benutzer es leicht erweitern/anpassen kann und eine Suchfunktion dabei 
ist.

Vielleicht könnte man das Wiki ja als Funktion in part-db integrieren. 
Auf jeden Fall könnte man auch in die part-db-Seiten Links auf die Hilfe 
einbauen.

Es wäre gut, wenn die Online-Hilfe/die Doku auch separat von Part-DB 
upgedatet werden könnte, um Fehler darin schneller ausbügeln und zum 
"Kunden" zu bringen. So könnte man die Konfiguration zwischen lokaler 
oder netzweiter (Intranet oder Internet) Hilfe umschalten.

Uhu Uhuhu schrieb:
> Darüber habe ich mir bisher keine Gedanken gemacht. Was mir spontan
> einfällt, wäre ein MoinMoin-Wiki, das man parallel zum part-db Server
> installiert.

Sieht interessant aus, das kannte ich bisher noch gar nicht. Allerdings 
habe ich nach einem ganz kurzen Blick in den Sourcecode das Gefühl, dass 
das viel zu viel des Guten ist, also total überdimensioniert für unser 
doch relativ kleines Projekt :-)

Ich kenne mich allgemein nicht so mit Wikis o.ä. aus, aber ich vermute 
mal, bei solchen Systemen wird der Inhalt (also die selbstgeschriebene 
Hilfe) in einer Datenbank abgelegt?
Dann müsste das System auf jeden Fall mit einer SQLite funktionieren, 
ansonsten wird das Hochladen eines Updates per SVN "schwierig". Mit 
SQLite müsste das ja aber funktionieren...

Ausserdem sollte sich das Hilfesystem ohne Eingriff des Benutzers 
installieren lassen wenn man Part-DB installiert. Wäre irgendwie doof 
wenn man das Hilfesystem noch selber irgendwie 
installieren/konfigurieren müsste.

Uhu Uhuhu schrieb:
> Vielleicht könnte man das Wiki ja als Funktion in part-db integrieren.
> Auf jeden Fall könnte man auch in die part-db-Seiten Links auf die Hilfe
> einbauen.

Jup, so hätte ich mir das auch vorgestellt.

Urban B. schrieb:
> Ich kenne mich allgemein nicht so mit Wikis o.ä. aus, aber ich vermute
> mal, bei solchen Systemen wird der Inhalt (also die selbstgeschriebene
> Hilfe) in einer Datenbank abgelegt?

MoinMoin ist - leider - in Pearl geschrieben, aber damit hat man nichts 
zu tun. Die Wikiseiten sind normale Dateien, die den Text in dem Format 
enthalten, wie man es im Quelltext-Editor eingibt.

> Allerdings
> habe ich nach einem ganz kurzen Blick in den Sourcecode das Gefühl, dass
> das viel zu viel des Guten ist, also total überdimensioniert für unser
> doch relativ kleines Projekt :-)

Das ist ein Schwäbische-Hausfrau-Argument - das juckt keinen.

Udo Neist schrieb:
> Es wäre gut, wenn die Online-Hilfe/die Doku auch separat von Part-DB
> upgedatet werden könnte, um Fehler darin schneller ausbügeln und zum
> "Kunden" zu bringen.

Das sollte wegen der einfachen Dateistruktur kein größeres Problem sein. 
Updates müßten einfach als neue Version importiert werden. Der Anwender 
hat dann die Möglichkeit, sich die Änderungen gegenüber seiner letzten 
Version anzeigen zu lassen.

Dokuwiki kommt ohne Datenbank aus, nutzt Dateien. Man braucht nur ein 
Unterverzeichnis zu packen und entpacken, schon ist die Aktualisierung 
der Texte erledigt :-) Ich nutze Dokuwiki für verschiedenste Zwecke, 
darunter auch eine Developer-Doku.

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

Dokuwiki gefällt mir mittlerweile besser, als MoinMoin...

In Tools | Footprints ist ein ziemlich lästiger Fehler:
- Das Laden der Footprintliste dauert seine Zeit - das ist normal
- Unnormal ist, daß die Seite jedesmal neu geladen wird, wenn man
  von einem anderen Tab, oder einem anderen Fenster in FF auf die
  Footprint-Liste umschaltet.

Der Fehler macht das nachträgliche Suchen von Footprints für bereits 
angelegte Teile zur Geduldprobe.

Nachtrag: Das Problem mit der Footprints-Seite liegt daran, daß die 
Seite zu groß ist und FF sie neu rendert, wenn der Tab hervorgeholt 
wird.

Alles in allem frage ich mich allerdings, welchen praktischen Nutzen 
diese Bildchen haben.

Uhu Uhuhu schrieb:
> Alles in allem frage ich mich allerdings, welchen praktischen Nutzen
> diese Bildchen haben.

Ich finde die Bilder schon praktisch.;-) SO sieht man auf den ersten 
Blick welche Bauform man auf Lager hat

Christoph B. schrieb:
> SO sieht man auf den ersten Blick welche Bauform man auf Lager hat

Nur ob der Chip jetzt breit- oder schmalbeinig ist, das siehst du nicht 
- da bist du mit dem Namen besser bedient...

Seh ich genauso wie Uhu, die Footprint Bilder finde ich eher unwichtig. 
Ein weiteres Beispiel dafür sind passive SMD Komponenten, ob das Bild 
jetzt 0402 oder 0603 oder so darstellt erkennt man auch nicht wirklich 
und muss es ja auch nicht, der Name sagt doch genug. Allerdings stören 
die Footprints auch nicht und wer will, muss sie ja nicht 
installieren...

Mehr als 6 Wochen mit Audits und Prüfmethodenumstellung sowie der 
Weihnachtsstress ist rum. Auf gehts an die Arbeit am Filemanager...

Was soll der Filemanager alles können? Up- und Download ist ja die 
wenigste Arbeit, hauptsächlich das UI muss ich machen.

Grüße
Udo

Udo Neist schrieb:
> Mehr als 6 Wochen mit Audits und Prüfmethodenumstellung sowie der
> Weihnachtsstress ist rum. Auf gehts an die Arbeit am Filemanager...

Cool :-) Bei mir dauerts leider noch ein paar Wochen bis der 
Prüfungsstress vorbei ist... :-(

Udo Neist schrieb:
> Was soll der Filemanager alles können? Up- und Download ist ja die
> wenigste Arbeit, hauptsächlich das UI muss ich machen.

Also wichtig ist sicher mal, dass man per Button auf irgendeiner Seite 
den Manager als Popup (schöner wäre natürlich ein schönes 
JavaScript-Fenster, das sich einfach über die Seite legt, aber das wäre 
nur Kosmetik...) öffnen kann, und beim Schliessen dieses Managers muss 
irgendwie der gewählte Dateinamen (besser ein Array mit 0...unendlich 
Strings) an die ursprüngliche Seite (mit dem Button) übermittelt werden.

Im Manager selbst muss es die Möglichkeit geben, die Dateien in 
"img/footprints/", "img/iclogos/" und "media/" zu durchsuchen, am besten 
auch mit Suchfunktion (welche man natürlich auch noch später nachreichen 
könnte, da nicht zwingend notwendig). Rudimentäre Dateioperationen wie 
Löschen, Verschieben, Kopieren, Ordner anlegen sollten auch möglich 
sein, wobei aber nur im Verzeichnis "media/" Schreibrechte vorhanden 
sein dürfen, im Ordner "img/" sind nur Dateien, die von Part-DB 
bereitgestellt werden, dort darf der User keine Schreibrechte haben.

Dann natürlich die Uploadfunktion. Zielordner (irgenwo in "media/") 
wählen, lokale Dateien oder Internet-URL wählen, und Dateien hochladen 
lassen. Bei der Angabe einer Internet-URL soll die Datei direkt aus dem 
Internet auf den Server runtergeladen werden (Dateiname der Zieldatei 
sollte dabei wählbar sein). Möchte ein Benutzer übrigens eine 
Internet-URL verwenden, die Datei aber nicht runterladen (z.B. um immer 
auf das aktuelle Datenblatt verwiesen zu werden), so braucht er den 
Manager gar nicht erst aufzurufen, sondern gibt einfach direkt die URL 
in das Adressfeld z.B. in edit_part_info.php ein.

Ich hoffe ich habe nichts vergessen ;-)

mfg

Den Filemanager als neues DIV über die Part-DB zu legen ist nicht 
wirklich ein Problem. Fast alle Aktionen werden dann über Ajax laufen. 
Einen Multi-Uploader muss ich mir auch erstmal anschauen. Was recht 
einfaches hab ich unter http://davidwalsh.name/multiple-file-upload 
gefunden. Nur geht das wohl mit dem IE nicht. SWFUpload wäre wohl 
besser. Schau ich mir mal genauer an.

Hallo Udo,

Ich habe mal noch die Debug-Möglichkeiten von Part-DB etwas ergänzt. Und 
zwar wird im Debug-Modus das "error reporting level" von PHP 
hochgesetzt, damit man möglichst viele Fehlermeldungen bekommt (zum 
Aufspüren von unsauber programmierten Codezeilen oder als "deprecated" 
markierten Funktionen). Nur "strict errors" werden nicht ausgegeben (ich 
kann mir nicht erklären wofür man diese Meldungen gebrauchen kann - zum 
Teil kommen da Meldungen, die völlig unbegründet sind).

Soweit sieht das bei mir ganz gut aus, es kommen trotz hohem "error 
reporting level" keine Fehlermeldungen mehr. Doch sobald man in Part-DB 
"Template-Debugging" aktiviert, hagelt es nur noch von "undefined 
offset" und "deprecated function", alle durch die Datei 
"lib/vlib/vlibTemplate/debug.php" verursacht.

Mache ich etwas falsch, oder ist die genannte Datei wirklich so unsauber 
programmiert? Das ist natürlich schade, diese Meldungen müssen weg, 
damit man das höhere error reporting level auch optimal zum debuggen 
einsetzen kann.

VLib wird wohl leider nicht mehr wirklich aktiv weiterentwickelt (auf 
Sourceforge letzte Änderung im Jahr 2009)... Ich habe trotzdem mal die 
neuste Version runtergeladen und in Part-DB eingebaut (oder hast du mit 
Absicht eine ältere Version verwendet?). Bezüglich der Fehlermeldungen 
hat es aber nichts bewirkt.

Ausserdem musste ich schon etwa ein halbes Dutzend mal Apache neu 
starten, weil irgendwas mit vlib geklemmt hat. Bei Änderungen am HTML 
Code von irgendwelchen Seiten aktualisiere ich die entsprechende Seite 
alle paar Sekunden wieder, um zu schauen wie sich die Änderung im Code 
im Browser bemerkbar macht. Doch manchmal kommt nach einem Refresh 
plötzlich nur noch ein "vlib parse error", selbst wenn ich die 
entsprechende *.tmpl Datei komplett leere, kommt der Fehler weiterhin. 
Erst ein Neustart von Apache behebt den Fehler und die Seite wird wieder 
geladen.

Ich habe keine Ahnung was da das Problem sein könnte, vielleicht 
irgendwas mit dem Cache-Mechanismus (den ich nicht näher kenne) von 
vlib?

Konntest du diesen Fehler auch schon nachvollziehen? Hast du eine Idee 
was das sein könnte?

mfg

Ich hatte vor Jahren die letzte nicht auf Sourceforge gehostete 
vlib-Version geladen und seitdem verwende ich diese. Updaten wäre wohl 
angebracht ;-) Das mittlerweile PHP weiter ist und daher Fehler von vlib 
produziert werden können, versteht sich daher von selbst. Den Debug-Code 
verwende ich sehr selten, eher kommentiere ich Bereiche im Template aus 
und kann so den Fehler einkreisen.

Ich habe auch hin und wieder Hänger mit vlib und Ajax, wobei da eher der 
Cache vom FF wohl dazwischenfunkt. Mit Chrome gehts besser. In der 
vlibIni.php lässt sich das Verhalten der Engine beeinflussen. Die 
Variable CACHE_LIFETIME lässt sich ja auch 0 setzen, was das 
Cache-Verhalten praktisch abschalten sollte. Dann ist aber der Aufruf 
von vlibTemplateCache() sinnlos und man kann vlibTemplate() verwenden.

Udo Neist schrieb:
> Ich hatte vor Jahren die letzte nicht auf Sourceforge gehostete
> vlib-Version geladen und seitdem verwende ich diese. Updaten wäre wohl
> angebracht ;-)
OK, das Update lade ich heute noch ins SVN hoch.

> Das mittlerweile PHP weiter ist und daher Fehler von vlib
> produziert werden können, versteht sich daher von selbst.
Jup, das würde die "deprecated"-Meldungen begründen. Die meisten 
Fehlermeldungen stammen jedoch von Zugriffen auf Array-Elemente, die gar 
nicht existieren. Man müsste also an vielen Stellen noch ein "if 
isset()" einfügen. Mal schauen, vielleicht nehme ich mal mit dem 
Entwickler von vlib Kontakt auf um das zu klären.

> Den Debug-Code
> verwende ich sehr selten, eher kommentiere ich Bereiche im Template aus
> und kann so den Fehler einkreisen.
Um zu schauen, wie die Loop-Strukturen und die übergebenen Variablen so 
aussehen, ists aber manchmal ganz praktisch. Ich habe es zwar auch nur 
selten verwendet, trotzdem möchte ich diese Funktion nicht wieder 
rausnehmen müssen :-)

> Ich habe auch hin und wieder Hänger mit vlib und Ajax, wobei da eher der
> Cache vom FF wohl dazwischenfunkt. Mit Chrome gehts besser. In der
> vlibIni.php lässt sich das Verhalten der Engine beeinflussen. Die
> Variable CACHE_LIFETIME lässt sich ja auch 0 setzen, was das
> Cache-Verhalten praktisch abschalten sollte. Dann ist aber der Aufruf
> von vlibTemplateCache() sinnlos und man kann vlibTemplate() verwenden.

Also bei "normaler" Verwendung von Part-DB hatte ich noch nie Probleme, 
nur beim Entwickeln wo ich sehr häufig ganz kleine Änderungen an den 
*.tmpl Dateien vorgenommen habe, und das Ergebnis im Browser jedes mal 
per Refresh aktualisierte. Naja, wenn das Caching wirklich ein ernstes 
Problem darstellen würde, können wir es dann ja immernoch ausschalten...

Urban B. schrieb:
>> Den Debug-Code
>> verwende ich sehr selten, eher kommentiere ich Bereiche im Template aus
>> und kann so den Fehler einkreisen.
> Um zu schauen, wie die Loop-Strukturen und die übergebenen Variablen so
> aussehen, ists aber manchmal ganz praktisch. Ich habe es zwar auch nur
> selten verwendet, trotzdem möchte ich diese Funktion nicht wieder
> rausnehmen müssen :-)

print_r($array); und im Browser den Quelltext anzeigen lassen ;-) 
Verschachtelte Arrays sind mit 0=>array, 1=>array usw. aufzubauen.

Udo Neist schrieb:
> print_r($array); und im Browser den Quelltext anzeigen lassen ;-)

Ja klar geht das auch :-)
Aber im Debug-Modus brauchts nur einen einzigen Buttonklick und man hat 
alle Loops und alle Variablen, die auf der jeweiligen Seite verwendet 
werden, schön aufgelistet. Und das auch noch in einem separaten Popup, 
so dass die Seite an sich nicht verändert wird (macht man ein print_r() 
bevor der HTML-Header geschrieben wurde, funktionieren z.B. die header() 
Funktionen nicht mehr, es "verfälscht" dann also quasi das Ergebnis - 
wenn auch nur selten wirklich spürbar).

Schlussendlich kann ja jeder so debuggen wie er möchte. Ich fände es nur 
schade, diese bereits in vlib integrierte Debugmöglichkeit zu vermeiden, 
nur weil niemand die genannten "if isset()" ergänzen möchte. Wenn ich 
mal Zeit habe kann ich das ja auch selber übernehmen und dann den neuen 
Code an den vlib-Entwickler schicken, vielleichts wirds ja in 
Sourceforge aufgenommen... Aber momentan habe ich anderes zu tun ;-)

Ich habe den Filemanager schonmal ein nutzbares UI verpasst, allerdings 
noch nicht für die Part-DB. Sobald noch die Befehle (Rename, Delete, 
Copy, Move, Up- und Download) funktionieren, kann ich es dank CSS sehr 
einfach an Part-DB anpassen.

Im Moment besteht der Filemanager aus einigen vlib-Templates, ein CSS, 3 
Javascript-Dateien (ajax.js, dom.js und filemanager.js) und verwendet an 
manchen Stellen, bedingt durch den Einbau in ein anderes Framework, noch 
dojo. Letzteres ist für den Filemanager innerhalb von Part-DB nicht 
notwendig und wird entfernt.

Die Entwicklung steht nicht. Wir hatten in den letzten Wochen weniger 
Zeit für das Projekt. Derzeit entwickle ich einen Filemanager, der die 
alten Up-/Downloadformulare genauso wie Copy/Move/Rename/Delete und 
ähnliche Befehle für die verschiedenen Inhalte wie Grafiken ersetzt. Ich 
kann diesen allerdings noch nicht in Part-DB integrieren, da er noch ein 
paar Funktionen eines Javascript-Frameworks nutzt, die ich ersetzen 
will.

Marco tom Suden schrieb:
> Hi Leute,
Hallo!

> Wird Aktuell noch an der part-db gewerkelt?
Jain, bei mir sind grad Semesterprüfungen :-(
In einer Woche kanns aber weitergehen :-)

> Hätte gern mal die Part-DB 0.3.0 getestet,bzw offline also auf VM.
> Gibt's aber ja noch nicht zum dl,sondern nur Online.
Die Sources sind ja im Google Code, die kann man runterladen: 
https://code.google.com/p/part-db/source/browse/#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.

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.

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

Oh, nach genauerem Betrachten der Fehlermeldung habe ich gemerkt, dass 
in der vlibIni.php tatsächlich ein Fehler war (bzw. sehr unschöne 
Programmierung). Ich frage mich schon ein bisschen, was sich da der 
Entwickler von vlib überlegt hat, ist ja ultrakomisch was der da gemacht 
hat^^ (zur Info: vlib wurde nicht von uns entwickelt, alles im 
vlib-Ordner stammt nicht von uns).

Ich habe nun mal wenigstens ein "public static" vor die Methoden 
geschrieben, jetzt dürften diese Fehlermeldungen nicht mehr kommen. 
Aktualisiere einfach deine Installation nochmal per SVN.

Falls es trotzdem noch weitere Fehlermeldungen gibt, einfach nochmal 
hier melden :-)

@all
Ich habe gerade rausgefunden, dass die derzeit benutzte MySQL Engine 
"MyISAM" gar keine Transaktionen unterstützt. Das ist natürlich sehr 
schade, für die User wären Transaktionen nämlich sehr von Vorteil, da 
die Datenbank keine halbfertigen Operationen mehr übernehmen würde.

Ein Beispiel wäre, wenn der Benutzer alle Teile einer Baugruppe abbucht 
(Button "Teile abfassen") und mittendrin ein Fehler auftauchen würde. 
Dann wären die ersten paar Teile erfolgreich abgefasst worden, doch die 
restlichen Bauteile konnten aufgrund des Fehlers nicht mehr abgefasst 
werden. Der Benutzer hat dann keine Change zu erkennen, bis wohin die 
Abbuchung noch erfolgreich war, bzw. er merkt nicht mal dass ein Teil 
der Bauteile abgebucht wurden, und ein Teil nicht.
Ein Fehler kann z.B. duch ein Programmierfehler verursacht werden, oder 
durch eine gleichzeitige Transaktion eines anderen Benutzers. Zweiteres 
ist zwar erst ab mehr als vielleicht 10 bis 20 Benutzer einigermassen 
realistisch, doch in einem kleinen Unternehmen könnte dies durchaus zu 
einem Problem werden.

Könnte man mit Transaktionen arbeiten, würden alle Änderungen, die 
bereits erfolgreich abgeschlossen wurden, wieder problemlos rückgängig 
gemacht werden. Beim Beispiel mit den Baugruppen würde das dann 
bedeuten, dass einfach kein einziges Bauteil abgebucht wurde. Das wäre 
für den Benutzer dann ganz einfach nachzuvollziehen und es gibt keine 
falschen Bestände in der Datenbank.

Es gibt doch nichts mühsameres als eine schiefgelaufene Transaktion die 
dann so halbfertig in der Datenbank verewigt bleibt ;-)

Daher wäre vielleicht ein Umstieg auf "InnoDB" sinnvoll. Ich kenne mich 
damit leider nicht wirklich aus, doch nach ein paar Recherchen im 
Internet dürfte InnoDB etwas langsamer sein als MyISAM. Kommt aber immer 
drauf an was man macht (Lesen / Schreiben). Nach ein paar Tests mit 
Part-DB habe ich festgestellt, dass das Laden der Bauteile einer 
Kategorie etwa doppelt so lange dauert wie mit MyISAM. Meine VM mit 
einem Kern meines i7-3770k und 2GB RAM schafft nun 240 Bauteile in 180ms 
statt in 90ms. Interessanterweise dauert es umso länger, je mehr 
CPU-Kerne ich der VM zuordne...Bei 4 Kernen dauert es um die 500ms, das 
ist schon beachtlich. Ich denke mal dass VirtualBox da irgendwie 
ausbremst...

Nun, die längere Ladezeiten sind zwar mühsam wenn man einen langsamen 
Server hat oder viele Bauteile auf einmal anzeigen möchte. Ich 
persönlich bin aber der Meinung, dass die Konsistenz der Datenbank 
wichtiger ist als die Geschwindigkeit. Ausserdem könnte man die 
Bauteilelisten auch auf mehrere Seiten aufteilen, so dass z.B. maximal 
200 Teile pro Seite angezeigt werden (so wie es ja in jedem Online-Shop 
auch üblich ist).

Was meint ihr dazu? Udo, hast du vielleicht schon Erfahrungen mit InnoDB 
gemacht?

P.S.
Seit MySQL 5.5 ist InnoDB sowieso zur Standard-Engine geworden, das ist 
ja schonmal kein schlechtes Zeichen. Vielleicht wird die Performance in 
der nächsten Zeit ja auch noch verbessert...

EDIT:
Und etwas mehr Geschwindigkeit könnte man vermutlich auch noch mit ein 
paar Optimierungen von Part-DB rausholen. Bisher habe ich die Klassen 
natürlich noch nicht sonderlich auf Geschwidnigkeit getrimmt, sondern 
vielmehr auf die Funktionalität.

Ich würde den Umstieg auf InnoDB befürworten. Geschwindigkeit ist nicht 
das Ziel, sondern Datensicherheit und Nutzbarkeit der Part-DB. Ich würde 
auch jede Suchanfrage auch auf x Ergebnisse einschränken. Wer benötigt 
schon den gesamten Bestand am Bildschirm? Die Einschränkung könnte man 
ja auch mit einer Checkbox oder in der Konfiguration ein- oder 
ausschalten.

Ich habe die Abhängigkeit meines Filemanagers vom dojo-Framework soweit 
beseitigt. Download eines ausgewählten Files funktioniert. Bin gerade an 
der Verarbeitung von Befehlen (Rename, Delete, Copy und Move). Der 
Dialog dazu fehlt noch komplett. Erst wenn das alles funktioniert, dann 
gehts an den Upload. Meine Shell-Klasse werde ich wohl nicht benötigen, 
werde das im Filemanager direkt integrieren.

Okay also wenn ich das alles richtig verstanden habe, genügt ja für jede 
Tabelle ein einziger, kleiner Befehl:

ALTER TABLE `xy` ENGINE=InnoDB

Das kann man problemlos als ganz normales Datenbankupdate in die 
db_update_steps.php schreiben, der Benutzer merkt gar nichts davon. 
Zumindest bei meinen Test hat das funktioniert, bzw. deutet die 
gesunkene Geschwindigkeit darauf hin, dass es funktioniert hat :-)

Falls dadurch noch Probleme verursacht werden, ist das ja schnell wieder 
rausgenommen...
Jetzt muss ich einfach "nur" noch alle Klassen etwas umbauen, damit die 
auch sinnvoll mit den Transaktionen umgehen können.

Ausserdem habe ich noch erste Versuche mit SQLite gestartet. Ich finde, 
SQLite macht es den Hobby-Anwendern, die nicht viel Ahnung von 
Datenbanken haben, sehr viel leichter als MySQL. Und fürs Hobby genügt 
SQLite allemal, und Transaktionen werden auch unterstützt. Ich weiss 
noch wie schwer ich mich getan habe, als ich das erste mal eine MySQL 
Datenbank gebraucht habe. Da kann ich gut verstehen wenn einige User das 
Handtuch werfen und zur "Konkurrenz" gehen.
Ebenfalls für eine einfachere Handhabung habe ich einen Installer 
gebaut, der beim ersten Aufruf der Seite automatisch gestartet wird. 
Dort lassen sich bequem die wichtigsten Einstellungen tätigen (vor allem 
die Verbindung zur Datenbank). So muss sich auch niemand mehr von Hand 
um die config.php kümmern, und falls eine SQLite Datenbank verwendet 
wird, muss nichtmal eine Datenbank vorbereitet werden.

Eigentlich dachte ich ja, mit dem Einsatz von PDO sollte SQLite ganz 
leicht auch unterstützt werden. Tja, ganz so einfach ist es dann aber 
leider doch nicht :-( Es gibt einige MySQL-Befehle, die SQLite nicht 
kennt bzw. anders formuliert werden müssen. Ausserdem müssen in SQLite 
scheinbar alle Indizes über die gesamte Datenbank eindeutig sein, nicht 
nur in der jeweiligen Tabelle. Daher müsste ich noch ein paar Indizes 
umbenennen. Irgendwie sollte das dann aber schon auch noch funktionieren 
denke ich mal :-)

Und wegen dem Upload-Manager, du kannst dich ja melden wenn er 
einigermassen fertig ist, dann schauen wir mal wie wir den am besten 
einbauen.

Urban B. schrieb:
> Und wegen dem Upload-Manager, du kannst dich ja melden wenn er
> einigermassen fertig ist, dann schauen wir mal wie wir den am besten
> einbauen.

Mach ich :-) Bin ja schon mitten drin. Die Befehle werden auch schon 
ausgeführt. Aktuell fehlen mir nur noch ein paar Dialoge und der 
Upload-Teil.

"PHP Deprecated" ist erstmal kein Fehler, sondern nur ein Hinweis, das 
die genannte Funktion als "nicht mehr erforderlich/als überholt" 
markiert wurde und irgendwann in der Zukunft entfällt. Man sollte sich 
als Programmierer dann eine Alternative ausdenken (z.B. eine eigene 
Funktion schreiben, die entsprechend heißt.

"PHP Notice" heißt nur, hier gibts einen Hinweis. In der Regel sind das 
nicht definierte Variablen oder Indices eines Arrays.

Den anderen Fehler schaue ich mir in der Klasse mal an. Eventuell kann 
ich den Fehler beheben.

Fehler: PHP Strict Standards:  Non-static method vlibIni::vlibTemplate() 
should not be called statically, assuming $this from incompatible 
context

Ich habe im Konstruktor den Block

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.

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?! ;-)

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

Udo Neist schrieb:
> Du kannst meine Änderung wieder rückgängig machen, da ich die
> originale Methode nur auskommentiert habe.

Ist gemacht. Entweder bin ich zu blöd, oder es gibt in Google Code keine 
Möglichkeit, eine Änderung rückgängig zu machen bzw. eine frühere 
Revision wiederherzustellen?! Sollte doch eigentlich möglich sein würde 
ich meinen...

@ Marco tom Suden
Hast du mal die zwei Zeilen in die start_session.php eingefügt? hat das 
nichts gebracht?

Marco tom Suden schrieb:
> Ich versuche mir grad mal einen kleinen Überblick zu verschaffen, wie
> das ganze überhaupt Code technisch abläuft.
> Um vtl sogar das Problem genauer Definieren zu können.

Auskommentieren ist hier das Zauberwort :-D Nach wie vor das Nr. 1 
Debugwerkzeug bei mir :-)

Ich kann im Moment dein Problem mit der weißen Seite nicht überprüfen, 
da ich wohl keine ganz aktuelle Datenbank habe. Mir fehlt die Tabelle 
"part-db.pricedetails". Ansonsten läuft nach dem erstmaligen Aufruf von 
install.php soweit alles, egal ob mit oder ohne meiner Änderung an 
vlibTemplate.php.

Ansonsten besteht die Frage, ob Javascript aktiv ist. Ohne JS 
funktioniert Part-DB nicht vollständig.

Edit: Muss wohl meine Datenbank mal löschen und neu aufbauen. Sind noch 
ein paar mehr SQL-Fehler aufgetaucht.

Udo Neist schrieb:
> Ich kann im Moment dein Problem mit der weißen Seite nicht überprüfen,
> da ich wohl keine ganz aktuelle Datenbank habe. Mir fehlt die Tabelle
> "part-db.pricedetails".

Wenn du mit einer Datenbank der Version 12 beginnst, sollte alles 
Notwendige mit den Datenbankupdates nachgerüstet werden, auch die 
Tabelle "pricedetails". Wenn du also eine Part-DB Installation aus dem 
SVN-*Trunk* oder die noch ältere aus der Download-Seite (V0.2.2) hast, 
kannst du die Datenbank von dort kopieren und dann diese für Part-DB 
0.3.0 verwenden. Die wird dann entsprechend angepasst durch die 
DB-Updates.

Aber es gilt immernoch: Die Datenbank ist dann nicht mehr 
abwärtskompatibel, eine upgedatate DB kann also nicht mehr mit den 
stabilen Versionen von Part-DB verwendet werden. Daher nur mit Kopien 
der produktiven Datenbank arbeiten, nicht mit dem Original! :-)

@Marco tom Suden
Ich habe sonst auch keine Ahnung mehr wodurch das Problem verursacht 
werden könnte. Vielleicht findest du es ja noch raus. Ansonsten kann ich 
später eventuell auch selbst mal einen Windows Server aufsetzen zum 
probieren (trotz Windows-Allergie!^^).

Ich hatte die Datenbankversion 13 genutzt. Wahrscheinlich war die etwas 
inkompatibel zu deiner Version und irgendein Update hat fehlgeschlagen. 
Ich werde da wohl von vorne anfangen müssen. Ich habe ja noch kein 
Produktivsystem am Start, alles nur für die Entwicklung.

Udo Neist schrieb:
> Ich hatte die Datenbankversion 13 genutzt. Wahrscheinlich war die etwas
> inkompatibel zu deiner Version und irgendein Update hat fehlgeschlagen.

Ja, ich musste ab und zu das Update von v12 auf v13 nochmal ändern, es 
ging nicht anders. Daher funktioniert auch die Online-Demo nicht mehr 
korrekt, da gibts auch noch Datenbankfehler. Man müsste nur wieder mal 
eine DB der Version 12 einspielen.

Udo Neist schrieb:
> Ich werde da wohl von vorne anfangen müssen. Ich habe ja noch kein
> Produktivsystem am Start, alles nur für die Entwicklung.

Für diesen Fall habe ich den Ordner "development/testfiles/database" 
erstellt. Ich habe dort meine DB v12 vom Produktivsystem abgelegt, damit 
auch Leute ohne eigenes Produktivsystem mit richtigen Datensätzen testen 
können: 
https://part-db.googlecode.com/svn/branches/uneist...

Gute Idee :) Dann werde ich diesen Dump mal einspielen.

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.

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.

Marco tom Suden schrieb:
> Was ist eigentlich damit gemeint?
>
> Die SVN Revision konnte nicht aus
> "C:\wamp\www\part-db-0.3.0/.svn/entries" gelesen werden.

Das ist nur eine Meldung, dass in der Datei die Revisionsangabe fehlt. 
Anscheinend wurde das Format dieser Datei geändert, denn in älteren 
Versionen von SVN konnte man dies auslesen. Wahrscheinlich ist das ganze 
in eine SQLite-Datenbank mit dem Namen wc.db gewandert. Manche Server 
verbieten Shellzugriffe von PHP aus und daher wurde von "svnversion" per 
system() in get_svn_revision() auf eine manuelle Lösung umgestellt. Die 
funktioniert halt nicht mehr. Ich begebe mich mal auf die Suche nach 
einer Lösung.

Ein Glück hatte ich erst vor kurzem das Firefox-Addon SQLite-Manager 
installiert ;-) Folgendes habe ich gefunden: Die wc.db enthält in der 
Tabelle eine Spalte 'revision', in der die gewünschte Information 
gespeichert ist.

@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));

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

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.