WebsiteBaker Support (2.8.x) > Diskussion über WB (closed)
WB 2.8
Stefek:
Bei einigen Modulen kann man zwar Hand anlegen, aber ich denke, dass es die Sache von den Modulentwicklern ist, ihre Module auch für WB 2.8 rauszugeben.
Sicher könnte man helfen, doch dieser Umstand sollte keine Bremse für das 2.8 Release sein.
Stefek
ruebenwurzel:
@stefek
--- Quote ---Und ja, was mich etwas "beunruhig" - jetzt werden schöne Skins erstellt, die dann bei jedem Update ihrerseits selbst upgedatet werden müssen. Immer und immer wieder, bei jedem Update. Hat zwar auch Vorteile, aber nicht nur.
Ist im Moment aber nicht so wichtig.
--- End quote ---
Da liegst du aber völlig falsch. Gerade durch die Trennung von code und design müssen bei künftigen updates des WB codes an den eigenen designs nix aber auch gar nix mehr gemacht werden. Bisher ist es so, das alle, die ein eigenes Backenddesign nutzen es nach einem Core update mühsam wieder anpassen mussten. Das gehört mit den skinable admin interfaces der Vergangenheit an, da man im admin Verzeichnis nix mehr ändern braucht.
--- Quote ---Eine Frage habe ich noch wegen der Media Verwaltung - da hat der Ruud mit Argos an etwas gearbeitet, was recht praktisch aussah. Gibts da irgendwelche Info zu?
--- End quote ---
Als aufmerksamer Leser des Forums, ist dir sicher nicht entgangen, dass es eigentlich geplant ist, das theme von Argos als drittes skinable Admin interface in den Core von WB aufzunehmen. Sobald Argos die notwendigen Anpassungen an WB 2.8 gemacht hat und mir das Paket schickt, kommt es mit ins Paket hinein.
Der User von WB 2.8 kann dann zwischen 3 backend-themes on the fly im laufenden Betrieb umschalten und wählen, ob er das classic (WB 2.7), das wb_theme (WB 2.8) oder das von Argos am besten findet, oder er macht sich einfach sein eigenes.
Matthias
Stefek:
--- Quote from: ruebenwurzel on June 15, 2009, 08:22:43 AM ---Da liegst du aber völlig falsch. Gerade durch die Trennung von code und design müssen bei künftigen updates des WB codes an den eigenen designs nix aber auch gar nix mehr gemacht werden. Bisher ist es so, das alle, die ein eigenes Backenddesign nutzen es nach einem Core update mühsam wieder anpassen mussten. Das gehört mit den skinable admin interfaces der Vergangenheit an, da man im admin Verzeichnis nix mehr ändern braucht.
--- End quote ---
Ich liege überhaupt nicht falsch. Aber vielleicht guckst Du zu beschränkt.
Wenn es so wäre, wie Du schreibst, können wir Dinge wie dieses interessante Thema für die Zukunft vergessen und gleich einpacken:
https://forum.WebsiteBaker.org/index.php/topic,14057.0.html
Oder wie willst Du eshinkriegen, dass diese Felder zukünftig drin sind, ohne an die Skins zu gehen?
Wenn Deine Antwort ist, dass die keiner braucht, dann liegst DU falsch.
Das Interesse ist da. Dass Du Dich an dem Thema nicht beteiligt hast, macht es nicht uninteressanter für den Rest der Beteiligten.
--- Quote ---
--- Quote ---Eine Frage habe ich noch wegen der Media Verwaltung - da hat der Ruud mit Argos an etwas gearbeitet, was recht praktisch aussah. Gibts da irgendwelche Info zu?
--- End quote ---
Als aufmerksamer Leser des Forums, ist dir sicher nicht entgangen, dass es eigentlich geplant ist, das theme von Argos als drittes skinable Admin interface in den Core von WB aufzunehmen.
--- End quote ---
Ich spreche nicht von seinem Backend, ich spreche von der Media Verwaltung hier:
https://forum.WebsiteBaker.org/index.php/topic,11931.msg86047.html#msg86047
Oder willst Du mir einreden, dass es über das Skin selbst gesteuert wird. *hustel*
Stefek
ruebenwurzel:
@stefek
1.)fakt ist, dass alle skinable admins auch bei künftigen Versionen funktioneren werden, ohne dass man Änderungen machen muss. Dies war bisher nicht der Fall. Alle, die sich jetzt mühsam ein WB 2.7 backend gebastelt haben, werden beim update auf 2.8 sehen was ich meine.
2.)logisch und selbstverständlich dürfte wohl auch sein (deswegen bin ich da nicht konkret drauf eingegangen) dass neue features von künftigen WB Versionen selbstverständlich im eigenen Template nachgepflegt werden müssen. Aber das Handling (lediglich htt und css anpassen) ist um vieles einfacher. Außerdem bietet de neue Technik ja auch die Möglichkeit, eben gerade nicht alles was möglich ist in das backend design reinzupacken. Was spricht gegen ein basic_theme für einfache User bei dem unabhängig von den Einstellungen der Userverwaltung gewisse Optionen (Module installieren, admin-tools) einfach vom Design nicht unterstützt werden. Du siehst, dass es hier manigfache Möglichkeiten gibt. Dass du dies kritisierst kann ich ehrlich geasagt nicht ganz nachvollziehen.
3.)Den von dir angesprochenen Thread hab ich sehr wohl gelesen. Aber wie du in diesem thread ja lesen kannst hat da jeder seine eigenen Vorstellungen welche zusätzlichen Felder mit welchen Funktionen da rein sollen. Aber was macht WB aus. Es ist einfach zu handeln, auch und gerade für nicht programmierer. Eine Flut von zusätzlichen Feldern deren Notwendigkeit und Logik nicht sofort erkennbar ist wiederspricht der Maxime WB einfach zu halten. Was in einer künftigen Version sicher geregelt werden muss ist das Handling von mehrsprachigen Seiten und die Benutzerverwaltung. Aber bitte so, dass es auch ein DAU kann. In WB 2.8 kommt so was halbgares definitiv nicht mehr rein.
4.)Mediaverwaltung: Sehe ich auch mehr als eine globale zu lösende Aufgabe für künftige Versionen. Dass was gemacht werden muss, dadrüber sind sich alle einig. Es gibt ja auch verschiedene Lösungansätze. Warum z.B. nicht über die Medienverwaltung der Editoren, oder sollte man die gar nicht benutzen und was eigenes kreieren, dass dann aber von allen Editoren auch unterstützt werden muss. Aber auch hier das Ziel (neben der Sicherheit beim Dateiupload!!!!) keep it simple, aber biete auch Möglichkeiten für die die mehr wollen.
5.)
--- Quote ---Aber vielleicht guckst Du zu beschränkt.
--- End quote ---
Lass solche Sprüche.
Matthias
Stefek:
Hallo Matthias.
Na, das ist doch mal eine umfangreiche und gute Anwort.
Ich gebe Dir eine vernünftige Antwort zu den Punkten:
1) Ja, nur solange keine neuen Funktionen hinzukommen, die über das Backend ansteuerbar sind.
2) Ich übe keine Kritik im eigentlichen Sinne, sondern versuch diesen Punkt deutlich zu machen:
=>Sobald in Updates neue Funktionen hinzukommen, die über das Backend angesteuert werden, müßen ALLE Themes erweitert werden.
=>Wenn man auf AMASP oder der offiziellen Seite zusätzliche Skins zum Nachrüsten anbietet, müßen auch diese upgedatet werden - und das ist, wie wir wissen, nicht unbedingt einfach.
=> Ich als Designer mache für meine Kunden sehr oft ein Custom Skin - ja, es ist schwieriger im Moment, als mit dem Skinable Konzept, muss aber dennoch auch dann nach jedem Update wieder neu gemacht werden.
Aber siehe hier, ich schrieb: "Das ist nicht so wichtig":
--- Quote from: Stefek on June 14, 2009, 02:10:10 PM ---Und ja, was mich etwas "beunruhig" - jetzt werden schöne Skins erstellt, die dann bei jedem Update ihrerseits selbst upgedatet werden müssen. Immer und immer wieder, bei jedem Update. Hat zwar auch Vorteile, aber nicht nur.
Ist im Moment aber nicht so wichtig.
--- End quote ---
Für den 2.8 ist es gut - man kann Erfahrungen sammeln und vielleicht wird auch etwas effizienteres für 2.9 gemacht werden -> Stichwort jQuery.
Was übersehen wird, ist, dass die meisten Bestandteile des Skins von Skin zu Skin gleichbleibend sind. Das gesamte Skin kann alleine mit 4, 5 Dateien geändert werden.
Ich habe hier ein Skin rumliegen, mit dem das ganz einfach demonstriert werden kann. Und vielleicht werde ich es zum Wochendende hin mal hochladen - oder ich warte auf die Änderungen von Luishanne und mache es erst dann.
Die anderen HTT Files können getrost über CSS gesteuert werden und man hat trotzdem alles Custom.
Und man hat das Problem mit den vielen verschiedenen Skins nicht mehr, sie upzudaten usw.
Aber: wie gesagt, für 2.8 ist dieses Konzept gut, und es sollte jetzt kein Stopp fürs nächste Release werden.
Es ist keine Kritik, sondern einfach ein Ausdruck der "Beunruhigung" - es könnte mir auch egal sein, da ich meine Skins gut überblicken kann - ich behandele das aber aus dem Blickfeld ALLER im Umlauf befindlichen Themes.
3) Nun, wenn Du ihn gelesen hast, dann kannst Du Dich ja auch dadran beteiligen.
Es ist klar, dass viele Gesichtspunkte viele Ideen ergeben, aber deswegen ist der Thread da, um die einfachsten und nötigsten Felder ausfindig zu machen, oder sich auf sie zu einigen.
Es ist nichst mehr für 2.8, aber ganz sicher etwas, was früher oder später rein sollte.
Ich meine, wir arbeiten hier mit einem guten Werkzeug und schauen, wie man es noch verbessert.
Man kann es auch demokratisch lösen, wie hier:
https://forum.WebsiteBaker.org/index.php/topic,12988.0.html
16 Leute, denen daszusagt, einer der sagt, dass es nicht im Core sein sollte.
Obwohl das ganze komplett fertig ist (und vielleicht nur angepasst werden müsste), keine Spur davon in der Subversion.
4) Ja, gut. Dann sag das gleich, dass das Ding noch nicht reif für 2.8 ist.
5) Das war kein Spruch. Ich habe mich sehr sehr sehr ausgiebig mit dem Thema Backend beschäftigt und kenne jeden Aspekt des Backends genau. Alle Problematiken und alle Möglichkeiten - solange es sich auf die Gestaltung bezieht.
Deswegen habe ich auch eine klare Vorstellung davon, wenn ich sage, dass es auch anders gelöst werden kann - dass es das nicht muss, ist eine andere Sache.
Es geht um Einfachheit.
Und die kann ich erreichen. Kein Spruch ;-)
Nochmal danke, dass Du Dir die Zeit gelassen hast.
Ich schätze das sehr - nur mit Kommunikation kann man es noch besser machen.
Viele Grüße,
Christian /Stefek
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version