Autor Thema: commmit rejected  (Gelesen 704 mal)

Offline erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 573
commmit rejected
« am: 26 August 2021, 15:24:08 »
Sorry, das ist mein erster Versuch eines commit...
Der commit wird verweigert mit folgender msg:
*** EN 10_KNX.pm line 1923: code with attributes (apart from class) is not allowed
mein check mit der commandref_join.pl (lokal) bringt jedoch keine Fehler.
Die "böse Zeile" (da gibst mehrere...) schaut z.B. so aus:
<code class="pad30l">define lamp1 KNX 0/10/11:dpt1:listenonly</code> ... wobei die class definiert ist.
Bitte um Unterstützung
l.g. erwin
« Letzte Änderung: 26 August 2021, 15:37:53 von erwin »
FHEM aktuell auf RaspberryPI mit Busware ROT / Weinzirl IP731
Maintainer 10_KNX.pm
CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT
1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,...
MQTT2, KNX, SONOFF, mySENSORS,...

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15695
Antw:commmit rejected
« Antwort #1 am: 26 August 2021, 15:27:22 »
Die gezeigte Zeile hat zwei Ende-Tags (</code></code>). Evtl. liegt ja da das Problem?

(OT: Nach meiner Erfahrung ist bei commandref weniger Formatierung mehr...)
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 573
Antw:commmit rejected
« Antwort #2 am: 26 August 2021, 15:38:32 »
sorry, das war ein c&p fehler - habs ausgebessert...
FHEM aktuell auf RaspberryPI mit Busware ROT / Weinzirl IP731
Maintainer 10_KNX.pm
CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT
1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,...
MQTT2, KNX, SONOFF, mySENSORS,...

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15695
Antw:commmit rejected
« Antwort #3 am: 26 August 2021, 15:48:54 »
Dann sorry für den Hinweis.
Evtl. ist aber schlicht das "apart from" nicht (mehr) richtig (da gab's mal Diskussionen über Formatierungen, weil immer mal wieder nicht geschlossene Tags etc. dazu geführt hatten, dass ein Modul den "nachfolgenden" HTML-Code aus anderen Modulen oder dem frame "abgeschossen" hatten und der dann wüst aussah...)
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 573
Antw:commmit rejected
« Antwort #4 am: 26 August 2021, 17:27:50 »
Ich hab den Thread gefunden... war nicht leicht:   https://forum.fhem.de/index.php/topic,105376.0.html  ;D
ich hab jetzt fast alle "privaten classen" vermeiden können, bis auf eine:
Die Idee ist, eine lange Aufzählung von links oder optionen 2 spaltig zu machen...versus endlos lang scrollen...
Beispiel siehe screenshot.
um dennoch einchecken zu können, werde ich das Übel wohl fressen müssen.
2 spaltig wäre dennoch schöner, könnte man das in betracht ziehen?
l.g. erwin
FHEM aktuell auf RaspberryPI mit Busware ROT / Weinzirl IP731
Maintainer 10_KNX.pm
CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT
1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,...
MQTT2, KNX, SONOFF, mySENSORS,...

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15695
Antw:commmit rejected
« Antwort #5 am: 26 August 2021, 17:35:45 »
2 spaltig wäre dennoch schöner, könnte man das in betracht ziehen?
Kann ich nicht beurteilen, da muss ggf. jemand anderes (Rudi?) ran.

In dem Thread ist zu finden:
Man wandelt es um in sowas wie <table class="XXX">, wobei XXX nicht die Realisierung, sondern den Anwendungsfall beschreibt.
Der Style-Maintainer muss die Klasse XXX in der .css Datei passend gestalten.
Wir sollten irgendwo (hier?) die Klassennamen festlegen.
Nach dem müßte dann eben eine generische "Anwendungs-Klassennamen" Benennung erfolgen?

Ich kenne mich mit den HTML-Untiefen nicht aus, würde aber annehmen, dass eine Funktionsbezeichnung wie "2rowtable" ok wäre und Rudi (?) das dann irgendwo zentral einchecken müßte, damit der hook nicht zuschlägt?
Da in dem anderen Thread die Frage gestellt war, kannst du entweder warten, wann Rudi (?) das hier liest, oder auch proaktiv dort einen konkreten Vorschlag machen. Da auch andere da mitlesen, geht das vermutlich schneller...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 24494
Antw:commmit rejected
« Antwort #6 am: 26 August 2021, 18:12:56 »
Zitat
mein check mit der commandref_join.pl (lokal) bringt jedoch keine Fehler.
Ich habe die SVN-Fehlermeldung und commandref_join.pl angepasst.

Zitat
2 spaltig wäre dennoch schöner, könnte man das in betracht ziehen?
Schoener ist relativ, insb. wenn man jemanden fragt, der commandref.html auf dem Mobiltelefon liest.
Das Problem mit den Klassen war, dass die Leute angefangen haben Farben zu verwenden, was aber nur mit einem bestimmten Style halbwegs passend war, und mit anderen unleserlich.

Idealerweise wuerde sich jemand die Muehe machen CSS-Klassen fuer Problemfaelle zu erstellen, und diese dann fuer alle Styles bzw. Geraete anpassen. Im commandref selber duerfte man dann Klassen verwenden, aber keine definieren.
Solange bleiben wir bei einem "klassenlosen Gesellschaft".

Offline erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 573
Antw:commmit rejected
« Antwort #7 am: 26 August 2021, 19:53:03 »
Hallo Rudolf,
danke für die Info und das anpassen der commandref_join.pl !
Zitat
Schoener ist relativ, insb. wenn man jemanden fragt, der commandref.html auf dem Mobiltelefon liest.
.. das hätte ich berücksichtigt , die Frage bleibt, wie breit (viewport) ist ein Moblitelefon... unendliche varianten.
Im attachment ein html-file, als demo.
l.g. erwin
FHEM aktuell auf RaspberryPI mit Busware ROT / Weinzirl IP731
Maintainer 10_KNX.pm
CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT
1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,...
MQTT2, KNX, SONOFF, mySENSORS,...

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 24494
Antw:commmit rejected
« Antwort #8 am: 26 August 2021, 20:01:53 »
Zitat
Im attachment ein html-file, als demo.
Das sowas moeglich ist, ist mir schon bewusst (f18 kennt auch die Bildschirmgroesse), aber das gehoert nicht ins Doku-Abschnitt des Moduls sondern ins globale CSS, wie ich das vorhin geschrieben habe.

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 17453
  • s/fhem\.cfg/configDB/g
Antw:commmit rejected
« Antwort #9 am: 28 August 2021, 09:36:03 »
Und bitte nicht vergessen, dass die Texte aus der commandref auch für "help" verwendet und dafür nahezu alle Formatierungen entfernt werden, damit help auch in telnet einigermassen lesbare Ergebnisse ergibt.
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Lesen gefährdet die Unwissenheit!

Offline Prof. Dr. Peter Henning

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8134
Antw:commmit rejected
« Antwort #10 am: 28 August 2021, 09:51:01 »
Ich würde es zu schätzen wissen, sich in der CommandRef auf kurze Texte beschränken zu können und alle längeren Sachen und Beispiele ins Wiki zu verlagern.

Da gibt es Module, bei denen die Commandref gigantisch aufgebläht wurde...

LG

pah

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15695
Antw:commmit rejected
« Antwort #11 am: 28 August 2021, 10:33:55 »
Ich würde es zu schätzen wissen, sich in der CommandRef auf kurze Texte beschränken zu können und alle längeren Sachen und Beispiele ins Wiki zu verlagern.

Da gibt es Module, bei denen die Commandref gigantisch aufgebläht wurde...
...there's more than one way...

Da mich das auch stört, setze ich "modular", und evtl. wäre es auch weiter eine Idee, das als default zu setzen (das alles ist hier aber irgendwie OT, oder?).

Das Argument mind. einer der Autoren derartiger Module ist afaik, dass er die Hoheit über die commandref behalten will und "schlechte" Erfahrungen im Wiki gemacht hat. Auch (teils) nachvollziehbar...

(Vermutlich nicht nur) mein persönliches Leitbild  als Maintainer ist, die commandref so zu gestalten, dass a) die englische Version vollständig ist (DE gibt es nur, wenn so übernommen), und die b) so ist, dass man das Modul ausschließlich mit der commandref in Betrieb nehmen kann. Meistens kann man die daher relativ kurz halten, aber manche Module sind eben auch etwas komplexer bzw. kennen viele Hardware-Typen etc., von daher ist es nachvollziehbar, dass eine commandref eben auch wächst und wächst...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}