Entwickler Unterstützung gesucht - Release-Vorbereitung

[MicHau]

Das sonstige Release ist ja unabhängig vom Editor - und hier habe ich bisher noch nichts gehört, vgl. mein Ursprungsposting. D.h. wenn das so weiter geht, wird es noch sehr lange dauern, bis es kommt...

Ich nehme an, du spielst darauf an:

Somit würden wir als nächstes Richtung Freeze der internen Strukturen schauen - und genau da sehe ich noch Handlungsbedarf!
[HILFE]Ich such Unterstützung beim Aufräumen und polieren (neudeutsch: Refactoring) der internen Strukturen![/HILFE]
So ist z.B. die templateenginge.js inzwischen sehr "gewachsen".
Mit der der hatte ich damals angefangen, als ich noch nicht sonderlich viel über JavaScript Internas wusste... (Der iconhandler.js ist da schon deutlich weiter - und JavaScript Profis wissen sicher nochmals deutlich mehr)

Ich biete meine Hilfe gerne an, bin aber alles andere als eine JavaScript Profi. Ich würde mich als Script-Anfänger mit Profi-Knowhow in Nicht-Script-Sprachen bezeichnen. Wenn mir jemand auf die Sprünge hilft, was da genau wo zu ändern wäre bzw. was aktuell nicht geschickt gelöst ist, kann ich mich damit auseinander setzen (learning-by-doing hat bisher noch immer funktioniert).

[Chris M.]

Ich nehme an, du spielst darauf an:

Ja

Ich biete meine Hilfe gerne an, bin aber alles andere als eine JavaScript Profi. Ich würde mich als Script-Anfänger mit Profi-Knowhow in Nicht-Script-Sprachen bezeichnen. Wenn mir jemand auf die Sprünge hilft, was da genau wo zu ändern wäre bzw. was aktuell nicht geschickt gelöst ist, kann ich mich damit auseinander setzen (learning-by-doing hat bisher noch immer funktioniert).

Das klingt schon mal sehr gut - wenn leider auch nicht perfekt. Denn da bin ich auch gestartet und habe so etwas wie die templateengine.js verbrochen...

Ziel wären saubere Strukturen (wie z.B. im iconhandler.js oder Editor).

Punkte die gemacht werden müssten und sollten:

• Umstellen der templateengine.js auf saubereres Objekt, dass den globalen Namensraum nicht mehr verpestet
• Ggf. modulatisiern der templateengine - d.h. das gewachsenes identifizieren, dabei ggf. Gemeinsamkeiten zusammenfassen und ggf. auslagern, wenn sinnvoll
• Grundsätzlich immer ein Auge auf effiziente Strukturen haben
• Mal die ganze Anwendung profilien und nach Bottlenecks suchen (alleine das identifizieren ist schon viel wert!) (*)
• Die ganzen Widgets mal durchforsten, ob man da nicht auch mehr Code vereinheitlichen und ggf. Auslagern kann (d.h. den bestehenden Weg einfach weiter gehen)

Ich denke der letzte Punkt ist mit allgemeinem Programmier-KnowHow gut machbar. Der davor wohl auch.
Bei den Punkten der templateengine sollte man wissen, wie JavaScript tickt, d.h. erst mal bestehenden, guten Code wirklich verstanden haben. Die Sprache ist erstaunlich komplex und anders, dafür dass die sich optisch wie C / C++ / Java tarnt.

--
(*): Dabei wichtig zu wissen: Zum Release werden die Dateien zusammengefasst und Minimized. D.h. die reine Ladezeit ist hier nicht so wichtig. Aber sind die DOM-Updates geschickt? Muss der zwischendrinnen einen Reflow oder gar einen Redraw machen? Etc. pp. - das ist spannend.

[makki]

Das ist, glaub ich, der Punkt, der noch nicht wirklich angekommen ist: auch aktuelles SVN ist kein zwingendes Malprogramm!

Doch schon, ich benutze die CV (mal von der Demo abgesehen) selbst auch ausschliesslich so.. Nur beschleicht mich das Gefühl, das erheblich mehr in das Thema "Malprogramm in 1D/2D/3D" fliesst, als in das IMHO eigentliche "Killerfeature" der CV: "just do it"
Ich würde mich da sogar reinhängen, hab allerdings die Angst immer was vom "Malprogramm" kaputt zu machen (meine Meinung ist immernoch: jQuery-UI, Themes, keinerlei Layout in Code oder config!)

Natürlich kommen so Sachen die - mit beliebig hohem Aufwand - toll aussehen besser im Auge an, aber da bin ich nach 20J IT zu nüchtern für und suche eher die technisch richtige Lösung
Weil spätestens übermorgen will ich das die Visu aus dem ETS-Export fällt

Makki

[swiss]

Hmmm...

Naja so schlimm finde ich das "malen" mit der CV nicht. Der Aufwand ist wesentlich geringer als beim HS. Dazu kommt, dass ich die Funktion Rowspan sehr schätze. Was mich nämlich bei der Releas immer gestört hat war, dass wenn man ein paar Slider und Switch auf einer Seite plazierte sehr schnell an den Punkt kam wo man scrollen musste. Und ich hasse scrollen in einer Visu. Nun kann ich auch viele Steuerelemente übersichtlich anordnen und brauch nicht zu scrollen.

