Das deutsche Python-Forum

Die textareas im django admin panel sind alle gleich groß. Das ist aber nicht immer schön. In PyLucid kann der User damit Stylesheets und HTML Code bearbeiten und dabei ist die default Größe ein wenig klein.

Ich hab ein kleines JavaScript gebastelt, welches die Größe dynamisch anpasst, je nach dem wie viel Inhalt in dem Textfeld drin steckt.

Das ganze kann man einfach selber nutzten, wenn man es bei seinem Projekt hier speichert: templates_django/admin/base_site.html

Der Code ist hier: http://www.djangosnippets.org/snippets/427/

Schön wäre es natürlich, wenn die Größe sich quasi "live" anpassen würde. Also wenn man beispielsweise in einem leeren Feld plötzlich viel Text reinpackt. Aber soviel wollte ich nicht machen. Wahrscheinlich wird es mit newforms-admin wieder anders zu lösen sein

In PyLucid hab ich noch andere Teile des Templates geändert: http://pylucid.net:8080/pylucid/browser ... _site.html

Vielleicht kann der ein oder andere das Snippets selber nutzten

jens hat geschrieben:Die textareas im django admin panel sind alle gleich groß. Das ist aber nicht immer schön. In PyLucid kann der User damit Stylesheets und HTML Code bearbeiten und dabei ist die default Größe ein wenig klein.

Hältst du Textareas wirklich für das geeignete Werkzeug, um Stylesheets und HTML-Code zu bearbeiten? Ohne Syntaxhighlighting und Komfortfunktionen wie automatisch schließende Tags?

Glaubst du nicht, dass eventuell ein Upload die bessere Idee wäre? Oder zumindest die Empfehlung, Stylesheets und HTML mit einem vollwertigen Editor zu bearbeiten, und dann nur noch zu pasten?

Zur Beantwortung deiner Frage trägt das natürlich nur wenig bei, aber mir scheint, dass du das Problem falsch angehst.

Edit: Quotes korrigiert

lunar hat geschrieben:

jens hat geschrieben:Die textareas im django admin panel sind alle gleich groß. Das ist aber nicht immer schön. In PyLucid kann der User damit Stylesheets und HTML Code bearbeiten und dabei ist die default Größe ein wenig klein.

Hältst du Textareas wirklich für das geeignete Werkzeug, um Stylesheets und HTML-Code zu bearbeiten? Ohne Syntaxhighlighting und Komfortfunktionen wie automatisch schließende Tags?

Glaubst du nicht, dass eventuell ein Upload die bessere Idee wäre? Oder zumindest die Empfehlung, Stylesheets und HTML mit einem vollwertigen Editor zu bearbeiten, und dann nur noch zu pasten?

Zur Beantwortung deiner Frage trägt das natürlich nur wenig bei, aber mir scheint, dass du das Problem falsch angehst.

[OT]Macht man in WordPress auch so [/OT]

Oder man macht ein Pygments Template Tag für Django.

Ja, mir ist schon klar, das man wesentlich mehr machen kann. Bis soweit das man Dreamweaver als Web-App nachgebaut hat. Aber dafür ist keine Zeit

Bei den default Größen wollte ich es aber auch nicht belassen. Das ist einfach zu klein.

Mal sehen, wenn denn mal newforms admin kommt, dann geht das evtl. auch anders...

lunar hat geschrieben:Hältst du Textareas wirklich für das geeignete Werkzeug, um Stylesheets und HTML-Code zu bearbeiten? Ohne Syntaxhighlighting und Komfortfunktionen wie automatisch schließende Tags?

Ich halte es nicht unbedingt für Benutzerfreundlich, aber mal als Gegenfrage: ist es Benutzerfreundlich, um einen vergessenen Punkt oder ein Komma zu korrigieren, eine Datei herunterzuladen, sie zu ändern, und wieder hochzuladen?

keppla hat geschrieben:ist es Benutzerfreundlich, um einen vergessenen Punkt oder ein Komma zu korrigieren, eine Datei herunterzuladen, sie zu ändern, und wieder hochzuladen?

