Lagerverwaltung Part-DB V0.2.2

Urban B. schrieb:
> (der User muss nicht selbst eine Datenbank anlegen)

Das kann auch die Installationsroutine erledigen.

> wenn SQLite eingesetzt wird, kann
> Part-DB z.B. vor jedem Datenbankupdate selbstständig ein Backup der DB
> anlegen.

PHP kann doch ein Shell-Skript, bzw. das Windows-Äquivalent dazu 
starten, oder nicht?

> Versteh mich nicht falsch - ich will nicht MySQL schlechtmachen oder so.

Mir geht es nicht um MySQL - hätten wir SQLite, dann wäre meine 
Argumentation gegenüber MySQL dieselbe -, sondern um den Testaufwand. 
Wir unterstützen zwei Betriebssysteme und wenn wir dann auch noch zwei 
Datenbanken unterstützen, dann muß - wenn man es solide machen will - 
schon der vierfache Testaufwand betrieben werden.

Wie gründlich man als Entwickler sowas dann letztlich macht, wirst du 
selbst wissen. Mein innerer Schweinehund hat mich meistens davor 
bewahrt, das auch nur annähernd gründlich genug zu tun und die Quittung 
kam dann mit ziemlicher Sicherheit hinterher.


Markus Müller schrieb:
> Ich habe das mit der Datensicherung der MySQL DB in EleLa relativ leicht
> gelöst:
> - Man wählt die Sicherungsdatei aus, die ist eine SQLite Datenbank

Warum sicherst du in eine SQLite DB?


Ich habe in einem Rails-Projekt recht gute Erfahrungen mit dem 
Dump-Programm von MySQL gemacht. Das kickt man an und schon hat man eine 
Textdatei, die alle Daten enthält, mit der man eine leere DB befüllen 
kann und das Anlegen einer leeren DB kann man per Skript machen, das aus 
der Installationsroutine angekickt wird.

Uhu Uhuhu schrieb:
> PHP kann doch ein Shell-Skript, bzw. das Windows-Äquivalent dazu
> starten, oder nicht?

Uhu Uhuhu schrieb:
> Ich habe in einem Rails-Projekt recht gute Erfahrungen mit dem
> Dump-Programm von MySQL gemacht. Das kickt man an und schon hat man eine
> Textdatei, die alle Daten enthält, mit der man eine leere DB befüllen
> kann und das Anlegen einer leeren DB kann man per Skript machen, das aus
> der Installationsroutine angekickt wird.

Ja, genau so hatten wir es schonmal eingebaut, das funktioniert auch 
wunderbar solange man genügend Rechte hat, so ein Skript 
auszuführen. Unser Ziel ist es aber, dass Part-DB weitgehendst auch 
auf einem einfachen Webspace läuft - und da ist dann häufig nix mehr mit 
Skripte ausführen, weil exec() vom Hoster gesperrt ist.

Marco tom Suden schrieb:
> Damit währe glaube ich mal diese Punkt abgehakt,oder.

Jup, die Pfad-Konstanten sollten somit (hoffentlich) auf allen Systemen 
funktionieren.

Marco tom Suden schrieb:
> Was is denn sonst noch so auf der Bug-list oder wie man das jetzt
> nennt?.

Nun, da sind noch einige Sachen. Zum richtig Testen ist es eigentlich 
noch zu früh denke ich. Eine ToDo-Liste gibts noch in der 
Quellcode-Dokumentation (nicht alle Punkte betreffen aber die Version 
0.3.0 - einige können noch länger warten, z.B. die System-Updates und 
die Benutzerverwaltung).
Wenn du in der config.php die Einstellung "developer_mode" auf "true" 
stellst, kommt ein neuer Menüpunkt "Entwickler-Werkzeuge" zum Vorschein, 
dort drin ist dann der Link zur Quellcode-Dokumentation.

Wichtig wäre mir in nächster Zeit mal jemand der sich mit Datenbanken 
etwas besser auskennt, da einige kompliziertere Abfragen noch nicht 
genau das machen was sie sollten :-)

>z.B. dass es AUTOINCREMENT anstatt AUTO_INCREMENT heisst

Bei SQLite deklariere ich das Feld nur als "INTEGER NOT NULL PRIMARY 
KEY" und es ist automatisch ein Autoincrement-Feld.

EleLa merkt sich den CREATE TABLE Code als SQLite Syntax. Dazu habe ich 
eine Routine geschrieben "ChgQueryCreateSQL()", die biegt alles um auf 
MySQL und PostgreSQL. Feldtypen, AutoIncrement und Indize.
Wichtig ist, dass Felder mit der gleichen Funktion auch den gleichen 
Name haben, wie "ID" "Bezeichnung" "Beschreibung" "AendDatum" um die 
globalen Funktionen besser nutzen zu können.

>Also werden nur die Backups als SQLite abgespeichert, oder kann man auch
>direkt von Anfang an mit SQLite arbeiten?

EleLa kann SQLite, MySQL und PostgreSQL. Nach dem ersten Setup wird man 
in der Regel mit SQLite beginnen um mal rein schnuppern zu können ob 
einem überhaupt das Programm gefällt und es sind auch schon einige 
Datensätze (Widerstände) vorhanden.
Jederzeit kann man auf MySQL oder PostgreSQL wechseln.
Wenn man in EleLa nur die Verbindungsdaten des MySQL Servers eingibt, so 
kann EleLa mit einem Tastenklick eine neue Datenbank samt aller Tabellen 
automatisch anlegen (der MySQL-User muss natürlich die Rechte haben). 
Ein Import der bestehenden SQLite Daten in MySQL und man hat innerhalb 
weniger Sekunden MySQL als Server.
Mit EleLa ist der Wechsel der Datenbank ein Kinderspiel und alles 
Menügeführt.

Uhu Uhuhu schrieb:
> Warum sicherst du in eine SQLite DB?

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

Markus Müller schrieb:
> EleLa merkt sich den CREATE TABLE Code als SQLite Syntax. Dazu habe ich
> eine Routine geschrieben "ChgQueryCreateSQL()", die biegt alles um auf
> MySQL und PostgreSQL. Feldtypen, AutoIncrement und Indize.

So ähnlich habe ich mir das auch vorgestellt. Da Part-DB bis jetzt nur 
MySQL unterstützte, sind alle Updatebefehle auch in MySQL Syntax 
gespeichert. Nun habe ich in der Updateroutine einfach mal ein 
rudimentärer "Konverter" eingebaut, der eben z.B: ein "AUTO_INCREMENT" 
automatisch durch ein "AUTOINCREMENT" ersetzt, oder sowas wie 
"ENGINE=InnoDB" entfernt.

Ich habe auch festgestellt dass mit SQLite das hier nicht funktioniert:

1

INSERT INTO tabelle SET key=value

Das hier funktionier hingegen bei SQLite und MySQL:

1

INSERT INTO tabelle (key) VALUES (value)

Schlussendlich müssen wir Entwickler uns einfach darauf einigen, dass 
immer die zweite Variante verwendet wird. Das sollte eigentlich kein 
Problem sein, an andere Code-Guidelines halten wir uns ja auch.
Und wenn wirklich mal eine fehlerhafte Datenbankabfrage in ein Release 
kommt - davon geht die Welt auch nicht unter. Ausser der Fehler passiert 
beim Datenbankupdate und es existiert kein Backup - dieses Problem 
hätten wir aber bei SQLite sicher nicht, und wenn wir dein System für 
das Backup einer MySQL Datenbank auch noch einbauen, existiert das 
Problem auch bei MySQL nicht mehr.

Markus Müller schrieb:
> EleLa kann SQLite, MySQL und PostgreSQL. Nach dem ersten Setup wird man
> in der Regel mit SQLite beginnen um mal rein schnuppern zu können ob
> einem überhaupt das Programm gefällt

Genau sowas finde ich für Einsteiger sehr wichtig, darum "kämpfe" ich ja 
auch für die Unterstützung von Part-DB für SQLite :-)
Auch der Installer, den es bisher noch nicht gab, finde ich wichtig. Ich 
bin mir ziemlich sicher, dass schon viele Leute Part-DB runtergeladen 
haben, dann aber mit dem Einrichten überfordert waren und es aufgegeben 
haben. Das ist natürlich schade, denn mit einem benutzerfreundlichem 
Installer und SQLite-Datenbank lässt sich das weitgehendst verhindern.

Dass man auch einfach zwischen verschiedenen Datenbanken wechseln kann, 
ist für den Anfang sicher nicht notwendig. Später, wenn wir mehr Zeit 
für solche Sachen haben, könnte man natürlich immernoch einen 
"Konverter" einbauen. Momentan haben wir aber wichtigere Sachen zu tun 
:-)

EDIT:
Ich habe in unseren "Issues" gleich mal einen Link eingefügt zur 
Beschreibung der Datenbanksicherung von Markus: 
https://code.google.com/p/part-db/issues/detail?id=3

>Später, wenn wir mehr Zeit für solche Sachen haben

Ja, klar. War bei mir am Anfang auch nicht drin und kam erst später.
Macht erst mal weiter mit eurem Projekt und bringt das auf einen guten 
Stand.

Irgend wann einmal, wenn PartDB gut läuft können wir auch mal dran gehen 
und EleLa/PartDB von der Datenstruktur her angleichen, dann wäre EleLa 
und PartDB mit dem gleichen Datenbestand nutzbar. Ein Front-End für 
Lokal und eines Internettauglich :-)
Im moment sind die noch zu verschieden, hier die EleLa-DB:
http://www.mmvisual.de/Hilfe/EleLa/TutorialDB/TutDB.htm

Daß ein unbedarfter User mit MySQL zurecht kommt, ist letztendlich eine 
Frage der Anleitung, nach der er das macht. Er muß ja nicht im Einzelnen 
verstehen, was da passiert, aber so lange er ein Kochrezept an die Hand 
bekommt, nach dem er nur Schritt für Schritt vorgehen muß, dann wird er 
diese Klippe nehmen. Und wenn man ihn zusätzlich noch mit Skripten 
versorgt, die ihn vor Tippfehlern bewahren, dann ist das ganz prima.

Nur ohne, oder mit einer Doku, die in Rudimenten über diverse Threads, 
Quelltexte, Readmes etc. pp. verstreut ist, wird das natürlich nix.

Marco tom Suden schrieb:
> Habe grad mal alles durch gegangen,als ich bei Zeige/Statistik an kam,
> dauerte es erst ne weile bis überhaupt was angezeigt wurde.

Das ist eine Baustelle, wo mal einer mit mehr Datenbankkenntnissen ran 
muss :-) Momentan habe ich dort noch improvisiert, es werden Sachen mit 
PHP berechnet, die man (mit genügend Kenntnissen^^) auch mit SQL machen 
könnte, damit würde es gleich viel schneller gehen.

Marco tom Suden schrieb:
> Nach dem 2 Versuch öffnete sich die Seite wie sie soll, jedoch fiel mir
> sofort das Karo mit (?) ins Auge. Das sicherlich das € darstellen
> soll,was glaub ich mal an der Kodierung UTF-8 / ANSI liegt.

Ja, das ist auch ein Problem von mir, weil ich da den Durchblick noch 
nicht habe mit den verschiedenen Kodierungen :-( In der Konfiguration 
kannst du übrigens noch den Zeichensatz ändern, bringt das auch nichts 
wenn du den auf "ISO-8859-1" stellst?

In den *.tmpl Dateien sind bisher auch alle ä, ö, ü ganz normal 
gschrieben, und nicht in HTML-Schreibweise (ä). Bei mir 
funktioniert das zwar, ich weiss aber nicht inwiefern das auch mit 
anderen Systemen kompatibel ist, bzw. ob sich das mit dem Ändern des 
Zeichensatzes lösen lässt.

Udo, hast du hier vielleicht den Durchblick und kannst mir mit ein paar 
Sätzen mal einen kurzen Crashkurs geben? :-D

Ich finde die Schreibweise ä mühsam und würde sie gerne vermeiden 
wenn es geht.

Markus Müller schrieb:
> Irgend wann einmal, wenn PartDB gut läuft können wir auch mal dran gehen
> und EleLa/PartDB von der Datenstruktur her angleichen, dann wäre EleLa
> und PartDB mit dem gleichen Datenbestand nutzbar. Ein Front-End für
> Lokal und eines Internettauglich :-)
> Im moment sind die noch zu verschieden, hier die EleLa-DB:
> http://www.mmvisual.de/Hilfe/EleLa/TutorialDB/TutDB.htm

Uiuiui, da hat sich ja schon richtig was ergeben bei dir :-D Gegen deine 
DB sieht unsere ja grad mickrig aus :-D
Also falls das mal was werden würde mit dem Angleichen von 
Part-DB/EleLa, dann sicher erst in ferner Zukunft. Unsere nächsten Ziele 
sind erstmal die Version 0.3.0 stabil zu machen. Dann arbeiten wir auf 
die Version 1.0.0 hin, wo nochmal sehr viel getan werden muss: es soll 
eine Benutzerverwaltung und ein automatisches System-Update geben.
Die Arbeit geht uns erstmal also nicht aus :-)

Uhu Uhuhu schrieb:
> Daß ein unbedarfter User mit MySQL zurecht kommt, ist letztendlich eine
> Frage der Anleitung, nach der er das macht.
Ja stimmt schon auch. Aber dann müssen wir wieder zwei verschiedene 
Anleitungen schreiben, eine für Windows und eine für Linux. Ist also 
auch doppelter Aufwand.

Naja - ich werde mir in den nächsten paar Wochen das Thema SQLite 
nochmal genauer anschauen und ausführlichere Tests machen. Dann kann man 
besser abschätzen wieviel Mehraufwand es wirklich bedeutet. Bis jetzt 
habe ich aber den Eindruck, mit ein paar SQL Guidelines kriegen wir das 
sehr gut in den Griff.

Marco tom Suden schrieb:
> Ja das geht auch, meinte nur wenn man das auf utf-8 hat geht's nicht.
> Mit ISO-8859-1 geht's auch mit auskommentierter Zeile.
>
> Unter utf-8 jedoch nicht.
>
> Wenn du nichts dagegen hast,würde mir gern mal die ganze
> Konstruktion,etwas genauer ansehen,vtl Find ich ja ne Lösung dafür ;-).

Ach so, dann ist doch alles gut? :-)
Genau für diesen Fall gibts doch die Möglichkeit, den Zeichensatz zu 
ändern.

Meine Vermutung ist, dass Zeichen wie ä halt immer funktionieren, 
unabhängig vom Zeichensatz. Verwendet man aber ganz normale Zeichen wie 
ä, ö, ü, so muss man dem Browser halt mitteilen wie er die Zeichen 
interpretieren soll. Ist aber nur eine Vermutung von mir, da ich 
eigentlich mit Webseiten-Entwicklung nicht viel am Hut habe.

Vielleicht sollte man in der Installationsroutine eine Erkennung des 
Betriebssystems einbauen. Wird Windows verwendet, soll der Zeichensatz 
automatisch auf ISO-8859 gesetzt werden, ansonsten auf utf-8.

Die Zeichen in der DB sollten immer UTF-8 sein, denn wenn man mal einen 
Server-Umzug von Windows <> Linux macht, dann sollte der eine Export 
beim anderen Import immer gehen.
Zum zweiten ist UTF-8 unter Linux Standard.
Mit htmlentities() sollte das ganze dann auch korrekt gewandelt werden.

>Uiuiui, da hat sich ja schon richtig was ergeben bei dir :-D

Bei meiner Versino 0.x war das auch noch so. ;-)
Um so mehr PartDB nutzen um so mehr Anforderungen und entsprechend 
Tabellen/Felder wird es geben.
Foreign Key's nutze ich nicht, denn SQLite kann das nicht. Wird alles im 
Programm geprüft.

Markus Müller schrieb:
> Die Zeichen in der DB sollten immer UTF-8 sein, denn wenn man mal einen
> Server-Umzug von Windows <> Linux macht, dann sollte der eine Export
> beim anderen Import immer gehen.

Ja, das macht Sinn. Ist bei Part-DB auch standardmässig auf UTF-8 
gesetzt, kann jedoch geändert werden. Theoretisch könnte man diese 
Möglichkeit vielleicht auch noch rauswerfen, also dass es immer mit 
UTF-8 arbeitet, da dies ja jeder MySQL Server unterstützen sollte.

Markus Müller schrieb:
> Foreign Key's nutze ich nicht, denn SQLite kann das nicht.
Sicher? http://www.sqlite.org/foreignkeys.html

Stimmt, jetzt kann SQLite das. Ab der Version 3.6.19.
Ich nutze schon viel länger SQLite und damals konnte SQLite das nicht.

Wenn Du jetzt SQLite mit Foreign Keys unter Linux nutzt, dann musst Du 
auch sicherstellen, dass die DLL libsqlite.so auch wirklich eine 
aktuelle ist. Ältere Linux-Distris haben zum Teil nicht die neueste 
libsqlite mit dabei. Ich meine sogar, als ich vor einem halben Jahr mal 
Debian in eine VBox installiert habe, dass dort auch nur eine 
V3.6.irgendwas dabei war und nicht mal eine 3.7.x.
Bei mir überprüft EleLa die Konsistenz der Daten und ich zeige auch 
entsprechende Fehlermeldungen. Wenn das nur die DB macht, dann kommen 
kryptische Meldungen auf den Bildschirm und das ist immer schwierig zu 
handeln. Foreign Keys sind nur für den Notfall da, falls man mal ein Bug 
in der Programmierung drin hat, um die Daten zu schützen.

EleLa macht auch alles mit UTF-8, da das Standard der 
Programmierumgebung Lazarus ist. Damit wäre schon mal der erste 
Meilenstein für das Zusammenspiel gelegt ;-)

