Druckversion des Themas
Hier klicken um das Topic im Orginalformat anzusehen
Forum Sefrengo.org _ Hacks/ Sonstiges _ CSS-Editor-Bereinigung Version 1.0
Geschrieben von: Olaf Thu. 7. December 2006, 00:30
So, hier der komplette Hack für den CSS-Editor!
Die andauernden Probleme die es immer wieder gab, das der Upload nicht klappt, das Regeln die wohlüberlegt eingefügt wurden angemeckert wurden, das es nicht möglich war Hacks einzubauen weil es die Fehlerprüfung unmöglich machte abzuspeichern, alles passe, Ende, vorbei. Der Editor gibt jetzt in der Datei das aus was hochgeladen wird, ganau in der Reihenfolge, mit Zeilenumbrüchen, Leerzeichen und allem was ihr sonst angebt.
Aber Achtung!!! Alle Kommentare werden gnadenlos entfernt!!! Wenn jemand mag, es darf sich gerne noch darüm gekümmert werden, bkm und ich sind daran gescheitert. Es ist eine kleine Vorbereitung in der Datei versteckt, näheres aber dann von mir, ihr wisst ja wo ihr mich findet.
Die Fehlerberichte und der Entwicklungsprozess ist http://forum.sefrengo.org/index.php?showtopic=525&st=0, wenn nötig dann auch dort weiterdiskutieren, Fehler zu melden.
Ich empfehle abgebildete Einstellungen im Projekt vorzunehmen:
|
ZIP entpacken, ins Backendverzeichnis kippen, hochladen. Die enthaltene css_edit.tpl sollte auch mit hochgeladen werden! Es ist nur eine Änderung von einem Textfeld zu Textarea gemacht, dies ist notwendig da es auch die Möglichkeit gibt das mehrzeilige Selektoren vorkommen.
CSS_Editor_Bereinigung_v._1.0.zip ( 13.22KB )
: 76Ich persönlich würde mich freuen wenn sich die Maintainer mal dazu äußern würden ob sie das übernehmen. Ich bin der Meinung, dass damit der Editor so bleiben kann wie er ist. Für die Zukunft würde ich noch anregen, eine Möglichkeit zu schaffen direkt in der physischen CSS arbeiten zu können, sprich, die Datei selbst in eine Textarea zu laden und dort zu editieren. Zu beachten wäre dabei, dass nicht nur die Datei editiert wird sondern auch die Einträge in der DB zu aktualiesieren sind. Dies könnte sich hinter dem Bleistifftsymbol in der Rechten Spalte der Übersicht verbergen, wozu das sich dort öffnende Feature da ist erschließt sich mir nicht.
Vielleicht wär das auch was für ne Thickbox
Mitgewirkt haben, bkm, summerbrother und braendle, Danke.
Geschrieben von: bjoern Thu. 7. December 2006, 10:57
Wenn die Erweiterung hält, was sie verspricht, kommt Sie in den Kern.
Thema physische Dateien:
Die gibt es nicht. Die Datei wird aus Datenbankinhalten generiert. Somit ist die Datei praktisch nur ein "Cache". Das ist ja gerade das Hauptproblem des Editors.
Damit dieser die CSS Datei wie gewünscht abbilden kann, muss die interne Logik so umgebaut werden, das die Datei als Ganzes betrachtet wird und bei Gelegenheit in Ihre Einzelteile zerlegt wird.
Momentan läuft es so, dass es nur die Einzelteile gibt, die bei Bedarf zu einem großen Ganzen zusammengesetzt werden. Dummerweise entsprechen die verfügbaeren Einzelteile aber nicht der Summe der möglichen Einzelteilen. Womit ich sagen will, letzteres ist größer, und noch schlimmer: es ist eine dynamische Größe, die alleine durch die Entwicklung von CSS Standards wächst.
Geschrieben von: Olaf Thu. 7. December 2006, 11:10
Ach so, du gehst da anders ran. Die Datei existiert sehr wohl, die wird auf den Server geschrieben und wird bei jedem edit gändert und vom Besucher-Browser geladen. Ich dachte jetzt man holt die Datei in eine Textarea, schreibrechte hat sie automatisch, editiert die dort und stößt dann über die inc.css.php sowas wie einen upload an. In dessen Folge wird die DB und die Datei aktualisiert.
Wenn das so nicht geht, dann wirds schwieriger.
Zu der unbekannten Größe "Standards", das kann ja erst mal so bleiben, automatisiert geht nur CSS1, alles weitere muss per Hand gemacht werden. Oder was willst du damit sagen!?
Geschrieben von: bjoern Thu. 7. December 2006, 11:24
Damit will ich sagen, dass Du als Programmierer dann ewig dem "gerade aktuellen Standard" hinterherprogrammierst, weil sich dauernd etwas ändert. Wenn Du Supportverträge verkaufen willst, ist das die ideale Lösung. Willst Du aber etwas allgemeingültiges schaffen, was möglichst robust ist und lange Besatand hat, ist dies der falsche Weg.
Daher will ich ja umbedingt, das die Grundlage des CSS Editors eine Datei ist und über eine simple textarea bearbeitbar ist. Der WYSIWYG CSS Editor kann ja gerne darauf aufbauen, überhaupt kein Problem. Aber wenn es kracht (also wie jetzt), nicht das gewünschte abgebildet werden kann, dann muß es die Möglichkeit geben, auf die unterste Ebene zu kommen und dort arbeiten zu können.
Solange dies nicht möglich ist, ist der CSS Editor keine dauerhafte Option für das System.
Geschrieben von: Olaf Thu. 7. December 2006, 11:46
Mit diesem Hack erreichst du doch die unterste Ebene, in der kleinen Textarea ganz links 
Da kannst du jetzt reinschreiben was du willst, es wird einfach alles übernommen! So wie ich von Anfang an wollte, schon beim anderem Projekt (leider nicht mehr nachzulesen). Wenn ich in meine CSS "Blödsinn" reinschreibe, dann steht das jetzt auch drin. Es Kracht nicht mehr!
Nebenbei, CSS1 ist allgemeingültig, wird Bestand haben.
IMHO ist von der Programmlogik unser Ziel schon erreicht. Alles andere, die automatisierte Eingabe und das Edit "direkt an der Datei" sind nun nur noch Zusatzfeatures.
Klar wäre es schön die Automatismen mal anzupassen, aber das wäre ein anderes Thema.
Wahrscheinlich denkst du viel weiter als ich
Nachtrag Wie sieht denn die Alternative aus, Editor rausschmeißen, Textarea rein? Wie soll denn derjenige der von CSS nur marginal gehört hat seine Schriftart ändern, der dreht doch durch 
Geschrieben von: feniweb Thu. 7. December 2006, 18:50
@Olaf
Super Arbeit.
@björn
Wie sieht den das mit den im FCK+Tiny auswählbaren CSS-Einstellungen aus, hat das keinen einfluss? Wird das alles im ContentFlex aus dieser spezielen CSS-Datei angezeigt und Auswählbar?
Gruss
Geschrieben von: andi Fri. 8. December 2006, 08:30
hallo olaf
klingt alles sehr gut. aber irgendwie bin ich zu blöd, die von dir vorgeschlagenen einstellungen für das projekt zu tätigen. ich finde unter der ganzen administration nirgends diese optionen zum einstellen der css-parameter. 
gruss andi
Geschrieben von: Olaf Fri. 8. December 2006, 08:35
Admin -> Projekte -> Schraubenschlüssel (2. Symbol von rechts in der rechten Spalte des zu bearbeitenden Projektes) -> ganz runterscrollen
Geschrieben von: andi Fri. 8. December 2006, 08:36
argh, das icon (kommt mir eher vor wie eine bombe) habe ich doch glatt übersehen, weil es so abgesoftet war :-) sorry und danke!
Geschrieben von: bjoern Fri. 8. December 2006, 11:39
Ja, erst einmal eine Textarea, die eine Datei schreibt. Das ist die unterste Ebene, die einfach da sein muss. Darauf können grafische Tools aufgesetzt werden. Wer möchte, kann so etwas ja programmieren. Sicherlich erst einmal ein Komforteinbusse.
Ich weiß jetzt nicht genau, was Du meinst, und wenn ich es wüsste, bin ich mir relativ sicher, das das Thema dieses Threads ein anderes ist.
Geschrieben von: Olaf Fri. 8. December 2006, 11:51
Na dann proggt mal. Frage mich nur wie dann die ganzen Styleauswahlen in den Modulen gehen soll, das geht doch alles über die DB. Wie gesagt ich seh das nicht so. Solange kein neuer Editor da ist würd ich den alten nicht rausschmeißen. Die Textarea kann ja trotzdem kommen, ich schlug ja da auch was vor.
Wir können das beenden, mein Standpunkt ist vertreten, vielen Dank
Geschrieben von: eknem Fri. 8. December 2006, 17:33
wie wäre es mit einer Trennung?
1. Eine CSS für das Layout, per Textarea zu bearbeiten.
2. Eine CSS für den Content, mit dem jetzigen Editor zu bearbeiten.
Ich mache es jetzt auch schon so. Die CSS fürs Layout ist hardgecodet, die andere wird importiert. Nachteil ich kann die CSS fürs Layout nur per FTP ändern. Hier wäre eine Textarea für mich sehr nützlich.
Hätte den Vorteil, dass die Angaben die nur fürs Layout notwendig sind gar nicht in der Datenbank auftauchen. Und die damit Auswahl, der für die Redakteuer erforderlichen Regeln nicht so umfangreich ist.
Geschrieben von: Olaf Fri. 8. December 2006, 19:13
1. Eine CSS für das Layout, per Textarea zu bearbeiten.
2. Eine CSS für den Content, mit dem jetzigen Editor zu bearbeiten.
Wenn du diese Unterscheidung für dich machst o.k., aber wozu sollte Sefrengo sich darum kümmern, siehe mein Vorschlag weiter oben. Dann kannst du entscheiden wie du bearbeitest
Hätte den Vorteil, dass die Angaben die nur fürs Layout notwendig sind gar nicht in der Datenbank auftauchen. Und die damit Auswahl, der für die Redakteuer erforderlichen Regeln nicht so umfangreich ist.
Das wiederum ist ein guter Gedanke, entweder beim Upload ein Schalter der bewirkt ob die Daten für Module bereitgestellt werden oder nicht. Oder/und im Editor dafür ein Schalter bei den entsprechenden Selektoren. Nur ob das jemand reinprogrammiert.... müsste bestimmt die DB angepasst werden
Geschrieben von: eknem Fri. 8. December 2006, 20:04
Da ist mein Gedankengang ganz einfach, die eine CSS gehört zum Layout (hat sich keine Redakteuer drum zu kümmern) die andere gehört zum Content und damit von Fall zu Fall in den Bereich des Redakteuers.
Eine etwas andere, bzw. meine besondere Sichtweise des Begriffes "Trennung von Layout und Inhalt"
PS: darum soll sich auch nicht Sefrengo kümmern, sondern der Webseiten Entwickler.
Geschrieben von: summerbrother Fri. 8. December 2006, 20:46
So, nun auch mein Senf mal wieder dazu. Die absolute Trennung ist ein schöner Gedanke aber doch in der Praxis nicht durchzusetzen. Haben wir doch schon alles durchprobiert. Olaf, weisst Du noch bei der XHTML-Version ? Da haben wir doch genau das praktiziert. War aber nicht wirklich praktikabel.
Den Editor komplett zu entfernen und gegen eine Textarea auszutauschen halte ich für Quark. Wo ist dann der Unterschied zur Bearbeitung per FTP ?
Olafs Ansatz ist schon ganz ok und praktikabel. Nu stell man sich noch vor, das in der Übersicht der Regeln mittel Ajax die jewelis zu bearbeitende Regel sich *zisch* öffnet und beim schliessen speichert...
Wahlweise kann man in select-Feldern klicken oder einfach, wie jetzt auch, in der kleinen Textarea direkt schreiben....
Geschrieben von: Olaf Fri. 8. December 2006, 22:57
@eknem
FULLACK, und damit ist das dann eine Frage des Rechtemanagments, die vom Layout bekommt kein Redakteur zu Gesicht und fertig.
@summer
XHTML-Edition, du meinst das Musterlayout, da zeigte sich das es nicht allgemeingültig zu händeln war. Weil du nie weist was der User genau braucht, und damit sind wir wieder bei eknem, das muss der Admin machen
Wir werden ja sehen wie Björn letztlich entscheidet, ich seh es so, dass sich erst mal niemand finden wird der einen anderen Editor da einbaut.
Geschrieben von: braendle Fri. 8. December 2006, 23:44
Vielleicht sollte man jemanden fragen, der sich damit auskennt
Geschrieben von: Olaf Sat. 9. December 2006, 00:37
Ja mei, ich geh immer davon aus das niemand Zeit hat 
Mich persönlich wird's natürlich freuen wenn du meine Vorstellungen umsetzt
Nu Spass beiseite, du hast dich ja sehr rar gemacht. Wenn ich gar nicht mehr weitergekommen wäre hätte ich dich bestimmt auch gefragt. So denke ich aber immer, geh damit keinen auf die Ketten, die haben alle so viel zu tun. Und im Forum hab ich ja gefragt, fällt mir gerade ein. Das ist denk ich die beste Adresse, oder!?
Und dann heißts, Freiwillige vor...
Geschrieben von: bkm Sat. 9. December 2006, 00:37
Oder vielleicht mal ganz einfach einen Plan erstellt was wirklich gebraucht wird und nicht einfach zur nächsten Version wieder raus fliegt.
Eine Kombi Version DB=> cssfile && CSSEditor=>Textarea finde ich schon nicht schlecht, wenn man davon ausgeht das nicht jeder CSS
aus dem "Kopf" erstellt und Module auch auf CSS zugreifen.
IMHO
Geschrieben von: bjoern Sat. 9. December 2006, 00:45
Damit wir uns nicht falsch verstehen, ich habe nichts dagegen, wenn wir ein möglichst komfortables Tool haben.
Es muss technisch aber so gestaltet sein, dass sich die CSS Datei ohne Kompromisse bearbeiten lässt.
Das diejenigen, die wirklich mit CSS arbeiten wollen, dies, aufgrund der Einschränkungen des Editors, per FTP und damit am System vorbei machen, kann es ja nicht sein.
Die Textarealösung ist für mich die einzige Möglichkeit, die ich ressourcenmässig bewältigen kann. Das dies nicht nur ein Gewinn ist, ist mir klar. Unter dem Strich wiegt für mich in diesem Fall der Gewinn an Flexibilität aber mehr als der Erhalt vom Komfort.
Wenn jemand natürlich die Zeit hat, eine Lösung zu finden, die weniger schmerzhaft ist, würde ich das natürlich sehr begrüssen.
Geschrieben von: Olaf Sat. 9. December 2006, 01:27
Das ist doch nun gegeben, was stört denn noch, dann raus damit. Das einzige Gegenargument kam bisher von andi, wegen dem Meckern beim Upload, ich dachte es wäre besser so, kann aber deaktiviert werden.
Ebend, gibt es dir nicht zu denken wenn sogar ich sage, "ist o.k. so, kann so bleiben"
Dann sag mir doch das es so nicht geht wie ich vorschlug, dann geb ich Ruhe. Mir fehlen oft eure Argumente
Wenn du es schaffst eine Textarea zu proggen, dann kann es doch nicht mehr so ein großer Schritt sein, die in ein neues Template zu packen und zusätzlich anzubieten. Wird die Datei gespeichert schreibst du sie gleichzeitig in die DB und fertig.
Es kann IMHO beides geben!
Geschrieben von: luxli Sat. 9. December 2006, 02:55
Der CSS-Editor ist doch für Newby und schnelles Ändern oder Erstellen einzelner CSS ideal und die Auswirkung kann sofort kontrolliert werden. Darum begrüsse ich diese Bereinigung.
Andererseits
Das ist der springende Punkt.
Wäre es nicht möglich, dies ähnlich dem was Alexander http://forum.sefrengo.org/index.php?s=&showtopic=598&view=findpost&p=4588 im Nachsatz erwähnt zu lösen.
Geschrieben von: andi Sat. 9. December 2006, 11:24
stimmt so nicht ganz, da gabs noch einen zweiten punkt, welcher björn nochmals «aufgabelt»:
genau hier störe ich mich am aktuellen system. da mir der editor wirklich zu umständlich ist muss ich immer den umweg über den ftp machen. will ich das ganze auch noch im system für die module bereit halten muss ich zusätzlich jedes mal das veränderte css-file in sefrengo neu importieren. eine «einfache» textarena wäre für mich ein segen.
Geschrieben von: Olaf Sat. 9. December 2006, 11:41
Sach, liest jemand was ich schreibe???? Das ist kein Problem des Editors! Der Editor öffnet sich wenn du auf einen Selektor klickst. Das ist ein Problem des Core! Stichwort, Vorhaltung der CSS, Einbindung ins System.
Somit gebe ich die Frage zurück, was stört am jetzigem Verfahren mit Upload und Editor, was hindert dich daran mit diesem Hack ohne FTP zu arbeiten? Bitte nicht wieder Textarea, das gehört hier nicht hin.
EDIT Ach so, im übrigen fehlen mir wieder deine Argumente
Du sagst es hindert dich, aber was hindert dich daran, das lässt du offen.
Es kann doch nicht sein, das ihr das nicht kapiert.
Geschrieben von: feniweb Sat. 9. December 2006, 11:46
@alle
Aber über ein Textarea hätte ich auch nichts.
Müssen die CSS-Regeln in der DB stehen um allen Modulen zugänglich zu machen?
Gruss
Geschrieben von: andi Sat. 9. December 2006, 16:45
ganz einfach...es ist umständlich (da bin ich mit einem geeignetem texteditor schneller)
auch mit hack muss ich mit einem ftp arbeiten...ausser ich will den (umständlichen) editor nutzen, um neue klassen, selektoren usw. anzulegen.
ich schalt mich hier jetzt mal aus, verfolge das geschehen aber gerne weiter...
gruss andi
Geschrieben von: Olaf Sat. 9. December 2006, 18:04
Das ist doch aber ein Programm für PC oder MAC, nich fürn Server
auch mit hack muss ich mit einem ftp arbeiten...ausser ich will den (umständlichen) editor nutzen, um neue klassen, selektoren usw. anzulegen.
Nein, ebend nicht, du sparst jetzt den Schritt FTP. Du nutzt einfach den Editor nicht! Du editierst deine Dateien local, lädtst sie hoch und fertig. Das ist der einzige Gewinn den dieser Hack bringt. Und natürlich das es wenigstens möglich ist im Editor eigene Angaben zu machen und er Alles annimmt. Wenn du das verstehst und dann meinen FeatureRequest richtig einordnest, dann sind wir doch einer Meinung, oder!?
EDIT
Wieso ist es eigentlich umständlich mit dem Editor neue IDs anzulegen? Oben Selector auswählen, NAME eingeben, in Textarea die Regeln reingeschrieben. Ich könnt mir sogar vorstellen zukünftig bei kleineren Sachen so zu arbeiten. Ich glaub nicht das ein anderer Editor viel schneller zu bedienen ist. Am Rande bemerkt
Geschrieben von: summerbrother Sat. 9. December 2006, 18:55
Ich bin der festen Überzeugung, dass mit dem Editor in seiner jetzigen Form noch keiner gearbeitet hat. Sonst würde er erkennen, dass die Arbeit um ein vielfaches erleichtert ist, für alle Beteiligten.
Ich hätte auch nie gedacht, dass Olaf sich irgendwann mal für den Editor ausspricht, aber ich habs ja schon immer gesagt ..
So, ich fahr ne Woche zum Skifoahn und Ihr diskutiert das hier schön weiter..
Geschrieben von: braendle Sat. 9. December 2006, 23:36
Ich nu wieder ...
Danke Olaf, für den Einsatz ... ich hatte wenig Zeit, sehr wenig, einfach zu wenig um mich um größere Umbauten zu kümmern.
Die Problematik des Editors ist mir schon länger bewußt, aber für mich ist das Hobby und mit Beruf und Familie war das nicht in Einklang zu bringen.
Konzeptionell muss man sich eines klar machen:
Stilklassen müssen in den Modulen bereitgestellt werden könnn.
Ob das aus der DB geschieht oder nur durch Parsen der Stildateien ist eigentlich wurscht. Sinn und Zweck des Editors war, die Stile in der DB vorzuhalten um ein ständiges Parsen der CSS-Dateien (und damit Performance-Probleme) zu verhindern.
Also sollten die CSS-Infos - auch beim Bearbeiten einer CSS-Datei als ganzes - wieder in der DB laden. Das kann man sicherlich machen, was wohl am meisten stört ist der unzureichende Support von CSS2/CSS3-Selektoren und -Regeln beim Validieren und Schreiben ins File. Die Unantastbarkeit des CSS-Files sollte für die Zukunft wohl festgeschrieben werden.
Wobei - wenn ich Tools wie Dreamweaver sehe ... ach lassen wir das ... ich mag diese Vergleiche nicht.
Nun, es gibt für alles Lösungen:
1. Das CSS-File wird zukünftig nicht automatisch generiert, kann aber über einen entsprechenden Button generiert werden. Hierbei gehen aber Informationen, die nicht in der DB stehen verloren - eine entsprechende Warnung wird vorher ausgegeben.
2. CSS-Regeln, die über den Editor bearbeitet werden, werden im CSS-File auf Anforderng ersetzt. Nur die Regel selbst - nicht die ganze Datei. Jede Regel kann ene Kommentierung bekommen, die bei Generierung eines CSS-Files vor der Regel im CSS-File ausgegeben wird.
3. Das CSS-File wird als Textarea bearbeitbar und wird nach Bearbeitung in die DB importiert. Kommentare ausserhalb der Regeln werden beim Import der folgenden Regel des CSS-File zugeordnet.
4. Eine spezielle Kommentierung in der CSS-Datei ermöglicht Bereiche, die vom System als "benutzerdefinierte Regeln" interpretiert und in die DB ohne Änderungen übernommen werden.
Dies sollte die spezielle Hacks etc. die man so als Hardcore CSSler benötigt ermöglichen. Schlimmstenfalls kann eine komlette CSS-Datei als benutzerdefinierte Regel angelegt werden.
Die Kommentierung könnte so aussehen: /** UDCSS ..... UDCSS **/
"Benutzerdefinierte Regeln" werden immer in einem einfachem Textarea bearbeitet - komfortfreie Zone.
5. Es gibt in der DB eine Kopie der Regeln für die Auswahl in den Module und zum Generieren der Datei - für alle Notfälle
6. Validierungen werden am File durchgeführt und nutzen den CSS-Validator vom W3C o.ä. Tools im Netz.
7. Validierungen einzelner Regel werden ebenfalls über das W3C durchgeführt - dazu müssen ggf. temporäre File geschrieben werden können -> Schreib-Lösch-Rechte im Filesystem notwendig.
8. Die Vorschau bei Änderungen wird - wenn möglich - mit Seiten durchgeführt, die die Regel enthalten
9. Beim Upload einer CSS-Datei wird die nur importiert. Eine Prüfung nach W3C wird nur nach Aufforderung durchgeführt.
10. Einige der Ideen könnten man per Projekt-Einstellung zwischen Option und Pflicht umschaltbar machen, z.B. automatische Prüfung mit W3C-Validator, Auswahl des Validators aus einer Liste unterstützter Validatoren, Automatische Generierung des CSS-Files bei Neuanlage etc.
Die Liste der Option kann lang werden
11. Der Regel-Editor kann sicherlich optimiert werden und CSS-Regeln aus den Standards CSS2 und CSS3 unterstützen. Das Bedienkonzept kann optimiert werden.
12. Der Regel-Editor sollte als Unterstützungstool beim Bearbeiten von CSS-Files fungieren und sich dort nur im Bereich der aktiv bearbeiteten Regel auswirken.
Weitere Wünsche sind gerne gesehen.
So ... jetzt trink' ich mal meinen Wein weiter ... und warte auf die Reaktionen
Geschrieben von: Olaf Sat. 9. December 2006, 23:50
Das ist ganz einfach, lieber den Spatz in der Hand als den Adler auf dem Dach.
Schöne Woche
Gibts denn schon Schnee in Europa!?einverstanden
Geschrieben von: bkm Sun. 10. December 2006, 00:49
@braendle
Wäre dazu nicht ein Ansatz ein weiteres Feld in der DB (xxx_css) zuschaffen wo beim ersten auslesen des Files
die komplette Regel von /* bis } oder selector bis } gespeichert wird.
Dieses könnte dann zum zerteilen (für die DB bzw. den Editor ) oder neu schreiben des Files genutzt werden.
Geschrieben von: MaZderMind Sun. 10. December 2006, 04:24
Hi
Ich hab den Thread lange verfolgt und mir die Erweiterung auch angeguckt. Ich kann bjoerns Problem nachvollziehen und stimme ihm auch zu, verstehe abe nicht wo genau das Problem besteht.
Olafs bearbeitung ist doch gut und seine Idee hinter dem bearbeiten-Symbol der Stylesheet-Datei eine Textarea unterzubringen ist noch besser.
Für den Moment müsste es so aussehen, dass aus den DB-Inhalten eine CSS-Datei gemacht, der Inhalt in der Textarea ausgegeben und das ganze angezrigt wird. Beim speichern wird dieser Weg zurückverfolgt und die Datei wieder in die DB geschrieben.
Was ich aus Björns aussagen nun rausgelsen hab, ist dass dieser Weg idealerweise anderstum laufen sollte. Das heißt alles wird in der Datei gespeichert, der Editor liest die Datei ein, stellt die Regeln dar und speichert änderungen direkt in der Datei ab.
Problem stellt in diesem Fall die auswahl der Klassen z.B. im Editor dar. Die könnte über einen einzelnen Regex passieren, der die Klassennamen aus der Datei ausliest und in der DB ablegt. Bei jedem Backendseitenaufruf wird über das Dateialter die konsistenz dieser Werte getestet und ggf. erneueret.
Schritt eins ist nicht so schwehr einzubauen -- einfcher vermutlich als der Hack. die inc.css_edit_file (+zugehöriges Template) muss umgebaut werden, sodass die selben Prozesse wie beim Uploaden einer Datei ablaufen.
Schritt zwei ist eine tiefgreifende Änderung im core an die selbst ich mich nicht so ohne weiteres rantrauen würde. Vorerst sollte der erste Schritt allerdings genügen.
Gruß, Peter
Geschrieben von: andi Sun. 10. December 2006, 10:42
Nein, ebend nicht, du sparst jetzt den Schritt FTP. Du nutzt einfach den Editor nicht! Du editierst deine Dateien local, lädtst sie hoch und fertig. Das ist der einzige Gewinn den dieser Hack bringt. Und natürlich das es wenigstens möglich ist im Editor eigene Angaben zu machen und er Alles annimmt. Wenn du das verstehst und dann meinen FeatureRequest richtig einordnest, dann sind wir doch einer Meinung, oder!?
dein feature-request ist schon korrekt
. trotzdem wäre ein bearbeiten der css in einer textarea direkt im backend erfüllender als erst das css runterzuladen, im editor anzupassen und wieder zu importieren. habe mir gerade nochmals alles durchgelesen: grundsätzlich sind wir doch einer meinung update:
was mich beim jetztigen editor mit hack noch stört
- löschung der kommentare (diese sind bei grossen css-dateien für die strukturierung unumgänglich)
- sortierung der neuen einträge (ein neuer eintrag soll nicht immer am schluss der css eingesetzt werden - wiederum thema strukturierung)
- fehlende textarea für direkte bearbeitung (jaaaa, steinigt mich)
Geschrieben von: Olaf Tue. 12. December 2006, 11:10
Jo, so viele Ideen, so viele Gedanken, sogar andi und ich = Einigkeit
Und nu? Braendle, hast du jetzt Zeit das anzugehen? Hört sich eigentlich so an, dein Post. Wollen wir das angehen? Brauchst du mich dazu?
Sonst noch jemand Zeit und Lust da mitzumachen? Geben uns die Maintainer ihren Segen, helfen sie vielleicht sogar mit?
Geschrieben von: braendle Tue. 12. December 2006, 14:13
Und nu? Braendle, hast du jetzt Zeit das anzugehen? Hört sich eigentlich so an, dein Post. Wollen wir das angehen? Brauchst du mich dazu?
Sonst noch jemand Zeit und Lust da mitzumachen? Geben uns die Maintainer ihren Segen, helfen sie vielleicht sogar mit?
Jepp, mein Post hört sich so an ...
Nein, für den Anfang brauch ich keine Unterstützung für die Umsetzung ... aber zum Testen allemal. Verbesserungsvorschläge nehme ich aber weiterhin gerne und dankend an
Geschrieben von: Olaf Wed. 13. December 2006, 00:43
Ahh gute Neuigkeiten. Verbesserungsvorscläge, hm, eigentlich fällt mir nich so viel ein. Wie Andy schon schrieb, die Sortierung!
zu 6. vielleicht noch einstellbar welcher Level/Profil, in der URL zu erreichen per profile=css1 , 2 , 21 oder 3
zu 8. vielleicht eine Seite aus dem Frontend, einfach die CSS nach den vorhandenen einbinden
Das trau ich mir aber nur zu schreiben weil deine Ausarbeitung schon sehr komplex sind. Eigentlich braucht es nicht alles auf einmal was du alles aufzählst. Spatz <-> Adler
Nicht das wir ewig vom Adler träumen müssen 
EDIT ach so, wenn Bedarf besteht kann ich dir eine CSS erstellen, wo alles an Zeugs drinnen vorkommt was der Editor unterstützen sollte. Geb bescheid...
Geschrieben von: summerbrother Fri. 15. December 2006, 10:40
Schöne Woche
Gibts denn schon Schnee in Europa!?einverstanden
Zum ersten Rumrutschen hat es gereicht. Die Italiener sind da Meister im Präparieren.
Wenn Ihr noch wen zum Testen braucht, bin ich dabei...
Geschrieben von: mika Mon. 18. December 2006, 18:58
jetzt muss ich noch ne blöde frage stellen: ich hab die dateien von olafs hack hoch geladen und die einstellungen im projekt vorgenommen.
nun lade ich die betreffenden css-dateien über Design > CSS hoch und nach wie kennzeichnet das System bei diversen CSS-Formulierungen (z. B. * html .clearfix od. #main a[href^="http:"], #main a[href^="https:"]) den Selektor als fehlerhaft.
Bedeutet das nun, dass zwar die "fehlerhaften CSS-Dateien" ins System aufgenommen werden (Administration > Projekte > Fehlerhafte CSS-Regeln in CSS-Dateien aufnehmen 2=ja/0=nein = 2) aber trotzdem als fehlerhaft gekennzeichnet werden und das völlig normal ist, oder hab ich was vergessen?
lg Michel
Geschrieben von: andi Mon. 18. December 2006, 19:25
hallo mika
ich zitiere mich gleich selber mit der gleichen frage, welche ich in einem anderen beitrag bestellt hatte:
und die antwort von meister olaf:
Du wirst beim Upload zwar drauf hingewiesen aber es wird übernommen. Es kann ja mal sein du hast wirklich was vergessen oder falsch gemacht, nu kannst du die Regeln checken, wenn du nun diese Regeln speicherst werden sie auch als gültig übernommen.
ist also gewollt.
Geschrieben von: Olaf Mon. 18. December 2006, 21:48
@mika, noch ein Zitat:
Aber Achtung!!! Alle Kommentare werden gnadenlos entfernt!!!
Ich weiß jetzt nicht ob Yaml den Hack für IE5 MAC verwendet, das ist der /* no IE5 \*/ kontrollier mal. Denn der wird entfernt.
Ansonsten würde mich sehr freuen wenn du sonstige Erfahrungen mitteilst.
Geschrieben von: amk Mon. 18. December 2006, 22:18
nebenbei bemerkt: IE MAC? was ist bzw. war das eigentlich?!
Geschrieben von: mika Mon. 18. December 2006, 22:42
wie meinst' des jetzt? soweit ich weiss, war das ne superduperspezial-mac-ie-5.2-Version (zumindest bei OSX). Aber ich hab keinen. Trotzdem hätt ich gerne ein barrierearmes, browserübergreifend funktionierendes CSS. Und da stellt Yaml halt schon eine gute Plattform zum weiterarbeiten dar.
Aber zum Thema: Der Editor schmeisst das CSS derart um, dass ich Zeile für Zeile per Hand lesen muss. (sind halt auch eine große Menge Kommentare im Yaml-CSS drin. Ich experimentiere gerade mit der Datei /css/main/iehacks.css aus dem aktuellen YAML-Pack yaml_252_06110101)
Mit Dateivergleich meckert mein Programm, dass aufgrund zu umfangreicher Unterschiede hier kein Vergleich mehr möglich ist.
dauert also.@olaf: wie kommst du drauf, dass der Editor den mac-Hack rausschmeisst. Wird der als Kommentar deklariert?
michel
Geschrieben von: andi Mon. 18. December 2006, 23:00
nunja. ich würde sagen in der grafischen branche (leider) ein noch nicht ausgestorbener browser. bei seiten mit zielpublikum «macintosh user» sicherlich noch immer empfehlenswert zu unterstützen. immerhin tauglicher als ie 5 win.
soweit mir bekannt http://www.yaml.de/yaml_css_struktur.html. bietet aber eine möglichkeit, die «ie-mac-unterstützung» wieder zu integrieren.
klar /* no IE5 \*/
Geschrieben von: Olaf Tue. 19. December 2006, 00:39
Echt jetzt!? Eigentlich dürfte es nur die Kommentare entfernen.
dauert also.Das lässt sich IMHO dann ganz gut vergleichen. 2 Fenster nebeneinander und dann in dem einen die Kommentare überspringen. Du kannst dir ja dazu auch die angelegten Dateien vom Server holen, dann brauchst du nicht im Browser rumwurschteln.
@ADMINS
könnte man bitte diesen Thread ab hier: http://forum.sefrengo.org/index.php?showtopic=618&st=20#post-main-5255 splitten?
Dabei fällt mir auf, die Beitragslinks funktionieren nicht! Ich hab mir die ID aus'm DomInspector rausgesucht. Die sollten da eigenlich automatisch erscheinen, aber alles ab # fehlt dort, wäre jedenfalls gut
Geschrieben von: eknem Tue. 19. December 2006, 12:54
Hallo Olaf,
Du musst nicht die rechte, sondern die linke Maustaste benutzen, klicken und dann den Link ausschneiden
Geschrieben von: mika Tue. 19. December 2006, 12:56
Ich hab jetzt a bisserl experimentiert: Das Problem liegt vor allem im Download bereits hochgeladener CSS-Skripte. Ich habe die Kommentare aus der Grund-Datei entfernt, damit ich ein vergleichbares Ergebnis bekomme, hab anschließend die Datei hochgeladen, manche Selektoren als fehlerhaft markiert bekommen und dann wieder aus Sefrengo downgeloaded. Die erste Datei ist diejenige, die ich hochgeladen habe, die zweite diejenige, die ich downgeloaded hab:
hochgeladene:
{
body { min-height: none; }
html { height: auto; }
.clearfix { display: inline-block; }
* html .clearfix { height: 1%; }
.clearfix { display: block; }
* html .floatbox { width:100%; }
* html #col1 { position:relative; }
* html #col2 { position:relative; }
* html #col3 { position:relative; }
.hold_floats { height: 1%; }
* html ul { position: relative }
* html ol { position: relative }
* html dl { position: relative }
* html blockquote { zoom:1 }
#page_margins, #page, #header, #nav, #main, #footer { zoom: 1; }
* html #col1 { display: inline; }
* html #col2 { display: inline; }
* html #col1_content { overflow: visible; }
* html #col2_content { overflow: visible; }
* html #col3_content { overflow: visible; }
* html i, * html em { overflow: visible; display:inline-block; }
#ie_clearing {
display:block;
\clear:both;
width: 100%;
font-size:0;
margin: -2px 0 -1em 1px;
}
* html #ie_clearing { margin: 0 0 -1em 0}
html {margin-right: 1px}
* html {margin-right: 0}
#col3_content {margin-bottom:-2px; }
#col3 { position:relative; }
.c50l, .c25l, .c33l, .c38l, .c66l, .c75l, .c62l { display:inline; }
.c50r, .c25r, .c33r, .c38r, .c66r, .c75r, .c62r { display:inline; }
.subc, .subcl, .subcr { width:auto; zoom: 1; }
.subc, .subcl, .subcr { width:100%; w\idth: auto; }
}
@media screen
{
* html #col1_content { word-wrap: break-word; }
* html #col2_content { word-wrap: break-word; }
* html #col3_content { word-wrap: break-word; }
* html a,
* html a:hover { background-color: transparent; }
* html #footer a,
* html #footer a:hover { background-color: transparent; }
}
downgeloadede Datei!!!:
html {
height: auto;
}
.clearfix {
display: inline-block;
}
* html .clearfix {
height: 1%;
}
.clearfix {
display: block;
}
* html .floatbox {
width:100%;
}
* html #col1 {
position:relative;
}
* html #col2 {
position:relative;
}
* html #col3 {
position:relative;
}
.hold_floats {
height: 1%;
}
* html ul {
position: relative
}
* html ol {
position: relative
}
* html dl {
position: relative
}
* html blockquote {
zoom:1
}
#page_margins, #page, #header, #nav, #main, #footer {
zoom: 1;
}
* html #col1 {
display: inline;
}
* html #col2 {
display: inline;
}
* html #col1_content {
overflow: visible;
}
* html #col2_content {
overflow: visible;
}
* html #col3_content {
overflow: visible;
}
* html i, * html em {
overflow: visible;display:inline-block;
}
#ie_clearing {
display:block;
\clear:both;
width: 100%;
font-size:0;
margin: -2px 0 -1em 1px;
}
* html #ie_clearing {
margin: 0 0 -1em 0
}
html {
margin-right: 1px
}
* html {
margin-right: 0
}
#col3_content {
margin-bottom:-2px;
}
#col3 {
position:relative;
}
.c50l, .c25l, .c33l, .c38l, .c66l, .c75l, .c62l {
display:inline;
}
.c50r, .c25r, .c33r, .c38r, .c66r, .c75r, .c62r {
display:inline;
}
.subc, .subcl, .subcr {
width:auto;zoom: 1;
}
.subc, .subcl, .subcr {
width:100%;w\idth: auto;
}
@import url(* html #col1_content);
* html #col2_content {
word-wrap: break-word;
}
* html #col3_content {
word-wrap: break-word;
}
* html a,
* html a:hover {
background-color: transparent;
}
* html #footer a,
* html #footer a:hover {
background-color: transparent;
}
Was auffällt: Die @...-deklarationen werden vollständig durch @import(url...) ersetzt!?
Mir kommts ja fast so vor, als ob ich den hack gar nicht eingespielt hätte, aber ich habs gemacht und auch die Einstellungen im Projekt - ich verstehs nicht.
Was auch total komisch ist, ist die Tatsache, dass beim Hochladen in Design > Css was ganz anderes angzeigt wird, als dass dann als CSS eingebunden wird:
|
in der Seite hab ich dann das CSS über die FF-Web-Developer-Bar ausgelesen und das CSS stimmt mit dem überein, was dann downgeloaded wird (siehe oben).
Ich hab jetzt grade keinen ftp-Zugang, aber heute abend kontrolliere ich noch mal die dateien aus deinem Hack Olaf.
Ansonsten hab ich dann keine Ahnung mehr, was da passiert ??? ratlos
Geschrieben von: braendle Tue. 19. December 2006, 13:13
{
...
}
@media screen
{
...
}
Was auffällt: Die @...-deklarationen werden vollständig durch @import(url...) ersetzt!?
Ich weiss es, ich weiss es
CSS1 kennt keine Media-Typen in CSS-Dateien. Der Parser kennt nur CSS1. Die einzige Form der @-Einträge sind dort @import-Einträge und der CSS-Parser zerschiesst dir diese @media-Angaben in der Datei.
Sorry, die YAML-Erweiterung ist nicht mit dem CSS-Editor zu nutzen. Keine Chance - im Moment.
Diese Art der Dateien - da hatte ich es die Tage mit Björn drüber - werden in der nächsten Version des CSS-Bereiches unterstützt. Da hilft auch der Hack von Olaf zur Zeit nicht.
Geschrieben von: mika Tue. 19. December 2006, 14:10
alles klar. danke dir. dann werd ich ausschließlich mit dem dateimanager arbeiten und in den Projekteinstellungen die CSS-Dateien erlauben. Diese können dann auch ins Layout eingebunden werden. Ich kann zwar nicht direkt im SF editieren, aber brauche kein FTP. Hilft auch schon a bisserl weiter.
Merci und lg Michel
Geschrieben von: Olaf Tue. 19. December 2006, 17:42
Jo, danke, warum einfach wenns auch umständlich geht
Hautsache ich merk mir das....Ich seh auch keine Möglichkeit das noch irgendwie reinzuhacken, weil es nie mit dieser Schachtelung der {} zurechtkommen würde.
Ansonsten hört sich ja so an als wenn schon dran gearbeitet würde, toll.
Geschrieben von: braendle Tue. 19. December 2006, 21:17
Dazu benötigt man eine Art "zweite Ebene" in den CSS-Regeln, die es so noch nicht gibt.
Jo, am Konzept feile ich noch ein bissel, da hier noch einiges zu bedenken ist
Geschrieben von: amk Wed. 20. December 2006, 09:08
ich weiss doch
... war 'n joke ...MAC IE 5.2 gab's auch schon vor OSX - aber was war/ist das doch für ein alle nase lang abstürzender M$-schrott gewesen. nun wer dafür heute noch entwickelt setzt sich vermutlich auch das ziel css mäßig für IE4 & NS4 kompatibel zu sein. die arbeit spar ich mir schon seit mehreren jahren - weil irgendwann reichts dann auch
Geschrieben von: mika Wed. 20. December 2006, 10:16
ich habs im nachhinein dann schon verstanden - hab mal wieder länger gebraucht (wie so oft)
das mit den alten browsern is so ne sache. auf der einen seite hast du recht: irgendwann is' gut. aber du glaubst nicht, was in schulen (ich arbeite als lehrer) noch so alles auf den rechnern rumfleucht .... da steck ich etwas im dilemma.
andere Frage: kann man den css-parser eigentlich komplett abschalten und trotzdem die Editierfunktion nutzen?
lg michel
Geschrieben von: amk Wed. 20. December 2006, 10:26
hab mal wieder länger gebraucht (wie so oft)das mit den alten browsern is so ne sache. auf der einen seite hast du recht: irgendwann is' gut. aber du glaubst nicht, was in schulen (ich arbeite als lehrer) noch so alles auf den rechnern rumfleucht .... da steck ich etwas im dilemma.
andere Frage: kann man den css-parser eigentlich komplett abschalten und trotzdem die Editierfunktion nutzen?
lg michel
was dann aber an politik und schulwesen liegt - die situation würde ich nicht unterstützten in dem ich noch 10 jahre alte browser supporte.
trotzdem natürlich schön wenn wenigstens die lehrer sich engagieren ... auch das ist leider nicht überall der fall. vielerorts wird seit jahren resigniert zu lasten der schüler. aber alles OT (sorry)
soweit ich weiss kann man den parser nicht komplett abschalten (was ja mehr oder minder das problem ist)
Geschrieben von: FireFlyer Fri. 9. February 2007, 20:06
Wollte mal nachfragen, wie der Stand ist!
Wir es in der neuen SF-Version einen höheren CSS-Editor geben und wird man Unterordner nutzen können, damit man YAML einbinden kann?
Gruß
FireFlyer
Geschrieben von: firehorse Wed. 17. October 2007, 08:26
CSS1 ? *lool* outline kennt diese Version ebenfalls nicht usw.. sind wir nicht eigentlich schon lange bei Version 2.0? Ich nicht schon Version 2.1 draußen? Und sitzen die nicht schon seit mehr als 4 Jahren an 3.0? 
Eine Ausschaltfunktion wäre wirklich begrüßenswert. Man könnte diese ja nur für den Admin zugänglich machen, falls der Import weiterer Dateien überhaupt gestattet sein sollte. Es nervt mich schon seit Dedi, so dass ich CSS meist immer direkt ins Layout eintrage/angebe.
Dass es beim YAML nicht so einfach sein würde, war allerdings klar. Dort sind Hacks angegeben, damit auch der IE 4 für Windoofs 95 User noch etwas darstellen/anzeigen kann. Finde ich allerdings etwas übertrieben. Es würde heute auch ohne gehen oder der Star-Hack für IE 6 reichen. YAML ist außerdem zu fett und für Einsteiger überhaupt nicht geeignet, auch wenn sich dieses bei der aktuellen Version etwas gebessert hat. Persönlich würde CSS immer auf bezogen auf ein Projekt anfertigen. Zumal man seine eigenen Vorlagen ohnehin inpetto haben sollte, geht dieses ohnehin schneller als das gefummel unter SF und Yaml.
Etwas was grundlegend und immer wieder zur Kritik an YAML führt: Wie reagieren die Browser von Übermorgen da drauf?
Es ist und bleibt bestenfalls eine Notlösung und ein dickes Lob bleibt so nur den Seiten/Inhalten zu Yaml vorbehalten.
Wieder zu SF (oder auch Dedi), denn da war diese Version ja auch schon enthalten. Hier sollte wirklich mal überlegt werden wer denn überhaupt Änderungen an einer CSS-Datei vornehmen darf/soll. Immerhin sind SF/Dedi ja nicht nur für Eiinsteiger gedacht, sondern sind auch kommerziell im Einsatz. Sei es nun eine neue Version oder der Klick für den Admin.
Würde jedenfalls nicht ein so großes Gewisch um CSS innerhalb des CMS machen. Ein Autor sollte es können oder sich anderweitig informieren oder es lassen
@mika
Welches alte System ist heute noch voll im Betrieb? Sinngemäß! Schon der Zugang zum Netz dürfte die ollen Kisten schon an die Grenzen ihrer Leistungsfähigkeit bringen. Wer sich heute noch mit Windows 95/98 IE4/5 rumschlägt der braucht auch keinen Lehrer mehr. Da sind Hopfen und Malz verloren
gruss
firehorse
Unterstützt von Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)