Wieso so ein Aufwand? Vim im SSH-Fenster funktioniert klasse.

Leonidas hat geschrieben:

keppla hat geschrieben:ist es Benutzerfreundlich, um einen vergessenen Punkt oder ein Komma zu korrigieren, eine Datei herunterzuladen, sie zu ändern, und wieder hochzuladen?

Wieso so ein Aufwand? Vim im SSH-Fenster funktioniert klasse.

ich meinte benutzerfreundlich, nicht nerdfreundlich

keppla hat geschrieben:ich meinte benutzerfreundlich, nicht nerdfreundlich

Es gibt auch nano und auch der funktioniert im SSH-Fenster. Habe gehört, dass der inzwischen auch Syntax-Highlighting benutzt. Aber bei meiner letzten Benutzung habe ich gemerkt, dass er mit meinen Vim-Befehlen irgendwie nichts anfangen kann

Das Problem ist, dass manche ja nur FTP haben und AFAIK PyLucid das nur vorraussetzt. Wenn man SSH hat und n bisschen Ahnung von Django, dann hat man ja ruckzuck selber seine Seite gebastelt.

keppla hat geschrieben:

lunar hat geschrieben:Hältst du Textareas wirklich für das geeignete Werkzeug, um Stylesheets und HTML-Code zu bearbeiten? Ohne Syntaxhighlighting und Komfortfunktionen wie automatisch schließende Tags?

Ich halte es nicht unbedingt für Benutzerfreundlich, aber mal als Gegenfrage: ist es Benutzerfreundlich, um einen vergessenen Punkt oder ein Komma zu korrigieren, eine Datei herunterzuladen, sie zu ändern, und wieder hochzuladen?

Keine Ahnung, ob sowas als benutzerfreundlich empfunden werden würde... meine persönlichen Ansichten sind da wohl kein Maßstab, ich halte es wie Leonidas: emacs + ssh ist für mich benutzerfreundlich.

Gäbe es beim besten Willen keine andere Möglichkeit, würde ich aber den Upload immer noch den Textfeldern bevorzugen. Als Alternative gibt es aber doch Copy n' Paste: Strg+A, Strg+C, Strg+Tab, Strg+V wird ja wohl keinen überfordern, oder?

@Leonidas: Naja, nano unterstützt Syntaxhighlighting nicht wirklich. Genaugenommen kann es Text nur anhand von Regex-Ausdrücken farblich hervorheben, und zwar in Abhängigkeit von Dateiformat. Spätestens bei Python-Multiline-Strings sieht man, dass da ein größerer Unterschied zu vollwertigem Highlighting wie in richtigen Editoren besteht

lunar hat geschrieben:Gäbe es beim besten Willen keine andere Möglichkeit, würde ich aber den Upload immer noch den Textfeldern bevorzugen. Als Alternative gibt es aber doch Copy n' Paste: Strg+A, Strg+C, Strg+Tab, Strg+V wird ja wohl keinen überfordern, oder?

Mir schwirrt gerade die Idee im Kopf einen Editor wie Emacs oder Vim per RPC Seiten bearbeiten zu lassen - ist ja fast schon so eine Art "Contribute". Machbar ist es, wie die LodgeIt-Interfaces beweisen.

lunar hat geschrieben:@Leonidas: Naja, nano unterstützt Syntaxhighlighting nicht wirklich. Genaugenommen kann es Text nur anhand von Regex-Ausdrücken farblich hervorheben, und zwar in Abhängigkeit von Dateiformat. Spätestens bei Python-Multiline-Strings sieht man, dass da ein größerer Unterschied zu vollwertigem Highlighting wie in richtigen Editoren besteht

Gut, so weit habe ich es gar nicht getestet, habe nur im Gentoo-Wiki dazu etwas gesehen. Wozu auch? Ich habe bereits einen Editor. Jetzt brauche ich noch einen MUA
Abgesehen davon ist Pygments auch nicht viel mehr als ein etwas aufgebohrter Parser der mit Regulären Ausdrücken konfiguriert wird.