Bei MySQL lege ich die DB immer mit dem Code an:

1

CREATE DATABASE IF NOT EXISTS <######> DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci

Also hier unter Ubuntu 12.10 ist SQLite 3.7.13 in den offiziellen 
Paketquellen. Wie es auf den gängigen Webservern aussieht, weiss ich 
aber nicht.

Part-DB hat eigentlich eh schon "relativ hohe" Anforderungen an die 
PHP-Version (mind. 5.3), da sollte die hohe Anforderung bei SQLite auch 
nicht mehr so schlimm sein. Obwohl man meinen würde, dass heute PHP5 
Standard ist, musste ich meinen Webhoster anfragen ob Sie mir PHP 5.3 
installieren könnten. Die haben immer noch PHP4, und per Webfromular 
kann man es auf 5.2 aktualisieren lassen. Mit einer persönlichen Anfrage 
aktualisieren sie aber auch auf 5.3.

Alternativ könnte man immernoch im Installer schreiben:
Entweder SQLite >= 3.6.19, oder dann MySQL.

Obwohl auch in Part-DB seit der Version 0.3.0 die Beziehungen sehr genau 
"von Hand" überprüft werden, ist die Überprüfung durch das 
Datenbanksystem per Foreign Keys doch nochmal ein Plus an Sicherheit. 
Das werde ich noch einbauen müssen, bis jetzt werden nämlich auch bei 
MySQL keine Foreign Keys verwendet...

@Markus
Habe ich das eigentlich richtig verstanden, dass bei SQLite die Indizes 
innerhalb der ganzen Datenbank eindeutig sein müssen, bei MySQL aber nur 
innerhalb einer Tabelle?

Nein, bei mir sich die Indizes nur innerhalb der Tabelle eindeutig. Das 
geht so wie ich oben gezeigt habe.

Aber, wenn man bei SQLite den letzten Datensatz (z.B. ID = 15) löscht, 
dann ist der letzte ID = 14. Wenn man nun einen neuen Datensatz anlegt, 
so erhält der wieder 15. Bei MySQL würde der Datensatz die ID = 16 
erhalten. SQLite ist schon eine wirklich einfache Datenbank, SQLite ist 
fast wie ein Müllschlucker und frisst alles.
Besonders musst Du auf Datums und Zeitfelder aufpassen und die besser 
als Float Felder abfragen und selbst in das gewünschte Anzeigeformat 
wandeln, damit habe ich ständig Probleme. Das Datumsfeld als Float 
abzufragen macht bei MySQL keine Probleme.

Die SQLite Version kannst Du mit dem SQL Befehl einfach auslesen:

SELECT sqlite_version() AS Vers

Markus Müller schrieb:
> Nein, bei mir sich die Indizes nur innerhalb der Tabelle eindeutig. Das
> geht so wie ich oben gezeigt habe.

Hmm okay, dann muss ich mir das nochmal anschauen...Ich bekam immer eine 
Fehlermeldung (blabla...already exists...blabla) wenn ein gleichnamiger 
Index bereits in einer anderen Tabelle vorhanden war.

Momentan habe ich aber für sowas keine Zeit. Ab Freitag kanns dann 
wieder richtig weitergehen :-)

Vermutlich muss nur der Name des Indizes eindeutig sein, den also so 
z.B. benennen:
TabellenName_FeldName_IX
Probiere das mal.
PS: Index oder Primary key? Nicht dass wir jetzt da was durcheinander 
bringen.

Bei sieht das z.B so aus:

CREATE TABLE IF NOT EXISTS bauteil (
ID INTEGER NOT NULL PRIMARY KEY,
: :
AendDatum DATETIME);

CREATE TABLE IF NOT EXISTS bauteillager (
ID INTEGER NOT NULL PRIMARY KEY,
: :
AendDatum DATETIME);

Hinterher erzeuge ich die Indizes.

Markus Müller schrieb:
> Vermutlich muss nur der Name des Indizes eindeutig sein, den also so
> z.B. benennen:
> TabellenName_FeldName_IX

Ja, genau das meine ich. Es gibt bei uns verschiedene Tabellen, die 
gleichnamige Spalten haben. Also eine Spalte "A" in Tabelle 1, und eine 
Spalte "A" in Tabelle 2. Bei beiden ist diese Spalte A auch ein Index 
(nicht Primary Key) und heisst ebenfalls "A". Und da bekomme ich bei 
SQLite eine Fehlermeldung dass so ein Index schon existiert, bei MySQL 
hingegen funktioniert es. Daher kam die Vermutung, dass die Namen der 
Indizes bei MySQL nur innerhalb einer Tabelle eindeutig sein müssen, bei 
SQLite jedoch innerhalb der ganzen Datenbank.

Aber ein "Tabellenname_" vor die Index-Namen zu setzten ist natürlich 
kein Problem, werde ich dann vermutlich so einbauen.

Als nächstes (wenn ich wieder Zeit habe) werden aber erstmal überall 
Transaktionen eingebaut, damit im Fehlerfall immer ein Rollback 
durchgeführt werden kann. Und dann den Installer noch etwas ergänzen, 
die Importfunktionen wieder zum laufen bringen, einige kleine Bugs 
beheben usw usw... :-)

mfg

Transaktionen machen die DB auch schneller, da erst mal nichts auf die 
Disk geschrieben wird.

Wenn Du fragen zu SQL Befehlen hast kannst Du mir auch eine PN 
schreiben.
Ich kann Dir auch Teile von EleLa schicken, damit Du siehst wie ich z.B. 
"ChgQueryCreateSQL()" mache oder Felder im Update hinzufüge.
Ist halt Lazarus/Pascal und Du müsstest das umschreiben auf PHP.

Transaktionen dienen der Datenkonsistenz und nicht der Geschwindigkeit. 
Erst wenn alle SQL-Aktionen innerhalb einer Transaktion fehlerfrei 
ausgeführt wurden, dann erfolgt das COMMIT und die Datenbank schreibt 
die Daten endgültig auf Platte. Wenn man Geschwindigkeit herausholen 
möchte, dann per Indices, Keys, Cache etc. SQLite ist zwar nett, aber 
nur für Einzelplatzsysteme wirklich sinnvoll. Erstmal ist MySQL zu 
bedienen, danach kann man ja auch andere Systeme unterstützen. Die Idee, 
SQLite als Backup zu nutzen, finde ich interessant.

Markus Müller schrieb:
> Wenn Du fragen zu SQL Befehlen hast kannst Du mir auch eine PN
> schreiben.
> Ich kann Dir auch Teile von EleLa schicken, damit Du siehst wie ich z.B.
> "ChgQueryCreateSQL()" mache oder Felder im Update hinzufüge.

Danke für das Angebot, ich werde darauf zurückkommen wenn ich soweit bin 
und Hilfe brauchen könnte.

> Ist halt Lazarus/Pascal und Du müsstest das umschreiben auf PHP.

Das ist kein Problem, ich habe auch mal Pascal programmiert :-)

Udo Neist schrieb:
> SQLite ist zwar nett, aber
> nur für Einzelplatzsysteme wirklich sinnvoll.

Und genau das wird für viele Benutzer schon genügen, da sie zu Hause 
Part-DB nur auf einem einzigen Computer benutzen ;-)

Udo Neist schrieb:
> Erstmal ist MySQL zu
> bedienen, danach kann man ja auch andere Systeme unterstützen.

Jup, erstmal hat MySQL schon Priorität. Wenn es aber kein grosser 
Aufwand ist, kann ich SQLite auch schon in die Version 0.3.0 einbauen.

Übrigens habe ich gerade noch das Auslesen der SVN-Revision mit einem 
PDO Objekt gelöst, funktioniert wunderbar :-) Wird in nächster Zeit mal 
noch ins SVN hochgeladen...

Der Filemanager nimmt so langsam Formen an. Ich habe heute am 
Dialogsystem gearbeitet. Damit ihr euch schon mal ein Bild davon machen 
könnt, habe ich zwei Screenshots angehängt.

Das ganze basiert auf zwei Javascript-Klassen mit eigenem Namensraum. 
Derzeit fehlt noch die Anbindung der Dialogbuttons an frei definierbare 
Funktionen innerhalb der DOM-Klasse. Das Aussehen der Elemente ist in 
CSS-Dateien definiert. Im Moment erbt der Dialog noch ein Element der 
Webseite, wird aber noch korrigiert. Der PHP-Unterbau benötigt eine 
fileIO-Klasse.

Sieht doch schonmal ganz gut aus!

Vielleicht könnte man ja den Bereich "Ausgawähltes File / Dateiinfos" 
noch auf die rechte Seite nehmen, dann ist es auch besser für 
Bildschirme mit niedriger Auflösung (z.B. 1366x768) geeignet. Die blöden 
Netbooks haben einfach eine viel zu niedrige vertikale Auflösung...

Ach ja, falls das noch nicht geplant ist: Ganz oben wäre noch eine 
Navigations-Zeile sinnvoll, damit man sieht in welchem Ordner man sich 
gerade befindet. Also sowas in der Art:

1

media / footprints / TQFP

Wobei natürlich jedes dieser Elemente ein Link sein könnte um zum 
jeweiligen Ordner navigieren zu können.

Bin auf jeden Fall schonmal gespannt auf den fertigen Dateimanager :-)

Urban B. schrieb:
> Sieht doch schonmal ganz gut aus!

Danke :-)

> Vielleicht könnte man ja den Bereich "Ausgawähltes File / Dateiinfos"
> noch auf die rechte Seite nehmen, dann ist es auch besser für
> Bildschirme mit niedriger Auflösung (z.B. 1366x768) geeignet. Die blöden
> Netbooks haben einfach eine viel zu niedrige vertikale Auflösung...

Dank CSS lassen sich die 4 Blöcke (Ordner, Dateiinfo, Commands und 
Explorer) frei verschieben. Nur die IDs sind fest vergeben.

> Ach ja, falls das noch nicht geplant ist: Ganz oben wäre noch eine
> Navigations-Zeile sinnvoll, damit man sieht in welchem Ordner man sich
> gerade befindet. Also sowas in der Art:
>

1

media / footprints / TQFP

> Wobei natürlich jedes dieser Elemente ein Link sein könnte um zum
> jeweiligen Ordner navigieren zu können.

Breadcrumb-Navigation? Existiert schon auf der globalen Ebene der 
Webseite und wäre für den Dateimanager recht einfach zu adaptieren. Die 
Navigation enthält aber keine Links. Werde ich mal für die nächste Runde 
umsetzen.

> Bin auf jeden Fall schonmal gespannt auf den fertigen Dateimanager :-)

:-)

Udo Neist schrieb:
> Dank CSS lassen sich die 4 Blöcke (Ordner, Dateiinfo, Commands und
> Explorer) frei verschieben. Nur die IDs sind fest vergeben.

OK super!

Udo Neist schrieb:
> Breadcrumb-Navigation?

Lol, wusste gar nicht dass das so heisst xD Aber ja, laut Wikipedia ist 
das genau das was ich meinte :-) Halt wie in Nautilus, Windows Explorer 
usw.

Sind eigentlich die beiden Ordner links oben auf dem Screenshot 
aufklappbare Menüs wo dann die ganze Verzeichnisstruktur ersichtlich 
ist?

Urban B. schrieb:
>> Breadcrumb-Navigation?
>
> Lol, wusste gar nicht dass das so heisst xD Aber ja, laut Wikipedia ist
> das genau das was ich meinte :-) Halt wie in Nautilus, Windows Explorer
> usw.
>
> Sind eigentlich die beiden Ordner links oben auf dem Screenshot
> aufklappbare Menüs wo dann die ganze Verzeichnisstruktur ersichtlich
> ist?

In meinem Beispiel sind das zwei fest vergebene Verzeichnisse, die 
unterhalb eines gemeinsamen Verzeichnisses liegen. Ausserhalb dieser 
Verzeichnisse kann der Filemanager nicht zugreifen.

Natürlich lassen sich diese Verzeichnisse auch ändern. Entsprechend dem 
Einsatzzweck muss man die Konfiguration und Suchfunktion anpassen. Ich 
habe mal die Dateisuchfunktion rauskopiert, damit man mal eine 
Vorstellung davon hat.

1

function searchFiles() {

2

    /*

3

        Sucht nach Dateien

4

    */

5

6

    global $dirs;

7

8

    $fileIO = new fileIO;

9

    $fileIO -> readDir($dirs['dir'].'/'.$_GET['list'],'','cached',array('mime'=>$dirs['mime'][$_GET['type']],'recursive'=>false,'onlyfiles'=>false,'stripdir'=>true));

10

    $files = $fileIO -> getFiles();

11

    $tmpl = new vlibTemplateCache('templates/vlib/vlib_filemanager_list.html');

12

    $tmpl -> setVar('path',$_GET['list']);

13

    $tmpl -> setVar('type',$_GET['type']);

14

    if (count($files)>0) {

15

        asort($files);

16

        $array=array();

17

        if (strpos($_GET['list'],'/')>0) {

18

            $dir = explode('/',$_GET['list']);

19

            if (count($dir)>1) {

20

                $last = array_pop($dir);

21

                $array['dir'][]=basename(implode('/',$dir));

22

            }

23

        }

24

        foreach($files as $file) {

25

            if (is_dir($file)) {

26

                // Directory

27

                $array['dir'][]=str_replace($dirs['dir'].'/','',$file);

28

            }else{

29

                // File

30

                $array['file'][]=$file;

31

            }

32

        }

33

        foreach($array as $type => $file) {

34

            $tmpl -> newLoop($type);

35

            foreach($file as $name) {

36

               $tmpl -> addRow(

37

                    array(

38

                        'name'      =>  (($type=='dir' && strlen($_GET['list'])>strlen($name))?'..':basename($name)),

39

                        'path'      =>  (($type=='file')?$name:$name),

40

                        'b64name'   =>  base64_encode($dirs['dir'].'/'.$_GET['list'].'/'.$name)

41

                    )

42

                );

43

            }

44

            $tmpl -> addLoop();

45

        }

46

        $tmpl -> setVar('type',$_GET['list']);

47

    }else{

48

        $tmpl -> setVar('nofile',true);

49

    }

50

    $tmpl -> pparse();

51

}

52

53

54

class fileIO {

55

    function readDir($path = '.',$search = '',$exclude = '', $options = array('mime'=>array(),'recursive'=>true,'onlyfiles'=>false,'stripdir'=>false)) {

56

    /*

57

        Durchforstet das übergebene Verzeichnis rekursiv nach Dateien

58

59

        * Variablen

60

        $this -> files (array): Container für Dateien

61

        $path (string): Suchpfad (Default: .)

62

        $search (string): Suchmuster für preg_match()

63

        $exclude (string): Suchmuster für preg_match() zum Ausschliessen von Dateien/Verzeichnissen

64

        $options (array):

65

            recursive (bool): Rekursiv suchen

66

            onlyfiles (bool): Nur Dateien

67

            stripdir (bool): Gibt nur den Filenamen zurück

68

            mime (string): Mimetyp

69

70

        * Rückgabe

71

        $this -> files (array): Liste der Ergebnisse mit absoluten Pfad

72

73

        * Anforderung

74

        Kein Datenbanklink erforderlich!

75

76

        * Anmerkung

77

        Der Punkt ist das aktuelle Verzeichnis, ".." kennt man als "Verzeichnis höher" und "dir/" als "Verzeichnis tiefer".

78

79

    */

80

    }

81

}

Udo Neist schrieb:
> In meinem Beispiel sind das zwei fest vergebene Verzeichnisse, die
> unterhalb eines gemeinsamen Verzeichnisses liegen. Ausserhalb dieser
> Verzeichnisse kann der Filemanager nicht zugreifen.

Jup, ich denke schlussendlich soll der Benutzer die Verzeichnisse 
"img/footprints/", "/img/iclogos/" und "media/" im Dateibrowser zur 
Verfügung haben. In "img/..." darf er aber nur Leserechte haben, da die 
dort enthaltenen Dateien von Part-DB verwaltet werden, also auch Updates 
bekommen. Fummelt der Benutzer da drin rum, gibts nur ein Chaos.

Für die Dateien des Benutzers ist der Ordner "media/" vorhanden, dort 
kann er tun und lassen was er möchte. Part-DB hingegen wird dort keine 
Dateien ablegen.

Möchte ein Benutzer z.B. die Footprint-Bilder auf eine andere Art und 
Weise sortiert haben, so muss er unseren Footprint-Ordner nach media/ 
kopieren und dort nach seinen Wünschen organisieren.

Urban B. schrieb:
> Udo Neist schrieb:
>> In meinem Beispiel sind das zwei fest vergebene Verzeichnisse, die
>> unterhalb eines gemeinsamen Verzeichnisses liegen. Ausserhalb dieser
>> Verzeichnisse kann der Filemanager nicht zugreifen.
>
> Jup, ich denke schlussendlich soll der Benutzer die Verzeichnisse
> "img/footprints/", "/img/iclogos/" und "media/" im Dateibrowser zur
> Verfügung haben. In "img/..." darf er aber nur Leserechte haben, da die
> dort enthaltenen Dateien von Part-DB verwaltet werden, also auch Updates
> bekommen. Fummelt der Benutzer da drin rum, gibts nur ein Chaos.

Ich kann ja den Filemanager soweit ergänzen, dass er neben den 
Verzeichnisnamen auch Rechte verwaltet. Wäre also sowas wie:

1

$dir[0]['dir']="img/footprints/";

2

$dir[0]['name']="Footprints";

3

$dir[0]['type']="image";

4

$dir[0]['mode']="ro";

