Hallo Leute,
ich hab vor 5 Jahren mal mit Django gearbeitet und war damals sehr begeistert. Jetzt habe ich die Gelegenheit es für meine Arbeit einzusetzen, bin aber über die Struktur und Aufbau nicht ganz sicher und würd mich über den ein oder anderen Tipp freuen.
Wir haben eine Probenverwaltung, basierend auf mehreren Excel Dateien und viele Infos werden mehrfach eingetragen, gleichzeitig kann nicht editiert werden etc. Das würde ich gerne mit Django lösen.
Mein erster Entwurf funktioniert auch schon teilweise, allerdings arbeite ich komplett im Admin Bereich zur Dateneingabe und benutze zur Zeit nicht das Frontend.
Langfristig ist geplant, dass Benutzer ihre Daten zu den Proben selbst eingeben können, danach die Mitarbeiter die Daten zur Weiterverarbeitung und anschließend die Analyse in die Datenbank eintragen. Der Benutzer soll dann die Analyse quasi anschauen können.
Ich frag mich gerade, ob ich so etwas komplett im Admin Bereich aufbaue, oder Formulare im Frontend zur Verfügung stelle. Ist vielleicht eine komische Frage, aber ich dachte ich hol mir mal eine zweite oder dritte Meinung.
Vielen Dank für jegliche Hinweise!
Konzeptionelles Problem als Django Anfänger
Gleich vorweg: ich arbeite nicht mit Django, ich habe aber schon verteilte Datenbankanwendungen erstellt und da kein anderer bisher geantwortet hat, hier ein paar Tips zu verteilten Datenbankanwendungen.
Es gibt Stammdaten und Bewegungsdaten. Stammdaten ändern sich selten und Bewegungsdaten ändern sich ständig bzw. es werden immer neue hinzugefügt. Bei der Bearbeitung sollte beides strikt voneinander getrennt werden. Man fängt meist mit dem Frontend zur Bearbeitung der Bewegungsdaten an. Die Bearbeitung der Bewegungsdaten soll komfortabler sein, als die Bearbeitung der Stammdaten und muss auch mehr gegen Fehler abgesichert werden. Bei den Stammdaten reicht es anfangs meist, wenn diese direkt in der Datenbank eingegeben werden.
Bezogen auf Dein Problem:
Es gibt Stammdaten und Bewegungsdaten. Stammdaten ändern sich selten und Bewegungsdaten ändern sich ständig bzw. es werden immer neue hinzugefügt. Bei der Bearbeitung sollte beides strikt voneinander getrennt werden. Man fängt meist mit dem Frontend zur Bearbeitung der Bewegungsdaten an. Die Bearbeitung der Bewegungsdaten soll komfortabler sein, als die Bearbeitung der Stammdaten und muss auch mehr gegen Fehler abgesichert werden. Bei den Stammdaten reicht es anfangs meist, wenn diese direkt in der Datenbank eingegeben werden.
Bezogen auf Dein Problem:
- Mach Dir Gedanken darüber was Deine Bewegungsdaten sind und was sind Deine Stammdaten. Proben die neu hinzukommen sind sicherlich Bewegungsdaten. Vielleicht gibt es bei der Eingabe die Möglichkeit die Proben einzuordnen, zu kategorisieren. So ein Ordnungsschema oder solche Kategorien, das sind Stammdaten.
- Nachdem Du Bewegungs- und Stammdaten getrennt hast, machst Du die Datenbankstruktur.
- Lasse niemals die ganz normalen Benutzer mit dem Admin-Tool arbeiten. Sobald "normale" Benutzer mit dem Tool arbeiten sollen, brauchen diese ein Frontend für die Proben. Die Stammdaten kannst Du erstmal selbst über den Admin Bereich eintragen.
- Mach die Anwendung bunt mit Matlab basierten Auswertungen.
- Mach die Eingabe der Stammdaten sicher mit einem eigenen Frontend.
@MagBen: es ist nicht immer so einfach eine Trennung zwischen Stammdaten und Bewegungsdaten zu treffen. Eine bessere Trennung ist es, sich verschiedene Zugriffsebenen zu überlegen. Das ist dann mehr eine Trennung nach Tätigkeiten. Statt Matlab meinst Du wohl eher Matplotlib, ob wohl es einige sehr ansprechende Javascript-Toolboxen gibt, um Grafiken direkt im Browser zu erzeugen.
Wenn etwas richtig schief läuft bei einer Datenbank-Anwendung, dann ist oftmals hier der erste Fehler gemacht worden, bei der fehlenden Trennung von Stamm- und Bewegungsdaten.Sirius3 hat geschrieben: es ist nicht immer so einfach eine Trennung zwischen Stammdaten und Bewegungsdaten zu treffen
Ja natürlich Matplotlib. Wenn man sowieso schon Python macht, warum dann nicht auch gleich Berichte mit Matplotlib? Wenn Berichte mit Matplotlib nicht gefragt sind, würde ich ansonsten eher PHP für eine kleine Webanwendung nehmen. Bei einem Webhoster ist es natürlich nicht immer möglich Matplotlib zu nehmen. Man kann mit Matplotlib sehr schnell einen kleinen Berichtsgenerator erstellen, der von der Arbeitszeit weniger kostet als die Web-Lizenz von Crystal Reports (und auch bei Crystal Reports macht sich die Arbeit nicht von alleine).Sirius3 hat geschrieben: Statt Matlab meinst Du wohl eher Matplotlib, ob wohl es einige sehr ansprechende Javascript-Toolboxen gibt, um Grafiken direkt im Browser zu erzeugen.
Vielen Dank @MagBen und auch @Sirius3
Ich denke ich habe meine Stammdaten korrekt getrennt und bin jetzt quasi dabei ein eigenes Template für neue Proben anzulegen.
Was ich mich gerade im Moment frage, im Admin Bereich hab ich automatisch die Erstellung der jeweiligen Felder anhand der Variablen die ich in meinem Model definiert habe.
Ich hab gerade das Gefühl, dass ich das im User Frontend alles selbst definieren muss, oder hab ich da ein Kapitel in der Anleitung quasi übersehen...
Ich hab mir jetzt zumindest eine url samplesubmission/add/ angelegt und will mir jetzt das Formular aufbauen.
Gibt es hierfür vielleicht eine weiterführende Anleitung? Ich hatte meine Anwendung eine "vote" view hinzugefügt, einfach um das Tutorial in meiner Beispiel anzuwenden. Das klappt auch und ich konnte eine bestehende "Probe" ändern.
Ich frage mich gerade, ob es keinen einfacheren Weg gibt, alle Felder aus dem Model zu erzeugen, ähnlich wie im Admin Bereich. Oder hat man im Frontend einfach "alle Freiheiten" und somit auch die Handarbeit?
Vielen Dank schon mal!
Ich denke ich habe meine Stammdaten korrekt getrennt und bin jetzt quasi dabei ein eigenes Template für neue Proben anzulegen.
Was ich mich gerade im Moment frage, im Admin Bereich hab ich automatisch die Erstellung der jeweiligen Felder anhand der Variablen die ich in meinem Model definiert habe.
Ich hab gerade das Gefühl, dass ich das im User Frontend alles selbst definieren muss, oder hab ich da ein Kapitel in der Anleitung quasi übersehen...
Ich hab mir jetzt zumindest eine url samplesubmission/add/ angelegt und will mir jetzt das Formular aufbauen.
Gibt es hierfür vielleicht eine weiterführende Anleitung? Ich hatte meine Anwendung eine "vote" view hinzugefügt, einfach um das Tutorial in meiner Beispiel anzuwenden. Das klappt auch und ich konnte eine bestehende "Probe" ändern.
Ich frage mich gerade, ob es keinen einfacheren Weg gibt, alle Felder aus dem Model zu erzeugen, ähnlich wie im Admin Bereich. Oder hat man im Frontend einfach "alle Freiheiten" und somit auch die Handarbeit?
Vielen Dank schon mal!
-
Piet Lotus
- User
- Beiträge: 80
- Registriert: Dienstag 14. November 2006, 10:40
Hallo würmchen,
auch wenn du dich schon bedankt hast und deinen Post dadurch schon abgeschlossen hast
Hier noch ein paar Anmerkungen meinerseits. Der Adminbereich ist nur für die "Datenpflege" durch Nutzer, die wissen was sie tun gedacht. Vielleicht hat sich das mittlerweile im Adminbereich geändert, aber soweit ich weiß ist z.B. um bei deinem Fall zu bleiben eine Einschränkung auf nur die Proben eines Nutzeres nicht so leicht möglich, heißt wenn wir beide über den Adminbereich arbeiten, könnte ich deine Proben manipulieren und du meine...Aber diese Sicherheitseinschränkung kann mittlerweile auch "behoben" worden sein. Weiter hat man bei einer lebenden Anwendung oftmals den Wunsch z.B. kompliziertere "Berechnungen", Funktionalitäten, Navigationsmöglichkeiten oder Technologien (z.B. Ajax, REST usw.) zur Verfügung zu stellen und das geht halt leichter, wenn man selbst das Frontend baut. Jetzt sind wir bei deinen Stichworten "Freiheit" und "Handarbeit". Wie du sicherlich schon gelesen hast verfolgt Django das DRY-Prinzip (Don't Repeat Yourself) und damit kann ausgehend vom Model schon recht schnell was zusammenstecken. In den urls.py kannst du schon unter bestimmten Bedingungen über TemplateView direkt deine HTML-Seiten aufrufen. Dann gibt es die einige Shortcut-Methoden in den views. Und für einfache CRUD-Funktionalitäten bieten sich Classbased Views (CBV) an. Da kriegst du Pagination, Listenfunktionalität, Detailansichten, Löschseiten usw. teilweise auch schon automatisch oder kannst sie mit geringem Aufwand anpassen. Forms lassen sich ebenfals über ModelForm recht schnell aus dem aus dem Model ableiten. Und falls du die Templateerstellung abkürzen möchtest hast du ja die Möglichkeit dort Vererbung und z.B. as_table() zu nutzen. Wobei letzterer Befehl eine ganze HTML-Tabelle erzeugt. ich irgendwo mal gelesen habe, diesen Befehl nicht in "produktiv"-Systemen einzusetzen - mir fällt im Moment aber kein Grund gegen den Einsatz ein. Je nach eingesetzter Technologie möchte man aber z.B. seine Tabellenzeilen mit Links zur Bearbeitung der Objektzeile usw. ausstatten, auch dann müsste man sein eigenes Frontend bauen.
Vielleicht stoberst du einfach mal in der umfangreichen Django-Doku. Und wenn du dabei bleibst, entdeckst du mit der Zeit sowieso immer mehr Möglichkeiten...
Vielleicht konnten dir meine Zeilen ja noch einige Anregungen geben.
Viele Grüße
Piet
auch wenn du dich schon bedankt hast und deinen Post dadurch schon abgeschlossen hast
Hier noch ein paar Anmerkungen meinerseits. Der Adminbereich ist nur für die "Datenpflege" durch Nutzer, die wissen was sie tun gedacht. Vielleicht hat sich das mittlerweile im Adminbereich geändert, aber soweit ich weiß ist z.B. um bei deinem Fall zu bleiben eine Einschränkung auf nur die Proben eines Nutzeres nicht so leicht möglich, heißt wenn wir beide über den Adminbereich arbeiten, könnte ich deine Proben manipulieren und du meine...Aber diese Sicherheitseinschränkung kann mittlerweile auch "behoben" worden sein. Weiter hat man bei einer lebenden Anwendung oftmals den Wunsch z.B. kompliziertere "Berechnungen", Funktionalitäten, Navigationsmöglichkeiten oder Technologien (z.B. Ajax, REST usw.) zur Verfügung zu stellen und das geht halt leichter, wenn man selbst das Frontend baut. Jetzt sind wir bei deinen Stichworten "Freiheit" und "Handarbeit". Wie du sicherlich schon gelesen hast verfolgt Django das DRY-Prinzip (Don't Repeat Yourself) und damit kann ausgehend vom Model schon recht schnell was zusammenstecken. In den urls.py kannst du schon unter bestimmten Bedingungen über TemplateView direkt deine HTML-Seiten aufrufen. Dann gibt es die einige Shortcut-Methoden in den views. Und für einfache CRUD-Funktionalitäten bieten sich Classbased Views (CBV) an. Da kriegst du Pagination, Listenfunktionalität, Detailansichten, Löschseiten usw. teilweise auch schon automatisch oder kannst sie mit geringem Aufwand anpassen. Forms lassen sich ebenfals über ModelForm recht schnell aus dem aus dem Model ableiten. Und falls du die Templateerstellung abkürzen möchtest hast du ja die Möglichkeit dort Vererbung und z.B. as_table() zu nutzen. Wobei letzterer Befehl eine ganze HTML-Tabelle erzeugt. ich irgendwo mal gelesen habe, diesen Befehl nicht in "produktiv"-Systemen einzusetzen - mir fällt im Moment aber kein Grund gegen den Einsatz ein. Je nach eingesetzter Technologie möchte man aber z.B. seine Tabellenzeilen mit Links zur Bearbeitung der Objektzeile usw. ausstatten, auch dann müsste man sein eigenes Frontend bauen.
Vielleicht stoberst du einfach mal in der umfangreichen Django-Doku. Und wenn du dabei bleibst, entdeckst du mit der Zeit sowieso immer mehr Möglichkeiten...
Vielleicht konnten dir meine Zeilen ja noch einige Anregungen geben.
Viele Grüße
Piet
Hallo Piet,
Danke auch für Deine Hinweise.
Ich bin gestern auch noch über die ModelForm Klassen gestolpert, mich wundert es nur, dass es einem im Frontend irgendwie viel schwerer gemacht wird, als im Backend... Also mal eben schnell die Ergebnisse aus dem Admin Bereich im Frontend nachzubauen (fieldsets, Stacked Inline Models, Dynamisch weitere Modelle hinzufügen, etc) ist quasi unmöglich. Viele Tools die ich online gefunden habe, funktionieren in Django 1.7 nicht, dabei ist doch JQuery und alles schon vorhanden, seh ich doch im Admin Bereich... Kommt mir irgendwie komisch vor...
Ich schau mir jetzt mal die CBV an, mal sehen ob ich da fündig werde...
Vielen Dank auch für Deine Tipps!
Danke auch für Deine Hinweise.
Ich bin gestern auch noch über die ModelForm Klassen gestolpert, mich wundert es nur, dass es einem im Frontend irgendwie viel schwerer gemacht wird, als im Backend... Also mal eben schnell die Ergebnisse aus dem Admin Bereich im Frontend nachzubauen (fieldsets, Stacked Inline Models, Dynamisch weitere Modelle hinzufügen, etc) ist quasi unmöglich. Viele Tools die ich online gefunden habe, funktionieren in Django 1.7 nicht, dabei ist doch JQuery und alles schon vorhanden, seh ich doch im Admin Bereich... Kommt mir irgendwie komisch vor...
Ich schau mir jetzt mal die CBV an, mal sehen ob ich da fündig werde...
Vielen Dank auch für Deine Tipps!
@würmchen:
Der große Unterschied zwischen Adminbereich und Frontend ist, dass der Adminbereich sehr modelnah tickt und daher die Django-Leute dort die Assets für die Views alle mitliefern können (CSS, Javascript). Im Frontend bist du auf Dich gestellt und musst alles über Deine Views zusammenklöppeln.
Für unsere Projekte ziehen wir daher eher an Modelnähe und Aufgabenbereich des Benutzers die Grenze von Admin zu Frontend und nicht bei der "Dauerhaftigkeit" der Daten.
Abhängig von Deiner Modellierung kann die Einpflege der Probendaten modelnah sein, dann kannst Du prima von der Logik der Adminklassen profitieren und musst nicht alles neu schreiben.
Der große Unterschied zwischen Adminbereich und Frontend ist, dass der Adminbereich sehr modelnah tickt und daher die Django-Leute dort die Assets für die Views alle mitliefern können (CSS, Javascript). Im Frontend bist du auf Dich gestellt und musst alles über Deine Views zusammenklöppeln.
Für unsere Projekte ziehen wir daher eher an Modelnähe und Aufgabenbereich des Benutzers die Grenze von Admin zu Frontend und nicht bei der "Dauerhaftigkeit" der Daten.
Abhängig von Deiner Modellierung kann die Einpflege der Probendaten modelnah sein, dann kannst Du prima von der Logik der Adminklassen profitieren und musst nicht alles neu schreiben.