commmit rejected

[erwin]

Sorry, das ist mein erster Versuch eines commit...
Der commit wird verweigert mit folgender msg:

Code: [Auswählen]

*** 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]

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]

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

[Beta-User]

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]

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]

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

[rudolfkoenig]

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

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

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

[erwin]

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

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

[rudolfkoenig]

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.

[betateilchen]

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]

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]

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