5

$dir[1]['dir']="img/iclogos/"

6

$dir[1]['name']="IC Logos";

7

$dir[1]['type']="image";

8

$dir[1]['mode']="ro";

9

$dir[2]['dir']="media/"

10

$dir[2]['name']="Media";

11

$dir[2]['type']="";

12

$dir[2]['mode']="rw";

>
> Für die Dateien des Benutzers ist der Ordner "media/" vorhanden, dort
> kann er tun und lassen was er möchte. Part-DB hingegen wird dort keine
> Dateien ablegen.
>
> Möchte ein Benutzer z.B. die Footprint-Bilder auf eine andere Art und
> Weise sortiert haben, so muss er unseren Footprint-Ordner nach media/
> kopieren und dort nach seinen Wünschen organisieren.

Jupp. Ich werde zwar erst einmal nur einzelne Dateien verwalten können, 
aber wenn das klappt, dann ist es auch kein Problem, mehrere Dateien zu 
bearbeiten. Es bleibt nur zu überlegen, ob auch Verzeichnisse bearbeitet 
werden dürfen oder ob die Struktur einmal festgelegt wird.

Wenn der Filemanager in der jetzigen Form fertig ist, werde ich ihn ins 
Part-DB-Repo rüberziehen, damit wir den zusammen weiter entwickeln 
können. Die Software steht unter CC-BY-SA 3.0-Lizenz.

Udo Neist schrieb:
> Ich kann ja den Filemanager soweit ergänzen, dass er neben den
> Verzeichnisnamen auch Rechte verwaltet. Wäre also sowas wie:
> [...]

Das wäre super! Dann kann er auch ganz einfach angepasst werden wenn mal 
noch neue Verzeichnisse hinzukommen.

Udo Neist schrieb:
> Jupp. Ich werde zwar erst einmal nur einzelne Dateien verwalten können,
> aber wenn das klappt, dann ist es auch kein Problem, mehrere Dateien zu
> bearbeiten. Es bleibt nur zu überlegen, ob auch Verzeichnisse bearbeitet
> werden dürfen oder ob die Struktur einmal festgelegt wird.

Was meinst du mit "Verzeichnisse bearbeiten"? Umbenennen, Kopieren, neue 
Verzeichnisse erstellen? Das sollte natürlich in "media/" schon möglich 
sein, sonst muss der Benutzer ja all seine Dateien in einen Topf werfen. 
Oder eben das ganze Verzeichnis "img/footprints" (rekursiv) nach 
"media/footprints" kopieren sollte auch möglich sein.

Erstmal ist aber wichtig dass man Dateien hochladen und hochgeladene 
Dateien auswählen kann, die man dann den Bauteilen zuordnen kann...

Ich bin grad die Updateschritte auf die DB-Version 13 nochmal am 
anpassen. Es werden noch diverse Änderungen vorgenommen: Umstellung auf 
InnoDB, zusätzliche TIMESTAMP-Spalten, und - sehr wichtig - es werden 
Foreign Keys hinzugefügt.

Es gibt aber immernoch einen Updateschritt, der nicht funktioniert. Ich 
wäre froh wenn mir hier jemand helfen könnte, da meine SQL-Fähigkeiten 
begrenzt sind ;-)

Es geht um folgendes:
Bisher (bis DBv12) war es erlaubt, einem Bauteil eine Bestellnummer 
und/oder ein Preis zuzuordnen, ohne einen Lieferanten anzugeben. All 
diese Daten befanden sich in der Tabelle "parts". Jetzt ist dies aber 
nicht mehr erlaubt.
Für Bauteile, die keinen Lieferanten, jedoch eine Bestellnummer und/oder 
ein Preis besitzen, wird einfach ein Lieferant "Unbekannt" erzeugt:

1

INSERT IGNORE INTO `suppliers` (name, parent_id) VALUES ('Unbekannt', NULL)

Dann soll die ID von diesem (evtl. neuen) Lieferanten allen Bauteilen 
zugeordnet werden, die noch keinen Lieferanten (parts.id_supplier == 0), 
jedoch eine Bestellnummer (parts.supplierpartnr != '') und/oder einen 
Preis (preise.price > 0) haben. Mein Versuch sieht so aus:

1

UPDATE `parts` SET parts.id_supplier = (SELECT `id` FROM `suppliers` WHERE name='Unbekannt') WHERE (parts.id_supplier = 0) AND ((preise.price > 0) OR (parts.supplierpartnr != ''))

Ich glaube, man sieht was der Befehl machen sollte. Allerdings muss da 
wohl noch ein JOIN rein, damit genau der Preis geholt wird, der zum 
jeweiligen Bauteil gehört. Die Tabelle "preise" wird über die Spalte 
"part_id" mit einem Bauteil verknüpft. Dabei kann es aber auch Bauteile 
geben, die keinen Eintrag in der Tabelle "preise" haben! Mehr als ein 
Eintrag kann (sollte...) aber nicht existieren.
Ausserdem, wenn es jetzt mehrere Lieferanten mit Namen "Unbekannt" gäbe, 
sollte es trotzdem funktionieren (einfach einer dieser Lieferanten 
nehmen, egal welcher). Ich bin mir nicht sicher wie sich da mein Befehl 
verhalten würde...

Ist sicher nur eine Kleinigkeit für jemanden der was davon versteht :-)
Wäre super wenn mir da jemand helfen könnte, dann würde wenigstens mal 
das Datenbankupdate funktionieren.

Falls mehr Infos gebraucht werden, einfach melden.

mfg

na, nur nicht alle auf einmal! :-D

Ich hätte auch gleich schon das zweite "Problem":
Bevor die Foreign Keys hinzugefügt werden, sollen alle Datenbankeinträge 
mit einer "toten" parent_id auf die oberste Ebene gesetzt werden, also 
parent_id = NULL setzen. Ansonsten ist die Gefahr eines Fehlschlages 
beim Update zu hoch, weil es sein könnte dass es in der Spalte 
'parent_id' IDs gibt, die nicht (mehr) existieren (sollte zwar 
theoretisch nicht vorkommen - habe aber auch schon merkwürdige Dinge in 
meiner Datenbank gesehen)

Pseudo-Code für die Tabelle "categories":

1

UPDATE `categories` SET parent_id=NULL WHERE (parent_id existiert nicht in categories.id)

Für die anderen Tabellen kann ich das Ding natürlich auch selber 
anpassen.

mfg

Kann mir denn wirklich keiner helfen? ;-)

Ich habe noch diverse andere Sachen gemacht, die ich gerne wiedermal ins 
SVN laden würde, aber ohne das Datenbankupdate funktionieren die 
nicht...

Wenn sich keiner meldet, frage ich dann halt mal in einem MySQL Forum 
nach... Die Updateschritte sollten halt wirklich wasserdicht sein, und 
das krieg ich mit meinen MySQL-Fähigkeiten nicht hin :-(

Die Tabelle mit PHP auf machen und mit einer Schleife durchlaufen?
Es muss ja nicht unbedingt ein SQL Script sein, komplexere Teile können 
auch per PHP bearbeitet werden.

Markus Müller schrieb:
> Die Tabelle mit PHP auf machen und mit einer Schleife durchlaufen?
> Es muss ja nicht unbedingt ein SQL Script sein, komplexere Teile können
> auch per PHP bearbeitet werden.

Nein es sollte wenn möglich schon direkt per MySQL Queries erledigt 
werden, da das bisherige Updatesystem so aufgebaut ist dass nur MySQL 
Befehle abgearbeitet werden können. Ausserdem sollten die genannten 
Operationen ja problemlos mit MySQL lösbar sein, es liegt nur an meinem 
begrenzen Fähigkeiten dass ich es nicht hinkriege ;-)

Ich weiß das jetzt auch nicht auswendig und müsste in der Doku 
nachlesen. Ich habe das zumindest in meinen Updates so gelöst um die 
Unterschiede der SQL Syntax korrekt behandeln zu können.
Damit habe ich sogar die Möglichkeit gleiche Updates mehrfach aus zu 
führen, da erst geprüft wird ob z.B. das Feld nicht doch schon existiert 
und dann erst angelegt wird. Bei einem reinen SQL Script ist das viel 
schwieriger.

Markus Müller schrieb:
> Damit habe ich sogar die Möglichkeit gleiche Updates mehrfach aus zu
> führen, da erst geprüft wird ob z.B. das Feld nicht doch schon existiert
> und dann erst angelegt wird. Bei einem reinen SQL Script ist das viel
> schwieriger.

Jup, das war bisher tatsächlich ein Problem. Ich habe jetzt aber einen 
Zähler eingebaut, der sich merkt bei welchem Updateschritt ein Abbruch 
stattfand. So kann beim nächsten Versuch wieder an der gleichen Position 
weitergemacht werden. Beim Update von v12 auf v13 ist das auch dringend 
notwendig, da wird so viel an der DB verändert... ;-)

Das ganze Updatesystem soll später aber sowieso nochmal überarbeitet 
werden, da wir auch Systemupdates unterstützen möchten. Bisher wird nur 
die Datenbank an die neue Systemversion angepasst nachdem der Benutzer 
das System selbst aktualisiert hat.

OK also ich habs nochmal selbst probiert, und ich glaube sogar ich habs 
hingekriegt :-) Bei den Tests die ich durchgeführt habe, stimmte das 
Ergebnis jedenfalls...

Ich habe jetzt mal alle Änderungen ins SVN hochgeladen (r594).

Achtung! Es wird jetzt wieder eine Datenbank der Version 12 
vorausgesetzt, da ich den Schritt von v12 auf v13 verändert habe! Eine 
DB v12 liegt ja nach wie vor im "development" Ordner.

Die Online Demo wird nun in nächster Zeit vermutlich auch nicht mehr 
richtig funktionieren, da muss auch erstmal wieder eine frische DB 
geladen werden...

So, vielleicht kriege ich nun sogar auch noch die anderen 
Datenbankprobleme hin, die in der Doxygen Doku noch aufgelistet sind ;-)

mfg

P.S.
Falls es bei euch Probleme geben sollte beim DB-Update, bitte melden, 
vielleicht ist ja doch noch ein Wurm drin ;-)

K. J. schrieb:
> Leuft ;-)

Super, danke! :-)

K. J. schrieb:
> Jap aus irgendeinen Grund, wird der Datenbank Zeichensatz bei mir auf
> schwedisch gestellt für die umbenannten Tabellen.

Hmm dann musst du dir wohl noch eine schwedische Tastatur besorgen ;-)

Ne im Ernst, ich bin mir noch unsicher was die Befehle "CHARSET=..." und 
"COLLATE=..." genau bringen. Vorher haben wir ja eine Tabelle so 
erzeugt:

1

DROP TABLE IF EXISTS `categories`;

2

CREATE TABLE IF NOT EXISTS `categories` (

3

  `id` int(11) NOT NULL AUTO_INCREMENT,

4

  `name` mediumtext COLLATE utf8_unicode_ci NOT NULL,

5

  `parentnode` int(11) NOT NULL DEFAULT '0',

6

  PRIMARY KEY (`id`),

7

  KEY `parentnode` (`parentnode`)

8

) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=1 ;

Hier wird ja der Zeichensatz auf utf8_unicode_ci gesetzt. Aber was, wenn 
jemand einen anderen Zeichensatz haben möchte (auf Windows?) ? Oder wird 
das niemand wollen? ;-) Über die Konfiguration lässt sich ja jetzt der 
Zeichensatz des PDO setzen. Dieser Zeichensatz sollte dann eigentlich ja 
auch beim Anlegen neuer Tabellen verwendet werden nehme ich mal an. So 
ist halt der Zeichensatz nicht mehr hardgecoded, sondern der Benutzer 
kann ihn selber wählen. Aber ob das wirklich Sinn macht... Sollte man 
besser den Zeichensatz wieder auf utf8 hardcoden und die 
Konfigurationsmöglichkeit rauswerfen?

Und dann gibts da noch das "COLLATE=...". Hier bin ich mir auch nicht 
sicher. Wird da nicht standardmässig utf8 verwendet, wenn die Tabelle 
sowieso den utf8-Zeichensatz verwendet? Oder muss das wirklich noch 
separat angegeben werden?

Die blöden Zeichensätze bereiten mir echt Kopfschmerzen... :-(

K. J. schrieb:
> Was noch nett ist das neuerdings erst nach dem kompletten Update die DB
> Rev. geändert wird so kann man das auch selber grade biegen und dann das
> script nochmal durchlaufen lassen.

Jup, wenn ein Update fehlschlägt wird die aktuelle Position in der 
config.php abgelegt, damit beim nächsten Versuch wieder an der gleichen 
Position weitergemacht werden kann. Vorher war es echt mühsam wenn mal 
ein Update fehlgeschlagen hat... ;-)

Foreign Key's benötigen InnoDB.
Wegen der schwedische Zeichen werden vermutlich mit PHP falsch 
decodiert, die DB Definition ist korrekt.

Markus Müller schrieb:
> Foreign Key's benötigen InnoDB.

Ja, deshalb werden zu Beginn des Updates alle Tabellen auf InnoDB 
umgestellt:

1

ALTER TABLE `categories` ENGINE=InnoDB

Aber das hat mit dem Zeichensatz eigentlich ja nichts zu tun, oder?

Übrigens ist mir grad noch ein schlimmer Fehler im DB Update 
aufgefallen, es waren plötzlich alle Einkaufsinformationen doppelt 
vorhanden :-) Ist jetzt aber gefixt (r596).

Kann man eigentlich in Google Code nicht einzelne Verzeichnisse aus dem 
Changelog rausnehmen? Die Änderungen an der Doxygen Doku nerven extrem 
in der Änderungsliste, die wirklich wichtigen Änderungen gehen so total 
unter...

Übrigens, ich habe jetzt mal ein Dokuwiki in Part-DB mit eingebaut. Wer 
möchte, kann gerne daran arbeiten :-)

Und dann habe ich noch diverse Sachen gefixt: Man kann nun endlich nach 
Lieferanten und Bestellnummern suchen, die Statistik wird jetzt viel 
schneller geladen (Preisberechnung per MySQL statt PHP) und die 
Footprint-Bilder Auflistung habe ich umgebaut. Beim Aufrufen von Tools 
-> Footprints werden nun nicht mehr die über tausend Bilder geladen 
(sehr mühsam bei langsamen PCs). Wer es trotzdem wieder haben möchte, 
kann es in der Konfiguration ändern.

mfg

K. J. schrieb:
> Jap aus irgendeinen Grund, wird der Datenbank Zeichensatz bei mir auf
> schwedisch gestellt für die umbenannten Tabellen.

Ich habe mal die CHARSET=... und COLLATE=... wieder hinzugefügt (r598), 
könntest du nochmal eine DB v12 laden und schauen obs nun klappt?

Ausserdem gibts jetzt ein paar neue Sachen in Part-DB 0.3.0:

1

- Export für gesuchte Teile, Baugruppen und zu bestellende Teile

2

- Eigene Exportformate können ziemlich einfach in der config.php definiert werden

3

- Baugruppen können zum Bestellen vorgemerkt werden (damit tauchen Sie in der Liste der zu bestellenden Teile auf - war ziemlich tricky, vielleicht gibts da noch Bugs...)

4

- Obsolete Einkaufsinformationen werden in den Tabellen nicht mehr angezeigt

So langsam aber sicher wird die ganze Sache ziemlich kompliziert ;-) Die 
Einkaufsinformationen und Preisinformationen machen es einem nicht 
leicht, aber ich denke der Aufwand lohnt sich. Wenn man das selbe 
Bauteil mal bei diesem, mal bei einem anderen Lieferanten bestellt, muss 
das halt auch irgendwie gescheit verwalten können...

Gute Nacht! :-)

An dieser Stelle einfach mal ein Lob an Urban für seine Arbeit :-)

Ich hänge derzeit an den AJAX-Routinen für den IE (hab nur den 8er) 
fest. JScript ist halt nicht Javascript und das nervt tierisch :(

Udo Neist schrieb:
> JScript ist halt nicht Javascript und das nervt tierisch :(

Tja, das ist das Echo des Browserkrieges.

K. J. schrieb:
> Supi geht.

OK dann lassen wir das mal so :-)
Ich habe mich jetzt übrigens mal noch ein bisschen mit dem Thema 
Zeichensätze beschäftigt, da ich damit immernoch Mühe hatte. Einerseits 
haben wir ja den HTTP Zeichensatz (im HTML Header), und andererseits den 
Zeichensatz der Datenbank.

Die Kommunikation mit der Datenbank können wir wohl auf UTF-8 hardcoden 
denke ich (mit "SET NAMES utf8"). Jeder (einigermassen aktuelle) MySQL 
Server sollte UTF-8 unterstützen, so können Probleme und 
Missverständnisse vermieden werden. Übrigens habe ich heute 
herausgefunden dass der Befehl "SET NAMES utf8" bisher gar nicht 
funktioniert hat, in der nächsten Revision die ich hochlade, 
funktioniert es dann aber.

Eventuell könnte es aber bei einigen Benutzern zur falschen Darstellung 
von Umlauten führen. In früheren Versionen von Part-DB wurden die Daten 
wohl in "latin1" in der Datenbank abgelegt. Die Backups davon werden bei 
mir nun aber als UTF-8 interpretiert und somit die Umlaute falsch 
dargestellt. Ich bin mir aber nicht sicher ob das nur bei alten Backups 
passiert, oder obs auch im normalen Betrieb dann plötzlich passiert 
(beim Update auf eine neue Version von Part-DB)...Im schlimmsten Fall 
müssten die Benutzer dann ihre latin1-Datenbank nach UTF-8 konvertieren. 
Ist zwar irgendwie blöde, aber wenn man jetzt einfach was "bastelt" wird 
uns das Problem auf immer und ewig verfolgen ;-)

