|
|
|
|
|
|
| | Zitat von [DK]Peacemaker
Für die Leute mit MSDNAA Zugang, also Expression Encoder 3.0 bringt so ein schönes Screen-Capture Programm mit (Beispiel hab ich ja auch gepostet, obwohl niemand was dazu gesagt hat) und ich wollte das nur mal empfehlen
Mach ich jetzt immer während des Arbeitens an, hat man immer was zu zeigen, auch wenn nichts bei rumkommt | |
Ist das besser als das Snipping-Tool?
|
|
|
|
|
|
|
|
|
|
|
ich glaub wenn ich mal n größeres Zimmer hab, werd ich mir nen richtig schönen, großen Schreibtisch besorgen.
Also richtig groß.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Richtig toll wird es dann, wenn der Tisch absolut leer ist 
Bzw nu minimalistisch paar Blatt Papier und n Stift
|
|
|
|
|
|
|
|
|
|
|
Da brauchst du doch dann eine Harke, um an die weiter entfernten Gegenstände dran zu kommen.
|
|
|
|
|
|
|
|
|
|
|
|
Als ob ein Schreibtisch in der Größe leer bleibt.
|
|
|
|
|
|
|
|
|
|
|
Deshalb gibts ja diese tollen Klotische:
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von SkunkyVillage
Sag mal Achsel, gibt es eine Möglichkeit, dass bei jedem View eine bestimmte Funktion aufgerufen wird, ohne, dass ich die jedes Mal manuell im View implementieren muss?
| |
Wenn du es wirklich bei jedem haben willst, würde sich dafür eine Middleware anbieten. Wenn du es nur auf bestimmten haben willst, würde ich nen Decorator schreiben.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von GH@NDI
| | Zitat von SkunkyVillage
Gibt es eine valide Möglichkeit um Zeilenumbrüche in einer Textarea zu übernehmen, also so, dass sie in der Datenbank mitgespeichert werden? 
| |
Einfach das was kommt, in die Datenbank packen? Dann landen da nämlich stinknormale Newline-Characters.
| |
Wobei ich mich gerade frage: Sind es wirklich newlines? ODer sind es \n auf Unix Systemen und \r\n auf Windowssystemen?
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Achsel-des-Bösen
| | Zitat von GH@NDI
| | Zitat von SkunkyVillage
Gibt es eine valide Möglichkeit um Zeilenumbrüche in einer Textarea zu übernehmen, also so, dass sie in der Datenbank mitgespeichert werden? | |
Einfach das was kommt, in die Datenbank packen? Dann landen da nämlich stinknormale Newline-Characters. | |
Wobei ich mich gerade frage: Sind es wirklich newlines? ODer sind es \n auf Unix Systemen und \r\n auf Windowssystemen? | |
Sollte ja eigentlich das sein was der User abschickt.
Im Browser ist das immer ein "\n".
|
|
|
|
|
|
|
|
|
|
|
|
Ich formuliere um: Sind wir uns sicher, dass nicht irgendwelche komischen Windowsbrowser einfach ein "System.NEWLINE" einfügen, wenn der User return drückt?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ich hab ja letzte Woche schonmal angedeutet, dass ich gerade eine Javaanwendung schreibe, die XML mit JAXB 2.0 als oo-"Datenbank" benutzt und den Objektgraphen meiner Anwendung nach XML serialisiert und die resultierende XML-Datei wieder zu einem Objektgraphen deserialisiert.
Das läuft alles soweit. Ein Knackpunkt ist allerdings, dass Referenzen grundsätzlich nicht serialisiert werden. D.h. wird ein Objekt mehrfach referenziert, wird es genau so oft in die XML-Datei geschrieben, wie es referenziert wird. Dieses Verhalten kann man umgehen indem man xsd:IDREF bzw. xsd:IDREFS als Typ für ein Attribut/Element angibt. Dann wird das ID-Attribut des referenzierten Objekts in die XML-Datei geschrieben anstatt des serialisierten Objekts.
Hier kommt aber das Problem: Ich muss das Objekt, welches per xsd:IDREF referenziert wird, zumindest einmal komplett in die XML-Datei schreiben. Ansonsten habe ich eine Menge schöne ID-Referenzen auf das Objekt, das Objekt selbst aber nicht.
Nun bin ich am überlegen, wie ich das am besten lösen könnte. Ich könnte natürlich jedes Objekt einmal in eine große untypisierte Collection schmeißen und diese dann serialisieren. Oder ich könnte für jeden Typ eine eigene Collection anlegen und die Objekte darin ablegen. Aber das gefällt mir alles nicht, da mir das zu unstrukturiert erscheint. Eine der Bedingungen an die Software ist gerade, dass die "Datenbank" menschenlesbar und -bearbeitbar sein soll.
|
|
|
|
|
|
|
|
|
|
|
Ich hab mir das jetzt mal beides angeschaut, Achsel. Wie würdest du denn folgendes "Problem" lösen?
Es geht darum, dass ich bei jedem request prüfen möchte, ob ein Cookie gesetzt ist und wenn ja soll eine Session (falls noch nicht geschehen) gestartet werden. Quasi als Loginprüfung.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Smoking
Ich hab ja letzte Woche schonmal angedeutet, dass ich gerade eine Javaanwendung schreibe, die XML mit JAXB 2.0 als oo-"Datenbank" benutzt und den Objektgraphen meiner Anwendung nach XML serialisiert und die resultierende XML-Datei wieder zu einem Objektgraphen deserialisiert.
Das läuft alles soweit. Ein Knackpunkt ist allerdings, dass Referenzen grundsätzlich nicht serialisiert werden. D.h. wird ein Objekt mehrfach referenziert, wird es genau so oft in die XML-Datei geschrieben, wie es referenziert wird. Dieses Verhalten kann man umgehen indem man xsd:IDREF bzw. xsd:IDREFS als Typ für ein Attribut/Element angibt. Dann wird das ID-Attribut des referenzierten Objekts in die XML-Datei geschrieben anstatt des serialisierten Objekts.
Hier kommt aber das Problem: Ich muss das Objekt, welches per xsd:IDREF referenziert wird, zumindest einmal komplett in die XML-Datei schreiben. Ansonsten habe ich eine Menge schöne ID-Referenzen auf das Objekt, das Objekt selbst aber nicht.
Nun bin ich am überlegen, wie ich das am besten lösen könnte. Ich könnte natürlich jedes Objekt einmal in eine große untypisierte Collection schmeißen und diese dann serialisieren. Oder ich könnte für jeden Typ eine eigene Collection anlegen und die Objekte darin ablegen. Aber das gefällt mir alles nicht, da mir das zu unstrukturiert erscheint. Eine der Bedingungen an die Software ist gerade, dass die "Datenbank" menschenlesbar und -bearbeitbar sein soll.
| |
Und was spricht gegen typisierte Collections? Hast du so viele verschiedene Objekt-Typen? Aus "Repository"-Sicht, würde ich die XML Datei in Abschnitte unterteilen:
| |
| Code: |
<Database>
<Categories>
<Category Id="1" ... />
<Category Id="2" ... />
</Categories>
<Products>
<Product Id="1" CategoryId="2">
...
</Product>
<Product Id="2" ... />
<Product Id="3" CategoryId="1" .../>
</Products>
</Database>
|
|
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von SkunkyVillage
Ich hab mir das jetzt mal beides angeschaut, Achsel. Wie würdest du denn folgendes "Problem" lösen?
Es geht darum, dass ich bei jedem request prüfen möchte, ob ein Cookie gesetzt ist und wenn ja soll eine Session (falls noch nicht geschehen) gestartet werden. Quasi als Loginprüfung.
| |
Das wäre dann aber Aufgabe des Controllers, nicht des Views.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von [DK]Peacemaker
| | Zitat von SkunkyVillage
Ich hab mir das jetzt mal beides angeschaut, Achsel. Wie würdest du denn folgendes "Problem" lösen?
Es geht darum, dass ich bei jedem request prüfen möchte, ob ein Cookie gesetzt ist und wenn ja soll eine Session (falls noch nicht geschehen) gestartet werden. Quasi als Loginprüfung.
| |
Das wäre dann aber Aufgabe des Controllers, nicht des Views.
| |
Deshalb hab ich das in diesem Post nochmal relativiert und nicht gesagt "bei jedem View", sondern "bei jedem request". Weils mir selbst aufgefallen ist.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von SkunkyVillage
Ich hab mir das jetzt mal beides angeschaut, Achsel. Wie würdest du denn folgendes "Problem" lösen?
Es geht darum, dass ich bei jedem request prüfen möchte, ob ein Cookie gesetzt ist und wenn ja soll eine Session (falls noch nicht geschehen) gestartet werden. Quasi als Loginprüfung.
| |
Ich glaube du versuchst eine Problem zu lösen, das Django dir abnimmt. Deswegen: Wozu willst du das?
|
|
|
|
|
|
|
|
|
|
|
Also, da sich ASP.NET MVC ja viel von anderen Frameworks geborgt hat, erzähl ich dir kurz, was man da macht.
Man stelle sich eine Controller-Action vor, die nur dann ausgeführt werden darf, wenn man eingeloggt ist. Dann dekoriert man die Aktion mit einem entsprechendem Attribut [Authenticated] oder so.
Was ähnliches meint Achsel wohl auch. Darin kann man dann auch angeben, wohin man umgeleitet werden soll, bei nicht Login.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von [DK]Peacemaker
| | Zitat von Smoking
Ich hab ja letzte Woche schonmal angedeutet, dass ich gerade eine Javaanwendung schreibe, die XML mit JAXB 2.0 als oo-"Datenbank" benutzt und den Objektgraphen meiner Anwendung nach XML serialisiert und die resultierende XML-Datei wieder zu einem Objektgraphen deserialisiert.
Das läuft alles soweit. Ein Knackpunkt ist allerdings, dass Referenzen grundsätzlich nicht serialisiert werden. D.h. wird ein Objekt mehrfach referenziert, wird es genau so oft in die XML-Datei geschrieben, wie es referenziert wird. Dieses Verhalten kann man umgehen indem man xsd:IDREF bzw. xsd:IDREFS als Typ für ein Attribut/Element angibt. Dann wird das ID-Attribut des referenzierten Objekts in die XML-Datei geschrieben anstatt des serialisierten Objekts.
Hier kommt aber das Problem: Ich muss das Objekt, welches per xsd:IDREF referenziert wird, zumindest einmal komplett in die XML-Datei schreiben. Ansonsten habe ich eine Menge schöne ID-Referenzen auf das Objekt, das Objekt selbst aber nicht.
Nun bin ich am überlegen, wie ich das am besten lösen könnte. Ich könnte natürlich jedes Objekt einmal in eine große untypisierte Collection schmeißen und diese dann serialisieren. Oder ich könnte für jeden Typ eine eigene Collection anlegen und die Objekte darin ablegen. Aber das gefällt mir alles nicht, da mir das zu unstrukturiert erscheint. Eine der Bedingungen an die Software ist gerade, dass die "Datenbank" menschenlesbar und -bearbeitbar sein soll.
| |
Und was spricht gegen typisierte Collections? Hast du so viele verschiedene Objekt-Typen? Aus "Repository"-Sicht, würde ich die XML Datei in Abschnitte unterteilen:
| |
| Code: |
<Database>
<Categories>
<Category Id="1" ... />
<Category Id="2" ... />
</Categories>
<Products>
<Product Id="1" CategoryId="2">
...
</Product>
<Product Id="2" ... />
<Product Id="3" CategoryId="1" .../>
</Products>
</Database>
|
|
| |
Wenn ich es mir nochmal überlege, ist das eigentlich die einzige vernünftige Lösung.
Was mich daran stört sind die verschiedenen Einstiegsmöglichkeiten in den Objektgraphen die ich anbieten muss. Und das man dann, wenn man sich die XML-Datei anschaut, erstmal wüst hin und her springen muss um die Referenzierung nachvollziehen zu können.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von TriggerTG
Richtig toll wird es dann, wenn der Tisch absolut leer ist
Bzw nu minimalistisch paar Blatt Papier und n Stift
| |
Ein Schreibtisch kann noch so groß sein, leer wird der nie sein.
Wobei ich den bevor ich was neues mach schon immer aufräume, sonst kann man ja nicht arbeiten. 
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von SirSiggi
Ha, Karten fürs Summer-Breeze 2010 sind da. Inkl. DVD von 2008. Leck mich am Arsch, der die zigtausend Wall-of-Deaths bei Heaven Shall Burn sind einfach nur Wahnsinn. Ein Glück stand ich da an der Seite. Aber es ist einfach nur geil anzusehen.
| |
lass ma rüberwachsen :P(die dvd).
zum glück stand ich mitten drin und hab mitgemacht. nub :P.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Smoking
| | Zitat von [DK]Peacemaker
| | Zitat von Smoking
Ich hab ja letzte Woche schonmal angedeutet, dass ich gerade eine Javaanwendung schreibe, die XML mit JAXB 2.0 als oo-"Datenbank" benutzt und den Objektgraphen meiner Anwendung nach XML serialisiert und die resultierende XML-Datei wieder zu einem Objektgraphen deserialisiert.
Das läuft alles soweit. Ein Knackpunkt ist allerdings, dass Referenzen grundsätzlich nicht serialisiert werden. D.h. wird ein Objekt mehrfach referenziert, wird es genau so oft in die XML-Datei geschrieben, wie es referenziert wird. Dieses Verhalten kann man umgehen indem man xsd:IDREF bzw. xsd:IDREFS als Typ für ein Attribut/Element angibt. Dann wird das ID-Attribut des referenzierten Objekts in die XML-Datei geschrieben anstatt des serialisierten Objekts.
Hier kommt aber das Problem: Ich muss das Objekt, welches per xsd:IDREF referenziert wird, zumindest einmal komplett in die XML-Datei schreiben. Ansonsten habe ich eine Menge schöne ID-Referenzen auf das Objekt, das Objekt selbst aber nicht.
Nun bin ich am überlegen, wie ich das am besten lösen könnte. Ich könnte natürlich jedes Objekt einmal in eine große untypisierte Collection schmeißen und diese dann serialisieren. Oder ich könnte für jeden Typ eine eigene Collection anlegen und die Objekte darin ablegen. Aber das gefällt mir alles nicht, da mir das zu unstrukturiert erscheint. Eine der Bedingungen an die Software ist gerade, dass die "Datenbank" menschenlesbar und -bearbeitbar sein soll.
| |
Und was spricht gegen typisierte Collections? Hast du so viele verschiedene Objekt-Typen? Aus "Repository"-Sicht, würde ich die XML Datei in Abschnitte unterteilen:
| |
| Code: |
<Database>
<Categories>
<Category Id="1" ... />
<Category Id="2" ... />
</Categories>
<Products>
<Product Id="1" CategoryId="2">
...
</Product>
<Product Id="2" ... />
<Product Id="3" CategoryId="1" .../>
</Products>
</Database>
|
|
| |
Wenn ich es mir nochmal überlege, ist das eigentlich die einzige vernünftige Lösung.
Was mich daran stört sind die verschiedenen Einstiegsmöglichkeiten in den Objektgraphen die ich anbieten muss. Und das man dann, wenn man sich die XML-Datei anschaut, erstmal wüst hin und her springen muss um die Referenzierung nachvollziehen zu können.
| |
Wenn du selbst die Kontrolle über die Serialisierung hast, kannst du ja referenzierte Objekte als "Dummys" ablegen. Und dann wenn sie tatsächlich "ausdefiniert" wurden, dann entsprechend "auffüllen". Vielleicht ne Liste mitführen, welche referenziert, aber nicht gefüllt worden sind. Wenn du in deinem Objekt-Baum am Ende nämlich auch Auflistungen hast, die getrennt sind, wie die in der XML-Datei dürfte das eigentlich ganz elegant lösen.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Achsel-des-Bösen
| | Zitat von SkunkyVillage
Ich hab mir das jetzt mal beides angeschaut, Achsel. Wie würdest du denn folgendes "Problem" lösen?
Es geht darum, dass ich bei jedem request prüfen möchte, ob ein Cookie gesetzt ist und wenn ja soll eine Session (falls noch nicht geschehen) gestartet werden. Quasi als Loginprüfung.
| |
Ich glaube du versuchst eine Problem zu lösen, das Django dir abnimmt. Deswegen: Wozu willst du das?
| |
Ich hab mir selbst ein Loginscript geschrieben, welches halt über eine Session läuft. Allerdings will ich die Möglichkeit haben, dass User länger eingeloggt sein können, auch wenn der Browser geschlossen wird. => Cookie.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von SkunkyVillage am 24.11.2009 18:17]
|
|
|
|
|
|
|
|
|
| | Zitat von SkunkyVillage
| | Zitat von Achsel-des-Bösen
| | Zitat von SkunkyVillage
Ich hab mir das jetzt mal beides angeschaut, Achsel. Wie würdest du denn folgendes "Problem" lösen?
Es geht darum, dass ich bei jedem request prüfen möchte, ob ein Cookie gesetzt ist und wenn ja soll eine Session (falls noch nicht geschehen) gestartet werden. Quasi als Loginprüfung.
| |
Ich glaube du versuchst eine Problem zu lösen, das Django dir abnimmt. Deswegen: Wozu willst du das?
| |
Ich hab mir selbst ein Loginscript geschrieben, welches hat über eine Session läuft. Allerdings will ich die Möglichkeit haben, dass User länger eingeloggt sein können, auch wenn der Browser geschlossen wird. => Cookie.
| |
Ganz schön exotisch, willst du dir nicht schnell ein Patent drauf besorgen?
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von [DK]Peacemaker
| | Zitat von SkunkyVillage
| | Zitat von Achsel-des-Bösen
| | Zitat von SkunkyVillage
Ich hab mir das jetzt mal beides angeschaut, Achsel. Wie würdest du denn folgendes "Problem" lösen?
Es geht darum, dass ich bei jedem request prüfen möchte, ob ein Cookie gesetzt ist und wenn ja soll eine Session (falls noch nicht geschehen) gestartet werden. Quasi als Loginprüfung.
| |
Ich glaube du versuchst eine Problem zu lösen, das Django dir abnimmt. Deswegen: Wozu willst du das?
| |
Ich hab mir selbst ein Loginscript geschrieben, welches hat über eine Session läuft. Allerdings will ich die Möglichkeit haben, dass User länger eingeloggt sein können, auch wenn der Browser geschlossen wird. => Cookie.
| |
Ganz schön exotisch, willst du dir nicht schnell ein Patent drauf besorgen?
| |
Verarsch mich nicht. Das sind meine ersten Gehversuche mit Django und das alles soll einfach nur zum lernen sein, nicht um groß was zu entwickeln. Deshalb versuch ich halt so viel wie möglich selbst zu schreiben...
|
|
|
|
|
|
|
|
|
|
|
|
Du hast echt ne dünne Haut.
|
|
|
|
|
|
|
|
|
|
Hab ich? Also in dem Fall hab ich mich nichtmal angegriffen gefühlt, sondern wollte das nur mal klarstellen. Aber komm, dass DU eine Psychoanalyse von mir erstellt hast war ja klar. Ist für mich ungefähr genauso viel wert wie die Aussagen des Herrn Bush, Mussolini und Hitler zusammen im Bezug auf Weltfrieden.
Edit: Ich hab wohl noch Mao und den Teufel vergessen.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von SkunkyVillage am 24.11.2009 18:24]
|
|
|
|
|
|
|
|
|
| | Zitat von Teufel
Du hast echt ne dünne Haut. | |
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von SkunkyVillage
Hab ich? Also in dem Fall hab ich mich nichtmal angegriffen gefühlt, sondern wollte das nur mal klarstellen. Aber komm, dass DU eine Psychoanalyse von mir erstellt hast war ja klar. Ist für mich ungefähr genauso viel wert wie die Aussagen des Herrn Bush, Mussolini und Hitler zusammen im Bezug auf Weltfrieden.
Edit: Ich hab wohl noch Mao und den Teufel vergessen.
| |
Du Arsch, deine Haut ist noch dünner, als Teufel dachte.
|
|
|
|
|
|
|
|
| Thema: Gehirnsalat ( wir unter uns ) |
![[dk]peacemaker](./avatare/[dk]peacemaker.gif)
