WB 2.8

[susigross]

Kann man das schon irgendwo runterladen?
Der Link in der Newsbox führt ja nur auf eine Info-Seite.

[ruebenwurzel]

Hallo,

man kann sich jederzeit eine aktuelle Version vom SVN herunterladen. Entweder man nutzt einen client (z.B. Tortoise SVN) oder den link zum zip Archiv auf der Trunk-Seite (ganz unten)

http://project.websitebaker2.org/browser/trunk

Matthias

[susigross]

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.

[chio]

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.

[susigross]

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.

[ruebenwurzel]

@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

[Stefek]

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

[aldus]

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:

Code: [Select]

<?php // diese Zeile wie gehabt nicht ....
$display_none_str = "style=\"display:none;\"";
$perm_names = array (&#39;modules&#39;, &#39;templates&#39;, &#39;languages&#39;);
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

[Stefek]

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

[ruebenwurzel]

@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

[StudioVerlag]

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........

[Stefek]

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

[chio]

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.

[StudioVerlag]

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   , nee nicht wirklich.
Außerdem haste ja die Freiheit alles reinzupacken was DIR paßt, also auch nix valides.
Gruß, Hans>NUL

[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.

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

[Luisehahne]

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

[Stefek]

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]

[Luisehahne]

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

[Stefek]

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

[StudioVerlag]

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

[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

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. oder das von Argos am besten findet, oder er macht sich einfach sein eigenes.

Matthias

[Stefek]

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

[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.)

Aber vielleicht guckst Du zu beschränkt.

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":

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 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