Und dann zum HTTP-Zeichensatz. Der gibt eigentlich dem Browser ja nur 
bekannt, wie die Daten codiert sind. Da gibt es einmal die (ich nenne 
sie mal) "dynamischen" Daten, die z.B. von der Datenbank kommen, die 
erhalten wir immer in UTF-8 und werden auch so ausgegeben. Und dann 
gibts noch die "statischen" Daten, die hardgecoded (in *.php oder 
*.tmpl) sind. Die sind ja auch alle in UTF-8 codiert. Teilweise gibts 
Umlaute noch in HTML-Schreibweise, die könnten wir aber auch noch durch 
Umlaute (im Klartext) ersetzen. Es ist also immer alles UTF-8, somit 
könnten wir doch den HTTP-Zeichensatz auch auf UTF-8 hardcoden, oder? 
Wenn jetzt ein Windows Server eingesetzt wird, sind ja die Dateien von 
Part-DB immernoch UTF-8 und es müsste weiterhin funktionieren schätze 
ich. Oder liefert ein Apache Server auf Windows etwa latin1 Ausgaben, 
auch wenn die PHP/TMPL Dateien UTF-8 codiert sind? Das bin ich mir nicht 
so ganz sicher...

Zusammengefasst würde ich also sagen: Wir könnten alles auf UTF-8 
hardcoden und es sollte tzotzdem auf allen Server-Systemen richtig 
funktionieren. Einzig bei der Bearbeitung der PHP/TMPL Dateien unter 
Windows muss man darauf aufpassen, dass die Dateien auch wieder UTF-8 
codiert gespeichert werden. Aber das sollte ja jeder ernstzunehmende 
Code-Editor beherrschen.

K. J. schrieb:
> Aso hab mich mal ans Wiki gemacht,

Super! :-)
Uhu hat sich ja diesbezüglich auch mal gemeldet, vielleicht müsstest du 
mit ihm mal besprechen ob/was/wie/wann er auch noch an der Doku 
arbeitet.

> ich weis nur nicht ob ein einfaches
> Coppy der Seiten reicht damit sie übernommen werden.

mmh ich verstehe die Frage nicht ganz. Also grundsätzlich solltest du im 
DokuWiki einfach Änderungen machen und dann die Dateien ins SVN 
hochladen können. Man sieht ja in der Online-Demo dass das bereits 
geklappt hat.

Übrigens habe ich nur mal ein paar grobe Einstellungen gemacht im 
DokuWiki. Vielleicht gäbe es noch ein paar andere Sachen die man ändern 
könnte. z.B. macht es nicht viel Sinn dass der Benutzer schlussendlich 
auch die Möglichkeit hat, Änderungen an der Doku durchzuführen (sieht 
irgendwie komisch aus wenn man die Doku einer Software selbst verändern 
kann). Da könnte man sicher noch ein bisschen was anpassen...

Udo Neist schrieb:
> An dieser Stelle einfach mal ein Lob an Urban für seine Arbeit :-)

Vielen Dank :-)

K. J. schrieb:
> Ja, werd mich drum kümmern werde auch mal schauen ob wir das ganze nicht
> mal etwas abspecken können alleine die Sprachfiles sind son eine ganze
> menge die wir nicht brauchen, denke DE und EN werden reichen,

Jup, gute Idee.

K. J. schrieb:
> das gleiche für die doxigen doku die ist sowas von aufgebläht.

Ja es sind halt sehr viele Dateien, aber viel weglassen kann man da 
nicht denke ich. Ausserdem kriegt der Endanwender die Doxygen-Doku 
nicht, die ist nur für Entwickler. Der ganze Ordner "development" kommt 
schlussendlich nicht in die Download-Archive, deshalb habe ich die 
Doxygen Doku auch von "documentation" nach "development" verschoben.

Was ich aber schön finden würde, wäre wenn man die Änderungen im Ordner 
"doxygen" im Changelog in Google Code irgendwie ausblenden könnte. Aber 
ich vermute mal das ist nicht möglich (?)...

@ Marco tom Suden (falls du noch mitliest)
Wenn du auf deinem Windows Server den HTTP Zeichensatz auf "UTF-8" 
einstellst, werden dann die Umlaute richtig dargestellt (nicht bei den 
Daten schauen die aus der Datenbank kommen, sondern bei statischen 
Inhalten, z.B. die Tabellenüberschrift "Datenblätter")?

Urban B. schrieb:
> z.B. macht es nicht viel Sinn dass der Benutzer schlussendlich
> auch die Möglichkeit hat, Änderungen an der Doku durchzuführen (sieht
> irgendwie komisch aus wenn man die Doku einer Software selbst verändern
> kann).

Das sehe ich nicht ganz so. Wenn die Doku schlecht ist - MS ist in 
dieser Disziplin ganz große Klasse! - ist es mehr als wünschenswert, daß 
man als Nutzer z.B. leeres Stroh eliminieren, verkorkste Übersetzungen, 
oder Formulierungen reparieren kann...

Dokuwiki ist genau dafür ganz prima geeignet: man kann neue Versionen 
einspeisen und private Änderungen notfalls mit Hilfe der diff-Funktion 
finden und übernehmen, falls sinnvoll.

Aber es ist durchaus sinnvoll, die Änderbarkeit an einen speziellen 
Wiki-Login zu koppeln, daß nicht aus Versehen Änderungen gemacht werden. 
Der Username muß natürlich bekannt gemacht werden.

Uhu Uhuhu schrieb:
> Aber es ist durchaus sinnvoll, die Änderbarkeit an einen speziellen
> Wiki-Login zu koppeln, daß nicht aus Versehen Änderungen gemacht werden.
> Der Username muß natürlich bekannt gemacht werden.

Ja, so ähnlich hätte ich mir das auch vorgestellt. Also dass 
standardmässig die Editier-Buttons nicht sichtbar sind (die meisten 
Anwender werden die nicht brauchen), aber mit der Möglichkeit, dass man 
eben doch was verändern kann wenn man möchte (z.B. wir Entwickler 
brauchen das ja). Sei es ein Login, oder evtl. auch in der Konfiguration 
von Part-DB eine Option wie "Änderungen in der Dokumentation zulassen".

Wie gesagt, ich habe mich nicht grossartig mit DokuWiki beschäftigt. Ich 
habs einfach mal in Part-DB eingefügt und ein paar grundlegende 
Einstellungen getätigt, so dass wir mal eine Grundlage für die Doku 
haben. Ihr dürft daran gerne noch Einstellungen verändern usw.

Uhu Uhuhu schrieb:
> Udo Neist schrieb:
>> JScript ist halt nicht Javascript und das nervt tierisch :(
>
> Tja, das ist das Echo des Browserkrieges.

Problem ist gelöst. Ajax funktioniert jetzt auch mit dem IE8. Jetzt muss 
ich erstmal einen Schönheitsfehler im Bezug auf die Testseite beheben, 
dann kommen die Kommandos hinzu. Ich habe mir überlegt, dass ich die 
Verzeichnisse per Konfiguration von Änderungen ausnehmen kann (jetziges 
Verhalten). Alternativ würde man per Einfachklick das Verzeichnis zum 
Bearbeiten markieren und ein weiterer Klick würde das Verzeichnis 
öffnen. Neue Ordner können nur dann erstellt werden, wenn eine weitere 
Konfigurationsoption dies freischaltet. Schließlich soll nicht jeder an 
der bestehenden Struktur was ändern können, eventuell neu erstellte 
Verzeichnisse würde vom System u.U. auch gar nicht berücksichtigt 
werden.

Habt Ihr eigentlich ein Release-Datum (final) auf dem Schirm, oder 
entwickelt Ihr so vor Euch hin ?

Ne, derzeit haben wir kein Release-Fahrplan. Nach meinem Wissen gibt es 
derzeit drei Baustellen:

1) Umstellung des Codes auf Modul-/Klassenbasis
2) Neuer Filemanager
3) Dokumentation im Form eines Wikis

Ich vermute mal, dass wir irgendwo bei 90% sind. Am eigentlichen Code 
arbeitet derzeit nur Urban und ich bin am Filemanager dran. Nach der 
Veröffentlichung der Version 0.3 soll die Kommunikation zwischen 
Anwendung und Server auf Ajax umgestellt werden und somit die veraltete 
Frame-Variante komplett ersetzen.

Für den produktiven Betrieb ist die 0.2.x vorgesehen.

Grüße
Udo

So, die Importfunktionen sollten nun (r606) auch funktionieren. Falls 
noch jemand Bugs findet, bitte melden :-)
Ihr glaubt gar nicht, wie froh ich bin dass wir nun Transaktionen 
verwenden können :-D Eine Funktion, die die Werte aus dem Import-Text 
auf Gültigkeit überprüft, wurde so zum Kinderspiel. Einfach alles normal 
importieren, aber am Schluss ein Rollback statt einem Commit ausführen 
:-)

Ausserdem habe ich den Code-Styleguide vom Google-Code Wiki in die 
Doxygen-Doku verschoben. So gibts schlussendlich nur zwei 
Nachschlagewerke: Die Doxygen Doku für Entwickler, und das DokuWiki für 
Anwender (und beide Nachschlagewerke sind natürlich auch online auf der 
Demo-Seite verfügbar).

So braucht es das Google Code Wiki gar nicht mehr.

Den Code-Styleguide sollte demnächst dann unter 
http://partdb.grautier.com/uneistkami89/development/doxygen/html/styleguide.html 
erreichbar sein.

Gespeichert ist die Seite übrigens unter 
"development/doxygen/related_pages/". Man kann sehr schön eigene Seiten 
in die Doxygen Doku aufnehmen, die sich dann auch ins Menü integrieren. 
Wie man das genau macht, kann man in den in diesem Ordner vorhandenen 
Dateien nachschauen.

Ich wäre nun übrigens langsam für den Dateimanager bereit, wie sieht die 
Lage bei dir aus, Udo? :-)

mfg

Urban B. schrieb:
> Ich wäre nun übrigens langsam für den Dateimanager bereit, wie sieht die
> Lage bei dir aus, Udo? :-)

Ich wollte heute einige der Kommandos fertig machen, damit der 
Filemanager zumindest mit den Basisfunktionen auch nutzbar ist. Vorerst 
halt nur für Dateien, das mit den Verzeichnissen kommt später noch dazu. 
Den Upload-Teil werde ich die Tage dann integrieren.

Aktueller Stand Filemanager:

- Befehle funktionieren, sind aber auf Dateien beschränkt
- Alle Meldungen über einen modalen Dialog (Formulare, Meldungen)
- Fehlermeldungen des Webservers werden als Statusmeldung direkt im 
entsprechenden Block angezeigt (kein Dialog)
- (Access-)Token als Absicherung für die Kommandos, da man auf den 
HTTP-Referrer nicht bauen kann
- Vorschau von Grafiken
- Mimetyp-Grafiken für alle anderen Files (optional)
- Anpassen des Designs über CSS. Nur wenige Elemente sind in den 
Templates fest über Style-Regeln definiert.

Basis sind XMLHttpRequests und JSON auf Seite von Javascript. Die 
Javascript-Klassen haben einen eigenen Namespace.

ToDo:

- Verzeichnisfunktionen einführen
- Fehlermeldungen des Webservers als modaler Dialog

Die aktuelle Version werde ich die Tage von den Eigenheiten meiner 
Webseite befreien und erstmal in den Development-Ordner kopieren. Eine 
Minidoku füge ich hinzu.

Grüße
Udo

Edit:
Es fehlt noch der Upload-Teil. Hab mich erstmal auf meinen eigenen Code 
konzentriert ;-)

Revision 609: Der Filemanager ist im Verzeichnis 
"development/filemanager" zu finden.

Super, dann geht die Version 0.3.0 nun ja endlich langsam in die 
Endphase über :-)

Also ich bin auch noch nicht ganz fertig, aber es sind jetzt 
hauptsächlich nur noch Kleinigkeiten die noch fehlen. Und beim Testen 
werden dann sicher auch noch einige Bugs auftauchen...

Ich wollte dich aber schon lange mal noch was ganz anderes fragen. Du 
hast  ja mal das Skript "svn.sh" erstellt, das ich mittlerweile übrigens 
in "tools.sh" umbenannt habe (habe noch eine neue Funktion hinzugefügt, 
die nichts mit SVN zu tun hat). Ein Teil dieser Funktionen sind übrigens 
nun auch sehr bequem über Part-DB unter "Entwickler-Werkzeuge" 
erreichbar. Ich bin einfach zu faul um jedesmal ein Terminal aufzumachen 
;-)
Meine Frage bezieht sich aber auf das Commiten. Du hast ja dort den 
Parameter "--force" mit eingebaut. Ich frage mich aber ein bisschen, ob 
das geschickt ist. Einerseits werden doch so eventuelle Änderungen im 
Repository, die seit dem letzten Update gemacht wurden, einfach 
überschrieben, oder? Und andererseits habe ich gelesen dass dann die 
Ignore-Dateien auch nicht mehr ignoriert werden (verwende ich für den 
Debug-Log und config.php). Zweiteres ist nicht schlimm, aber ersteres 
könnte zu Problemen führen wenn man nicht aufpasst.

Ich selber benutze einen grafischen SVN Client der sich in Nautilus 
integriert. Bei jedem Commiten überfliege ich alle geänderten Dateien 
nochmal um zu prüfen, ob auch wirklich genau das hochgeladen wird, was 
hochgeladen werden soll. Und falls meine lokale Kopie nicht mehr aktuell 
ist, bekomme ich eine Fehlermeldung weil ich kein "--force" verwende. So 
werde ich gezwungen, erst mal ein Update durchzuführen und es wird 
sichergestellt dass ich keine Dateien aus Versehen überschreibe.

Ich habe das leider auch schon bei anderen Projekten erlebt (git) dass 
Leute einfach mal drauflos committen und Änderungen von Anderen wieder 
(aus Versehen) rückgängig machen. Das ist extrem mühsam...

Meine Frage wäre also: Sollten wir da nicht besser das "--force" 
entfernen, um unbeabsichtigte Änderungen zu vermeiden?

mfg

Das "--force" bezieht sich ja nur auf "svn add" und durchsucht rekursiv 
alle Verzeichnisse. Mit "--no-ignore" würdest du gesperrte Dateien 
hinzfügen, so lese ich zumindest die Doku. Zudem fehlt da eh noch der 
Befehl "svn resolve --accept working *" (oder ne Variante), um Konflikte 
zu lösen. Das Script ist noch lange nicht perfekt und sollte ja auch 
erstmal nur die Arbeit in meinem Branch erleichtern. Es ist halt nicht 
für Mehrbenutzer-Repos ausgelegt und darf jederzeit angepasst werden :-)

Udo Neist schrieb:
> Das "--force" bezieht sich ja nur auf "svn add"

Ups, da habe ich wohl nicht richtig hingeschaut^^ Sorry, ich dachte das 
war beim "commit" ;-) Beim "add" sollte das dann ja tatsächlich nicht so 
wild sein...

Udo Neist schrieb:
> Mit "--no-ignore" würdest du gesperrte Dateien
> hinzfügen, so lese ich zumindest die Doku.

Jo nach Doku würde ich das auch sagen, wenn ich aber diverse Meldungen 
in Foren richtig verstanden habe, tut es das eben nicht. Ich habs 
allerdings nie selber ausprobiert, das Committen mit der Konsole ist mir 
etwas ungeheuer. Ich setze da lieber auf hübsche Klicki Bunti GUIs, dann 
kommt auch das richtige bei raus :-D

Aber dann hat sich das ja auch mehr oder weniger erledigt. Ich wollte 
nur sichergehen dass man (die, die es verwenden) mit dem Skript keine 
unbeabsichtigten Sachen im Repo überschreibt.

Das nächste Mal schaue ich mir den Code etwas genauer an bevor ich hier 
nachfrage, versprochen! :-D

Lieber ne doofe Frage stellen, als dumm sterben ;-)

Udo Neist schrieb:
> Lieber ne doofe Frage stellen, als dumm sterben ;-)

Hehe, wie wahr :-)

...wie still es doch sein kann in diesem Thread :-)

Ich habe vor ein paar Wochen noch ein neues (grosses...) Projekt 
angefangen, daher ist Part-DB in letzter Zeit leider etwas auf der 
Strecke geblieben. Dieses Wochenende versuche ich aber wieder daran zu 
arbeiten :-)

@Udo, siehts bei dir (bzw. beim Dateimanager) ähnlich aus oder bist du 
in der Zwischenzeit weiter gekommen?

mfg
Urban

