WebsiteBaker Community Forum
WebsiteBaker Support (2.8.x) => 
Hilfe & Support (deutsch) => General Help & Support => Diskussion über WB (closed) => Topic started by: susigross on June 13, 2009, 09:04:36 AM
-
Kann man das schon irgendwo runterladen?
Der Link in der Newsbox führt ja nur auf eine Info-Seite.
-
Hallo,
man kann sich jederzeit eine aktuelle Version vom SVN herunterladen. Entweder man nutzt einen client (z.B. Tortoise SVN (http://tortoisesvn.net/downloads)) oder den link zum zip Archiv auf der Trunk-Seite (ganz unten)
http://project.websitebaker2.org/browser/trunk (http://project.websitebaker2.org/browser/trunk)
Matthias
-
Vielen Dank Matthias,
ich hatte gehofft, WB 2.8 produziert validen html-Code, aber momentan ist das noch nicht so.
Beispiel: Wysiwig-Seite angelegt ...admin/pages/modify.php?page_id=1 produziert 8 html-Fehler.
Das Problem ist: wenn der Core schon unsauberen Code liefert, ist es schwerer, Module zu schreiben, die sauberen Code liefern.
-
Nur als Anmerkung für die, die solche Aussagen falsch verstehen könnten:
Du redest davon, dass der W3C-Validator im Backend (!) Unstimmigkeiten findet.
Dieses Problem betrifft aber NUR den Validator, für Browser oder User hat das keinerlei Bedeutung.
-
Nun die Browser verkraften solche Fehler unterschiedlich gut. Manchmal wundert man sich, daß etwas in einem Browser nicht funktioniert, und wenn man die html-Fehler entfernt, klappt es plötzlich. Mit sauberem Code fährt man auf alle Fälle besser, und weh tut er auch nicht.
-
@frankH
wenn du dir den Code von WB 2.8 anschaust, dann wirst du sicherlich gemerkt haben, dass wir für das backend eine neue Technik einbauen werden. Ziel ist es die absolute Trennung von Code (im admin Verzeichnis) und design (backend themes im Template Verzeichnis). Ein Grund warum WB 2.8 nicht schon längst (zumindest als RC) draußen ist, ist, dass im admin Verzeichnis immer noch style Elemente vorhanden sind. Das heißt, das backend ist momentan noch die größte Baustelle.
Erst wenn alle styles (css-files) und templates (htt-files) in die backend themes im Templates ausgelagert sind kann man sich daran machen diese Themes zu validieren. Bei der Gestaltung dieser themes haben die User dann vollkommen freie Hand (wie bei frontend templates halt auch) . Von komplett tabellenfreien themes bis hin zu strict validen themes ist alles möglich. Abe wie gesagt, dafür muss erst noch die Basis geschaffen werden.
Und wenn es nach mir geht, ja, das default backend theme von WB sollte zumindest in der WB 2.8 final dann auch valide sein.
Matthias
-
Hallo.
Ich habe es mir angeschaut in den letzten Tagen und wie Matthias sagt - es geht Valide. Es sind einfach einige Unstimmigkeiten noch im Core.
Es gibt auch noch eine Datei, die es nicht als HTT File gibt, was noch nachgeholt werden sollte, um wirklich eine freie Hand zu gewähleisten.
Mein größtes "Sorgenkind" ist der Page-Tree auf der "Seiten" Übersicht.
Das ist die Stelle mit den meisten Errors.
Hier bin ich aber völlig überfragt, weil - wenn jQuery einzug hält ins Core, vielleicht könnte man das gleich mit erledigen?
Und wenn es nach mir geht, ja, das default backend theme von WB sollte zumindest in der WB 2.8 final dann auch valide sein.
Das dürfte nicht das Problem werden.
Das Skinable ist ein gutes Feature für 2.8
Ich habe auch schon für private Zwecke ein neues Skin erstellt und wenn noch die von Dir genannten Macken beseitigt sind, ist es leicht, das ganze valide zu machen.
Gruß,
Christian
-
Ich schruppe eh grade an der "style='display: ;'" problematik,
und bin auch am Validieren - also der meiste Teil ist, so wie ich es
hier gesehen habe, halt fehlende alt-tags bei den Icons; in so fern
kein grosser Beinbruch und in den Templates zu Beheben.
Heftiger sind da schon die core-geschichten mit dem Templates, das
nicht überschriebene Kennungen einfach leer bleiben.
Ich hatte es dann hier in einer private Studie zum Beispiel in
"admin/addons/index.php" wie folgt gelöst:
<?php // diese Zeile wie gehabt nicht ....
$display_none_str = "style=\"display:none;\"";
$perm_names = array ('modules', 'templates', 'languages');
foreach ($perm_names as $item)
if ($admin->get_permission( $item ) != true)
$template->set_var ("DISPLAY_".strtoupper($item), $display_none_str);
?>
Und dann im Template statt "style='{DISPLAY_LANGUAGES};'" eben nur mit der Kennung gelöst.
Dann noch alt-tags vergeben ... und Grün ist es ... und die Webdeveloper-Tools geben nun endlich auch Ruhe.
Gruß
Aldus
-
Hallo Aldus,
ja, diese Dinger sind es. Die sind leichter zu beheben.
Neben den schwierigeren, die Du in der Studie bahandelt hast, kommt auch noch eine Reihe von selected und checked in der admin/settings/index.php.
Der Validator sagt dann:
Error Line 205, Column 34: the name and VI delimiter can be omitted from an attribute specification only if SHORTTAG YES is specified
<option value="4"selected>4</option>
Error Line 220, Column 93: the name and VI delimiter can be omitted from an attribute specification only if SHORTTAG YES is specified
…ash_inline" value="inline" checked />
Die Frage stellt sich, wie sehr will man sich diesem ganzen "Validator-Dogma" beugen. Da hat Chio nicht ganz unrecht.
Auf der anderen Seite, wenn es ohne all zu viel Aufwand gemacht werden kann, dann ist es auch gut.
Zum Thema wollte ich aber noch was sagen. Stichwort "Gestaltungsfreiheit".
Ich würde mich freuen, wenn zu allen HTT's (also zu den ganzen Templates) eine Variable mit der {THEME_URL} gesetz wird.
Ich arbeite ein Theme aus, wo die Input Buttons mit dem <button> Element ersetzt werden und es soll ein Icon dazwischen. In der Art:
<button bla bla onClick="blabla"><img src="{THEME_URL}/images/blabla.gif">{BLA}</button>
Ich finde, wenn wir es schon Skinable machen, dann sollten auch diese Freiheiten drin sein.
Also ich wollte da mal drum bitten.
Dazu habe ich für meine Installationen (momentan noch auf 2.7) einige weitere Icons im Backend drin, um den Kunden die Orientierung zu erleichtern. Das kann ich jetzt nicht mehr machen, weil früher konnte man einen relativen Pfad zu den Icons setzen - jetzt nicht mehr. Es bleibt nur die Möglichkeit über die {THEME_URL}, die leider nicht überall gegeben ist.
Gruß,
Stefek
-
@stefek
1.) THEME_URL als Variable gibt es bereits, zieh dir am besten mal ne aktuelle SVN Version und schau dir die backend themes im templates Verzeichnis an.
2.) luisehahne ist momentan dran die admin/pages/settings.php und admin/pages/index.php in core und htt files aufzudröseln. Sobald das fertig ist kommt das auf SVN.
Matthias
-
Die Frage stellt sich, wie sehr will man sich diesem ganzen "Validator-Dogma" beugen. Da hat Chio nicht ganz unrecht.
Auf der anderen Seite, wenn es ohne all zu viel Aufwand gemacht werden kann, dann ist es auch gut.
Also wenn sogar Microsoft nach zig Jahren ein Einsehen hat, wär's eine Farce ein CMS, also die Quelle, nicht validen Code produzieren zu lassen. Wer mit einem CMS müllen will soll's tun, fachlich versierte Webdesigner werden "sowas" meiden. Sowas ist für die Tonne. Es hat nicht's mit einem Diktat zu tun, sondern mit "auf gleicher Grundlage" arbeiten können. Auf gemeinsamer Grundlage arbeiten heißt z.B. auch Arbeitsersparnis, weil u.a. endlich die Seiten in Client korrekt interpretiert werden. Was nur wenige bedenken, mit Clients sind nicht nur Browser gemeint.
Gruß, Hans>NUL
Edit: Wenn man außerdem bedenkt, daß der W3C-Validator nicht alle Fehler auflistet........
-
Hallo Matthias.
Danke für die Antworten.
1) Bezieht sich die {THEME_URL} auf alle HTT Files?
Die SVN Version habe ich am Mittwoch Montag, den 8.6.'09 gezogen - da war es noch nicht der Fall.
2) Geht Dietmar auch an die /admin/pages/sections.php bei? Die ist am wenigsten behandelt worden.
Gruß,
Stefek
-
Wer mit einem CMS müllen will soll's tun, fachlich versierte Webdesigner werden "sowas" meiden. Sowas ist für die Tonne.
Jo. Dann sind wir halt alle _nicht_ fachlich versiert. Und WB war bisher für die Tonne ;-)
Ich bin durchaus der Meinung, dass Seiten valid sein sollen, u.a. etwa, weil man Fehler einfacher findet.
Allerdings möchte ich auch darauf hinweisen, dass das Web _nicht_ vom Fleck gekommen wäre, wenn es in der Hand von i-Tüpfel reitenden Sturschädeln wäre. Und manch einer kümmert sich GsD. mehr um Inhalt und Design als um ewige Frickeleien, um einen Programm zu dienen. OK - jedem sein Sport.
-
Jo. Dann sind wir halt alle _nicht_ fachlich versiert. Und WB war bisher für die Tonne
Deshalb muß man keine ideologische Diskussion aufmachen, oder auf angebliche Feststellungen abheben, zumal ich noch nicht mal auf einen schrottigen WB verwiesen habe, denn der macht's TRANSITIONAL.
Es wurde doch klar und deutlich gesagt worauf's ankommt.
Wenn man wie zu lesen ist WB (CORE) auch STRICT-kompatible werden möchte, kann es einem nicht egal sein ob's valide ist. Um nicht mehr geht's doch und nur das wurde angesprochen.
Noch habe ich in kein WB-Wohnzimmer gekotzt. Vielleicht kommt das noch :-D , nee nicht wirklich.
Außerdem haste ja die Freiheit alles reinzupacken was DIR paßt, also auch nix valides.
Gruß, Hans>NUL
-
@stefek
1.) THEME_URL als Variable gibt es bereits, zieh dir am besten mal ne aktuelle SVN Version und schau dir die backend themes im templates Verzeichnis an.
Hallo Matthias.
Ich habe jetzt die aktuellste Subversion geladen, doch in den meisten Templatefiles ist die Variable nicht aktiv.
Aus den oben genannten Gründen, bitte ich dadrum, dass sie in alle bestehenden HTT Files aufgenommen wird. Erst das lässt das "Skinable-Konzept" richtig zur Entfaltung kommen.
Gruß,
Stefek
-
Hallo,
Ich stimme allen bei die auch fürs Backend validen Code fordern. Habe schon manchen Fehler beseitigen können pder bin beim bereinigen des Codes darauf gestossen. Stimmt die /pages/inde.php ist mit das Schlimmste. 232 Fehler.
Ich meine auch festgestellt zu haben, dass der Seitenaufbau schneller ist.
Wie Matthias schon schribe, bin ich dabei den Code zu bereinigen und eine htt dazu zu erstellen. Finde das mit den URL Variablen auch nicht verkehrt. ADMIN_URL, WB_URL, WB_PATH, THEME_URL sollten immer mit rein.
Was sonst noch als Standard rein könnte, können wir ja bis zur 2.9 ausdiskustieren.
Gruss
Dietmar
-
Hallo Dietmar.
Danke für die Antwort.
Handelt es sich dabei um den Seiten-Baum?
Das wäre natürlich klasse.
2) Geht Dietmar auch an die /admin/pages/sections.php bei? Die ist am wenigsten behandelt worden.
Gehst Du an die oben genannte Datei auch bei? Es fehlt derzeitig eine HTT mit dem Namen pages_sections.htt .
Das ist dahingehend schade, alsdass ich für die anderen beiden (pages_modify.htt und pages_settings.htt) einen "Kopf" (mit Namen der Seite etc. - siehe Anhang) gestalten kann, nicht aber für diese Seite. Das ist beschränkend und ich kann also auch die beiden nicht frei gestalten, sonst wird das nicht einheitlich.
Wie Matthias schon schrieb, bin ich dabei den Code zu bereinigen und eine htt dazu zu erstellen. Finde das mit den URL Variablen auch nicht verkehrt. ADMIN_URL, WB_URL, WB_PATH, THEME_URL sollten immer mit rein.
Das finde ich große Klasse.
Ich habe noch einige "Kleinigkeiten" (was Umsetzung angeht), die zwar im "Classic Theme" keine Rolle spielen, für ausgefeiltere Custom Themes aber sehr wünschenswert wären. Kein Overhead für die Funktion und wer es in seinem Theme nicht drin haben will, lässt es weg - aber die Möglichkeit wäre gegeben.
Wem kann ich das reporten, so dass es nicht zu kompliziert wird? (Mit SVN Bugreport etc. muss ich zu meiner Schande zugeben, bin ich nicht vertraut).
Gruß,
Stefek
[gelöscht durch Administrator]
-
Hallo Stefek,
die pages_sections.htt ist bereits bei Matthias im Test und ist valide HTml, im Moment arbeite ich an der inde.php im Ordener pages. Jetzt weis ich auch ,warum sich da noch keiner rangewagt hat.
Habe auch vorgeschlagen, das komplette Backend valide Html zu machen. Wird aber komplett erst mirt der WB 2.9 möglich sein. Einiges ist bereits valide. Jetzt fallen auch html Fehler in den Modulen auf.
Gruss
Dietmar
-
Hallo Dietmar.
Danke.
Der zweite Absatz macht Sinn.
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.
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?
Gruß,
Stefek
-
Jetzt fallen auch html Fehler in den Modulen auf.
Das isses.
"ruebenwurzel" hatte schon sehr, sehr früh auf diesen Umstand hingewiesen, wenn ich mich recht erinnere. Mit WB2.8 werden einige Module überprüft und gegebenenfalls angepaßt werden müssen. Wenn's so weitergeht wird WB 2,8 "richtig knackig".
Gruß, Hans>NUL
-
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
-
@stefek
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.
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.
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?
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
-
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.
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.
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?
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.
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
-
@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.)Aber vielleicht guckst Du zu beschränkt.
Lass solche Sprüche.
Matthias
-
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":
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.
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 (https://forum.WebsiteBaker.org/index.php/topic,14152.msg87696.html#msg87696) 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
-
Hi,
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
You, man kann so ziemlich alles aus dieser statistisch nicht relevanten Abstimmung rauslesen. Ich lese das ganze wie folgt:
a) Relevanz der Abstimmung:
19 Leute haben abgestimmt. Derzeit sind 8077 Mitglieder registriert. Zählt man nur die mit mehr als 10 Posts und min. 1 Post im letzten halben Jahr, dürften das um die 1500 Mitglieder ergeben (hab die Übung vor ca. 1.5 Jahren mal gemacht). Das heisst, es haben sich < 1.3% der "potentiellen" Zielgruppe geäuusert, was schon mal eine Aussage an sich ist. Zählt man nun noch die Anzahl derjenigen zusammen, die überhaupt in diesem Thread geantwortet haben, bleiben nunmehr 6 Leute übrig: Stefek, Lousou, Mr-fan, Clara, Kweitzel, Doc.
b) Zur Frage ein Muss fürs nächste WB Release:
muss unbedingt in WB 2.8: 32%
nur wenn ich es abschalten kann: 52%
nicht benötigt: 10%
nur zum selbst einbauen anbieten: 6%
c) Hätte man nur ja / nein zugelassen, würde ich das ganze wie folgt deuten:
ja: 31%
nein: 69% (nur wenn abschaltbar, umgangssprachlich für: mir wurscht, nicht benötigt, eigenständiges Packet)
d) Ausblick über WB 2.8 hinaus:
Die nächste Version des FCKEditors (derzeit noch Beta) lädt zudem um ein vielfaches schneller (https://forum.WebsiteBaker.org/index.php/topic,1670.msg85042.html#msg85042) und bietet die Möglichkeit, einen Div bei Klick (http://ckeditor.com/ckeditor/3.0b2/_samples/divreplace.html) in ein WYSIWYG Feld zu verwandeln.
Das ist übrigens ein Grund, warum ich diese "Poll" hier im Forum nicht mag. Man bekommt wegen der geringen "Teilnahme" meist keine statistisch relevanten Aussagen, man "grenzt" wenn einsprachig gestellt einen Grossteil der Leute von vornherein aus. Zudem erfordert die "richtige" Fragestellung der Umfrage ein vielfaches mehr an Aufwand als wenn man direkt nach der Meinung der Nutzer fragt. Im letzteren Fall "beteiligen" sich dann meist auch nur Leute, die es wirklich interessiert und nicht nur "Leute", die halt mal irgendwo klicken, ohne aber den Thread wirklich gelesen zu haben (meine rein private Schlussfolgerung nach Sichtung einiger erstellten Polls hier im Forum).
Klar muss man die Leute in den Entwicklungsprozess "einbinden", aber ich halte eine Poll nicht wirklich für das geeignete Mittel. Wie immer, nur meine völlig "private" Meinung zu diesem Thema :-)
Gruss Christian
-
Hallo Doc,
deinem Beitrag kann ich zu 100 % zustimmen.
Aber es hat sich wohl nicht nur in der Politik herumgesprochen, dass relative Zahlen ohne Nennung der Grundmenge den Eindruck vermitteln, dass Mehrheiten entstanden sind.
Bei der Europawahl in Deutschland lag die Wahlbeteiligung unter 43%.
Das sich hieraus dann Mehrheiten ableiten lassen ist wohl zur Zeit die grösste Schwäche einer Demokratie.
Vielleicht sollte man auf den Stimmzetteln immer ein Feld machen:
Bin mit der derezeitigen Politik nicht einverstanden
und dieses dann ebenso zulassen wie eine Partei/Kandidaten und nur Wahlergebnissse mit einer Beteiligung von über 50 % werten.
Bin mal gespannt, wie dann Europa- oder Bundestagswahlen aussehen würden. Vermutlich würden wir dann nie eine Regierung haben......(hmmm).
GRuss
erpe
-
Hi Erpe,
Aber es hat sich wohl nicht nur in der Politik herumgesprochen, dass relative Zahlen ohne Nennung der Grundmenge den Eindruck vermitteln, dass Mehrheiten entstanden sind.
Das ist ja das schöne – oder fatale – an der Interpretation von solchen Zahlenmaterials. Ohne "Gesundrechnung" der Grundmenge, sprich mit 8077 Teilnehmern als Grundlage haben sogar weniger als 0.24% der Forenteilnehmer eine Meinung zu diesem Thema :wink:
Gruss Christian
-
Damit stimme ich nicht ganz überein.
c) Hätte man nur ja / nein zugelassen, würde ich das ganze wie folgt deuten:
ja: 31%
nein: 69% (nur wenn abschaltbar, umgangssprachlich für: mir wurscht, nicht benötigt, eigenständiges Packet)
Das ist völlig aus der Luft gegriffen.
Und ja, die Menge der Teilnehmer liegt meistens in diesem Bereich.
Manchmal mehr - siehe Droplets.
Man könnte das weiter herausfinden, indem man die Newsletter Funktion von SMF für Projektzwecke benutzt und die (von den 8077) noch aktiven User würden sicher mitmachen, wenn auch hier ein Schwund wäre.
Außerdem war die Fragestellung korrekt.
Weil die Idee so war, dass es Zuschaltbar gemacht werden soll.
Ist das Ding einmal drin, kann man es zuschalten und viele würden im Nachhinein (außer Dir vielleicht) die Nutzwirkung davon erkennen und es öfter einsetzen, als von Dir gedacht.
Siehst Du, Du kannst es nicht wissen - nur mutmaßen, weil Du Polls nicht magst, schließt Du von Dir auf die Mehrheit.
8-)
Stefek
-
@Stefek:
Wie in meiner Post erwähnt, bezieht sich das ganze auf meine Sichtweise der Dinge. Auch Du kennst nicht die Absicht der 52% die für: "Only if I can enable/disable it through the WB panel" gewählt haben. Deine Interpretation in Post 28 ist daher ebenfalls reine Vermutung.
Die Tatsache, dass Leute ein Feature abstellen möchten, spricht für meine schon des öfteren gemachte Beobachtung bei Polls. Ich habs zwar nicht runtergeladen und getestet, klingt aber irgenwie interessant. Also wähle ich mal ja klar, aber nur wenn ich´s auch ausschalten kann, dann kann ich später testen. Für mich haben diese 52% mit "mir wurscht" gestimmt. Die Poll ist einfach schlecht gestellt und lässt bei derzeitigem Stand 52% freie Interpretation zu. Was ich übrigens auch in meiner ersten Post dazu erwähnt habe.
Was ich und wohl auch Erpe (vorsicht schon wieder eine Mutmassung von mir) aber "schlecht", bzw. falsch finden sind Statements wie:Man kann es auch demokratisch lösen, wie hier:
16 Leute, denen daszusagt, einer der sagt, dass es nicht im Core sein sollte.
Das ist weder demokratisch, noch in irgendeiner Form statistisch relevant. Zudem können 52% der abgegebenen Stimmen nicht eindeutig zugeordnet werden. Denoch zu behaupten, das wäre demokratisch oder eine "Mehrheit" für oder gegen ableiten zu wollen, ist schlicht gesagt: "dicker Tobak" :-P
Da das ganze nicht wirklich Threadrelevant ist, erspare ich mir weitere Äusserungen in diesem Thread. Wer will kann mir diesbezüglich ja ne PM schicken.
Gruss Christian
-
Ja, mein Lieber.
Was nur stört, ist dass Du Deine Mutmaßungen so popularisierst, als sollte das nächste WB Treffen eine Pilgerfahrt für Dich werden.
Du übergehst einfach den tieferen Sinn meiner Aussagen und hängst Dich bei Kleinigkeiten auf.
Das klärt jetzt weder den Grund, warum das Teil nicht aufgenommen wurde noch rechtgertig es ihn.
Quasi keine Demokratie in keinster Hinsicht.
Und ich könnte einige Anmerkungen dazu machen, dass auch Deine Heiligkeit nicht immer richtig mutmaßt und dass durch die ach so tollen popularisierten Aussagen schon das ein oder andere nette Vorhaben sich wie ein Luftschloß im Nix aufgelöst hat.
Also wie gesagt: Nur weil Du das Feature nicht gut findest, ist noch keine Antwort darauf, warum es nicht aufgenommen wird.
So, bin gespannt...
-
Hallo,
wann kommt 2.8 denn vermutlich raus? Kanns schon gar nicht mehr abwarten :)
Lg
-
wann kommt 2.8 denn vermutlich raus? Kanns schon gar nicht mehr abwarten :)
Wenn fertig dann fertig es sind ja größere Modifikationen in der 2.8 und da sollte es schon fast ohne Bugs sein.
Aber ein andere Vorschlag warum wird nicht mit dem Projekt hier zusammen gearbeitet?
https://forum.WebsiteBaker.org/index.php/topic,14309.0/topicseen.html
Da sind gute Lösungsansätze drin, wie ich auf der Seite sehen konnte.
Da dort ja schon einiges mehr integriert ist, es sieht zumindest für mich so aus, könnte wenn die zwei Projekt Teams zusammen arbeiten das nur zum Vorteil von WB sein.
Ja ich weiß es sind in den letzten Jahren hier einige Menschen vor den Kopf gestoßen worden, aber wenn man mal das alte alte sein lässt und einfach von vorn anfängt.....
Wie man an dem Projekt oben sieht hängen doch noch einige an WB und wollen etwas erreichen also warum nicht gemeinsam.
Stephan
P.S. Wenn die Worte im engl. Teil auch auftauchen sollen kann ja jemand das übersetzen und dort einstellen.
Mein engl. ist so gut das ich Google-Translate benutzen kann.
-
Hallo,
wann kommt 2.8 denn vermutlich raus? Kanns schon gar nicht mehr abwarten :)
Lg
Ich denke "März"?
The first RC wich includes all new features of the next version is planned for begin of March. After RC testing phase the Final release is planed for end of March.
Jahr steht ja nicht dabei. http://project.websitebaker2.org/milestone/2.8.x
Bin auch gespannt.
Stefek
-
Nur weil ich es grad aufgeschnappt habe: Man kann Backends durchaus so bauen, daß keine umfassenden Änderungen in den Templates nötig sind, wenn Funktionen hinzu kommen. (Ich bau unter Windows ganze Wizards so zusammen.) Ganz ausschließen läßt sich das natürlich nie, aber 90% kriegt man hin. :-D Ich vermute aber mal, daß die derzeitigen Core-Bibliotheken das so nicht hergeben. (Also nicht ohne größere Änderungen.) Könnte man ja mal für später im Hinterkopf behalten.
-
Hallo Bianca,
momentan ist es im 2.8 so, dass wenn Du eine Erweiterung im Backend anbietest (nenn es Hack), Du gleichzeitig die HTT Files mitliefern muss für die Themes.
Da aber vorraussichtlich an die Dutzende Themes in Umlauf gebracht werden könnten, wird es nicht machbar sein.
Mein ursprünglicher Vorschlag war, nur die
head
foot
und das CSS File "skinable" zu machen. (In einem Paket zu bündeln.)
Später erkannte ich, dass noch einige weitere Files mit drin sein sollten (wie das Login z.B.)
Aber viele andere HTT Files sollten meiner persönlicher Meinung nach im Admin Folder drin bleiben.
Code von Design zu trennen ist gut, was aber nicht heißt, dass jeder Hans und Franz an alle Designparts gehen sollte.
Wie dem auch sei.
Stefek
-
Man braucht eigentlich nur ein vernünftiges "Theme" - oder eine saubere HTML-Basis -, und schon kann man wirklich ALLES machen, indem man nur das CSS ändert. Wer's nicht glaubt: http://www.csszengarden.com
Ist aber wohl offtopic. ;)
-
Vielleicht Offtopic aber trotzdem Klasse............. ..........
-
Nein, genau richtig.
Meine Rede.
Die anderen Files die ich aufgelistet habe nur um etwas mehr Einfluß auf bestimmte Elemente zu nehmen wie z.B. das Menü, Grafiken, Logo(s) und das Login.
Stefek
Hab ich nicht schon mal geschrieben, dass wir seelenverwand sind :wink:
-
Hallo,
so wie es jetzt vorgesehen und integriert ist kann man exact dasselbe tun. Vom Grundsatz her genügt es sich ein bestehendes skinable admin interface zu kopieren, den header und footer und das css anzupassen und fertig. Das werden die meißten wohl auch machen.
Der große Vorteil der jetzigen Version ist aber (und damit auch gleich der größte Nachteil deines Vorschlages) dass man halt auch alles andere ändern kann wenn man will ohne an irgendwelchen core rumschrauben zu müssen. Bei deinem Vorschlag stefekt, hätte dann wieder jeder im core rumgefrickelt und bis auf die Lösung, die sich dann in einer künftigen WB version niederschlägt hätten alle anderen ein Problem beim update. Und was ein weiterer Riesen Vorteil ist, dass man bei künftigen WB updates sein Interface nur dann anpassen muss, wenn man eventuell vorhandene neue Features auch tatsächlich einbauen will. Es geht darum gerade für das Aussehen von WB größtmögliche Flexibilität anzubieten, und das geht nur über die jetzt angefangene Lösung.
Ich denke was momentan ein bisserl zur Verwirrung führt ist die Tatsache, dass es gerade für die Medienverwaltung verschiedene Ansätze gibt. Grundsätzlich sollte das aber nicht Theme des skinable admin Interfaces sein. Eine vernünftige Medienverwaltung ist an anderer Stelle zentral zu regeln. Ob man das über die Einbindung der diversen Editor Erweiterungen, über einen third-Party script oder einen eigenen script handelt, damit können, sollen und müssen sich die devs nach 2.8 auseinandersetzen.
Matthias
-
Ich guck mir das bei Gelegenheit erst mal in Ruhe an, bevor ich weiter mitrede. :-D
-
Der große Vorteil der jetzigen Version ist aber (und damit auch gleich der größte Nachteil deines Vorschlages) dass man halt auch alles andere ändern kann wenn man will ohne an irgendwelchen core rumschrauben zu müssen. Bei deinem Vorschlag stefekt, hätte dann wieder jeder im core rumgefrickelt und bis auf die Lösung, die sich dann in einer künftigen WB version niederschlägt hätten alle anderen ein Problem beim update. Und was ein weiterer Riesen Vorteil ist, dass man bei künftigen WB updates sein Interface nur dann anpassen muss, wenn man eventuell vorhandene neue Features auch tatsächlich einbauen will. Es geht darum gerade für das Aussehen von WB größtmögliche Flexibilität anzubieten, und das geht nur über die jetzt angefangene Lösung.
Hallo Matthias,
wie Du selbst schreibst, wir der Otto normal User nur die von mir gelisteten Files ändern.
Der Fortgeschrittene User wird aber eher kein Problem haben, die HTT Files auch im Admin Ordner zu varrieren wie es ihm gefällt/beliebt und im Falle eines Upgrades weiß er, dass er ein Backup von seinen HTT Files machen sollte.
Diese Vorgehensweise hat einen weiteren Vorteil, nämlich, wenn die Developer neue Funktionen ins PHP schreiben, diese einfach nur noch an die im admin folder bestehenden HTT Files angepasst werden müssten.
Alle Themes sind weiterhin verwendbar und müßen selbst bei den groben Änderungen von Otto Normal User nicht angepasst werden - da die Anpassungen im Core bleiben (HTT Files dürfen zum Core gehören).
Nur der "Fortgeschrittene" User muss die Templates abgleichen, und ihm wirds nicht weh tun.
Aber es reicht.
Ich will es nicht wieder aufrollen.
Stefek
-
Aber es reicht.
Ich will es nicht wieder aufrollen.
Also das rafft jetzt auch keiner mehr, ohne sich selber tief reinzuknien. :-D Seien wir doch erstmal einfach froh und dankbar, daß es überhaupt ein skinnable Backend gibt. :wink:
-
Aber es reicht.
Ich will es nicht wieder aufrollen.
Also das rafft jetzt auch keiner mehr, ohne sich selber tief reinzuknien. :-D Seien wir doch erstmal einfach froh und dankbar, daß es überhaupt ein skinnable Backend gibt. :wink:
Und wie ich mich reingekniet hab.
Aber ja, ich bin sehr froh.
Nicht falsch verstehen.
Vieles davon ist sehr sinnvoll - ich kann auch Matthias nachvollziehen. Stimme einfach nicht vollständig mit ihm in diesem Punkt überein.
Wird doch nicht verboten sein...? 8-)
Gruß,
Stefek
-
Ach, naja, die Zeit wird zeigen, ob es da noch Optimierungsbedarf gibt oder nicht. :-D
-
Hi,
Ach, naja, die Zeit wird zeigen, ob es da noch Optimierungsbedarf gibt oder nicht.
Das stimmt.
Der Output Filter der mit WB 2.7 eingeführt wurde, hat den Weg für richtig coole Module wie den Frontend Filter von Thorn, oder Dropplets bereitet. Die Funktionalität des Output Filters ist mit WB 2.8 durch ein Droplets abgedeckt und der Output Filter wird daher mit WB 2.9 von der Bildfläche verschwinden.
Ein schönes Beispiel, wie mit einer Idee und einem ersten Schritt eine grössere Flexibilität (Droplets, Frontendfilter) geschaffen wurde.
Doc
-
Ja, Ideen leben und entwickeln sich. Manche Entscheidungen bereut man später, andere nicht.
Aber mal ehrlich - wenn es nix mehr am WB zu verbessern gäbe - was würden wir dann alle mit unserer Freizeit anfangen?!? :-D :-D :-D