-> Scrollen in einer Visu ist für mich ein ein NoGo. Dann lieber einmal Sehnenscheidenenzündung und dann dafür aber eine gut bedienbare Visu.

[Chris M.]

Das malen hat ja noch nicht mal richtig angefangen, dass kommt erst mit den 2D Seiten (die Heizungs-Seite ist die einzige in der "freien Wildbahn" die ich da kenne...).
Und Malen ist ein Seegen gegenüber dem Konstruieren, dass man für die 3D Seiten brauchen wird...

Text-Seiten werden immer Just-do-It und für Skripte, etc. da sein. Nutzt man die ohne colspan, sind die auch 100% kompatibel zum Release. Und selbst mit colspan und group sind die ratz fatz gebaut - auch per Skript.

Dass mehr Aufwand in's Eye Candy fließt ist vollkommen klar:

• der einfache Text-Modus ist schon weitestgehend fertig
• das Eye Candy hat Nachholbedarf
• das ist komplexer und braucht dafür einfach mehr

Kaputt machen kann man da auch nicht viel. Zumindest wenn man an den Nicht-Design-Elementen dreht. Die Designs haben so robust zu sein, dass die das abkönnen.

[peuter]

So ist z.B. die templateenginge.js inzwischen sehr "gewachsen".
Mit der der hatte ich damals angefangen, als ich noch nicht sonderlich viel über JavaScript Internas wusste... (Der iconhandler.js ist da schon deutlich weiter - und JavaScript Profis wissen sicher nochmals deutlich mehr)

Um nochmal zu diesem Thema zurückzukommen:
Schon alleine die Tatsache, dass ich nach dem Lesen nicht wirklich wusste was da zu tun wäre, hat mir gezeigt, dass ich nicht unbedingt geeignet bin, die Aufgabe zu übernehmen. Ich bin also weit weg davon ein Javascript-Profi zu sein.
Nach der Nachfrage von Michael(MicHau) und der darauf folgenden Erklärung ist mir immerhin klarer was zu tun ist.

Wenn sich da in naher Zukunft niemand geeigneteres findet kann ichs mal versuchen. Immerhin hab ich ja zumindest Teile der templateengine.js selbst "verbrochen".

[makki]

Nur um das nochmal klarzustellen: ich habe den neuen Editor mindestens "mit zu verantworten" und stehe dazu!
Da brauchts sicherlich noch feinschliff, aber das kann werden..

Nur sehe ich da eben eine Fehlentwicklung, was den ganzen sums aussenrum angeht - klares Ziel meinerseits ist "Auto-Visu" - Auflösungs-/Endgeräte-unabhägig und ohne jegliche (per config) Einflussmöglichkeit des Layouts!!
Alles andere ist für mich Sehnenscheidentzündung=Malprogramm.

Sorry, aber nach 5J mit halbfertiger Visu traue ich mich das mal so ganz knapp auf den Punkt zu bringen

Makki

[vlamers]

Auch wenn ich für die Release Vorbereitun ungeeignet bin.

Was meinst du mit Fehlentwicklung in richtung malen?

Wer nicht malen will definiert seine menüs und switches, slider etc ohne flavour, colspan, rowspan usw.

Wer es sich selbst antun möchte, zuviel Zeit hat oder so wie ich einfach drauf steht wenn das gut aussieht und a bissl was her macht der kann malen bis die Sehnen schmerzen.

Ich persönlich finde das, im Vergleich zu den anderen, die Universellste Lösung für "maler" und "puristen"

Gruß

[Chris M.]

Wenn sich da in naher Zukunft niemand geeigneteres findet kann ichs mal versuchen. Immerhin hab ich ja zumindest Teile der templateengine.js selbst "verbrochen".

Naja, wenn's schief geht, kann man's ja immer noch zurückdrehen...

Nur sehe ich da eben eine Fehlentwicklung, was den ganzen sums aussenrum angeht - klares Ziel meinerseits ist "Auto-Visu" - Auflösungs-/Endgeräte-unabhägig und ohne jegliche (per config) Einflussmöglichkeit des Layouts!!

Keine Angst, das wird immer so gehen. Das geht aber auch jetzt schon - folglich ist in dem Bereich natürlich wenig (aber auch nicht keine!) Weiterentwicklung passiert (z.B. ist <include> genau aus dem Grund der automatischen Config-Generierung reingekommen...). Der andere Bereich musste halt noch etwas aufholen - und der ist auch zwingend notwendig um Interessenten zu gewinnen. Auch wenn die dann nur das einfache nehmen...

Die Verteilung der Vorführwagen in einem Autohaus entspricht auch nicht dem Verhältnis der Zulassungstatistik...

Wer nicht malen will definiert seine menüs und switches, slider etc ohne flavour, colspan, rowspan usw.

Eben.

Wer es sich selbst antun möchte, zuviel Zeit hat oder so wie ich einfach drauf steht wenn das gut aussieht und a bissl was her macht der kann malen bis die Sehnen schmerzen.