Leider nein :( Wird wohl noch bis Ende April oder Mitte Mai dauern, bis 
ich wieder mehr Zeit habe. Im Moment raubt mir die Vertretung eines 
Kollegen etwas die Zeit. Wie es im Juni aussieht, weiß ich auch noch 
nicht. Da steht bei uns eine Reakkreditierung an. Ich versuch zumindest 
mal den Uploader zu integrieren, damit wenigstens diese Baustelle im 
Dateimanager geschlossen werden kann.

So, habe einen einfachen Uploader integriert. Es wird kein Flash oder 
ähnliches verwendet. Nur der Browser sollte möglichst aktuell sein. Es 
fehlt nur noch die Option, nach dem Upload direkt ins Zielverzeichnis zu 
wechseln.

Ok super, also wenn der Uploader schon funktionsfähig ist, kannst du ihn 
ja mal ins SVN hochladen.

Wenn der Uploader einen Haufen Dateien braucht, wäre es vielleicht 
sinnvoll wenn wir ihm ein eigenes Verzeichnis spendieren, also im 
Hauptverzeichnis einen Unterordner "filemanager/" o.ä. (anstatt 
JS-Dateien in "javascript/", CSS in "templates/" usw.)

Das Wechseln nach 5s in das Zielverzeichnis funktioniert jetzt auch. Ob 
das auch bei fehlgeschlagenen Uploads funktioniert, kann ich noch nicht 
beurteilen, da es nur sporadisch auftritt.

Die Installation in ein eigenes Verzeichnis wäre mir auch lieber, da der 
Filemanager ja absichtlich als Add-On/Modul für ein CMS oder ähnliches 
gedacht ist. Javascript und CSS müssen eingebunden, die 
Grafikverzeichnisse verlinkt werden. Ansonsten sollte es ziemlich 
pflegeleicht sein. Ich werde vielleicht morgen mal die aktuelle Version 
ins Repo einbinden. In die jetzige Version der Part-DB kann man 
allerdings nur das Aufrufen per Popup-Window nutzen. Eigentlich ist es 
für die Nutzung innerhalb eines DIV-Elements auf der Hauptseite 
vorgesehen. Es wird ein Fenster mit mindestens 600px Breite gebraucht.

Nächstes Feature: Interner Viewer ähnlich eines Dialogs

Unterstützt werden PDF und Images. PDF wird vom jeweiligen Plugin 
angezeigt, die Images werden bei Übergröße über CSS skaliert. Letzteres 
ist kein ideales Verhalten, aber sollte bei jedem Browser funktionieren. 
Kleinere Bilder füllen den Viewer nicht aus. Dieser wird nicht 
angepasst. Wäre noch was für die ToDo-Liste. Vielleicht unterstütze ich 
später auch noch Videos oder anderes per object-Tag.

Ich habe den Filemanager mit Kommentaren versehen und ein paar kleinere 
Anpassungen für Part-DB gemacht. Wie man den Filemanager in einen 
Webseite einbaut, kann man in der Datei vlib_filemanager.html sehen. 
dom.css und filemanager.css dabei nicht vergessen!

Aktuelle Version ist in der Revision 613 enthalten.

ToDo:
- Viewer soll auch Text-Dateien anzeigen können, dabei soll 
Syntax-Highlightning unterstützt werden.
- Hauptverzeichnis für Dateioperationen wird in filemanager.php bzw. 
conf.php definiert, aber kann dort noch nicht gesperrt werden. Geht 
derzeit nur über eine interne Variable in filemanager.js.
- README ändern, da es nicht mehr aktuell ist.
- Doxygenkompatible Kommentare, kann auch jemand vom Part-DB-Projekt 
übernehmen ;-)

Ich habe mir das mal angeschaut aber ich blicke noch nicht so richtig 
durch :-(

Wie würde man den Filemanager später z.B. in "edit_part_info.php" (bzw. 
dem *.tmpl davon) einbinden?

Die Bedienung stelle ich mir etwa so vor (Bsp. "edit_part_info.php"):
- Der Benutzer klickt unter Dateianhänge/Dateiname auf den Button "..."
- Der Filemanager öffnet sich in einem neuen Fenster (Popup)
- Falls nötig, kann der Benutzer die Datei erst noch hochladen
- Der Benutzer wählt die entsprechende Datei aus und klickt auf "OK"
- Der Filemanager schliesst sich und der Pfad zur gewählten Datei wird 
automatisch in das Textfeld "Dateiname / URL" in "edit_part_info.php" 
geschrieben.

Wie man das so hinkriegt weiss ich aber leider nicht... ;-)

mfg

Dachte ich mir schon, dass dazu noch Fragen sind :-) Ich werde noch eine 
Testseite machen, auf dem der Aufruf für den Upload-Teil gezeigt wird. 
Erst wenn die dann so läuft wie angedacht, würde ich den Filemanager in 
Part-DB einbauen.

Im Grunde besteht der Uploadmanager nur aus einem Dialogfenster und 
einem zweiten Element für die Anzeige des Uploads selbst. Innerhalb der 
gleichen Seite wäre es ein

1

onclick="filemanager.command('upload');"

auf einem entsprechenden Button. Für den Aufruf in einem Popup muss man 
mehr machen. Erstmal ein onclick-Event, das ein neues Fenster erzeugt. 
In dem Fenster wird dann der komplette Filemanager aufgebaut, aber die 
normalen Funktionen wären abgeschaltet, d.h. das Element links oben mit 
den Verzeichnissen wäre abgeschaltet.

Okay dann warte ich diesbezüglich noch ab :-)

Momentan habe ich noch ein anderes Problem. Unter "Zu bestellende Teile" 
werden nun ja jeweils zu jedem Bauteil alle verfügbaren 
Einkaufsinformationen angezeigt, jeweils mit einem Radiobutton um 
auszuwählen, welchen Artikel man nun genau bestellen möchte. Anhand 
dieser Auswahl wird dann übrigens der Gesamtpreis der Bestellung 
berechnet, und auch für den Bestelllisten-Export ist diese wichtig.

Das Problem ist nun aber, dass die Radiobuttons etwas höher sind als der 
Text alleine, und das führt bei mehreren Einkaufsinformationen zu einer 
Verschiebung in der Höhe (zwischen den verschiedenen Spalten). Siehe 
angehängtes Bild.

Ich habe keine gescheite Idee, wie man die Zeilen jeweils aufeinander 
ausrichten könnte. Die einzige Idee war, dass man für jede 
Einkaufsinformation eine eigene Zeile macht, und die dann mit "rowspan" 
zusammenfasst wo sie nicht gebraucht werden. Allerdings würde das extrem 
viel Aufwand bedeuten, vieles verkomplizieren und neue Probleme mit sich 
ziehen.

Hat jemand eine gute Idee wie man das machen könnte?

Nachtrag:
Das Beispiel im Anhang ist natürlich ziemlich übertrieben. Bei 2 oder 3 
Einkaufsinformationen ist dieses Problem erst leicht ersichtlich. 
Trotzdem ist es unschön und sollte wenn möglich verbessert werden :-)

Warum ausgerechnet Radio-Buttons? Select mit allen Infos wäre passender.

Auf http://phpbookworm.singollo.de/project/part-db/index.html ist der 
Filemanager in zwei Modi zu sehen:

- Innerhalb eines DIV-Elements
- In einem Popup-Fenster

Ausprobieren ist ausdrücklich erlaubt. Fehlerberichte wären sehr 
hilfreich, um den Filemanager fertig zu bekommen.

ToDo:
- Breadcrumb-Anzeige der Verzeichnisstruktur hinzufügen.
- README ändern, da es nicht mehr aktuell ist.
- Doxygenkompatible Kommentare, kann auch jemand vom Part-DB-Projekt
übernehmen ;-)

Udo Neist schrieb:
> Warum ausgerechnet Radio-Buttons? Select mit allen Infos wäre passender.

Daran habe ich auch schon gedacht. Irgendwie finde ich es aber mit 
Radiobuttons übersichtlicher, weil man direkt auf einen Blick alle 
Möglichkeiten sieht. So sieht man halt sehr schnell, welche Teile man 
bei welchen Lieferanten bekommt und kann so entscheiden, wo man 
bestellen möchte.

Wenn ich z.B. 10 zu bestellende Teile habe, müsste ich bei Comboboxen 
erst bei jedem einzelnen Teil schauen (klicken, schauen, anwählen), ob 
es das bei z.B. Conrad gibt. Bei Radiobuttons sieht man auf einen Blick
- "aha, 3 der Teile gibts bei Reichelt, aber alle 10 gibts bei Conrad, 
also bestelle ich alle 10 bei Conrad"
- oder "aha, 5 gibts bei Reichelt und Conrad, die anderen 5 gibts nur 
bei Conrad, ich muss also sowieso bei beiden Lieferanten bestellen, 
markiere also bei den 5 Teilen wo ich wählen kann jeweils den 
Lieferanten mit dem tieferen Preis".

Und dann kommt dann manchmal auch noch der Mindestmengenzuschlag hinzu, 
den man berücksichtigen muss...

kurz gesagt: Radiobuttons halte ich für übersichtlicher (klar, wenn 
jedes Teil 10 verschiedene Einkaufsinformationen hat, wirds auch 
unübersichtlich. Aber ich schätze mal die meisten Benutzer von Part-DB 
werden maximal 3 Einkaufsinformationen pro Bauteil haben).

Theoretisch könnte man aber auch beide Varianten implementieren, und die 
Wahl dem Benutzer überlassen. Ist eigentlich auch ganz einfach, so wie 
die Tabellen jetzt aufgebaut sind (Spalten in der config.php definiert).

Warum dann nicht alle Elemente mit einem identischen height-Wert 
ausstatten? Entweder Listen oder DIV/P-Elemente verwenden. Ist bisschen 
Fummelarbeit, zugegeben, aber die praktikabelste Lösung.

Funktioniert das dann auch ziemlich 
browser-/schriftarten-/betriebssystemunabhängig?

Und sollte man das am besten gleich in CSS machen?
Bin leider in HTML/CSS nicht wirklich fit...ein Beispiel wäre super :-)

Entweder du nimmst bei jedem Element das Inline-Verfahren

1

style="height=1.5em;"

oder du definierst das im CSS

1

eklist{height: 1.5em;}

und bindest das dann als

1

class="eklist"

ein. Im Template muss das dann nur einmal pro Spalte an der richtigen 
Stelle der Schleife eingetragen werden. Steht da nur ein BR-Tag, dann 
mach mal daraus ein DIV-Element.

PS: Die Höhe hab ich einfach mal beispielsweise genommen. Kommt auf das 
Radio-Element an, wie hoch das dann tatsächlich ist. "em" ist eine 
relative Größe.

Super, danke!

Mit ein bisschen Internetrecherche bin ich nun auf das hier gekommen:

1

<div style="display:inline-block; height:1.7em; line-height:1.7em;">

Das scheint zu funktionieren, zumindest im IE und im FF (Win7/Ubuntu) 
siehts nun so aus wie es soll.

Dann kann ich das ja endlich mal abhaken...

Wenn ich mich nicht täusche, ist nun etwa alles, was ich für die Version 
0.3.0 vorgesehen habe, eingebaut. Ich wäre froh, wenn ein paar Leute nun 
langsam mit dem Testen beginnen würden, es gibt sicher noch viele Bugs 
und Sachen die ich vergessen habe :-)

Vom geplanten Systemupdate sind halt schon ein paar Fragmente in der 
aktuellen Version drin, die kann man ignorieren, die kommen nicht in die 
v0.3.0. Aber der Filemanager kommt natürlich rein, der ist aber noch 
nicht fertig.

Ich würde mich sehr über Rückmeldungen aller Art (Bugs, Vorschläge, 
Bemerkungen) freuen!

Noch nicht wirklich ausgiebig getestet sind übrigens der Installer und 
die Import/Exportfunktionen, hier ist also das Testen besonders wichtig.

Ich habe die komplette Testsuite mit dem aktuellen Stand des 
Filemanagers reinkopiert. Ist recht groß das ganze, da es neben GeShi 
auch noch die vlibTemplate-Engine drin hat. Letztere ist eigentlich 
überflüssig, aber ich wollte die Testsuite nicht extra umschreiben.

Die beiden Dateien index.html und popup.html zeigen, wie man den 
Filemanager in eine Seite integriert.

Revision 615 steht zur Verfügung.

ToDo:
- Globale Rechte und Benutzerrechte integrieren. Einerseits werden 
Standardrechte zu definieren sein, andererseits soll die Token-Abfrage 
zu einem Rechtesystem erweitert werden.
- Doxygenkompatible Kommentare, kann auch jemand vom Part-DB-Projekt
übernehmen ;-)
- Aktualisierung von http://weinbauer73.myparts.info/ (Test-Branch)

Udo Neist schrieb:
> Ausprobieren ist ausdrücklich erlaubt. Fehlerberichte wären sehr
> hilfreich, um den Filemanager fertig zu bekommen.

Gefällt mir schon gut.

Kleinigkeiten hätte ich allerdings:
Obwohl ich bereits im Filemanager einen Unterordner ausgewählt habe bzw 
mich darin befinde, muss ich im Uploader den Unterordner erneut 
auswählen.

Im IE 9 funktioniert leider weder "Filemanager (gleiche Seite)" noch 
"Filemanager (per Popup)" (Popup geht zwar auf, aber es wird kein Inhalt 
angezeigt)

Beim FF und Opera gibts kleinere Schönheitsfehler, siehe Anhang.

mfg Pyro

Mit dem erneuten Auswählen im Uploadmanager hab ich erstmal so gemacht. 
Kann ich ja noch so umbauen, dass das angezeigte Unterverzeichnis als 
Vorauswahl dient.

Im FF habe ich eigentlich keine Darstellungsfehler, hatte das mit der 
19er und jetzigen 20er so entwickelt. Mit Opera, Chrome und dem IE (nur 
bis IE 8, da nur XP) hab ich es noch nicht probiert, aber ich kann mich 
die Tage mal ransetzen.

Ein Fehler hab ich schon gefunden. Ältere Browser verstehen den Mime-Typ 
"application/javascript" nicht, sondern die nie standardisierte Version 
"text/javascript". Warum der IE 8 dann immer noch das dom-Objekt nicht 
findet, konnte ich heute morgen noch nicht klären.

Ich hab dem IE8 zumindest schon mal die Anzeige im gleichen Fenster 
beigebracht. Bis auf den Darstellungsfehler und dem fehlenden Support 
für den Multifileupload von HTML5 läuft es. Eigentlich wollte ich das 
unabhängig von Flash oder Java halten, um nicht irgendwelchen 
IT-Restriktionen zu wider zu laufen :(

Hallo Christoph,

Danke für den Patch, das ist keine schlechte Idee. Ich habe ihn kurz 
angeschaut und werde ihn dann gleich übernehmen (mit ein paar 
Anpassungen - z.B. wenn es zu einem Namen mehrere exakt gleichnamige 
Bauteile gibt, soll der Vorgang abgebrochen werden weil das Ergebnis 
nicht eindeutig ist).

Momentan bin ich mich übrigens grad selbst am bestrafen ;-)
Als ich die Klasse "File" und die davon abhängigen Klassen erstellte, 
war mir bereits bewusst dass "File" ein nicht sehr geschickter Name ist, 
bin aber grad auf keine bessere Idee gekommen. Danach ist es leider in 
Vergessenheit geraten... Nun bin ich dabei, den Namen "File" durch 
"Attachement" zu ersetzen, diese neue Bezeichung ist viel 
aussagekräftiger und zutreffender. Man kann sich ja etwa vorstellen 
wieviel Arbeit das gibt... Und nein, automatisches copy&replace geht 
nicht, da "File" auch in anderen Zusammenhängen verwendet wird ;-)

Ich werde dann schon bald diese zwei Änderungen ins Repository 
hochladen. Dann muss man auf jeden Fall wieder eine Datenbank der 
Version 12 laden, da auch die Tabelle "files" in "attachements" 
umbenannt wird.

mfg

So, die Änderungen sind nun im Repository (r616).

Ich habe vorher gar nicht gesehen, dass im Patch das Suchen des 
entsprechenden Bauteiles in "build_deviceparts_import_template_loop()" 
geschah, das ist irgendwie nicht so passend weil diese Funktion nur für 
das Erzeugen eines Template-Loops (also für die Ausgabe) verantwortlich 
ist. Die eigentliche Import-Funktion braucht die Suchfunktion allerdings 
auch, daher habe ich sie nun in eine eigene Funktion 
"match_devicepart_names_to_ids()" ausgelagert. Scheint soweit zu 
funktionieren, wenns Probleme gibt bitte melden :-)

Christoph Emonds schrieb:
> Von Klassennamen, mit denen man sich ein Bein stellt, kann ich auch ein
> Lied singen (ich verdiene meine Brötchen als Softwareentwickler).

Ja, das glaube ich :-)
Ich bin zwar bei solchen Sachen ein Perfektionist, habe aber das Problem 
dass mir manchmal keine passenden Namen einfallen. Das war mir auch 
bewusst als ich die Klasse "File" getauft habe, daher stand das schon 
von Anfang an auf meiner (virtuellen :-) ToDo-Liste. Die virtuelle 
ToDo-Liste ist aber leider auch nicht von Datenverlust befreit :-D

Christoph Emonds schrieb:
> Im Moment ist bei mir das Datenschema Version 13. Heißt dass, dass ich
> erst ein Downgrade machen muss, bevor ich dann die neue Version mit den
> zwei Änderungen verwenden kann?

Ja, die Entwicklung findet momentan im Branch "uneist_kami89" statt, und 
die aktuelle Version ist noch nicht für den produktiven Einsatz gedacht. 
Heisst also, ich passe die Datenbankstruktur ab und zu wieder an, ohne 
ein entsprechendes Update rauszugeben. Stattdessen muss wieder eine alte 
Datenbank geladen werden, sonst läuft Part-DB nicht mehr korrekt.

Ein Downgrade auf v12 gibt es nicht. Ich hoffe, du setzt Part-DB 0.3.0 
nicht schon produktiv ein? ;-)

mfg

Vielleicht sollte man sich ein Deutsch-Englisch-Wörterbuch neben den PC 
legen, um passende englische Wörter zu finden? ;-)

PS: Mittlerweile hab ich auch Win7 in einer virtuellen Umgebung. So kann 
ich dann auch in meinem Kurzurlaub um den 1. Mai den Filemanager weiter 
entwickeln.

> Hatte mich da wohl von dem RC1 auf der Startseite dazu verleiten lassen,
> die Version schon einzusetzen.

