[Kommentar] Style-Guide
-
Ich hab schon vor längerem Angefangen einen Adapter zu schreiben der für die Adapter Entwicklung gedacht ist.
Mich hat es genervt das jeder irgendwas macht. Außerdem das man immer wieder die gleichen Schritte macht, die Zeit Kosten und Automatisiert werden können.
Fakt ist Stand heute ist das ganze bis jetzt ein besserer Template Customizer mit einem einfachen Editor, der alte aus dem JS Editor.
So etwas in der Art stand ja mal auf der Wunsch Liste.
Ich schwanke schon lange ob ich das Veröffentlichen soll oder nicht.
Alleine schaff ich es jedenfalls nicht das ganze soweit aus zu bauen das es als IDE für iobroker taugt.
Gesendet von meinem m8 mit Tapatalk
-
Die unterschiedlichen Beschriftungen kommen imho daher, dass an der Darstellung im Admin in der Entwicklungsphase noch Änderungen vorgenommen wurden. Bei zwei Adaptern habe ich es direkt Nach dem Aufruf mit der Vorlage des Admins umgesetzt… Ein paar Versionen später hatte sich die Darstellung aber geändert. Also müsste ich es im Nachgang nochmal wieder ändern, dass ist aber bei vielen nicht passiert.
Für eine how to bin ich auch, auch mit einer Übersicht der nutzbaren Funktionen wäre auch super wie zb pop ups, Tabellen usw. Um eine Tabelle in die Config zu bekommen, die man ändern kann, hab ich bestimmt 3 Wochen rumprobiert.
Das Problem ist auch, dass die Config eher ein notwendiges Übel ist. Und die meisten sich im frontend Bereich nicht so sehr zurecht finden (bri mir zumindestens so)
Von daher von mir auch ein
+1
Gesendet von meinem Handy
-
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
-