Es geht um die Wahlfreiheit. Jeder soll das nehmen können, was er braucht und will.

Den Leuten Sachen verkaufen, die die nicht brauchen, aber ihnen trotzdem weismachen, dass die die wollen braucht ein Werbeetat wie Apple...

[makki]

Chris, ich weiss absolut was du meinst ("verkauft" wird z.B. über das Metal-Design - niemand frägt ja, welchen Aufwand das macht!)
Ist dieselbe Nummer wie mit Rattengeilen HS-Visus, fixed alle an - Super - bis man feststellt, das man dafür 4 Wochen seine Familie verlassen muss und danach 4 Wochen Reha braucht

Ich mag gerne den selten so lauten Gegenpol darstellen: Minimaler Aufwand ist primärziel!
Damit gewinnt man keinen beliebtheits/Designer-preis, das ist mir absolut klar, aber das ist IMHO was - abseits der 1% Schreihälse - der Markt primär braucht.

Soviel nur zu meinen Beweggründen

Makki

[Bodo]

Design Metall rulez

Hoi

Ich hatte erst das uralte Standard-Design.
Dann habe ich auf des Metall-Design umgestellt.
Dabei habe ich 30% der vorher benötigten Elemente entsorgen können und eine bessere, logischere Gruppierung von zusammengehörigen Elementen erreicht.

Insgesamt einfacher, übersichtlicher und platzsparender.
Und nicht zuletzt skaliert es besser auf den verschiedenen Bildschirmen und Handys.

Man merkt einfach, dass das inteligenter gemacht ist und mehr drin steckt, ohne dass es aufwändiger wäre in der Programmierung. Eher das Gegenteil ist der Fall, es ist einfacher.
Und mit copy paste einer Einheit (z.B. Jalu mit Fensterstatus) unendlich schnell gemacht...

[peuter]

Zum Thema Refactoring:
Ich habe mich heute mal darin versucht und eine erste Version einer aufgeräumteren templateengine.js eingecheckt. Vornehmlich geht es erstmal darum den globalen Namensraum nicht mehr zu "verschmutzen". Da ich hierfür sämtliche Funktions-/Variablenaufrufe der templateengine ändern musste, kann ich es natürlich nicht ausschließen, das einige Dinge jetzt nicht mehr funktionieren. Also wer Probleme feststellt, bitte melden. Die Fixes dafür sind schnell gemacht.

Als zweites habe ich ansatzweise versucht die vorhandene Funktionen inhaltlich zu gruppieren, dafür habe ich alles was mit Navbars + Topnavigation zu tun hat in den sogenannten PagePartsHandler ausgelagert (kann man später in eine eigene js-Datei auslagern, wenn das inhaltlich tragbar ist).

Bei einer weiteren Gruppierung/Auslagerung der TemplateEngine-Methoden tue ich mich ein wenig schwer, Vorschläge sind da willkommen.

Ansonsten wäre für mich die structure/pure/_common.js auch ein Kandidat für ein solches Refactoring.

Abschließend sei nochmal erwähnt, dass ich kein Javascript-Profi bin und man das an einigen Stellen sicherlich besser hätte lösen können. Wer´s also besser weiß/kann, darf sich hier gerne mit einbringen.

Zum Thema "Visu malen":
Ich muss gestehen, dass ich die Diskussion nicht nachvollziehen kann. Auch im Metal-Design kann man sich genauso einfach und schnell ne Visu zusammenbasteln, wie in jedem anderen Design auch. Dann muss man einfach auf den ganzen "Eye-Candy"-Kram verzichten und hat ne einfache, mit wenig Aufwand erstellte Visu.
Wer die Zeit und Nerven hat, ein wenig mehr Zeit in die Erstellung seiner Config zu stecken, kann das eben auch tun.
Damit sollten eigentlich beide Zielgruppen gleichermaßen zufriedenstellend bedient sein.

Ich persönlich investieren lieber einmalig paar Stunden mehr in meine Config, damit Sie übersichtlich und alle Informationen die ich haben will mit wenigen Klicks zu finden sind. Denn ich spare lieber Zeit beim (mehrmaligen) Benutzen der Visu als beim (einmaligen) Erstellen.

[iwan]

Hallo

Zum Thema Refactoring:
Ich habe mich heute mal darin versucht und eine erste Version einer aufgeräumteren templateengine.js eingecheckt.

Das scheint noch irgendwio der Wurm drin zu sein.
Nach dem Update auf 1342 da meine seite so aus:

Auch mit der Democonfig kommt nicht mehr...
Bin jetzt wieder zurück auf 1332...

Iwan

[peuter]

Das scheint noch irgendwio der Wurm drin zu sein.
Nach dem Update auf 1342 da meine seite so aus:

Ok da war noch ein Fehler beim Text-Widget. In Rev. #1344 läuft die Demo-Config bei mir.

[iwan]

Hallo

Das bringt bei mir leider keine Änderung...

Iwan

Edit:
Hat sich erledigt!
Danke für den Hinweis mit der Konsole.
Hab's gefunden war was im structure_custom.js :-(