Naja...Wir entwickeln ja laufend im Repository, und momentan arbeiten 
wir auf die 0.3.0 RC1 hin. 0.3.0 Ist also quasi das Ziel, nicht der 
momentane Stand. Wenn die RC1 fertig ist, wird sie als Downloadpaket 
angeboten. Solange wir kein fertiges Paket anbieten, ist es noch nicht 
für Endanwender bestimmt.
Mir scheint, vielen Leuten ist nicht klar bewusst dass das Repository 
grundsätzlich nur für die Entwickler gedacht ist. Für den Endanwender 
stricken wir dann Archive, die man (ohne SVN Client) runterladen kann.

> Hmmm... Angenommen ich würde gerne die Datenbankstruktur meines
> "Testsystems" migrieren, kann ich mir die dafür nötigen Änderungen aus
> den Commit messages zusammensuchen und selber ein Änderungsskript
> erstellen?

Also zurück zur v12 migrieren wäre ein riesen Aufwand, bzw. u.U. gar 
nicht mehr möglich weil dort gewisse Funktionen noch nicht zur Verfügung 
standen. Wenn es dir nichts ausmacht wäre es einfacher, wenn du deine 
Datenbank von nun an jeweils selber aktualisierst, bis dann die RC1 
offiziell fertig ist. Bis dahin sollte es eigentlich fast keine 
Änderungen mehr geben (hoffe ich mal ;-).

Die Datenbankupdates sind in der updates/db_update_steps.php 
aufgelistet.
Im Commit von r616 siehst du, was du alles ändern müsstest, damit du 
deine Datenbank mit der Version 0.3.0 weiterverwenden könntest.

Wenn es nur eine handvoll Artikel sind, würde ich aber eher eine leere 
DB v12 nehmen und die Bauteile von Hand übertragen. Halt mit den 
Einschränkungen von v12, die z.B. nur einen einzigen Lieferanten pro 
Bauteil unterstützt.

> Hast du denn schon eine Idee, wann ein neues Release kommt?

Das ist schwierig zu sagen. Sobald Udo den Dateimanager fertig hat, 
können wir ausgiebig mit dem Testen anfangen und dann schon bald einen 
ersten Release Kandidaten rausgeben. Ausser die 80/20-Regel macht uns 
noch einen Strich durch die Rechnung :-)

Christoph Emonds schrieb:
> Solange solche Änderungen in den
> Commitmessages stehen, geht das schon :-)

Jup, das werden sie. Sollten aber wie gesagt nicht mehr häufig 
vorkommen.

Christoph Emonds schrieb:
> Auf jeden Fall vielen Dank für das Tool und eure Arbeit.

Gerne doch :-)

@K.J. falls du mitliest:
In der Online Demo sollte man nun auch wiedermal eine Datenbank der 
Version 12 einspielen. Ausserdem, wäre es vielleicht möglich Doxygen auf 
dem Server zu installieren? Ich habe nun nämlich die Doxygen Doku aus 
dem Branch entfernt, weil die stört in den Commits einfach zu stark, die 
wirklich wichtigen Änderungen gehen dabei unter. Wer sie braucht, kann 
sie ja ganz einfach selber erstellen, das Doxyfile ist ja vorhanden. 
Wenn nun auf dem Demo Server Doxygen auch installiert wäre, könnte man 
ab und zu mal in den Entwicklerwerkzeugen auf "Doxygen Doku 
aktualisieren" (o.ä.) klicken, dann steht auch diese Doku wieder online 
zur Verfügung. Noch komfortabler wäre natürlich, wenn sie jeweils nach 
dem auschecken der aktuellen SVN Revision gleich automatisch erstellt 
werden würde, muss aber nicht unbedingt sein.

Gruss
Urban

Christoph K. schrieb:
> Ich glaube ich habe einen Bug gefunden:

Da bist du nicht der Erste ;-)
https://code.google.com/p/part-db/issues/detail?id=5

mfg

hallo  kirkdis,

Also momentan gibts nur einen aktiven Branch, das ist der 
"uneist_kami89". Der sollte lauffähig sein, in der Online-Demo muss nur 
noch eine neue Datenbank eingespielt werden dann läufts dort auch 
wieder.

Die anderen Branches sind veraltet, da gibts nichts Interessantes mehr.

Hilfe bei der Doku können wir bestens gebrauchen, dazu gibts im 
genannten Branch extra ein DokuWiki das noch auf einen Freiwilligen 
Helfer wartet :-)

@K.J.
hast eine PN bekommen.

mfg

K. J. schrieb:
> Zur Online Demo kann mir jemand einen Snapschot seiner DB zur Verfügung
> stellen ?

Für solche Fälle habe ich extra mal meine DB (v12) in den Branch 
kopiert, die kannst du gerne verwenden:
https://part-db.googlecode.com/svn/branches/uneist_kami89/development/testfiles/database/v12_kami89.sql

Meine Demo funktioniert derzeit gar nicht, da sie einen Stand ausserhalb 
unseres SVN-Repos repräsentiert. Ich werde mal die Demo auf den Stand 
des Repos updaten und auch mal den Filemanager weiter schreiben. Gerade 
das Thema Javascript ist ja nicht ohne, weil fast jeder Browser seine 
Eigenheiten hat und man sich oft stundenlang die passende Doku zusammen 
suchen muss. Vorallem die unterschiedlichen IEs sind grauslich!

Javascript-Entwickler sind gerne willkommen :)

Wenn bei mir auf der Arbeit die Akkreditierung im Juni gelaufen ist, 
dann dürfte ich auch wieder mehr Zeit (und Nerven) für die Entwicklung 
haben.

Grüße
Udo

Den IE 6 und älter sind bei mir nicht auf der Liste. Warum soll ich mit 
den JS (nicht zu verwechseln mit Javascript; M$ wollte keine Lizenzen 
kaufen, daher diese Variante der ECMA-Scriptfamilie) unterstützen? Erst 
mit IE 7 näherte sich M$ an Javascript an, wobei da selbst im IE 10 noch 
Differenzen zum Quasi-Standard der Gecko/Webkit-Systeme bestehen.

Leider ist mir durch eine kleine Unachtsamkeit mein Raid mit den 
virtualisierten Windoofs (XP und 7) "abgeraucht", muss beides morgen neu 
installieren. Zum Glück hab ich aber noch ein XP auf dem Notebook ;-)

K. J. schrieb:
> gibt noch das Typische umlaut
> Problem aber da kümmer ich mich gleich noch drum.

Ja, das leidige Problem mit den Umlauten... ;-)
Das Problem liegt aber höchstwahrscheinlich nicht an deiner 
Installation, sondern an meiner Datenbank.

Wenn ich mich nicht täusche, liegt das Problem genau genommen an älteren 
Versionen von Part-DB. Wenn man da nämlich ISO-8859-1 als HTTP 
Zeichensatz verwendet hat, dann wurden die ISO-8859-1-codierten Zeichen 
als UTF-8 codierte Zeichen an die MySQL Datenbank übergeben. Beim MySQL 
connect ist nämlich kein Zeichensatz angegeben, also müsste automatisch 
UTF-8 verwendet werden.

Das würde dann also bedeuten, dass alle Benutzer, die den HTTP 
Zeichensatz auf ISO-8859-1 stehen haben, nun falsch codierte Zeichen in 
ihrer Datenbank haben. Solange man zum Decodieren auch wieder ISO-8859-1 
verwendet, fällt das natürlich nicht auf. Jetzt (v0.3.0) kann man 
allerdings den Zeichensatz nicht mehr wählen (weils nichts bringt), und 
die falsch codierten Zeichen in der Datenbank äussern sich in Form von 
kryptographischen Zeichen auf der Webseite.

Man könnte natürlich weiterhin den Zeichensatz auf ISO-8859-1 stellen, 
dann fällt das Problem nicht auf, aber das behebt nicht die Ursache 
sondern nur das Symptom.

Die Frage ist jetzt allerdings, wie wir das Problem lösen, ohne dass die 
Benutzer all ihre Umlaute von Hand austauschen müssen. Vielleicht würde 
es ein MySQL Befehl im Datenbankupdate tun, das alle falsch codierten 
Umlaute durch richtig codierte Umlaute ersetzt. Muss mal schauen ob das 
funktioniert...

Dabei muss ich aber noch anmerken, dass das alles nur Vermutungen sind. 
Ich habe nicht so wirklich viel Erfahrung mit dieser Problematik, ich 
habe einfach mal versucht das Phänomen mit logischen Schlussfolgerungen 
nachzuvollziehen ;-D

K. J. schrieb:
> Doxigen scheint zu laufen auf der DEMO.
Wunderbar!

mfg

Okay also ich habe gerade gemerkt dass meine Testdatenbank-Datei im SVN 
schon fehlerhaft ist, daher werden die Umlaute dann auch nach dem Import 
noch falsch dargestellt. Ich habe die Datei nun korrigiert und werde sie 
mit dem nächsten Commit hochladen.

Irgendwie kommen die falsch codierten Werte ziemlich sicher von einem 
Bug in einer früheren Version von Part-DB. In der Zwischenzeit habe ich 
aber mindestens einmal meine Datenbank exportiert und wieder Importiert 
(Umzug des Servers), durch den Import/Export konnten meine Daten aber 
ev. noch zusätzlich beschädigt worden sein. Denn mich macht etwas 
stutzig, dass in meiner Datenbank ein 'ä' ganze 4 Bytes belegt, das kann 
also nicht nur durch ein falsch codiertes Zeichen entstanden sein. Da 
muss mindestens zweimal nacheinander etwas schiefgelaufen sein.

Dieser spezielle Fall lässt sich vermutlich nur durch Textersetzung 
korrigieren. Allerdings frage ich mich, ob noch mehr Leute von diesem 
Problem betroffen sind.

Hat jemand noch eine Datenbank, die mit einer Part-DB <= 0.2.2 betrieben 
wird und noch nie exportiert/importiert wurde?
Falls ja, würde mich interessieren, wie dort die Umlaute abgespeichert 
werden. Werden sie in phpMyAdmin korrekt angezeigt? Falls nicht, kann 
man sich den Hex-Code anschauen, z.B. damit:

1

SELECT HEX(`name`) FROM categories WHERE ID = 5

Das Umlaute-Problem ist sicher relativ leicht zu lösen. Viel schwieriger 
ist es aber, rauszufinden, wie die Datenbanken unserer Nutzer überhaupt 
aussehen ;-)

mfg

Eventuell ist in meinem Testbranch noch eine alte Version vorhanden.

PS: Ich habe zwar am Filemanager weiter gearbeitet, kann aber leider 
keine Fortschritte beim IE vermelden. Bis einschliesslich IE9 fehlt mir 
FormData(), um einen verbesserten Uploader fertig zu stellen. Da muss 
ich wohl oder übel auf Flash oder die alte Methode zurück greifen :( 
Wobei Flash ja nicht überall zu finden wäre.

Udo Neist schrieb:
> Eventuell ist in meinem Testbranch noch eine alte Version vorhanden.

OK wäre super wenn du da bei Gelegenheit mal nachschauen könntest :-)

Udo Neist schrieb:
> PS: Ich habe zwar am Filemanager weiter gearbeitet, kann aber leider
> keine Fortschritte beim IE vermelden. Bis einschliesslich IE9 fehlt mir
> FormData(), um einen verbesserten Uploader fertig zu stellen. Da muss
> ich wohl oder übel auf Flash oder die alte Methode zurück greifen :(
> Wobei Flash ja nicht überall zu finden wäre.

Hmm also das klingt, als ob es noch etwas länger dauern wird (?). 
Theoretisch könnten wir sonst ja auch nochmal den simplen Upload-Button 
wie bisher verwenden bis der neue Dateimanager fertig ist. Dann könnten 
wir den ersten Release Kandidat der Version 0.3.0 schon sehr bald zum 
Download anbieten, und du kannst dir für den neuen Uploader problemlos 
die Zeit nehmen, die du brauchst.

Arbeiten kann man ja auch mit dem alten Uploader, bisher ging das 
schliesslich auch :-)

Falls niemand etwas dagegen hat, würde ich mich dann mal ums 
Fertigstellen der 0.3.0 RC1 kümmern. Das Problem mit der 
Zeichencodierung hätte dann jetzt erstmal höchste Priorität, denn das 
muss noch vor dem Release behoben werden.

Fündig geworden :-) Sind beides Dumps der Struktur, die ich mal 
irgendwann bei Revision 4xx oder höher gemacht habe.

http://code.google.com/p/part-db/source/browse/branches/uneist/readme/createtables-FOR-V0.2.1-rev12.sql.orig
http://code.google.com/p/part-db/source/browse/branches/uneist/readme/createtables-FOR-V0.2.1.sql

Nimm erstmal den alten, funktionsfähigen Uploader. Ich werde wohl eine 
Lösung mit Iframe bauen müssen, damit wenigstens sowas ähnliches wie mit 
FF, Chrome und Co funktioniert.

Also ich habe mal einen Test gemacht. Neue Datenbank angelegt, Struktur 
mit dem SQL Skript aus v0.2.2 erzeugt und meine Part-DB 0.2.2 mit dieser 
Datenbank verknüpft. Dann eine neue Kategorie 'ä' angelegt und in 
phpMyAdmin den Bytecode davon angeschaut.

Das Zeichen 'ä' sollte dem Bytecode 0xC3 0xA4 (UTF-8) bzw. 0xE4 
(ISO-8859-1) entsprechen.

Ergebnis mit HTTP Zeichensatz UTF-8: 0xC3 0x83 0xC2 0xA4
Ergebnis mit HTTP Zeichensatz ISO-8859-1: 0xC3 0xA4

Erklärung:
Bei ISO-8859-1 wird das 'ä' als 0xE4 von PHP entgegengenommen und MySQL 
übergeben. Da für die Übertragung kein Zeichensatz vereinbart wurde, 
beginnt hier ein Glücksspiel. In meinem Fall geht MySQL wohl davon aus, 
dass es ISO-8859-1 codiert ist. Intern arbeitet MySQL aber mit UTF-8, 
also wird das Zeichen nach UTF-8 konvertiert und als 0xC3 0xA4 in der 
Datenbank abgelegt. In diesem Fall wird das Zeichen also richtig codiert 
in der Datenbank abgelegt.
Bei UTF-8 wird das 'ä' als 0xC3 0xA4 von PHP entgegengenommen und MySQL 
übergeben. MySQL nimmt aber wieder an es sei ISO-8859-1. 0xC3 entspricht 
dann 'Ã', 0xA4 entspricht '¤'. Beide Zeichen werden dann wieder 
(unnötigerweise!) nach UTF-8 konvertiert. 'Ã' ergibt dann 0xC3 0xA4, '¤' 
entspricht 0xC2 0xA4.

Zusammengefasst kann man also sagen, dass zwei Fehler das Problem 
verursachen:
- Beim Verbindungsaufbau mit dem MySQL Server wird kein Zeichensatz 
vereinbart. Es ist reine Glückssache, dass der richtige Zeichensatz 
verwendet wird
- Der Benutzer kann in Part-DB den HTTP Zeichensatz selber einstellen. 
Wählt er den falschen, gibts ein Durcheinander.

Lösungsvorschlag:
- Für die MySQL-Verbindung wird IMMER UTF-8 verwendet (hardcoded). Das 
ist in der aktuellen Entwicklerversion bereits so gemacht.
- Der HTTP Zeichensatz wird IMMER auf UTF-8 eingestellt (hardcoded), der 
Benutzer kann es nicht ändern. Was er nicht ändern kann, kann er nicht 
falsch machen ;-) Ausserdem wäre hier m.M.n. ISO-8859-1 sowieso falsch, 
weil unsere PHP/TMPL Dateien ja auch UTF8-codiert sind.

Machen wir diese Umstellung, wird es Benutzer geben die nach dem Update 
auf 0.3.0 das gleiche Problem haben wie ich. Lösen könnte man es mit 
Search&Replace in der Datenbank.

Ich werde mal schauen wie die "4-Byte-Codes" der wichtigsten paar 
Zeichen (Umlaute und noch ein paar Sonderzeichen) lauten und ein 
entsprechender Search&Replace Befehl ins Datenbankupdate einbauen.

Man könnte beim Update einfach einen Dump der Datenbank machen, den mit 
Recode auf UTF-8 trimmen und wieder einspielen. 100% sicher ist das 
Verfahren nicht, aber immerhin besser als das Scannen aller Daten und 
halbmanuell das ändern. Beim Einlesen "--default_character_set utf8" 
nicht vergessen, damit MySQL nicht wieder was falsch macht ;-)

Dump:

1

mysqldump --set-charset utf8 --default_character_set utf8 -uUSER -pPASS DATABASE >dump

Einlesen:

1

mysql --default_character_set utf8 -uUSER -pPASS DATABASE <dump

Weitere Optionen können hilfreich sein, z.B.
--add-drop-table
--hex-blob
--create-options
--extended-insert

Wobei einige Optionen bereits mit per Default gesetzt sind (siehe auch 
--opt).

Udo Neist schrieb:
> mysqldump

Können wir leider nicht verwenden weil das bei den meisten Hostern nicht 
läuft ;-)
Part-DB sollte möglichst ohne exec() auskommen sonst kann man es auf 
einem normalen Webspace nicht mehr verwenden...

Das Ersetzen mit dem MySQL Befehl "REPLACE()" habe ich grad getestet, 
funktioniert zumindest bei meiner fehlerhaften Datenbank super. Ist 
sicher nicht sehr elegant, aber allemal besser als gar nichts 
unternehmen ;-)

Hallo,

