[Kommentar] Style-Guide
-
Muss es wirklich eine IDE für Adapter-Entwicklung werden?
DIe Idee eines "Adapter-Generators" finde ich Bombe.
Man gibt den Namen an klickt sich die io-package-EInstellungen zusammen, sagt welche Parameter man erfassen will mit seinen Datentypen (inkl. Arrays und so) und kann dann konfigurieren wie das im Frontend ist und bekommt:
-
package/io-package.json
-
alle nötigen Files
-
index_m.html vorbereitet ggf mit Übersetzungen oder wenigstens auch hier vorbereitet
-
eine main.js als Template nur spezifischer auf das zusammengeklickte ausgerichtet
Das ganze als ZIP.Datei (oder halt auf dem lokalen Rechner in einem verzeichnis.
Das wäre eine soooooo große Hilfe als ersten Schritt. Aber damit ist schon viel vorbereitet für die Standard-Adapter-Fälle.
Dann hat jeder seine eigene IDE für alles weitere und so … Aber quasi ein "Adapter-basis-generator" wäre GEIL!!!
-
-
PS: Sowas muss auch kein Adapter sein … Auch ein Web-Wizard der dann eine ZIP Datei als Download ergibt wäre ne idee ...
Logik-technisch wäre ich sofort dabei ... aber die ganze UI und auch index_h.html generieren eher schwierig für mich
-
Ich lad das Ding am Wochenende mal auf Github hoch.
Gesendet von meinem m8 mit Tapatalk
-
Bin gespannt
-
Na da habe ich ja was angestellt…. :roll:
Schade, das ich bis jetzt nix mit UI außer davor sitzen anfangen kann. Seufz.
-
Bitte erwartet nicht zu viel. Die Pläne sind gewaltig, aber genau so groß die Wissenslücken.
Außerdem fehlt mir gerade leider die Zeit zum Programmieren.
Gesendet von meinem m8 mit Tapatalk
-
Eigentlich sollte es styleguide sein. Mindestens dachte ich dass eins gibt.
Nun dürch die Änderungen, die MaterialCSS auch macht sind manche Beschriftungen nach unten gerutscht.
Fakt list, die müssen oben sein und alles anderes ist Bug.
Auch für Code gibt es Style Guide: Google JS Style.
-
Interessant … höre ich alles zum ersten mal :-))
@Bluefox: Nicht hauen Bitte
Haben es halt nie enforced und wenn dann UI-Legasteniker wie ich an UIs rumpfuschen passiert sowas
-
Auch für Code gibt es Style Guide: Google JS Style. `
Dann weiß ich nun was ich dringend mal lesen sollte..Edit: das ist aber ganz schön viel..
Gesendet von meinem Handy
-
Auch für Code gibt es Style Guide: Google JS Style. `
2 Spaces indentation, ughhh :?Naja, ich hab meinen eigenen Style "Guide" für meine Libs & Adapter. Recommended-Einstellungen von TSLint + https://github.com/AlCalzone/ioBroker.tradfri/blob/master/tslint.json. Das wird dann auch schön automatisch vom Editor umgesetzt bzw. angemeckert.
Eigentlich sollte es styleguide sein. Mindestens dachte ich dass eins gibt.
Nun dürch die Änderungen, die MaterialCSS auch macht sind manche Beschriftungen nach unten gerutscht.
Fakt list, die müssen oben sein und alles anderes ist Bug. `
Die Erfahrung hab ich auch gemacht bei einem Adapter. Da waren 1-2 Felder, die einfach nicht so wollten wie ich und anders aussahen als der Rest. Das hat schon 1h Google + etwas Tricksen gekostet bis alles normal aussah. -
Muss es wirklich eine IDE für Adapter-Entwicklung werden?
DIe Idee eines "Adapter-Generators" finde ich Bombe. `
Könnte eine Erweiterung des template-adapters werden und so in die Richtung von create-react-app gehen. Eine Anwendung, die man einmalig z.B. per npx ausführt und aus verschiedenen Template-Schnipseln das nötigste zusammenbaut. Dann könnte man z.B. den normalen und den TypeScript-Template-Adapter zusammenführen.
-
Bei Google Style Guide kann/muss man auch Ausnahmen machen. 4 Spaces als "indent" ist so eins.
-
Für die ioBroker-Adapter wäre es super wenn einer das Thema treibt und es einfach macht. `
Bin jetzt erst durch https://forum.iobroker.net/viewtopic.php?f=17&t=15654&p=164915#p164915 auf dieses Posting aufmerksam geworden. Und was einen Style-Guide angeht so bin ich gerne bereit, mich hierfür zu engagieren, am besten mit 1-2 anderen, die hier auch schon einschlägige Erfahrung haben.Auf github scheint(!) es irgendwelche Vorgaben zu geben, aber github ist halt eine Entwickler-Platform. Insofern schlage ich vor, die Anwender-Doku ausschließlich auf der ioBroker-Webseite zu veröffentlichen und Installation, Change-Log, Abhängigkeiten, Kurzbeschreibung, technische Details usw. auf github und evtl. parallel dazu auch bei den Fragezeichen hinter den Adaptern. Da gehört das Zeug m.E. nämlich hin. Da ist dann ein Schema dahinter. Und auch für github braucht es m.E. detaillierte Vorgaben. Gutes Beispiel: SQL- vs. Viessmann-Adapter (auf die schnelle, weil ich da grad dran bin). Wobei das github-Readme hinter dem Fragezeichen fast schon Overkill ist. Hinter dem Fragezeichen stelle ich mir eine Kurzbeschreibung vor, Change-Log, Installationsanleitung und vor allem -voraussetzungen (Stichwort "npm" beim Admin-Adapter, mit dem ich eben zu tun hatte). Bei der automatisch generierten Webseite der Adapterliste kann man ja bei github hinter den Links bleiben.
Wenn sich außer mir noch ein paar Nasen finden dann sollte man für die einen eigenen Bereich definieren, damit hier nicht allzu viele mitmischen (außer den Entwicklern).
-
Noch ein Wort zum Style-Guide und wie man das handhabt, daß sich die Leute dran halten. Das kann man m.E. insofern forcieren, als man in der Adapterliste einen Marker einführt für styleguide-konforme UIs, evtl. sogar eine Gruppierung. Wenn ein Adapter dann nicht mehr oben bei den styleguide-konformen Adapter auftaucht, dann besteht durchaus die Möglichkeit, daß sich der eine oder andere Entwickler überlegt, was der tun kann um wieder oben aufzutauchen
-
Lasst bitte Styleguide und Webseite/Doku nicht zu arg mischen. Zwei Threads - je einen pro Thema - ist ganz ok
Ich schreibe mal im anderen Thread nochwas
-
Naja - auch für die Webseite (Anwender-Doku) muß (sollte) es einen Styleguide geben! D.h. mehrere verschiedene: * UI
-
"Fragezeichen"
-
Anwender-Doku (Webseite)
-
github
-