Leonidas hat geschrieben:

lunar hat geschrieben:Gäbe es beim besten Willen keine andere Möglichkeit, würde ich aber den Upload immer noch den Textfeldern bevorzugen. Als Alternative gibt es aber doch Copy n' Paste: Strg+A, Strg+C, Strg+Tab, Strg+V wird ja wohl keinen überfordern, oder?

Mir schwirrt gerade die Idee im Kopf einen Editor wie Emacs oder Vim per RPC Seiten bearbeiten zu lassen - ist ja fast schon so eine Art "Contribute". Machbar ist es, wie die LodgeIt-Interfaces beweisen.

Was aber wohl kaum ein Feature für die Masse sein wird, solange entsprechende Editoren nicht direkt Unterstützung dafür bieten...

Die Lodgeit-Schnittstellen wurden ja auch aus der Notwendigkeit geboren, und sind auch nur für zwei Editoren verfügbar...

lunar hat geschrieben:@Leonidas: Naja, nano unterstützt Syntaxhighlighting nicht wirklich. Genaugenommen kann es Text nur anhand von Regex-Ausdrücken farblich hervorheben, und zwar in Abhängigkeit von Dateiformat. Spätestens bei Python-Multiline-Strings sieht man, dass da ein größerer Unterschied zu vollwertigem Highlighting wie in richtigen Editoren besteht

Gut, so weit habe ich es gar nicht getestet, habe nur im Gentoo-Wiki dazu etwas gesehen. Wozu auch? Ich habe bereits einen Editor.

nano startet halt schön schnell. Ich habe keine Lust, emacs zu starten, nur um einen Buchstabendreher in einer Konfigurationsdatei zu korrigieren...

Abgesehen davon ist Pygments auch nicht viel mehr als ein etwas aufgebohrter Parser der mit Regulären Ausdrücken konfiguriert wird.

Nano hat noch nicht mal einen Parser, da läuft alles über Reguläre Ausdrücke...

lunar hat geschrieben:Mir schwirrt gerade die Idee im Kopf einen Editor wie Emacs oder Vim per RPC Seiten bearbeiten zu lassen - ist ja fast schon so eine Art "Contribute". Machbar ist es, wie die LodgeIt-Interfaces beweisen.

Was aber wohl kaum ein Feature für die Masse sein wird, solange entsprechende Editoren nicht direkt Unterstützung dafür bieten...[/quote]
Das Problem sehe ich im Moment weniger an den Editoren. Viele kann man durch Plugins erweitern. DrPython könnte man ziemlich einfach mit so etwas ausstatten, gleiches gilt für TextMate. Das Hauptproblem ist, dass es keine Frameworks/CMS-Systeme gibt, die sowas unterstützen würden. Es wäre aber interessant, so ein Interface zu designen und in diverse CMS-Systeme einzubinden. Wenn sowas unterstützt werden würde, dann würde auch die Editor-Unterstützung nicht lange auf sich warten lassen.

Ich habe vor einiger Zeit einen Blog gesehen, dessen Administration via AJAX und DHTML ging - aber das ist sogar noch komfortabler blackbird - sowas hätte ich gerne als Plugin für Textpress

lunar hat geschrieben:Die Lodgeit-Schnittstellen wurden ja auch aus der Notwendigkeit geboren, und sind auch nur für zwei Editoren verfügbar...

Was aber hauptsächlich daran liegt, dass die Hauptnutzer von LodgeIt entweder den einen oder den anderen Editor nutzen.

lunar hat geschrieben:nano startet halt schön schnell. Ich habe keine Lust, emacs zu starten, nur um einen Buchstabendreher in einer Konfigurationsdatei zu korrigieren...

Für mich als vim-User fällt dieses Argument weg, da Vim ähnlich schnell wie nano startet - kann sein, dass da einige Millisekunden Unterschied sind, aber letztendlich ist das aus User-Perspektive egal. Und ich habe für die Config-Dateien oft schon ein entsprechendes Syntax-Highlighting dabei, so als zusätzliches Schmankerl.