ich hab da ein Problem mit part-db beim Webhoster Strato. Anscheinend 
stimmen die Links nicht. Beim Aufruf der Startseite bekomme ich folgende 
Meldungen:

The requested URL /mnt/webj/c0/03/5587203/htdocs/part-db/navigation.php 
was not found on this server.

Nach meinem Verständnis ist der Teil "/mnt/webj/c0/03/5587203/htdocs" 
der Pfad auf dem Server, jedoch nicht die richtige URL von außen. 
Versuchsweise habe ich in "start_session.php" folgende Zeile angepasst:

define('BASE_RELATIVE', './');

Danach konnte ich auf part-db zugreifen. Allerdings denke ich mal das 
dass nicht so ganz der richtige Weg ist. Hat da einer von euch einen 
Tipp ?

Gruß
Dirk

Hallo Dirk,

Kannst du mal hinter den drei Pfad-Defines diese Zeilen einfügen

1

print 'BASE = "'.BASE.'"<br>';

2

print 'DOCUMENT_ROOT = "'.DOCUMENT_ROOT.'"<br>';

3

print 'BASE_RELATIVE = "'.BASE_RELATIVE.'"<br>';

4

print 'DIRECTORY_SEPARATOR = "'.DIRECTORY_SEPARATOR.'"<br>';

und die Ausgabe hier posten?

mfg

So, habe grad nochmal ein Update hochgeladen (r619), da sind noch ein 
paar wichtige Änderungen drin. Unter anderem auch eine Migration der 
alten config.php in das neue Format, damit man die Einstellungen nicht 
nochmal tätigen muss.

Übrigens war bisher ja der PayPal-Link tot, weil Jacobs PayPal-Konto 
nicht mehr erreichbar ist. Nach Absprache mit K.J. geht der Link nun 
(zumindest vorläufig) auf mein PayPal Konto. Falls tatsächlich Spenden 
getätigt werden, werde ich es sammeln und bei Erreichen eines 
nennenswertes Betrages hier bekanntgeben um das weitere Vorgehen 
abzuklären.

Vermutlich werde ich schon bald den aktuellen Entwickler-Branch in den 
Trunk mergen, und dann ein Paket für die 0.3.0 RC1 zum Download 
anbieten.

mfg

So hab jetzt mal die print Anweisungen eingefügt und bekomme folgende 
Ausgabe:

BASE = "/mnt/webj/c0/03/5587203/htdocs/part-db"
DOCUMENT_ROOT = "/home/strato/http/premium/rid/72/03/5587203/htdocs"
BASE_RELATIVE = "/mnt/webj/c0/03/5587203/htdocs/part-db/"
DIRECTORY_SEPARATOR = "/"

Ich habe keine Ahnung was Strato da hinter den Kulissen macht, aber die 
Ausgaben stammen direkt von meinem Webspace bei Strato :-(

Naja, zur Not kann ich immer noch den Pfad manuell im Source anpassen.

> Das Paket muss ich glaube ich erstellen b.z.w. Uploaden, glaub das kann
> ich nur als einziger.

OK wenn es dann soweit ist melde ich mich einfach bei dir.

> p.s. Hab die Doku für die GPL Geschichte angefangen, leider ist das
> ganze recht kompliziert die GPLv2 ist nicht wirklich einfach zu
> verstehen.

Hehe ja das glaube ich ;-) Ich kenne mich da leider auch zu wenig aus, 
müsste mich auch erst genauer informieren was da alles geregelt wird...

Dirk B. schrieb:
> BASE = "/mnt/webj/c0/03/5587203/htdocs/part-db"
> DOCUMENT_ROOT = "/home/strato/http/premium/rid/72/03/5587203/htdocs"
> BASE_RELATIVE = "/mnt/webj/c0/03/5587203/htdocs/part-db/"
> DIRECTORY_SEPARATOR = "/"

Das ist ja wirklich eine komische Sache, mit solch unterschiedlichen 
Pfaden vom Server kommt Part-DB nicht zurecht. Ich habe mal ein bisschen 
im Internet nachgeschaut und bin auf das hier gekommen: 
http://www.strato-faq.de/artikel.html?sessionID=4ca68360450406176b63d8a14b819b56&id=10

Aber selbst diese Beschreibung passt nicht zu deinen Pfaden, da dort 
deine Domain ja nicht enthalten ist. Weiss der Geier, was Strato hier 
für Spielchen treibt ;-)
Ich denke mal das ist für uns Entwickler unmöglich, die korrekten Pfade 
zu bekommen, vermutlich wirds also auf das hier rauslaufen:

Dirk B. schrieb:
> Naja, zur Not kann ich immer noch den Pfad manuell im Source anpassen.

Ja das geht natürlich, wird dann aber bei jedem Update wieder 
überschrieben. Ansonsten könnte ich noch eine Funktion einbauen, die es 
explizit erlaubt, die Pfade manuell zu setzen, und die dann auch bei 
einem Update nicht überschrieben werden. Werde mal schauen was man da 
machen kann.

Rein für die Webseite sind die Pfade nicht so kritisch, also wenn die 
Seite richtig angezeigt wird passt das schon. Allerdings kann es 
Probleme geben bei den Pfaden zu Footprint-Bilder oder Dateianhängen. 
Denn bevor ein Pfad zu einer Datei in der Datenbank abgelegt wird, wird 
ein Replace druchgeführt, der den BASE Pfad durch "%BASE%" ersetzt. So 
gibt es keine Probleme wenn man Part-DB auf einem anderen Server (mit 
anderem BASE Pfad) installiert, alle Pfade in der Datenbank 
funktionieren dann immernoch weil eben der absolute Pfad dort nicht 
abgelegt wird. Wenn du jetzt bei der manuellen Definition der Pfade was 
falsches eingibst, könnte es unter Umständen sein dass diese 
Textersetzung nicht mehr funktioniert.

Allerdings wäre auch dieses Problem schnell wieder lösbar, du müsstest 
dann bei einem Server-Umzug halt manuell in der Datenbank alle 
Basis-Pfade noch durch "%BASE%" ersetzten, dann läufts wieder. Wichtig 
ist einfach dass du das weisst, sonst ärgerst du dich nach einem Umzug 
über die nicht mehr funktionierenden Dateipfade...

mfg

Eine Möglichkeit zum manuellen Setzen wäre natürlich sehr gut.

Zu den Footprints hätte ich sowieso noch eine Frage. Wenn ich z.B. ein 
TQFP64 Gehäuse anlegen möchte, wie muss ich das mit den neuen Footprint 
Bildern denn machen ?

Wie wäre es mit folgenden Code? Wenn BASE und BASE_RELATIVE auf das 
gleiche Verzeichnis zeigen, dann wird "./" als Pfad zurückgegeben, 
ansonsten einen aus DOCUMENT_ROOT zusammengebauten (altes Verhalten).

1

define ('BASE_RELATIVE', ((BASE == str_replace(DOCUMENT_ROOT, '', str_replace(DIRECTORY_SEPARATOR, '/', BASE))) ? '.'.DIRECTORY_SEPARATOR : str_replace(DOCUMENT_ROOT, '', str_replace(DIRECTORY_SEPARATOR, '/', BASE)).DIRECTORY_SEPARATOR));

Ob es auf allen Strato-Hosts funktionieren wird, bezweifel ich. 
Vielleicht setzt Strato ein BIND oder nen Link auf das Verzeichnis und 
schiebt dem Apachen was anderes unter? Ziemlich merkwürdiges Setup.

Dirk B. schrieb:
> Zu den Footprints hätte ich sowieso noch eine Frage. Wenn ich z.B. ein
> TQFP64 Gehäuse anlegen möchte, wie muss ich das mit den neuen Footprint
> Bildern denn machen ?

Nun, das ist momentan ein bisschen blöd...Eigentlich war dafür der neue 
Filemanager gedacht. Also man hätte dann den neuen Footprint angelegt 
und mit dem Filemanager das passende Bild dazu ausgewählt. Da der 
Filemanager aber noch fehlt, müsste man theoretisch den Dateipfad des 
entsprechenden Bildes in das Textfeld "Bild:" eintippen (bzw. per 
Copy&Paste aus der Footprintbilder-Übersicht).
Es gibt momentan nur einen Workaround der das etwas einfacher macht. Man 
kann statt dem Dateipfad einfach z.B. "DIP28" eintippen und so 
übernehmen. Weil das Bild dann aber nicht gefunden wird, taucht der 
Eintrag dann unter "Footprints mit fehlerhaften Dateinamen" auf, inkl. 
Vorschlägen für Dateipfade die ein "DIP28" beinhalten. Dort kann man das 
passende dann anwählen und übernehmen.

In der Version 0.2.2 läuft es momentan ja auch nicht anders...
Sobald der neue Filemanager kommt, ist das Problem dann aber auch 
beseitigt. Man könnte ja z.B. auch mit dem Zuweisen der Bilder noch 
warten und das dann erst später machen wenn der Filemanager fertig ist.

Demo Tester schrieb:
> leider funktioniert die Demo zur Zeit nicht

Huch, @K.J. hat mein Update von gestern vielleicht die config.php 
zerschossen?

K. J. schrieb:
> Urban B. schrieb:
>> Huch, @K.J. hat mein Update von gestern vielleicht die config.php
>> zerschossen?
>
> Jup scheinbar ;-)

Hmm ja jetzt habe ich den Fehler gesehen ;-)
Passiert dann wohl bei allen, die schon die 0.3.0 verwendeten.
Macht aber nix, beim Upgrade von der 0.2.2 auf die 0.3.0 oder wenn noch 
gar keine config.php vorhanden ist sollte alles funktionieren.

Ich habe jetzt eben noch eine Versionsnummer für die config.php 
eingeführt. So kann man im Falle eines Formatwechsels (wie von 0.2.2 auf 
0.3.0) die alte config.php aufs neue Format updaten. Steht in der 
config.php noch keine Version drin, geht das System davon aus dass es 
sich um Part-DB 0.2.2 handelt, was jetzt natürlich nicht stimmt wenn man 
bereits Version 0.3.0 benutzt hat weils bisher diese Versionsnummer noch 
nicht gab.

Also ich habe mal einen STRATO workaround in start_session.php eingebaut 
(r620). Zusätzlich gibt es jetzt auch die Möglichkeit die Pfade ganz 
manuell zu setzen in der config.php, falls es noch andere so komische 
Server gibt.

@Dirk B.
kannst du mal schauen ob der workaround so funktioniert?

Habs gerade mal ausprobiert, geht jetzt wunderbar.

Vielen Dank für die schnelle Hilfe!

Eine Sache war mir noch bei den Lieferanten aufgefallen. Wenn man dort 
eine Webseite angibt ist der Link über dem Eingabefeld zusammengesetzt 
aus der Part-db URL und der Lieferanten URL. Das funktioniert natürlich 
nicht.

Aus "www.digikey.de" wird z.B. "http:/www.xyz.de/part-db/www.digikey.de

Gruß
Dirk

Ich habe auf der Arbeit auch einen Laserbarcodescanner, der über die 
alte DIN-Tastaturbuchse bzw. PS/2 läuft. Auch einige neuere USB-Scanner 
kann man als USB-HID direkt nutzen.

Dirk B. schrieb:
> Eine Sache war mir noch bei den Lieferanten aufgefallen. Wenn man dort
> eine Webseite angibt ist der Link über dem Eingabefeld zusammengesetzt
> aus der Part-db URL und der Lieferanten URL. Das funktioniert natürlich
> nicht.

Ah ja, liegt nur am fehlenden http://, werde das noch einbauen dass es 
automatisch vor das www gesetzt wird wenn der Benutzer es weglässt. Ist 
dann im nächsten Commit von mir drin.

K. J. schrieb:
> So heute nen Barcode Scanner bestellt, das einzige was mir für mein
> Lager fehlt, also werde ich mich mal dran machen das Sinnvoll
> umzusetzen.

Daran habe ich auch schon lange gedacht dass wir das mal noch einbauen 
müssen, super dass du dich da grad drum kümmerst :-)

Schön wäre auch wenn man für jede Einkaufsinformation auch noch einen 
Barcode abspeichern könnte, und zwar den vom Lieferanten. So könnte man 
z.B. beim Einbuchen von bestellten Teilen den Barcode auf der Verpackung 
kurz scannen und dann noch die Stückzahl eingeben. Das würde das Suchen 
des Bauteiles ersparen.

Wobei es natürlich auch andere Varianten gäbe für diese Aufgabe, z.B. 
ist ja noch ein "pending orders" geplant, damit könnte man eine 
Bestellung mit einem Klick einbuchen. Das setzt aber natürlich voraus 
dass man auch jede getätigte Bestellung in Part-DB eingibt...

Es gibt eine PDF-Klasse mit Barcode-Support. Mit dem passenden Drucker 
hat man direkt entsprechende Etiketten. Ich habe sowas für einen Dymo 
Labelwriter 320 bzw. 400 mal umgesetzt (allerdings nur unter Linux und 
Cups als Printerserver).

K. J. schrieb:
> Das würde gehen wen die Strichcodes der Hersteller die Bestellnummern
> sind bei Reichelt z.b. ist das nicht so, da ist es wahrscheinlich
> irgendeine Lagernummer.

Jo, man müsste den Barcode auf der Verpackung erstmal in Part-DB 
registrieren, also einer Einkaufsinformation zuordnen...

K. J. schrieb:
> Die Überlegung wehre noch ein Dritter Scan, z.b. für die Anzahl, oder
> Löschbestätigung die frage wehre ob es nicht zuviel Overhead wehre
> dreimal Scannen ist schon recht viel was Sagt ihr ?

Also wenn man es so macht, dass einmal gescannte Optionen und 
Stückzahlen gespeichert werden, entsteht ja kein unnötiger Overhead.

Also z.B. so:
- Option "Ausbuchen" scannen
- Stückzahl "3" scannen
- Bauteil 1 scannen --> 3 Stück werden abgebucht
- Bauteil 2 scannen --> 3 Stück werden abgebucht
- Stückzahl "1" scannen
- Bauteil 3 scannen --> 1 Stück wird abgebucht
- Bauteil 4 scannen --> 1 Stück wird abgebucht
- Option "Einbuchen" scannen
- Bauteil 5 scannen --> 1 Stück wird eingebucht
- Bauteil 6 scannen --> 1 Stück wird eingebucht
- usw.

Ich habe gerade eben (r625) den aktuellen Trunk von Part-DB 0.2.2 nach 
"tags" kopiert. Nun ist mein SVN Client grad dran, den Branch 
"uneist_kami89" in den Trunk zu mergen. Ich hoffe das klappt, das 
Programm scheint ein bisschen Mühe zu haben^^

Das heisst dann also, dass von jetzt an die ganze Entwicklung wieder im 
Trunk stattfindet.

Ich würde vorschlagen, dass mal ein paar Leute das Update auf die 
Version 0.3.0 RC1 machen (aus dem Trunk) und hier berichten ob alles 
geklappt hat. Überschreibt man eine Part-DB 0.2.2 Installation mit der 
0.3.0 RC1, sollte die alte config.php auf das neue Format aktualisiert 
werden und dann noch ein Installer erscheinen um ein paar weitere 
Angaben zu erfassen. Dann muss man noch das Datenbankupdate durchlaufen 
lassen, und Part-DB 0.3.0 RC1 sollte einsatzbereit sein.

Wenn die ersten Rückmeldungen dann positiv sind, schnüre ich ein Paket 
für die Version 0.3.0 RC1, das wir dann zum Download anbieten. (Für das 
Updatepaket müssen dann z.B. das Verzeichnis "development" und den 
Menüeintrag zu den noch nicht vorhandenen System-Updates entfernt 
werden)

...und mein SVN Client ist immernoch am mergen...der braucht wohl noch 
eine Weile ;-)

Ich kann es ja am WE auf meine Demoseite hochladen und austesten :-)

Verdammt jetzt habe ich fast eine Stunde (!!) gewartet und jetzt bricht 
der SVN Client mit einer Fehlermeldung ab...das läuft ja super...

So ein Merge ist wohl eine Wissenschaft für sich. Erst wollte ich es mit 
dem Merge-Befehl machen, hat aber nicht geklappt. So wie ich das 
verstanden habe, müsste ich erst alle Änderungen vom Trunk, die seit dem 
Erstellen des Branches "uneist_kami89" commited wurden, in den Branch 
mergen, damit ich den Branch wieder in den Trunk mergen kann. Da all 
diese commits aber sinnlos sind (weil im Branch eh alles neu ist) habe 
ich nun versucht einfach die Dateien aus dem Branch in den Trunk zu 
commiten. Jetzt reklamiert er irgendwas wegen Verzeichnissen die Dateien 
beinhalten blabla...

Es kann sich also nur noch um Stunden handeln ;-)

Lass dir Zeit :-) Vor morgen Nachmittag werde ich eh nicht dran gehen.

So, jetzt scheint es geklappt zu haben (r626) :-)
Hat wieder fast eine Stunde gedauert zum hochladen...

@Udo
Naja, es gibt ja schon die Online Demo von K.J., die müsste sich morgen 
ja wieder automatisch aktualisieren. Wenn das Update korrekt 
funktioniert, erscheint dann zwar leider der Installer um noch ein 
Administratorkennwort zu erstellen. Ist zwar blöd in der Online Demo, 
sollte aber sicherheitstechnisch eigentlich unproblematisch sein (man 
kann zwar die config vermurksen, aber die ist ja schnell wieder 
hergestellt).

@K.J.
Falls jemand in der Online Demo ein Administratorkennwort eingibt, 
kannst du in der config.php die Variable 
"$config['installation_complete']['admin_password']" auf "false" 
stellen, dann erscheint der Installer nochmals um ein neues Kennwort 
einzugeben. Ausserdem musst du noch die Variable 
"$config['is_online_demo']" auf "true" stellen.

