Hallo,
ich möchte demnächst zwei Projekte angehen. Ein kleineres zum Einstieg, ein großes danach und bräuchte Eure Hilfe:
Zum Umstieg von PHP auf Python habe ich mir die Aufgabe gestellt, eine Software zur Entscheidungsfindung mit Hilfe eines decision trees zu programmieren.
A byte of python habe ich gelesen und einige Codestücke ausprobiert.
Die Frage die sich mir stellt ist die nach den richtigen Werkzeugen, wobei ich mir schon gewisse Gedanken gemacht habe. Erst aber besser eine Beschreibung der Projekte:
Zum 1. Projekt:
Dazu benötige ich einen Baum, der mit jeder Entscheidung an einem Knoten um die möglichen Handlungsalternativen wächst. Dabei kann ein Knoten mehr als zwei Kinder haben - also kein binary tree.
Ich analysiere gerade den Quellcode von http://treeline.bellz.org und habe mir http://articles.sitepoint.com/article/h ... database/3 angesehen.
Dort wird die Nummerierung des Baumes anhand der Tree Traversale beschrieben, die ich gerne in Python nachprorammieren möchte. Dabei soll der Baum auf ein Liste abgebildet werden, die die Knotenobjekte enthält. Ein Knotenobjekt soll dabei die zwei "Identifikationsnummern", den Knotennamen etc. aufnehmen.
Auch einen XML Baum mittels element-tree habe ich in Erwägung gezogen - bin mir aber nicht schlüssig, ob mich das weiter bringt bzw. wie ich die Bäume später abspeichern möchte (in einer DB oder als XML).
Gibt es hier schon eine Klasse für Python die ich nicht gefunden habe und solche Bäume erzeugen kann?
Zum 2. Projekt:
Ich würde gerne eine Open Source Software für Anwaltskanzleien entwickeln. Ich bin mir im Klaren darüber, dass dies nicht innerhalb von zwei Wochen geht, aber in diesem Segment gibt es nichts wirklich brauchbares. Nun möchte ich das Projekt von Anfang an auf eine solide Basis stellen. Das heißt für mich in erster Linie Python. Meine Rahmenbedingungen die ich mir schon überlegt habe:
* Client - Server Architektur, da mehrere Nutzer im System arbeiten sollen. Client = Browser, d.h. der Anwender soll über einen Browser arbeiten.
* Client hat in jedem Fall OpenOffice installiert, wobei ich hier http://www.lucid-desktop.org/ im Auge behalten möchte, die für 2.0 auf Python umsteigen. Vielleicht gibt es ja dann OO im Browser. http://www.ulteo.com/home/en/home habe ich auch gesehen.
* Client läuft auf Linux. Kompatibilität mit Windows also zweitrangig. Nutzerzahl <= 50.
* Server läuft auf Linux in einem Netzwerk - abgesichert durch IPcop oder ähnliche OpenSource Produkte
* Speicherung der Daten in MySQL und Dateien (Schriftsätze, PDFs etc.) in Ordnerstruktur auf Server.
* Die Features der Software sind im Einzelnen erst einmal nicht wirklich wichtig. Beispielhaft seien Akten- und Mandantenverwaltung, gemeinsames Adressbuch, gemeinsamer Kalender etc. genannt. Wichtig wären mir folgende Dinge:
- Serverseitig soll später auf OCR (Tesseract/Ocropus) zugegriffen werden können, so das gescannte Dokumente in die Anwendung eingelesen und etwa durch Indizierung weiterverarbeitet werden. Weiterhin wäre in Zukunft eine Interaktion mit Asterisk und Faxserver denkbar. Auch eine Spracherkennung von http://cmusphinx.sourceforge.net sollte später vielleicht integrierbar sein.
- Interaktion des Serverprogramms mit den einzelnen OO Installationen auf den Clientrechnern (Beispiel: Client teilt Server mit, er möchte einen neuen Schriftsatz erstellen. Server weist OO auf Client an zu starten, ein Dokument zu öffnen und nach Bearbeitung wird es an den Server übermittelt, der es in einer zentralen Ordnerstruktur ablegt und die Dokumentendaten in die Datenbank übernimmt).
Welche Python Werkzeuge nehm' ich denn da am Besten dafür?
Serverseite:
-Zope (dann würde ich mir die dortige DB ansehen) - kann Zope mit System (OCR etc.) interagieren?
-Django (gefällt mir sehr) - ist zwar ein Webframework, aber spricht was dagegen das als "serverseitige" Basis-Lösung zu benutzen?
Würde gerne ein Ajax Framework für den Client verwenden, kann aber so gut wie kein JS. Pyjama http://pyjs.org/ würde mir - meine ich zumindest - sehr entgegenkommen.
Wie würdet Ihr das anstellen? Wäre ja gut, wenn ich in Projekt 1 lernen würde mit den Werkzeugen die ich im Projekt 2 verwende umzugehen - auch wenn diese dann vielleicht etwas überdimensioniert sind.
Grüße
Descartes
PS: Danke fürs Durchhalten bis hierher!
Zwei Projekte geplant - "Werkzeuge" für Python?
-
Leonidas
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Wieso nicht einfach die Kinder in einer Liste/Set verwalten?Descartes hat geschrieben:Dort wird die Nummerierung des Baumes anhand der Tree Traversale beschrieben, die ich gerne in Python nachprorammieren möchte. Dabei soll der Baum auf ein Liste abgebildet werden, die die Knotenobjekte enthält.
Oder JSON, pickle...Descartes hat geschrieben:Auch einen XML Baum mittels element-tree habe ich in Erwägung gezogen - bin mir aber nicht schlüssig, ob mich das weiter bringt bzw. wie ich die Bäume später abspeichern möchte (in einer DB oder als XML).
In der Stdlib eher nicht, vielleicht in PyPI. Aber sowas ist ja auch eher unüblich, normalerweise macht man die Bäume einfach als Node-Instanzen die über Referenzen verbunden sind.Descartes hat geschrieben:Gibt es hier schon eine Klasse für Python die ich nicht gefunden habe und solche Bäume erzeugen kann?
Warum MySQL?Descartes hat geschrieben:* Speicherung der Daten in MySQL und Dateien (Schriftsätze, PDFs etc.) in Ordnerstruktur auf Server.
Es kann mit allem arbeiten mit dem Python zurecht kommt. Aber für sowas würde ich eher einen großen Bogen um Zope machen.Descartes hat geschrieben:-Zope (dann würde ich mir die dortige DB ansehen) - kann Zope mit System (OCR etc.) interagieren?
Dann lerne JS. Daran führt momentan kaum ein Weg vorbei (GWT und Cappuchino überzeugen mich noch nicht) und eigentlich ist die Sprache auch ziemlich cool.Descartes hat geschrieben:Würde gerne ein Ajax Framework für den Client verwenden, kann aber so gut wie kein JS. Pyjama http://pyjs.org/ würde mir - meine ich zumindest - sehr entgegenkommen.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Meinst Du eine verschachtelte Liste? Ich hab in den letzten Tagen soviel über Bäume gelesen, dass ich aus dem Wald gar nicht mehr herausfinde. Vieles in der Art wie http://ais.informatik.uni-freiburg.de/t ... refVar.pdf - wobei dort nur binary-trees beschrieben werden und in solche kann man alle Bäume überführen. Ich fand diese Art der Nummerierung einfach elegant.Leonidas hat geschrieben:Wieso nicht einfach die Kinder in einer Liste/Set verwalten?Descartes hat geschrieben:Dort wird die Nummerierung des Baumes anhand der Tree Traversale beschrieben, die ich gerne in Python nachprorammieren möchte. Dabei soll der Baum auf ein Liste abgebildet werden, die die Knotenobjekte enthält.
Ja, mal sehen. Zunächst würde ich es gerne schaffen, einen Baum zu erzeugen und mit ihm zu arbeiten. Wie ich es dann ablege kommt auch ein wenig darauf an, wie es später verwendet werden soll. XML hätte wohl den Vorteil, dass ich es in andere Formate umwandeln kann.Leonidas hat geschrieben:Oder JSON, pickle...Descartes hat geschrieben:Auch einen XML Baum mittels element-tree habe ich in Erwägung gezogen - bin mir aber nicht schlüssig, ob mich das weiter bringt bzw. wie ich die Bäume später abspeichern möchte (in einer DB oder als XML).
Im PyPI hatte ich nichts gefunden. Lediglich das (Debian)Paket Django Treebeard scheint etwas in dieser Richtung anzubieten - besser ist es aber wohl, wenn ich mich (zu Übungszwecken) selbst darum kümmere, denn irgendwo habe ich gelesen, dass Bäume "Brot und Butter" für Programmierer wären.Leonidas hat geschrieben:In der Stdlib eher nicht, vielleicht in PyPI. Aber sowas ist ja auch eher unüblich, normalerweise macht man die Bäume einfach als Node-Instanzen die über Referenzen verbunden sind.Descartes hat geschrieben:Gibt es hier schon eine Klasse für Python die ich nicht gefunden habe und solche Bäume erzeugen kann?
Zunächst die ganz einfache Antwort: Ich kenne die DB von PHP her. Eine FlatfileDB kommt bei der anfallenden Datenmenge wohl einfach nicht in Betracht. SQLlite ist nicht für solche sondern eher für "embedded" Projekte gemacht. MySQL kann auf einem extra Server laufen und ist nach meiner Erfahrung auch stabil. Das einzige was ich mir noch nicht genauer angesehen habe ist PostgreSQL. Meinst Du letztere hätte Vorteile oder an welche Art der Speicherung hattest Du gedacht?Leonidas hat geschrieben:Warum MySQL?Descartes hat geschrieben:* Speicherung der Daten in MySQL und Dateien (Schriftsätze, PDFs etc.) in Ordnerstruktur auf Server.
Danke! Damit werde ich Zope / Grok aus meiner Liste streichenLeonidas hat geschrieben:Es kann mit allem arbeiten mit dem Python zurecht kommt. Aber für sowas würde ich eher einen großen Bogen um Zope machen.Descartes hat geschrieben:-Zope (dann würde ich mir die dortige DB ansehen) - kann Zope mit System (OCR etc.) interagieren?
Mein Bauch tendierte auch eher zu Django.
Eigentlich dachte ich "nur" an ein paar "Aufhübschungen" der Clientseitigen Anzeige (Klare Struktur, ausblenden momentan unwesentlicher Elemente) und hatte mir hierzu MochiKit / jquery / script.aculo.us i.V.m. Prototype / Pyjama angesehen. Die beiden von Dir genannten hatte ich gar nicht auf dem Schirm. Warum überzeugen diese Dich noch nicht? Was müssten diese zwei noch bieten um Dich zu überzeugen?Leonidas hat geschrieben:Dann lerne JS. Daran führt momentan kaum ein Weg vorbei (GWT und Cappuchino überzeugen mich noch nicht) und eigentlich ist die Sprache auch ziemlich cool.Descartes hat geschrieben:Würde gerne ein Ajax Framework für den Client verwenden, kann aber so gut wie kein JS. Pyjama http://pyjs.org/ würde mir - meine ich zumindest - sehr entgegenkommen.
Grüße
Descartes
-
Sr4l
- User
- Beiträge: 1091
- Registriert: Donnerstag 28. Dezember 2006, 20:02
- Wohnort: Kassel
- Kontaktdaten:
Guck dir mal SqlAlchemy ( http://www.sqlalchemy.org/ ) an.
Ansonsten kannst du dich mal durch die Liste lesen http://wiki.python.org/moin/WebFrameworks . Von Zope würde ich auch Abstand halten, ich selber nutze gerne Werkzeug, aber Django ist auch ein gute Wahl.
Ansonsten kannst du dich mal durch die Liste lesen http://wiki.python.org/moin/WebFrameworks . Von Zope würde ich auch Abstand halten, ich selber nutze gerne Werkzeug, aber Django ist auch ein gute Wahl.
-
Leonidas
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Nein, ich meine ein Set:Descartes hat geschrieben:Meinst Du eine verschachtelte Liste? Ich hab in den letzten Tagen soviel über Bäume gelesen, dass ich aus dem Wald gar nicht mehr herausfinde. Vieles in der Art wie http://ais.informatik.uni-freiburg.de/t ... refVar.pdf - wobei dort nur binary-trees beschrieben werden und in solche kann man alle Bäume überführen. Ich fand diese Art der Nummerierung einfach elegant.Leonidas hat geschrieben:Wieso nicht einfach die Kinder in einer Liste/Set verwalten?
Code: Alles auswählen
class Node(object):
def __init__(self, *nodes):
self.children = set(nodes)PostgreSQL oder SQLite (das kommt lt. gerold mit erstaunlich großen Datenmengen sehr schnell zurecht) oder irgendeine Key-Value-Datenbank (Tokyo Cabinet kommt mit bis zu 8EB = 8192 Petabyte zurecht - das sollte wohl fürs erste reichen) wären so die ersten Sachen die mir einfallen würden.Descartes hat geschrieben:Zunächst die ganz einfache Antwort: Ich kenne die DB von PHP her. Eine FlatfileDB kommt bei der anfallenden Datenmenge wohl einfach nicht in Betracht. SQLlite ist nicht für solche sondern eher für "embedded" Projekte gemacht. MySQL kann auf einem extra Server laufen und ist nach meiner Erfahrung auch stabil. Das einzige was ich mir noch nicht genauer angesehen habe ist PostgreSQL. Meinst Du letztere hätte Vorteile oder an welche Art der Speicherung hattest Du gedacht?Leonidas hat geschrieben:Warum MySQL?Descartes hat geschrieben:* Speicherung der Daten in MySQL und Dateien (Schriftsätze, PDFs etc.) in Ordnerstruktur auf Server.
GWT und Cappucino kompilieren zu JS bzw. sind neue Sprachen die auf JS aufsetzen (im Fall von GWT ist dies Java, bei Cappucino ist das eine von Objective-C inspirierte Sprache namens Objective-J). Ich finde das ist gerade bei diesem kleinen Usecase wie mit Kanonen auf Spatzen schießen und außerdem schreib ich persönlich lieber JavaScript als Java. Ich seh schon, gleich kommt sma vorbei und behauptet das Gegenteil - das ist wohl etwas, wo wir in nächster Zeit wohl zu keiner Übereinstimmung kommen werdenDescartes hat geschrieben:Eigentlich dachte ich "nur" an ein paar "Aufhübschungen" der Clientseitigen Anzeige (Klare Struktur, ausblenden momentan unwesentlicher Elemente) und hatte mir hierzu MochiKit / jquery / script.aculo.us i.V.m. Prototype / Pyjama angesehen. Die beiden von Dir genannten hatte ich gar nicht auf dem Schirm. Warum überzeugen diese Dich noch nicht? Was müssten diese zwei noch bieten um Dich zu überzeugen?Leonidas hat geschrieben:Dann lerne JS. Daran führt momentan kaum ein Weg vorbei (GWT und Cappuchino überzeugen mich noch nicht) und eigentlich ist die Sprache auch ziemlich cool.Descartes hat geschrieben:Würde gerne ein Ajax Framework für den Client verwenden, kann aber so gut wie kein JS. Pyjama http://pyjs.org/ würde mir - meine ich zumindest - sehr entgegenkommen.
MochiKit kann man inzwischen aber ziemlich knicken. Prototype mochte ich auch nie so richtig gut und inzwischen wurde es auch ziemlich stark von jQuery überholt, eigentlich in jeder Hinsicht.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
-
problembär
Hallo,
also, erstmal finde ich Deine Themenüberschrift unglücklich, d.h. zu wenig aussagekräftig.
http://kumula.sourceforge.net/
http://canzeley.de/
Tatsächlich hab' ich für meine Einzelkanzlei das in Python geschrieben, was ich konkret brauche:
- Gebührenprogramm mit Textverarbeitungsanbindung
- win32com von Beteiligten-Datenbank (Lotus Approach) zu Textverarbeitung (MS Word).
- Buchführung (E/Ü-Rechnung) in Python in Verbindung mit Word; kein eigenes GUI, daher nicht allgemein benutzbar. (Andere haben für sowas das gemacht.)
- An einer Offline-Lösung für Mahnanträge bin ich dran, aber es ist leider sehr umfangreich, und die Online-Seite reicht doch für mich in den meisten Fällen.
Als kleine Demo meiner Sachen mal mwst.py, das ich wirklich häufig benutze (mit der Darstellung dort scheint was nicht in Ordnung zu sein; hab' nicht so viele Absätze gemacht, sollte aber laufen).
Ist schon komisch, daß ich ein so primitives Programm wirklich gut gebrauchen kann, während größere für einen Anwalt manchmal weniger bringen.
Na ja, viel Glück, und schreib doch mal, wie es so damit vorangeht.
Gruß
also, erstmal finde ich Deine Themenüberschrift unglücklich, d.h. zu wenig aussagekräftig.
Kann man so sehen. Obwohl es immer wieder versucht wird:Descartes hat geschrieben:Ich würde gerne eine Open Source Software für Anwaltskanzleien entwickeln. Ich bin mir im Klaren darüber, dass dies nicht innerhalb von zwei Wochen geht, aber in diesem Segment gibt es nichts wirklich brauchbares.
http://kumula.sourceforge.net/
http://canzeley.de/
Tatsächlich hab' ich für meine Einzelkanzlei das in Python geschrieben, was ich konkret brauche:
- Gebührenprogramm mit Textverarbeitungsanbindung
- win32com von Beteiligten-Datenbank (Lotus Approach) zu Textverarbeitung (MS Word).
- Buchführung (E/Ü-Rechnung) in Python in Verbindung mit Word; kein eigenes GUI, daher nicht allgemein benutzbar. (Andere haben für sowas das gemacht.)
- An einer Offline-Lösung für Mahnanträge bin ich dran, aber es ist leider sehr umfangreich, und die Online-Seite reicht doch für mich in den meisten Fällen.
Als kleine Demo meiner Sachen mal mwst.py, das ich wirklich häufig benutze (mit der Darstellung dort scheint was nicht in Ordnung zu sein; hab' nicht so viele Absätze gemacht, sollte aber laufen).
Ist schon komisch, daß ich ein so primitives Programm wirklich gut gebrauchen kann, während größere für einen Anwalt manchmal weniger bringen.
Man kann OOo ja z.B. auch mit PyUno steuern.* Client hat in jedem Fall OpenOffice installiert, wobei ich hier http://www.lucid-desktop.org/ im Auge behalten möchte, die für 2.0 auf Python umsteigen.
Tja, sehr die Frage, ob man sowas (nochmal) in Python selbst schreiben will, wo es doch "kontact" usw. schon gibt.* Die Features der Software sind im Einzelnen erst einmal nicht wirklich wichtig. Beispielhaft seien Akten- und Mandantenverwaltung, gemeinsames Adressbuch, gemeinsamer Kalender etc. genannt.
Tut mir leid, aber hast Du schonmal versucht, Sphinx zu trainieren? Das geht nicht. Ich kenne niemanden, der es schafft, Sphinx (II, III, IV) für mehr als ein paar Steuerkommandos zu benutzen, einschließlich der Entwickler von xvoice.Auch eine Spracherkennung von http://cmusphinx.sourceforge.net sollte später vielleicht integrierbar sein.
Na ja, viel Glück, und schreib doch mal, wie es so damit vorangeht.
Gruß
Hallo,
zunächst einmal vielen Dank für Eure Vorschläge. Ich habe mir alle durchgesehen und denke ich werde es mit Django, MySQL, Pyjama (mal sehen wie es läuft - ich finde die Idee einfach schön), Elixir (http://elixir.ematia.de/trac/) und spiff-guard (http://code.google.com/p/spiff-guard/) versuchen.
Werkzeug scheint mir sehr flexibel zu sein, aber ich denke zum Anfang wäre es besser eine etwas mehr in Richtung "All-in-One" Lösung zu gehen.
Bei den Datenbanken habe ich nicht wirklich einen großen Unterschied zwischen PostgreSQL und MySQL ausmachen können. Bei Geschwindigkeit und Stabilität hat mal die eine, mal die andere die Nase vorn. Features werden von PostgreSQL wohl ein paar mehr als von MySQL unterstützt und beide Unterscheiden sich in der Lizenz. Letzteres spielt aber bei meinem Projekt keine Rolle, da es sowieso frei zur Verfügung stehen wird.
Den Ausschlag für MySQL gab vor allem die Überlegung, dass ich diese DB kenne und für die Wartung in Kanzleien oftmals die ortsansässigen IT-Dienstleister zuständig sind. Ich meine (persönliche Ansicht), dass bei diesen MySQL bekannter als PostgreSQL ist und diese Leute damit vielleicht noch einen Tick besser zurecht kommen, wenn es Probleme gibt.
SQLAlchemy zu benutzen scheint mir ein wirklicher Vorteil zu sein, wobei ich Elixir verwenden möchte, da die Syntax einfacher zu sein scheint.
Pyjama als GWT Port - wie gesagt, ich finde die Idee einfach gut und werde sehen wie es so läuft.
Danke an Leonidas für die Starthilfe bei der Baum Geschichte. Ich werde mich jetzt daran versuchen und die Ergebnisse (dann besser in einem neuen Thread) präsentieren
@problembär
Ja, Du hast recht, der Titel war tatsächlich wenig aussagekräftig. Ich wollte mich allerdings nicht schon gleich zu Anfang extrem weit aus dem Fenster lehnen und irgendwelche Versprechungen machen (a la "Ich revolutioniere den Softwaremarkt für Anwälte"). Erst einmal werde ich den Entscheidungsbaum implementieren und dann gehe ich die Kanzleisoftware an. Wie gesagt ist das sicher eine sehr langfristige Angelegenheit, weswegen ich nicht gleich mit dem falschen Fundament anfangen wollte. Python ist so reich an Schnittstellen, Modulen etc., dass es zu Anfang schwer ist sich einen Überblick zu verschaffen.
Bei der freien Kanzleisoftware wäre noch http://sourceforge.net/projects/openlawyers/ zu nennen - dann aber sind wir (m.E.) komplett. Als Fazit kann man sagen, dass keine der Lösungen wirklich einer kommerziellen Version das Wasser reichen kann, wobei für Einzelanwälte und kleine Kanzleien vielleicht noch eine echte Lösung.
Die OOo E/Ü kannte ich und verwende Sie selbst für meine Nebentätigkeit.
Die Schnittstelle für EGVP (http://www.egvp.de/) ist bei mir auf dem Schirm, hat aber nicht die oberste Priorität - gerade weil es ja noch den Onlineweg gibt.
Für die OOo Anbindung habe ich noch das python-openoffice Paket unter Debian ausfindig gemacht - den Unterschied zwischen beiden muss ich mir erst noch ansehen.
Du hast vollkommen recht; für Spracherkennung i.S.v. Sprache zu Text gibt es nicht viel bzw. nichts unter Linux und nichts was tatsächlich einsatzfähig wäre. Das Projekt http://www.voxforge.org/ macht mir da ein wenig Hoffnung, dass sich das im Laufe der Zeit weiterentwickelt.
Für OCR mit Tesseract / Ocropus / CuneiForm sehe ich eine Entwicklung hin zu einer wirklichen Alternative zu kommerziellen Programmen (Abbeyy), falls sie das nicht schon sind.
Ist Kontact in der Lage ein gemeinsames Adressbuch und Kalender auf einem zentralen Server zu verwalten? Sobald mehrere Anwälte in der Kanzlei sind, ist es doch sinnvoll diese Daten gemeinsam und zentral zu verwalten. Die schönste Lösung die ich hier gefunden hatte war http://www.open-xchange.com, dessen Lizenzmodell aber nicht geeignet ist.
Ich werde jetzt mal versuchen einen Anfang zu machen und würde Dir dann Bescheid geben - vielleicht hast Du ja Lust dann das eine oder andere (evt. von Deinen schon für Dich umgesetzten Programmen) zu dem Projekt beizutragen - ich würde mich sehr über Mitstreiter freuen!
Viele Grüße
Descartes
zunächst einmal vielen Dank für Eure Vorschläge. Ich habe mir alle durchgesehen und denke ich werde es mit Django, MySQL, Pyjama (mal sehen wie es läuft - ich finde die Idee einfach schön), Elixir (http://elixir.ematia.de/trac/) und spiff-guard (http://code.google.com/p/spiff-guard/) versuchen.
Werkzeug scheint mir sehr flexibel zu sein, aber ich denke zum Anfang wäre es besser eine etwas mehr in Richtung "All-in-One" Lösung zu gehen.
Bei den Datenbanken habe ich nicht wirklich einen großen Unterschied zwischen PostgreSQL und MySQL ausmachen können. Bei Geschwindigkeit und Stabilität hat mal die eine, mal die andere die Nase vorn. Features werden von PostgreSQL wohl ein paar mehr als von MySQL unterstützt und beide Unterscheiden sich in der Lizenz. Letzteres spielt aber bei meinem Projekt keine Rolle, da es sowieso frei zur Verfügung stehen wird.
Den Ausschlag für MySQL gab vor allem die Überlegung, dass ich diese DB kenne und für die Wartung in Kanzleien oftmals die ortsansässigen IT-Dienstleister zuständig sind. Ich meine (persönliche Ansicht), dass bei diesen MySQL bekannter als PostgreSQL ist und diese Leute damit vielleicht noch einen Tick besser zurecht kommen, wenn es Probleme gibt.
SQLAlchemy zu benutzen scheint mir ein wirklicher Vorteil zu sein, wobei ich Elixir verwenden möchte, da die Syntax einfacher zu sein scheint.
Pyjama als GWT Port - wie gesagt, ich finde die Idee einfach gut und werde sehen wie es so läuft.
Danke an Leonidas für die Starthilfe bei der Baum Geschichte. Ich werde mich jetzt daran versuchen und die Ergebnisse (dann besser in einem neuen Thread) präsentieren
@problembär
Ja, Du hast recht, der Titel war tatsächlich wenig aussagekräftig. Ich wollte mich allerdings nicht schon gleich zu Anfang extrem weit aus dem Fenster lehnen und irgendwelche Versprechungen machen (a la "Ich revolutioniere den Softwaremarkt für Anwälte"). Erst einmal werde ich den Entscheidungsbaum implementieren und dann gehe ich die Kanzleisoftware an. Wie gesagt ist das sicher eine sehr langfristige Angelegenheit, weswegen ich nicht gleich mit dem falschen Fundament anfangen wollte. Python ist so reich an Schnittstellen, Modulen etc., dass es zu Anfang schwer ist sich einen Überblick zu verschaffen.
Bei der freien Kanzleisoftware wäre noch http://sourceforge.net/projects/openlawyers/ zu nennen - dann aber sind wir (m.E.) komplett. Als Fazit kann man sagen, dass keine der Lösungen wirklich einer kommerziellen Version das Wasser reichen kann, wobei für Einzelanwälte und kleine Kanzleien vielleicht noch eine echte Lösung.
Die OOo E/Ü kannte ich und verwende Sie selbst für meine Nebentätigkeit.
Die Schnittstelle für EGVP (http://www.egvp.de/) ist bei mir auf dem Schirm, hat aber nicht die oberste Priorität - gerade weil es ja noch den Onlineweg gibt.
Für die OOo Anbindung habe ich noch das python-openoffice Paket unter Debian ausfindig gemacht - den Unterschied zwischen beiden muss ich mir erst noch ansehen.
Du hast vollkommen recht; für Spracherkennung i.S.v. Sprache zu Text gibt es nicht viel bzw. nichts unter Linux und nichts was tatsächlich einsatzfähig wäre. Das Projekt http://www.voxforge.org/ macht mir da ein wenig Hoffnung, dass sich das im Laufe der Zeit weiterentwickelt.
Für OCR mit Tesseract / Ocropus / CuneiForm sehe ich eine Entwicklung hin zu einer wirklichen Alternative zu kommerziellen Programmen (Abbeyy), falls sie das nicht schon sind.
Ist Kontact in der Lage ein gemeinsames Adressbuch und Kalender auf einem zentralen Server zu verwalten? Sobald mehrere Anwälte in der Kanzlei sind, ist es doch sinnvoll diese Daten gemeinsam und zentral zu verwalten. Die schönste Lösung die ich hier gefunden hatte war http://www.open-xchange.com, dessen Lizenzmodell aber nicht geeignet ist.
Ich werde jetzt mal versuchen einen Anfang zu machen und würde Dir dann Bescheid geben - vielleicht hast Du ja Lust dann das eine oder andere (evt. von Deinen schon für Dich umgesetzten Programmen) zu dem Projekt beizutragen - ich würde mich sehr über Mitstreiter freuen!
Viele Grüße
Descartes
Wenn du Elixir verwendest fallen dir die meisten Stärken von Django weg, dann kannst gleich Werkzeug verwenden. Abgesehen davon find ich Elixir eher unnötig, imho kann SA-declarative das alles auch schon…Descartes hat geschrieben: zunächst einmal vielen Dank für Eure Vorschläge. Ich habe mir alle durchgesehen und denke ich werde es mit Django, MySQL, Pyjama (mal sehen wie es läuft - ich finde die Idee einfach schön), Elixir (http://elixir.ematia.de/trac/) und spiff-guard (http://code.google.com/p/spiff-guard/) versuchen.
Hallo,
O.K., zwar ist die SA Seite gerade nicht erreichbar, aber dann versuche ich es ausschließlich mit SA - ich dachte Elixir sei eine reine Vereinfachung der Syntax von SA, die nur von bestimmten Features keinen Gebrauch macht. Jedoch ist eine Komponente weniger wahrscheinlich auch besser bezüglich der Fehleranfälligkeit.
Danke dafür!
Grüße
Descartes
O.K., zwar ist die SA Seite gerade nicht erreichbar, aber dann versuche ich es ausschließlich mit SA - ich dachte Elixir sei eine reine Vereinfachung der Syntax von SA, die nur von bestimmten Features keinen Gebrauch macht. Jedoch ist eine Komponente weniger wahrscheinlich auch besser bezüglich der Fehleranfälligkeit.
Danke dafür!
Grüße
Descartes
-
Käptn Haddock
- User
- Beiträge: 169
- Registriert: Freitag 24. März 2006, 14:27
Hallo!
Interressante und sehr ambitionierte Projekte. Zur Zeit plane ich ähnliches im Geodatenbereich und habe eine ähnliche Zusammensetzung der Tools gewählt. Mit Ausnahme MySQL, das ist mir viel zu unsicher und anfällig im professionellen Einsatz. IMHO sagt die Verbreitung von MySQL nichts über dessen Qualität aus, es ist halt bei vielen Hostern verfügbar und wird meist als Datenhalde für Webseiten eingesetzt. Mit Postgres spart man sich einige Probleme, die man mit MySQL erst hat, selbst wenns dafür mehr Support gibt. PostgreSQL skaliert auch weit besser im oberen Leisungsbereich und bietet IMHO eine stabilere Plattform, von PostGIS gar nicht zu reden. Ich administriere im übrigen mehrere PostgreSQL-Server mit ca. 300 GB Geodaten
und hatte auch mal die Wahl zwischen Postgres und MySQL. Letztlich ist es aber eine Frage der Anforderungen, die das Projekt stellt und der Ressourcen die zur Verfügung stehen.
Aber das war eigentlich gar nicht was ich schreiben wollte. Vielmehr wollte ich dich darauf hinweisen, das du ein Geschäftsmodell brauchst, wenn du wirklich Leute davon überzeugen willst deine SW einzusetzen, selbst und _gerade_ wenn_ es Opensource sein soll. Meiner Erfahrung nach scheitern Projekte seltener an technischem Versagen oder fehlendem Einsatz sondern an der kompletten Fehleinschätzung der kaufmännischen Möglichkeiten und fehlender Brachenkenntnis. Du musst genau analysieren was der Bedarf ist, du mußt die gängigen Schnittstellen im Bussiness-Bereich wie z.B. Outlook oder zu gängiger SW implementieren, denn niemand schmeisst sein Kontakte oder Nutzdaten weg, nur weil er jetzt OSS einsetzen will. Du kannst im OSS-Berich nur Einnahmen über Entwicklung und Support erzielen, das muß genau kalkuliert werden, auch der Aufbau und Erhalt einer Community, die die SW nutzt. Zu unterschätzen ist auch nicht der Aufwand, eine Entwicklergemeinde zu orchestrieren, bzw ein Prjekt zu organisieren. Selbst wenn du nicht davon leben oder gar reich werden willst, solltest du diese Dinge beachten, wenn das Projekt erfolgreich sein soll. Als potentiell Selbstständiger überschätzt man sich leicht, das muß nicht sein. Aber abschrecken oder entmutigen soll dich das auch nicht, sondern nur etwas zum Denken anregen
Viele Grüsse
Uwe
Interressante und sehr ambitionierte Projekte. Zur Zeit plane ich ähnliches im Geodatenbereich und habe eine ähnliche Zusammensetzung der Tools gewählt. Mit Ausnahme MySQL, das ist mir viel zu unsicher und anfällig im professionellen Einsatz. IMHO sagt die Verbreitung von MySQL nichts über dessen Qualität aus, es ist halt bei vielen Hostern verfügbar und wird meist als Datenhalde für Webseiten eingesetzt. Mit Postgres spart man sich einige Probleme, die man mit MySQL erst hat, selbst wenns dafür mehr Support gibt. PostgreSQL skaliert auch weit besser im oberen Leisungsbereich und bietet IMHO eine stabilere Plattform, von PostGIS gar nicht zu reden. Ich administriere im übrigen mehrere PostgreSQL-Server mit ca. 300 GB Geodaten
und hatte auch mal die Wahl zwischen Postgres und MySQL. Letztlich ist es aber eine Frage der Anforderungen, die das Projekt stellt und der Ressourcen die zur Verfügung stehen.Aber das war eigentlich gar nicht was ich schreiben wollte
. Vielmehr wollte ich dich darauf hinweisen, das du ein Geschäftsmodell brauchst, wenn du wirklich Leute davon überzeugen willst deine SW einzusetzen, selbst und _gerade_ wenn_ es Opensource sein soll. Meiner Erfahrung nach scheitern Projekte seltener an technischem Versagen oder fehlendem Einsatz sondern an der kompletten Fehleinschätzung der kaufmännischen Möglichkeiten und fehlender Brachenkenntnis. Du musst genau analysieren was der Bedarf ist, du mußt die gängigen Schnittstellen im Bussiness-Bereich wie z.B. Outlook oder zu gängiger SW implementieren, denn niemand schmeisst sein Kontakte oder Nutzdaten weg, nur weil er jetzt OSS einsetzen will. Du kannst im OSS-Berich nur Einnahmen über Entwicklung und Support erzielen, das muß genau kalkuliert werden, auch der Aufbau und Erhalt einer Community, die die SW nutzt. Zu unterschätzen ist auch nicht der Aufwand, eine Entwicklergemeinde zu orchestrieren, bzw ein Prjekt zu organisieren. Selbst wenn du nicht davon leben oder gar reich werden willst, solltest du diese Dinge beachten, wenn das Projekt erfolgreich sein soll. Als potentiell Selbstständiger überschätzt man sich leicht, das muß nicht sein. Aber abschrecken oder entmutigen soll dich das auch nicht, sondern nur etwas zum Denken anregen Viele Grüsse
Uwe
---------------------------------
have a lot of fun!
have a lot of fun!
Nagut, dann erfülle ich mal meine Pflicht.Leonidas hat geschrieben:GWT und Cappucino kompilieren zu JS bzw. sind neue Sprachen die auf JS aufsetzen (im Fall von GWT ist dies Java, bei Cappucino ist das eine von Objective-C inspirierte Sprache namens Objective-J). Ich finde das ist gerade bei diesem kleinen Usecase wie mit Kanonen auf Spatzen schießen und außerdem schreib ich persönlich lieber JavaScript als Java. Ich seh schon, gleich kommt sma vorbei und behauptet das Gegenteil
GWT lohnt, wenn man Java beherrscht und insbesondere den gesamten Entwicklungsprozess auf die Java-Welt abgestellt hat (Ant, Maven, JUnit, Hudson, Nexus, Sonar, usw.) GWT ist jedoch (trotz des Namens) kein Widget-Toolkit, sondern "nur" ein hervorragender Compiler von Java in extrem optimiertes JavaScript. GXT (von Ext) ist ein Enterprise-kompatibles Widget-Toolkit das gut mit GWT zusammenarbeitet. Eine Alternativen wären Smartclient oder Qooxdoo.
Da ich mich zur Zeit beruflich mit Objective-C und iPhone/iPad-Entwicklung beschäftige, ist auf einmal auch Cappucino interessant für mich. Cocoa ist ein gutes UI-Toolkit mit hohem Abstraktionsgrad und Objective-C bzw. Objective-J (im Vergleich zu C++) eine "echte" objektorientierte Programmiersprache, die Spass macht.
Ich denke, es geht nicht so sehr darum, welche Programmiersprache nun gut ist (JavaScript ist in der Tat eine schicke Sprache - kein Widerspruch hier) sondern wie einfach kann ich auch komplexe Eingabeformulare und die üblichen tabellenlastigen Master-Detail-Views bauen.
Für das geplante Kanzlei-Projekt würde ich auf ein Browser-basiertes Frontend bzw. wenigstens auf eine Browser-basierte Auslieferung setzen. Alle UIs direkt mit HTML zu bauen erscheint mir jedoch zu primitiv. Genau hier können mächtigere Rahmenwerke (um den Preis der höheren Einarbeitungszeit) wie GXT oder Cappuccino (was man wahrscheinlich nur als Mac-Entwickler gut findet) ihre Stärken ausspielen.
Mir erscheinen für das Frontend noch zwei weitere Technologien interessant: Silverlight und Flash mit Flex. Flex ist sehr gutes UI-Rahmenwerk speziell für Business-Anwendungen. Flex-UIs kann man geschätzt 4x schneller bauen als vergleichbare UIs nur mit HTML. Zusätzlich gibt es von Adobe mächtige Werkzeuge nicht nur für Entwickler sondern auch für UX/IxD-Leute. Mag sein, dass das für ein OS-Projekt, das kein Geld hat, keine so große Rolle spielt. Silverlight ist zwar von Microsoft und bislang deutlich Flash/Flex unterlegen, aber Microsoft wäre nicht Micrsoft wenn sie nicht Vorsprünge aufholen könnten und letztlich sogar vorbeiziehen würden. Das UI-Rahmenwerk von SL3 ist inzwischen recht fortgeschritten und spannend finde ich, dass man Anwendungen nicht nur in C# sondern auch Ruby oder Python bauen kann. Daher wäre es durchaus im Rahmen eines Python-Projekts interessant.
Wenn man das Frontend unbedingt selbst mit HTML und JS bauen will, empfehle ich wenigstens einen Blick auf SproutCore, was ein Data-Binding (welches bei Flex standard ist und glaube ich bei Silverlight und Cappuccino ebenfalls möglich ist und allgemein der große Zeitsparer im Vergleich zu "herkömmlicher Programmierung ist) a la Objective-C KVO erlaubt.
Was fällt mir noch ein: Für mobile Endgeräte finde ich Titanium sehr interessant. Davon gibt es auch eine Desktop-Variante. Wie Adobe AIR erlaubt diese, basierend auf einem Browser-Widget Desktop-Anwendungen mit den bekannten Web-Technologien zu bauen. Das kann einfacher sein als klassisches Swing oder Tk oder WX oder WinForms oder was es da für Rahmenwerke aus dem letzten Jahrtausend so gibt. Zu beachten ist aber was ich oben gesagt habe: Wird es Formularzentrisch, sind HTML-Form IMHO ungenügend. Aber AIR bzw. Titanium erlauben ja auch die anderen erwähnten Technologien außer Silverlight. Und für Titanium gegenüber AIR spräche nicht nur, dass es Opensource ist, sondern das man auch Ruby oder Python statt JavaScript benutzen kann.
Stefan
-
problembär
Wenn man ohnehin OpenOffice voraussetzt, fragt sich eigentlich, warum man nicht direkt in OpenOffice-Basic schreibt (wie Canzeley usw.). Problem ist:
- Reichlich langsam,
- Bedienelemente sehen häßlich aus,
- Code nicht portabel, manchmal auch nicht zu neueren OpenOffice-Versionen (so daß er bei vielen nicht läuft, die eine auch nur leicht abweichende OpenOffice-Version haben (canzeley läuft z.B. bei mir nicht vollständig)), siehe z.B. auch das Kuddelmuddel unter "Voraussetzungen",
- Zum Schreiben wird man quasi gezwungen, den mitgelieferten Editor/IDE in OpenOffice zu verwenden.
Python und OpenOffice zusammen ist aber irgendwie noch weniger aus einem Stück.
Für wieviele Anwälte soll das eigentlich sein, das heißt, wie groß ist eure Kanzlei?
Ich alleine brauche natürlich keine Groupware.
Meist ist man am besten motiviert, das zu schreiben, was man selbst auch braucht.
Gruß
- Reichlich langsam,
- Bedienelemente sehen häßlich aus,
- Code nicht portabel, manchmal auch nicht zu neueren OpenOffice-Versionen (so daß er bei vielen nicht läuft, die eine auch nur leicht abweichende OpenOffice-Version haben (canzeley läuft z.B. bei mir nicht vollständig)), siehe z.B. auch das Kuddelmuddel unter "Voraussetzungen",
- Zum Schreiben wird man quasi gezwungen, den mitgelieferten Editor/IDE in OpenOffice zu verwenden.
Python und OpenOffice zusammen ist aber irgendwie noch weniger aus einem Stück.
Für wieviele Anwälte soll das eigentlich sein, das heißt, wie groß ist eure Kanzlei?
Ich alleine brauche natürlich keine Groupware.
Meist ist man am besten motiviert, das zu schreiben, was man selbst auch braucht.
Gruß
Hallo,
entschuldigt die späte Antwort, aber Familienfeste und Arbeit fordern Ihren Tribut.
1. Online Office Lösungen wie die unter http://wolkoholic.net/2009/05/online-of ... en-im-web/ beschriebenen kommen aufgrund der Datensensibilität nicht in Betracht.
2. Eine gute Installation solcher zentralen Textverarbeitungen auf einem zentralen Server im Intranet ist mir nicht bekannt.
3. Selbst wenn es eine solche gäbe, so wird der Server dadurch belastet. OO auf jedem Client macht deshalb IMHO Sinn, auch wenn die Wartung (Einspielen von Updates auf jedem Client) vielleicht etwas aufwendiger ist.
@Käptn Haddock:
Vielen Dank für Deine Hinweise. Viele hier - einschließlich Dir - scheinen PostgreSQL den Vorzug vor MySQL zu geben - so auch schon Leonidas in seinem Beitrag. Ich werde das noch einmal überdenken, denn gerade diese Erfahrungen / Empfehlungen wollte ich ja hören. Wäre schlecht diese dann zu ignorieren
Die Software soll nicht meinen Lebensunterhalt sichern. Wenn sie was dazu beiträgt ist es schön, wenn nicht ist es egal. Bis dieses Projekt mit den derzeit erhältlichen komerziellen Varianten mithalten kann, dürften ein paar lange Monate, eher ein Jahr oder mehr ins Land gehen. Aber jemand muss den Anfang machen ... Kanzleien werden nicht so einfach von Ihrem bestehenden System umsteigen. Ich meine eher, dass angehende Anwälte bzw. Kanzleineugründer auf diese Software setzen werden, wenn diese einmal gewisse Grundanforderungen erfüllt. Schnittstellen stehen auf der Roadmap, aber welche genau und wann diese implementiert werden, wird sich zeigen. Die kaufmännische Sichtweise, daher anbieten von Support, Installation u.ä. hatte ich jetzt weniger im Blick, aber über eine aktive Community freut sich ja jedes Projekt.
@sma:
Erst einmal Danke für die Hinweise. Ich muss sie mir aber erst mal näher ansehen, um etwas dazu sagen zu können.
Grüße
Descartes
entschuldigt die späte Antwort, aber Familienfeste und Arbeit fordern Ihren Tribut.
Na, das sind ja schon einige gute Gründeproblembär hat geschrieben:Wenn man ohnehin OpenOffice voraussetzt, fragt sich eigentlich, warum man nicht direkt in OpenOffice-Basic schreibt (wie Canzeley usw.). Problem ist:
- Reichlich langsam,
- Bedienelemente sehen häßlich aus,
- Code nicht portabel, manchmal auch nicht zu neueren OpenOffice-Versionen (so daß er bei vielen nicht läuft, die eine auch nur leicht abweichende OpenOffice-Version haben (canzeley läuft z.B. bei mir nicht vollständig)), siehe z.B. auch das Kuddelmuddel unter "Voraussetzungen",
- Zum Schreiben wird man quasi gezwungen, den mitgelieferten Editor/IDE in OpenOffice zu verwenden.
Finde ich jetzt gar nicht, den OO - im Speziellen der "Writer" - soll bei dieser Anwendung nur seine ureigenste Aufgabe erledigen. Textverarbeitung. Die Verwaltung der Akten / Mandate / Schriftsätze etc. soll hiervon getrennt sein, da diese Aufgaben mit einer sehr viel größeren und von OO unabhängigen Flexibilität durch Python erledigt werden können. Der Grund für die Installation von OO auf jedem Arbeitsplatzrechner sind zweierlei:problembär hat geschrieben:Python und OpenOffice zusammen ist aber irgendwie noch weniger aus einem Stück.
1. Online Office Lösungen wie die unter http://wolkoholic.net/2009/05/online-of ... en-im-web/ beschriebenen kommen aufgrund der Datensensibilität nicht in Betracht.
2. Eine gute Installation solcher zentralen Textverarbeitungen auf einem zentralen Server im Intranet ist mir nicht bekannt.
3. Selbst wenn es eine solche gäbe, so wird der Server dadurch belastet. OO auf jedem Client macht deshalb IMHO Sinn, auch wenn die Wartung (Einspielen von Updates auf jedem Client) vielleicht etwas aufwendiger ist.
Ich arbeite in einer kleineren Kanzlei mit etwa fünf Mitarbeitern und diese setzt als Software annotext ein. Ich will das Projekt nicht speziell für diese Kanzlei ins Leben rufen, sondern den Grundstein für eine vernünftige OpenSource Software im Anwaltsbereich legen. Diese soll vom Leistungsspektrum her Kanzleien von einem bis zu 50 Mitarbeitern abdecken.problembär hat geschrieben:Für wieviele Anwälte soll das eigentlich sein, das heißt, wie groß ist eure Kanzlei?
Ich alleine brauche natürlich keine Groupware.
Meist ist man am besten motiviert, das zu schreiben, was man selbst auch braucht.
@Käptn Haddock:
Vielen Dank für Deine Hinweise. Viele hier - einschließlich Dir - scheinen PostgreSQL den Vorzug vor MySQL zu geben - so auch schon Leonidas in seinem Beitrag. Ich werde das noch einmal überdenken, denn gerade diese Erfahrungen / Empfehlungen wollte ich ja hören. Wäre schlecht diese dann zu ignorieren
Die Software soll nicht meinen Lebensunterhalt sichern. Wenn sie was dazu beiträgt ist es schön, wenn nicht ist es egal. Bis dieses Projekt mit den derzeit erhältlichen komerziellen Varianten mithalten kann, dürften ein paar lange Monate, eher ein Jahr oder mehr ins Land gehen. Aber jemand muss den Anfang machen ... Kanzleien werden nicht so einfach von Ihrem bestehenden System umsteigen. Ich meine eher, dass angehende Anwälte bzw. Kanzleineugründer auf diese Software setzen werden, wenn diese einmal gewisse Grundanforderungen erfüllt. Schnittstellen stehen auf der Roadmap, aber welche genau und wann diese implementiert werden, wird sich zeigen. Die kaufmännische Sichtweise, daher anbieten von Support, Installation u.ä. hatte ich jetzt weniger im Blick, aber über eine aktive Community freut sich ja jedes Projekt.
Werde ich beachtenKäptn Haddock hat geschrieben:Selbst wenn du nicht davon leben oder gar reich werden willst, solltest du diese Dinge beachten, wenn das Projekt erfolgreich sein soll.
@sma:
Erst einmal Danke für die Hinweise. Ich muss sie mir aber erst mal näher ansehen, um etwas dazu sagen zu können.
Grüße
Descartes
-
problembär
@Descartes: Ich finde OpenOffice bei jedem einzelnen ja auch sinnvoll, das ist doch schonmal gut.
Daten in MySQL speichern auch (obwohl PostgreSQL inzwischen wohl eine bessere Wahl wäre und auch schon SQLite genügen könnte). Hast Du schonmal Kumula installiert:
http://www.kde-apps.org/content/show.ph ... tent=11997
http://www.kde-apps.org/content/show.ph ... tent=38892
http://www.kde-apps.org/content/show.ph ... tent=38891
Ist natürlich alles andere als fertig, aber von der Idee her (Python, MySQL, Client/Server, modular) Dir doch schon nahe.
Ich kann's leider nur schlecht testen, weil ich Multi-User usw. wie gesagt (vorerst) nicht brauche.
In jedem Fall sollte so eine Software aber eine (hier: OpenOffice-) Dokumentvorlage für Schriftsätze (ggf. mit Briefkopf) mitbringen. Ich habe natürlich eine für mich (mit Word) gebaut, die möchte ich aber nicht öffentlich machen (sonst sehen ja bei ganz vielen die Schriftsätze genau so aus wie bei mir).
Hättest Du Lust, schonmal eine öffentliche zu erstellen?
Im Gegenzug würde ich bei Interesse meine Datenbankstruktur offenlegen (obwohl auch Kumula eine mitbringt).
Gruß
Daten in MySQL speichern auch (obwohl PostgreSQL inzwischen wohl eine bessere Wahl wäre und auch schon SQLite genügen könnte). Hast Du schonmal Kumula installiert:
http://www.kde-apps.org/content/show.ph ... tent=11997
http://www.kde-apps.org/content/show.ph ... tent=38892
http://www.kde-apps.org/content/show.ph ... tent=38891
Ist natürlich alles andere als fertig, aber von der Idee her (Python, MySQL, Client/Server, modular) Dir doch schon nahe.
Ich kann's leider nur schlecht testen, weil ich Multi-User usw. wie gesagt (vorerst) nicht brauche.
In jedem Fall sollte so eine Software aber eine (hier: OpenOffice-) Dokumentvorlage für Schriftsätze (ggf. mit Briefkopf) mitbringen. Ich habe natürlich eine für mich (mit Word) gebaut, die möchte ich aber nicht öffentlich machen (sonst sehen ja bei ganz vielen die Schriftsätze genau so aus wie bei mir).
Hättest Du Lust, schonmal eine öffentliche zu erstellen?
Im Gegenzug würde ich bei Interesse meine Datenbankstruktur offenlegen (obwohl auch Kumula eine mitbringt).
Gruß
Hallo,
ich habe ein ähnliches Projekt in Aussicht.
Und zwar geht es um die Verwaltung einer Datenbank mit mehrsprachigen Fehlertexten. Neben verschiedenen Views und Möglichkeiten zur Manipulation der Datensätze sollen unter anderem auch PDF-Dokumente aus den Texten erstellt werden können.
Eine Webapplikation erscheint mir hier am sinnvollsten.
Nun habe ich mich ein bisschen beschäftigt, mit welchen Technologien dies wohl am besten umzusetzen ist. Bei den hier vorgestellten Möglichkeiten hat mir für das UI GWT (GXT kommt wg. der Lizenz nicht in Frage) am meisten zugesagt. Als Backend würde ich allerdings gerne auf Java verzichten und lieber Python einsetzen, allerdings sieht GWT auf den ersten Blick ziemlich Java-verliebt aus, was die Kommunikation zu einem Server betrifft.
Oder habt ihr da keine Bedenken, was das angeht und kann ich bedenkenlos auf ein GWT-UI mit Python-Server als Backend setzen?
Wenn ja, welche Python Application Server sind dann dafür gut geeignet? Django scheint mir für diese Anwendung zu sehr "view"-lastig zu sein, da ich meine Views in diesem Fall ja eben nicht mit django entwickeln will.
Turbogears habe ich mir ganz kurz angeschaut, macht auf den sehr kurzen Blick schonmal einen guten Eindruck.
Oder sollte ich, wenn ich Python einsetzen will, auf GWT verzichten und die Ajax-Möglichkeiten des AS nutzen?
Edit: Wegen fehlender MSSQL-Unterstützung ist django sowieso nicht geeignet. TurboGears mit sqlalchemy macht da ein besseres Bild. Meiner Meinung nach die bisher beste Python-Lösung für meine Anforderungen.
ich habe ein ähnliches Projekt in Aussicht.
Und zwar geht es um die Verwaltung einer Datenbank mit mehrsprachigen Fehlertexten. Neben verschiedenen Views und Möglichkeiten zur Manipulation der Datensätze sollen unter anderem auch PDF-Dokumente aus den Texten erstellt werden können.
Eine Webapplikation erscheint mir hier am sinnvollsten.
Nun habe ich mich ein bisschen beschäftigt, mit welchen Technologien dies wohl am besten umzusetzen ist. Bei den hier vorgestellten Möglichkeiten hat mir für das UI GWT (GXT kommt wg. der Lizenz nicht in Frage) am meisten zugesagt. Als Backend würde ich allerdings gerne auf Java verzichten und lieber Python einsetzen, allerdings sieht GWT auf den ersten Blick ziemlich Java-verliebt aus, was die Kommunikation zu einem Server betrifft.
Oder habt ihr da keine Bedenken, was das angeht und kann ich bedenkenlos auf ein GWT-UI mit Python-Server als Backend setzen?
Wenn ja, welche Python Application Server sind dann dafür gut geeignet? Django scheint mir für diese Anwendung zu sehr "view"-lastig zu sein, da ich meine Views in diesem Fall ja eben nicht mit django entwickeln will.
Turbogears habe ich mir ganz kurz angeschaut, macht auf den sehr kurzen Blick schonmal einen guten Eindruck.
Oder sollte ich, wenn ich Python einsetzen will, auf GWT verzichten und die Ajax-Möglichkeiten des AS nutzen?
Edit: Wegen fehlender MSSQL-Unterstützung ist django sowieso nicht geeignet. TurboGears mit sqlalchemy macht da ein besseres Bild. Meiner Meinung nach die bisher beste Python-Lösung für meine Anforderungen.
Auf beiden Seiten Java ist definitiv der einfachste Fall, aber wenn der Server JSON erzeugen kann, bieten sich Overlay Types an. Das geht auch prima.ice2k3 hat geschrieben:allerdings sieht GWT auf den ersten Blick ziemlich Java-verliebt aus, was die Kommunikation zu einem Server betrifft.
Oder habt ihr da keine Bedenken, was das angeht und kann ich bedenkenlos auf ein GWT-UI mit Python-Server als Backend setzen?
Wenn du quasi ein API entwerfen willst, und auf mehr oder weniger RESTfulle URLs mit JSON-Objekten (siehe oben) antworten willst, scheint mir Bottle eine einfache Lösung zu sein.ice2k3 hat geschrieben:Wenn ja, welche Python Application Server sind dann dafür gut geeignet?
Die Frage wäre noch, wo deine Daten herkommen sollen. Vielleicht brauchst du dann da noch SQLalchemy oder Storm oder PyMongo oder so.
Welcher Application Server hat denn da welche Ajax-Möglichkeiten?ice2k3 hat geschrieben:Oder sollte ich, wenn ich Python einsetzen will, auf GWT verzichten und die Ajax-Möglichkeiten des AS nutzen?
Im Prinzip ist GWT schon schick, doch man muss Java mögen mögen. Allerdings finde ich nach wie vor, die mitgelieferten Widgets sind eher simpel und GWT ist kein Widget Toolkit sondern eher ein Java nach JavaScript-Compiler mit Potential. Potential genug, um z.B. GXT zu übersetzen. Ist der Lizenzpreis von $329 wirklich ein K.O.-Kriterium?
Ach, interessant für dich könnte noch http://vaadin.com/comparison sein. Man muss allerdings beachten, dass die Punkte genau so gewählt wurden, dass Vaadin dabei gut weg kommt. Einiges finde ich diskussionswürdig - sprich, da bin ich anderer Meinung.
Oh, Microsoft-Welt: Nimm Silverlight :)ice2k3 hat geschrieben:Edit: Wegen fehlender MSSQL-Unterstützung
Oder probiere doch mal Pyjamas aus. Allerdings finde ich deren [url=hhttp://pyjs.org/examples/employeeadmin/output/EmployeeAdmin.html]Demo[/url] zum Fortlaufen...
Doch lieber SproutCore oder Cappucino? Aber diese Technologien kommen aus dem Mac-Dunstkreis. Flex 4? Technologisch ist das interessant und mit ActionScript 3 hat man da so einen Zwitter aus JavaScript und Java.
Oder Titanium Desktop: Basierend auf Webkit kann man da in Python (oder Ruby) sein UI bauen. Mit Titanium Mobile (was aber technisch anders funktioniert) quäle ich mich gerade. Ein Erfahrungsbericht zu der Desktop-Technologie würde mich sehr interessieren.
Stefan
Also Vaadin scheint für meine Anforderungen leider nicht zu passen:
Allerdings ist die Dokumentation dazu ziemlich mager, wollen wohl unbedingt ihre "Trainings" verkaufen
Pyjama sieht in der Beschreibung auch ganz nett aus, Homepage ist allerdings gesperrt (Web-Content-Filter
). Muss ich mir daheim mal anschauen.
Eine Lösung mit GWT + bottle + sqlalchemy hatte ich auch schon im Sinn, siehe auch hier: http://www.python-forum.de/post-163598.html#163598
Die anderen Vorschläge sagen mir nicht so ganz zu. Außer vielleicht Titanium, aber das wäre halt wieder so eine Lizenzgeschichte.
Edit: Zum Thema "Elixir" (wurde im Verlauf des Threads ein bisschen übergangen): Sinnvoll oder eher nicht?
GXT bietet schon schöne Widgets, das muss man sagen. Eine Frage zur Lizenz: Wenn das Projekt als OpenSource deklariert wird, aber das Firmennetz nie verlässt, da die Applikation nur firmenintern verwendet wird, ist das dann ein Lizenzverstoss?An application using Vaadin runs as a servlet in a Java web server
Allerdings ist die Dokumentation dazu ziemlich mager, wollen wohl unbedingt ihre "Trainings" verkaufen
Pyjama sieht in der Beschreibung auch ganz nett aus, Homepage ist allerdings gesperrt (Web-Content-Filter
). Muss ich mir daheim mal anschauen.Eine Lösung mit GWT + bottle + sqlalchemy hatte ich auch schon im Sinn, siehe auch hier: http://www.python-forum.de/post-163598.html#163598
Die anderen Vorschläge sagen mir nicht so ganz zu. Außer vielleicht Titanium, aber das wäre halt wieder so eine Lizenzgeschichte.
Edit: Zum Thema "Elixir" (wurde im Verlauf des Threads ein bisschen übergangen): Sinnvoll oder eher nicht?
Nachdem ich mir die von sma vorgeschlagenen Tools angesehen habe, finde ich, dass sich Titanium, Cappuccino und der GWT-Clone Pyjamas am Besten für mein Projekt eignen würden. Die Demoseite von Pyjamas ist tatsächlich nicht sonderlich attraktiv, aber insgesamt sehe ich hier alle Komponenten vertreten, die ich benötigen werde - zumindest soweit ich das jetzt absehen kann. Den klaren Vorteil sehe ich bei Pyjamas in der sehr stark an Python angelehnten Handhabung und in der freundlichen Lizenz.
Als Framework war bisher Django meine Wahl. Als Alternative dazu habe ich mir Pylons näher angesehen und finde, dass der nicht so stark monolithische Aufbau für mein Projekt besser geeignet ist. Django hat - von seiner Entstehungsgeschichte her - den Fokus auf der leichten Austauschbarkeit von Apps. Pylons Komponenten sind dagegen eher lose "verbandelt" und deshalb leichter austauschbar. Für mein Projekt ist mir letzteres wichtiger, so dass Pylons - um den Preis höherer Einarbeitung - die flexiblere Lösung ist.
@problembär
Die Lösung wird sicherlich eine Dokumentenvorlage für Schriftsätze u.ä. enthalten. Zunächst steht aber für mich das Grundgerüst auf dem Programm, d.h. Grundlayout, Kanzlei(metadaten) anlegen, ändern, löschen; Akte anlegen, ändern, archivieren; Mandant, Gegner, RAe erfassen etc. Wenn das alles steht und funktioniert gehts an die Schriftsätze, Dokumentenvorlagen und Textbausteine. Wird also noch ein Weilchen dauern.
Grüße
Descartes
Als Framework war bisher Django meine Wahl. Als Alternative dazu habe ich mir Pylons näher angesehen und finde, dass der nicht so stark monolithische Aufbau für mein Projekt besser geeignet ist. Django hat - von seiner Entstehungsgeschichte her - den Fokus auf der leichten Austauschbarkeit von Apps. Pylons Komponenten sind dagegen eher lose "verbandelt" und deshalb leichter austauschbar. Für mein Projekt ist mir letzteres wichtiger, so dass Pylons - um den Preis höherer Einarbeitung - die flexiblere Lösung ist.
@problembär
Die Lösung wird sicherlich eine Dokumentenvorlage für Schriftsätze u.ä. enthalten. Zunächst steht aber für mich das Grundgerüst auf dem Programm, d.h. Grundlayout, Kanzlei(metadaten) anlegen, ändern, löschen; Akte anlegen, ändern, archivieren; Mandant, Gegner, RAe erfassen etc. Wenn das alles steht und funktioniert gehts an die Schriftsätze, Dokumentenvorlagen und Textbausteine. Wird also noch ein Weilchen dauern.
Grüße
Descartes
Meine Meinung zu pyjamas:
Als das Grundprinzip gefällt mir sehr, würde das UI lieber in Python anstatt in Java programmieren. Aber dann hört es mit dem Positiven leider auch schon auf.
In der aktuellen Release (0.6) musste ich zuerst an der beim Setup generierten Batch-Datei schrauben, damit ich die examples erst einmal kompilieren konnte. Viele der Examples sind mit dem IE6 überhaupt nicht lauffähig (ja, bin im Betrieb leider noch daran gebunden...), größere Beispiele wie "Mail" sind extrem langsam. Von optimiertem JS also keine Spur.
Mit dem aktuellen RC (0.7pre1) konnte ich zwar problemlos nach dem Setup kompilieren, es sind aber nun *noch* weniger der Beispiele mit dem IE6 lauffähig.
Auch mit dem aktuellen Firefox treten bei den Beispielen ständig JS-Errors auf.
Mein Fazit: Keineswegs einsetzbar für Production-Applikationen. Das Paket im PyPI als "Production-Stable" zu kennzeichnen ist eine Frechheit...
Nun nochmal zu GXT:
Wenn ich meine GXT-UI im Quellcode mit einer OpenSource-Lizenz versehe, muss ich ihn dann auch öffentlich zur Verfügung stellen? Oder kann ich ein OpenSource-Programm auch firmenintern entwickeln, ohne dass der Quellcode in die Öffentlichkeit kommt?
Ich weiß, dass ist jetzt ein relativ radikaler Vorschlag, aber ich kann mir nicht vorstellen, dass mein Betrieb auf das Stichwort "OpenSource"-Entwicklung sonderlich gut reagiert.
Vielleicht kann ich sie aber auch überzeugen, könnte die OpenSource ja auch auf die UI/ auf den GXT-Teil beschränken und müsste den ganzen Server-Background nicht veröffentlichen.
Als das Grundprinzip gefällt mir sehr, würde das UI lieber in Python anstatt in Java programmieren. Aber dann hört es mit dem Positiven leider auch schon auf.
In der aktuellen Release (0.6) musste ich zuerst an der beim Setup generierten Batch-Datei schrauben, damit ich die examples erst einmal kompilieren konnte. Viele der Examples sind mit dem IE6 überhaupt nicht lauffähig (ja, bin im Betrieb leider noch daran gebunden...), größere Beispiele wie "Mail" sind extrem langsam. Von optimiertem JS also keine Spur.
Mit dem aktuellen RC (0.7pre1) konnte ich zwar problemlos nach dem Setup kompilieren, es sind aber nun *noch* weniger der Beispiele mit dem IE6 lauffähig.
Auch mit dem aktuellen Firefox treten bei den Beispielen ständig JS-Errors auf.
Mein Fazit: Keineswegs einsetzbar für Production-Applikationen. Das Paket im PyPI als "Production-Stable" zu kennzeichnen ist eine Frechheit...
Nun nochmal zu GXT:
Wenn ich meine GXT-UI im Quellcode mit einer OpenSource-Lizenz versehe, muss ich ihn dann auch öffentlich zur Verfügung stellen? Oder kann ich ein OpenSource-Programm auch firmenintern entwickeln, ohne dass der Quellcode in die Öffentlichkeit kommt?
Ich weiß, dass ist jetzt ein relativ radikaler Vorschlag, aber ich kann mir nicht vorstellen, dass mein Betrieb auf das Stichwort "OpenSource"-Entwicklung sonderlich gut reagiert.
Vielleicht kann ich sie aber auch überzeugen, könnte die OpenSource ja auch auf die UI/ auf den GXT-Teil beschränken und müsste den ganzen Server-Background nicht veröffentlichen.
-
problembär
Hmm, ob es dann jemals eine öffentliche OpenOffice-Anwalts-Dokumentvorlage geben wird? Ich bin gespannt (und ziehe mich bis dahin erstmal aus der Diskussion zurück).Descartes hat geschrieben:Zunächst steht aber für mich das Grundgerüst auf dem Programm, d.h. Grundlayout, Kanzlei(metadaten) anlegen, ändern, löschen; Akte anlegen, ändern, archivieren; Mandant, Gegner, RAe erfassen etc. Wenn das alles steht und funktioniert gehts an die Schriftsätze, Dokumentenvorlagen und Textbausteine.
Gruß