Benachrichtigungen
Alles entfernen
Fakturama 2
13
Beiträge
2
Benutzer
0
Reactions
2,843
Aufrufe
Topic starter
4. Februar 2016 14:32
Ich habe mir gerade Fakturama und den Connector für modified shop angeguckt. Eigentlich schon mal ganz gut soweit. (tu)(tu)
Mir ist gleich aufgefallen, dass der Connector nur in eine Richtung funktioniert und denke mir gerade, dass jetzt wo Fakturama sowieso auf eine externe Datenbank zugreifen kann, dies doch nicht so bleiben muss...
Was würde denn dagegen sprechen wenn das Datenbank-Layout von Fakturama kompatibel mit dem von einem Shopping-System (z.B. modified shop) wäre?
Man könnte dann mit Fakturama Artikel im Shop pflegen und nach dem Initialen Setup des Shops schon fast auf das Admin-Pannel verzichten.
4. Februar 2016 21:24
Dann würde ich mich aber an das DB-Layout eines Shops binden. Ich brauche aber ein Schema, was der Anwendung gerecht wird. Da denke ich, daß das vielleicht nicht ganz so geeignet wäre. Und so einen Konverter zu schreiben sollte schon machbar sein. moped kennt sich da bestens aus, da kann man schon was machen.
Viele Grüße
Ralf.
Wichtige Infos zum Posten im Forum.
Fehler gefunden?
Topic starter
5. Februar 2016 09:50
Dann würde ich mich aber an das DB-Layout eines Shops binden.
Dann wohl eher eine Synchronisation.
In Fakturama aber die Eingabemasken, welche für den/die Shop/s relevant sind.
Ich habe mir gerade ein Fork von Fakturama ( https://bitbucket.org/Aeronaut/fakturama-2) gemacht und arbeite mich die Tage mal rein.
Wer sich dieser Entwicklung anschließen möchte ist herzlich willkommen. (tu)
6. Februar 2016 00:34
Infos zu dieser ganzen Geschichte stehen auch im Wiki.
Viele Grüße
Ralf.
Wichtige Infos zum Posten im Forum.
Fehler gefunden?
Topic starter
6. Februar 2016 20:16
Ich bekomme die Entwicklungsumgebung gerade nicht zu laufen und glaube das liegt an zu langen Dateinamen bei den Abhängigkeiten...
Arbeitet ihr ebenfalls unter Windows oder unter Linux / MacOS?
7. Februar 2016 00:35
Ich entwickle das unter Windows. Bist Du nach der Anleitung im Wiki vorgegangen?
Viele Grüße
Ralf.
Wichtige Infos zum Posten im Forum.
Fehler gefunden?
Topic starter
9. Februar 2016 13:10
Ja, mehrmals... Ich habe dann versucht den alten Workspace von Eclipse zu löschen, als Windows dann meckerte, dass die Dateiname zu lang sind...
Im Moment meckert Eclipse:
The type org.apache.commons.logging.Log cannot be resolved.
Topic starter
10. Februar 2016 11:34
Also ich habe jetzt mehrmals den Workspace neu aufgebaut und jedesmal kommt ganz am ende:
The type org.apache.commons.logging.Log cannot be resolved.
Vermutlich zerschießt Eclipse den Workspace bei irgend einer Abhängigkeit, weil ein Datei-Pfad zu lang ist.
Eigentlich komme ich aus der MonoDevelop-C#-Ecke, da kommt mir dass ganze mit den Abhängigkeiten viel einfacher vor...
11. Februar 2016 20:53
Bist Du nach meiner Anleitung vorgegangen? Target-Umgebung gesetzt?
Viele Grüße
Ralf.
Wichtige Infos zum Posten im Forum.
Fehler gefunden?
Topic starter
11. Februar 2016 20:54
Ja.
11. Februar 2016 21:00
Dann verstehe ich es auch nicht. Die Länge der Dateinamen sollte eigentlich keine Rolle spielen. Und das angegebene Package verwende ich auch gar nicht.
Viele Grüße
Ralf.
Wichtige Infos zum Posten im Forum.
Fehler gefunden?
Topic starter
12. Februar 2016 20:54
Oky, der Fehler kommt erst, wenn ich die odftoolkit-0.6.1-incubating Lib hinzufüge...
Wenn ich das nicht mache, fehlt der Namespace org.odftoolkit.simple.Component (OfficeDocument.java)
Vielleicht habe ich das falsch gemacht??
12. Februar 2016 22:39
wo nimmst Du die denn her? Es muß die OSGi-Version verwendet werden, die steht hier: org.fakturama.print.openofficelibsimple-odf-0.8.2-incubating-SNAPSHOT-jar-with-dependencies.jar
Probier das mal.
Viele Grüße
Ralf.
Wichtige Infos zum Posten im Forum.
Fehler gefunden?