Dann hoffen wir mal dass alles rund läuft ;-)

Urban B. schrieb:
> Dann hoffen wir mal dass alles rund läuft ;-)

Schade, war wohl nichts, die Demo ist ziemlich tot :-(

@K.J.
Vielleicht bekommst du gescheite Fehlermeldungen wenn du in der 
config.php das Debugging aktivierst (das setzt automatisch das error 
reporting level runter damit man alle Fehlermeldungen und Warnungen zu 
sehen bekommt). Oder mal die config.php ganz löschen und schauen ob dann 
was kommt...

Und danke fürs ändern meiner Mailadresse, hat geklappt :-)

na, noch niemand die 0.3.0 RC1 ausprobiert? ;-)
Ich warte noch auf Fehlerberichte :-D

Wie gesagt, wenn hier die ersten Berichte positiv sind, werde ich 
offiziell ein Archiv von der 0.3.0 RC1 stricken und dann zum Download 
anbieten.

@K.J. Interessant wäre für mich noch, was bei der Online Demo vom Trunk 
passiert ist, da funktioniert momentan ja gar nichts mehr...

Gibt es irgendwo eine kleine Installations-Anleitung?
Ich hatte mal einen Test-Server mit Version 0.2.0 (?) aufgesetzt, aber 
nicht viel damit gemacht, kann ich die 0.3.0 da einfach drüber bügeln?

@K.J. OK alles klar.


M. K. schrieb:
> Gibt es irgendwo eine kleine Installations-Anleitung?

Naja, so halbwegs gibts eine (mittlerweile veraltete) Anleitung im 
DokuWiki: 
http://partdb.grautier.com/uneistkami89/documentation/dokuwiki/index.php

Aber die bringt für die Version 0.3.0 eigentlich nicht mehr viel, die 
müsste mal überarbeitet werden.

> Ich hatte mal einen Test-Server mit Version 0.2.0 (?) aufgesetzt, aber
> nicht viel damit gemacht, kann ich die 0.3.0 da einfach drüber bügeln?

Ja, eigentlich muss man einfach die alten Dateien mit den Neuen 
überschreiben. Da aber viele alte Dateien nicht mehr gebraucht werden, 
ist es sauberer wenn man alle alten Dateien erst löscht und dann die 
Neuen reinkopiert. Nur (falls vorhanden) die hochgeladenen Bilder im 
Verzeichnis "img" sollten nicht gelöscht, sondern ins neue Verzeichnis 
"media" verschoben werden, und die config.php sollte ebenfalls nicht 
gelöscht werden. Alles andere kann man einfach löschen.

Dann sollte beim ersten Aufrufen noch der Installer erscheinen um ein 
paar Eingaben zu erfassen. Dann noch das Datenbankupdate (auf das man 
hingewiesen wird) durchlaufen lassen und fertig. Datenbank-Backup vor 
dem Update machen falls man bereits Datensätze in der Datenbank hat!

Ich habe grad noch ein paar Änderungen hochgeladen (r631). Das 
Administratorpasswort wird jetzt nicht mehr einfach als MD5-Hash in der 
config.php abgelegt, sondern zuerst versalzen und dann als SHA256-Hash 
abgelegt. Für den Fall, dass ein Unberechtigter Lesezugriff auf die 
config.php bekommen würde, ist dies eine enorme Verbesserung der 
Sicherheit weil so Rainbow Tables nichts mehr bringen.

Ich dachte, diese Änderung mache ich besser jetzt, noch bevor die 0.3.0 
offiziell herausgegeben wurde. Bei denjenigen, die die 0.3.0 bereits 
verwenden, wird nach dem nächsten Update einfach der 
Installationsassistent nochmal aufgerufen, um das Administratorpasswort 
neu einzugeben.

Bitte führt das Update auf Revision 631 durch, nachher nehme ich diese 
Übergangslösung wieder raus!

Ausserdem habe ich die Dokumentation noch ein bisschen erweitert. Jetzt 
ist auch erklärt, wie man Apache, PHP, MySQL und phpMyAdmin installiert. 
Getestet habe ich es selbst schnell unter Ubuntu 13.04.

mfg

hmm ich beschäftige mich grad ein bisschen mit dem Thema Sicherheit um 
die Doku in diesem Punkt noch zu ergänzen, und eventuell auch noch ein 
paar Überprüfungen der Sicherheitseinstellungen in den Sourcecode 
einzubauen.

Grundsätzlich gibt es ja zwei Varianten, Part-DB zu installieren. 
Entweder installiert man es im Home-Verzeichnis und erstellt eine 
Verknüpfung in /var/www, oder man installiert Part-DB direkt in 
/var/www/.

Die erste Variante hat den Vorteil, dass man Part-DB ohne root-Rechte 
installieren und aktualisieren kann. Allerdings müssten die Dateirechte 
für die config.php und das Verzeichnis "media" dann jedoch auf 666 bzw. 
777 stehen, weil der Benutzer "www-data" in diesem Fall nicht der 
Besitzer der Dateien ist. Nur so kann Apache die config.php beschreiben 
und Dateien nach media hochladen. Unschön ist dann allerdings, dass 
die von Apache erstellten Dateien dem Benutzer "www-data" gehören, alles 
andere aber dem angemeldeten Systembenutzer. Irgendwie ein bisschen ein 
Durcheinander wie ich finde...

Daher frage ich mich ein bisschen, ob wir in der Doku besser nur die 
zweite Variante erklären, also dass man Part-DB mir root-Rechten in 
/var/www/ installiert, den Besitzer auf "www-data" und die Rechte auf 
644 bzw. 755 setzt. Das Updaten wird so zwar mühsamer weil es nur mit 
Root-Rechten durchgeführt werden kann, insgesamt empfinde ich diese 
Variante aber als "sauberer" und auch sicherer (weil die Dateirechte so 
eingeschränkter sein können, z.B. 755 statt 777).

Installiert man Part-DB auf dem Webspace eines Hosters, reichen ja auch 
644/755 aus um die Dateien beschreiben zu können.

Wobei man noch berücksichtigen sollte, dass das "Update-Root-Problem" 
nicht mehr vorhanden ist, sobald wir einen Updater in Part-DB 
integrieren. Dann wird das Update nämlich automatisch unter dem Benutzer 
"www-data" durchgeführt...

Jetzt wollte ich mal fragen, wie ihr das seht?

Ausserdem kam mir noch eine andere Idee in den Sinn. Irgendwie wäre es 
doch schön, wenn alle "individuellen" Dateien in einem separaten 
Verzeichnis liegen würden, sauber getrennt von den Part-DB 
Systemdateien. Konkret denke ich da an ein Verzeichnis "data", in dem 
dann die config.php und das Verzeichnis "media" liegt. Vielleicht 
bräuchte man dieses Verzeichnis später auch mal noch für andere Sachen. 
So ein data-Verzeichnis würde verschiedene Vorteile bieten:
- Möchte man regelmässige Backups von Part-DB machen, muss so neben der 
MySQL Datenbank nur dieses eine Verzeichnis "data" mitgesichert werden. 
Alle zu sichernden Dateien befinden sich in diesem Verzeichnis, und 
sonst nirgendwo.
- Schreibrechte für den Webserver sind nur in diesem data-Verzeichnis 
notwendig, überall sonst sind nur Leserechte nötig. So können die 
Dateirechte sehr restriktiv vergeben werden, was sicherheitstechnisch 
sicher keine schlechte Sache ist.
- (Man könnte sogar das data-Verzeichnis ausserhalb des Part-DB 
Hauptverzeichnisses betreiben, indem man ein Symbolischer Link erzeugt. 
So könnte das data-Verzeichnis z.B. auch auf einer Netzwerkfreigabe 
liegen, falls das jemand brauchen kann...)

Was meint ihr dazu?
Der einzige Nachteil dieser Umstellung ist eigentlich die Umstellung an 
sich^^ Solange die 0.3.0 aber noch nicht offiziell freigegeben wurde, 
sollte das aber nicht so tragisch sein...

Ich wäre froh um Rückmeldungen.

mfg

Urban B. schrieb:
> Jetzt wollte ich mal fragen, wie ihr das seht?

Ich bin unbedingt für die Installation unter root-Rechten. Diese 
Frickeleien mit Benutzerrechten sind einfach nur Murks.

Die Trennung von Code und Konfiguratiosdaten etc. ist auch 
wünschenswert.

Urban B. schrieb:
> Was meint ihr dazu?

Eine Trennung von Code und Benutzerdaten würde ich auch sehr begrüßen, 
vor allem in Hinsicht auf Backups.

Ich würde es durchaus nützlich finden wenn der "Durchschnittspreis für 1 
Stk.: *,* €" gleich direkt bei der Bauteileübersicht als Spalte 
angezeigt werden würde.


Wie legt man eig in der 0.2.2 Version Footprints an?
Die Footprints habe ich hochgeladen, werden auch unter Tools > 
Footprints angezeigt, unter Bearbeiten > Footprints habe ich mir bereits 
eine kleine Struktur angelegt, aber ich kann nirgends ein "Bild" 
auswählen wie hier im Forum einige Beiträge weiter oben beschrieben 
wurde.

Okay ich habe schonmal damit begonnen ein data-Verzeichnis zu erstellen, 
und die Doku ist jetzt umgeschrieben für die Installation als root, 
direkt in /var/www. Werde das Update bald hochladen.


Gerald *. schrieb:
> Ich würde es durchaus nützlich finden wenn der "Durchschnittspreis für 1
> Stk.: *,* €" gleich direkt bei der Bauteileübersicht als Spalte
> angezeigt werden würde.
Gute Idee, habe das gleich in die v0.3.0 mit eingebaut. Ist aber 
standardmässig nicht aktiviert, man muss diese Spalte in der config.php 
selber aktivieren. Konkret muss man die Zeile mit dem Arrayelement 
"$config['table']['category_parts']['columns']" aus der 
config_defaults.php in die config.php kopieren und dort noch die Spalte 
"average_single_price" einfügen. Ist halt bis jetzt noch nirgens 
dokumentiert welche Spalten zur Verfügung stehen, das muss dann auch mal 
noch in die Doku eingebaut werden...

> Wie legt man eig in der 0.2.2 Version Footprints an?
> Die Footprints habe ich hochgeladen, werden auch unter Tools >
> Footprints angezeigt, unter Bearbeiten > Footprints habe ich mir bereits
> eine kleine Struktur angelegt, aber ich kann nirgends ein "Bild"
> auswählen wie hier im Forum einige Beiträge weiter oben beschrieben
> wurde.

Ich vermute mal, diese Option ist erst nach der Veröffentlichung von 
0.2.2 hinzugefügt worden, steht also nur zur Verfügung wenn man Part-DB 
direkt per SVN runtergeladen hat. Am besten wartest du auf die Version 
0.3.0 :-)

lol, mir ist grad noch was merkwürdiges aufgefallen^^
In der Spalte "Datenblätter" fehlt bei mir im Firefox plötzlich das Icon 
für alldatasheet.com. Dateipfad habe ich überprüft, der passt. Cache 
geleert, im privaten Modus vom FF probiert, bringt alles nichts. Die 
anderen zwei Icons werden richtig angezeigt. Dann habe ich mal die 
Bilddatei umbenannt, dann funktionierts wieder. Wieder den alten 
Dateinamen gegeben, funktioniert nicht mehr.

Lustigerweise heisst die Bilddatei "ads.png". Da ich es mir nicht anders 
erklären konnte, vermutete ich mal dass Firefox aufgrund des Dateinamens 
meint, dass es sich bei dem Bild um Werbung handelt. Dann kam mir in den 
Sinn, dass es dann aber auch am AdBlock liegen könnte. Und tatsächlich: 
Adblock deaktiviert --> Bild wird angezeigt. AdBlock aktiviert --> Bild 
wird nicht angezeigt xD

Ich werde dann die Datei von "ads.png" wohl besser mal nach 
"alldatasheet.png" umbenennen... ;-)

Urban B. schrieb:
> Gute Idee, habe das gleich in die v0.3.0 mit eingebaut. Ist aber
> standardmässig nicht aktiviert, man muss diese Spalte in der config.php
> selber aktivieren.

Schon mal ein dickes Danke im voraus.

Urban B. schrieb:
> Am besten wartest du auf die Version 0.3.0 :-)

Die Umsetzung in der Demoversion gefällt mir schon gut.
Ich bin schon auf das Release gespannt :)

Es ist soweit! Part-DB 0.3.0 RC1 steht ab sofort zum Download bereit! 
:-)

https://code.google.com/p/part-db/downloads/detail?name=Part-DB_0.3.0.RC1.tar.gz

In Part-DB 0.3.0 sind jetzt übrigens auch .htaccess Dateien enthalten, 
um die Verzeichnisse vor unbefugtem Zugriff zu schützen. Nähere Infos 
dazu gibts in der Dokumentation.

Leider ist die Doku momentan aber nicht online verfügbar. Für diesen 
Fall habe ich im Verzeichnis "readme" die Datei "INSTALL.txt" noch 
ergänzt, ist halt nicht so schön zu lesen weils in Wiki-Syntax 
geschrieben ist, aber besser als nichts :-)

@K.J. wäre super wenn du die Online-Demo noch aktualisieren könntest, 
damit die Installationsanleitung aufgerufen werden kann.

mfg

Bin grad noch auf eine Idee gekommen. Wir haben ja noch den Webspace von 
Christian (holle), da habe ich kurzerhand mal die Doku hochgeladen um 
die Zeit zu überbrücken bis die offizielle Demo wieder aktuell ist:

http://kami89.myparts.info/dokuwiki/doku.php

Ist sonst etwas mühsam wenn man sich mit der INSTALL.txt begnügen 
muss...

Danke an dieser Stelle nochmal an Christian, und sorry dass es so lange 
dauert bis die Benutzerverwaltung umgesetzt wird ;-)

Ach so, ich dachte dass die Demo "Part-DB - 0.2.2 SVN (Aktuell)" auch 
täglich ein Update aus dem Trunk holt, und die Demo "Part-DB - 0.3.0 SVN 
Testversion" halt aus dem Branch ;-)

Daher ging ich davon aus, dass die Demo "Part-DB - 0.2.2 SVN (Aktuell)" 
auch auf die Version 0.3.0 updaten müsste, da die 0.3.0 ja nun im Trunk 
liegt.

Dass die Demo "Part-DB - 0.3.0 SVN Testversion" nicht mehr aktualisiert 
wird, liegt daran, dass ich den Branch "uneist_kami89" gelöscht habe, 
weil die Entwicklung nun ja wieder im Trunk stattfindet und der Branch 
daher nicht mehr benötigt wird.

Das Beste wäre dann wohl vermutlich, wenn du die Demo "Part-DB - 0.3.0 
SVN Testversion" einfach vom Branch "uneist_kami89" auf den Trunk 
umstellst, dann wird die wieder korrekt aktualisiert.

Christian schrieb:
> Hab noch einen Wunsch. Beim CSV oder XML export wird der Hersteller und
> die Part-ID (pid) nicht in einer Spalte aufgeführt.
> Wäre für diese Änderung dankbar.

Kein Problem, habs gleich eingebaut und hochgeladen 
(lib/lib.export.php): 
https://code.google.com/p/part-db/source/browse/trunk/lib/lib.export.php?spec=svn640&r=640

Um es zu verwenden musst du in der config.php die entsprechende 
$config['export']... Zeile neu definieren (aus config_defaults.php in 
die config.php kopieren und dort anpassen). Für die ID-Spalte musst du 
"id", für den Hersteller "manufacturer" im String ergänzen.

Hi, nachdem ich nun ebenfalls umgestiegen bin auf die partdb hab ich 
gleich mal ne Frage dazu. ;)

Ich würde mir gerne statt dem Lagerort die Bestellnummern ausgeben 
lassen.(Ich meine übrigens die Listenanzeige "showparts.php?xx")

Ich weiß nicht genau wieviel Aufwand das ist aber ich würd es mir auch 
selbst zutrauen. Kann ja nicht so schwer sein.. Denk ich mir.(Haha)
Leider durchblicke ich den Code noch nicht wirklich. Wäre für ein paar 
Tips sehr dankbar.

Grüße CK

Hallo Christopher,

> Ich würde mir gerne statt dem Lagerort die Bestellnummern ausgeben
> lassen.(Ich meine übrigens die Listenanzeige "showparts.php?xx")

mmh "showparts.php" klingt nach der Part-DB Version 0.2.2, wenn du den 
Release Kandidat der Version 0.3.0 benutzt oder noch auf die finale 
Version wartest, ist dein gewünschtes Feature bereits drin :-)
Da müsstest du dir mal die Dateien "config_defaults.php" und die 
"config.php" anschauen, speziell die Variable 
"$config['table']['category_parts']['columns']"

mfg

Das war ja fast zu einfach um wahr zu sein. Danke ich habs geschafft. 
Hab gleich auf RC1 geupdated.

Zeile in der config_defaults.php lautet in meinem Fall nun

1

 $config['table']['category_parts']['columns']           = 'hover_picture;name;description;instock_mininstock;footprint;storelocation;datasheets;attachements;button_decrement;button_increment;suppliers;supplier_partnrs';

Geniales Script... netten Abend wünsche ich noch.

PS: Beim update meldete der Server "File does not exist: 
/usr/share/javascript/toggle.js".

Lösung war: In der Datei "/etc/apache2/conf.d/javascript-common.conf" 
die Zeile "Alias /javascript /usr/share/javascript/" 
Kommentieren/Löschen und Apache neu starten.