commmit rejected

erwin · 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 Auswählen

<code class="pad30l">define lamp1 KNX 0/10/11:dpt1:listenonly</code> ... wobei die class definiert ist.
Bitte um Unterstützung
l.g. erwin

Beta-User · 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...)

erwin · 26 August 2021, 15:38:32

sorry, das war ein c&p fehler - habs ausgebessert...

Beta-User · 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...)

erwin · 26 August 2021, 17:27:50

Ich hab den Thread gefunden... war nicht leicht: https://forum.fhem.de/index.php/topic,105376.0.html

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

Beta-User · 26 August 2021, 17:35:45

Zitat von: erwin am 26 August 2021, 17:27:50
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:

Zitat von: rudolfkoenig am 24 November 2019, 18:08:15
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...

rudolfkoenig · 26 August 2021, 18:12:56

Zitatmein check mit der commandref_join.pl (lokal) bringt jedoch keine Fehler.

Ich habe die SVN-Fehlermeldung und commandref_join.pl angepasst.

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

erwin · 26 August 2021, 19:53:03

Hallo Rudolf,
danke für die Info und das anpassen der commandref_join.pl !

ZitatSchoener 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

rudolfkoenig · 26 August 2021, 20:01:53

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

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

Prof. Dr. Peter Henning · 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

Beta-User · 28 August 2021, 10:33:55

Zitat von: Prof. Dr. Peter Henning 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...

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