Tags in der Doku

[rudolfkoenig]

Es ist mir gerade aufgefallen, dass ab dem Modul Plugwise die Doku eingerueckt ist, ganz am Ende schaut es ganz schlimm aus. Ich vermute, dass dafuer offene <table> Tags verantwortlich sind. Ich habe deswegen das SVN pre-commit und contrib/commandref_join.pl mit den tags td/tr/table erweitert, man bekommt beim Aufruf von commandref_join.pl jetzt folgendes:

Code Auswählen Erweitern

EN FHEM/95_Alarm.pm: Unbalanced tr (-1, last line ok: 856)
EN FHEM/57_Calendar.pm: Unbalanced table (-3, last line ok: 1259)
EN FHEM/98_CustomReadings.pm: Unbalanced tr (1, last line ok: 163)
EN FHEM/98_CustomReadings.pm: Unbalanced td (3, last line ok: 163)
EN FHEM/36_EC3000.pm: Unbalanced tr (1, last line ok: 187)
EN FHEM/36_EC3000.pm: Unbalanced td (1, last line ok: 187)
EN FHEM/36_EMT7110.pm: Unbalanced tr (1, last line ok: 232)
EN FHEM/36_EMT7110.pm: Unbalanced td (1, last line ok: 232)
EN FHEM/36_EleroDrive.pm: Unbalanced tr (1, last line ok: 290)
EN FHEM/36_EleroDrive.pm: Unbalanced td (1, last line ok: 290)
EN FHEM/72_FB_CALLLIST.pm: Unbalanced tr (1, last line ok: 1041)
EN FHEM/72_FB_CALLLIST.pm: Unbalanced td (-3, last line ok: 1061)
EN FHEM/72_FB_CALLMONITOR.pm: Unbalanced tr (1, last line ok: 1746)
EN FHEM/72_FB_CALLMONITOR.pm: Unbalanced td (1, last line ok: 1746)
EN FHEM/36_LaCrosse.pm: Unbalanced tr (1, last line ok: 547)
EN FHEM/36_LaCrosse.pm: Unbalanced td (1, last line ok: 547)
EN FHEM/36_Level.pm: Unbalanced tr (1, last line ok: 208)
EN FHEM/36_Level.pm: Unbalanced td (1, last line ok: 208)
EN FHEM/00_MAXLAN.pm: Unbalanced tr (1, last line ok: 868)
EN FHEM/00_MAXLAN.pm: Unbalanced td (1, last line ok: 868)
EN FHEM/36_PCA301.pm: Unbalanced tr (1, last line ok: 291)
EN FHEM/36_PCA301.pm: Unbalanced td (1, last line ok: 291)
EN FHEM/73_PRESENCE.pm: Unbalanced tr (1, last line ok: 1059)
EN FHEM/73_PRESENCE.pm: Unbalanced td (1, last line ok: 1059)
EN FHEM/45_Plugwise.pm: Unbalanced tr (1, last line ok: 1372)
EN FHEM/45_Plugwise.pm: Unbalanced td (1, last line ok: 1372)
EN FHEM/40_RFXCOM.pm: Unbalanced tr (1, last line ok: 381)
EN FHEM/40_RFXCOM.pm: Unbalanced td (1, last line ok: 381)
EN FHEM/51_RPI_GPIO.pm: Unbalanced table (-4, last line ok: 705)
EN FHEM/49_SSCam.pm: Unbalanced table (2, last line ok: 1517)
EN FHEM/49_SSCam.pm: Unbalanced td (8, last line ok: 1520)
EN FHEM/34_SWAP.pm: Unbalanced tr (1, last line ok: 1261)
EN FHEM/34_SWAP.pm: Unbalanced td (1, last line ok: 1261)
EN FHEM/35_SWAP_0000002200000003.pm: Unbalanced tr (1, last line ok: 385)
EN FHEM/35_SWAP_0000002200000003.pm: Unbalanced td (1, last line ok: 385)
EN FHEM/35_SWAP_0000002200000008.pm: Unbalanced tr (1, last line ok: 78)
EN FHEM/35_SWAP_0000002200000008.pm: Unbalanced td (1, last line ok: 78)
EN FHEM/42_SYSMON.pm: Unbalanced table (-1, last line ok: 5074)
EN FHEM/42_SYSMON.pm: Unbalanced td (-66, last line ok: 4982)
EN FHEM/45_TRX.pm: Unbalanced tr (1, last line ok: 411)
EN FHEM/45_TRX.pm: Unbalanced td (1, last line ok: 411)
EN FHEM/73_km200.pm: Unbalanced td (-28, last line ok: 2985)
EN FHEM/95_remotecontrol.pm: Unbalanced td (-1, last line ok: 409)
DE FHEM/57_Calendar.pm: Unbalanced table (-3, last line ok: 1465)
DE FHEM/72_FB_CALLLIST.pm: Unbalanced tr (1, last line ok: 1237)
DE FHEM/72_FB_CALLLIST.pm: Unbalanced td (-3, last line ok: 1258)
DE FHEM/72_FB_CALLMONITOR.pm: Unbalanced tr (1, last line ok: 1897)
DE FHEM/72_FB_CALLMONITOR.pm: Unbalanced td (1, last line ok: 1897)
DE FHEM/98_HMinfo.pm: Unbalanced tr (1, last line ok: 2888)
DE FHEM/98_HMinfo.pm: Unbalanced td (1, last line ok: 2888)
DE FHEM/73_PRESENCE.pm: Unbalanced tr (1, last line ok: 1302)
DE FHEM/73_PRESENCE.pm: Unbalanced td (1, last line ok: 1302)
DE FHEM/51_RPI_GPIO.pm: Unbalanced table (-4, last line ok: 898)
DE FHEM/42_SYSMON.pm: Unbalanced table (-1, last line ok: 5736)
DE FHEM/42_SYSMON.pm: Unbalanced td (-66, last line ok: 5644)
DE FHEM/73_km200.pm: Unbalanced td (-28, last line ok: 3176)
DE FHEM/95_remotecontrol.pm: Unbalanced td (-1, last line ok: 495)

Ich moechte die Verantwortlichen bitten, das entsprechend zu fixen. Generell moechte ich bitten von Tabellen, soweit moeglich, Abstand zu halten, da es auf kleineren Bildschirmen zu Problemen fuehrt.

[Markus Bloch]

funktioniert das auch mit Argumenten in den Tags?

Code Auswählen Erweitern

<table class="...">

<td colspan="2">

Momentan kann ich FB_CALLLIST deswegen nicht einchecken, obwohl die Tags alle richtig sind.

Gruß
Markus

[rudolfkoenig]

Mag sein, dass das nicht tut, allerdings sollten solche "Features" eh nicht verwendet werden.
Urspruenglich sollte die Doku "pod" sein.

[Markus Bloch]

Du redest im Konjunktiv. Heist das, es soll irgendwann auf Pod umgestellt werden oder nicht mehr (aufgrund der Vielzahl)?

Ich glaube jedenfalls nicht, dass ich der einzige bin, der ein Tag mit Argumenten in der commandref hat. Ich schlage daher angehangene Änderung vor.

Gruß
Markus

[rudolfkoenig]

Heist das, es soll irgendwann auf Pod umgestellt werden

Nein, urspruenglich war pod geplant, aber wir haben dann HTML beschlossen.

Ich glaube jedenfalls nicht, dass ich der einzige bin, der ein Tag mit Argumenten in der commandref hat.

DAS ist kein Grund. Ich habe das "Problem" vor (gefuehlt) 2 Jahren beim UL schon unterbunden, weil manche Autoren angefangen haben mit Farben zu experimentieren, und das wurde mir zu bunt. Ich haette gerne nur Text, mit so wenig Dekorationen wie moeglich. Ich lass mich natuerlich ueberstimmen, aber nur mit sinnvollen Argumenten.

[DS_Starter]

Hallo Rudi,

habe die Doku von SSCam gefixt und eingecheckt.

Grüße
Heiko

[betateilchen]

Ich haette gerne nur Text, mit so wenig Dekorationen wie moeglich.

Meine vollste Unterstützung für diesen Wunsch!

[Dr. Boris Neubert]

Hallo Rudi,

in commandref_join muss Zeile 94 so was wie

Code Auswählen Erweitern

          $tagcount{$tag} +=()= ($l =~ /<$tag( [^>])*>/gi);

sein, damit auch öffnende Tags mit Attributen erkannt werden (ungetestet).

Grüße
Boris

[rudolfkoenig]

DAS ist mir schon klar, es geht in dieser Diskussion gerade darum, dass ich keine Attribute sehen will.

Sonst fangen die Leute mit "style='color:light-blue;font-size:48px'" und Vergleichbares an. Das habe ich fuer ul vor (gefuehlt) 2 Jahren einmal schon unterbunden, jetzt folgte nur table & co, da ich damals nicht auf die Idee kam, das man table in der Doku verwenden koennte.

[Dr. Boris Neubert]

Für mich sind Tabellen mit Rahmendeutlich besser lesbar als Tabellen ohne Rahmen und diese sind deutlich besser lesbar als Listen.

[justme1968]

eigentlich ist das ja ein typischer anwendungsfall für die trennung von inhalt und darstellung.

ob die tabelle farben und schnörkelchen hat sollte der anwender per stylesheet entscheiden dürfen.

ob es eine tabele gibt der entwickler/erstellter.

wie wäre es eine hand voll css klassen vorzugeben und als einziges zu erlauben?

damit könnte man auch lange beispiele aus- und einblenden.

[Dr. Boris Neubert]

Finde ich gut!

Brauchen wir für die Doku dann eigene Klassen für Tabellen, Listen, ...? Derzeit wir mMn ja schon das Stylesheet drübergezogen, dass für FHEMWEB auch sonst verwendet wird.

[herrmannj]

find ich auch gut. Das mit den vorgegeben Klassen und auch ein- und ausblenden. Der Profi schaut auf die man page type doku und der ambitionierte Anwender findet zusätzlichen Input.

vg
joerg

[betateilchen]

Damit macht man meines Erachtens das Erstellen der commandref-Teilen innerhalb eines Moduls gerade für neue Entwickler noch schwieriger als es bisher schon ist.

Ausserdem machen die Klassen keinerlei Sinn, wenn man "help <command>" in telnet verwendet. Was dann wieder an Klimmzügen notwendig wird, um die Attribute wieder wegzuregexen, mag ich mir heute nicht vorstellen.

[justme1968]

warum macht man es einem einsteiger schwerer wenn man ihm eine hand voll feste regeln vorgibt?

gerade dann sind die klassen sinnvoll weil dann eben keine formatierungs anweisungen/attribute entfernt werden müssen sondern nur ein einziges class attribut mit fest erlaubtem inhalt.

natürlich ist es etwas aufwändiger als 7bit ascii. aber aus der zeit sind wir inzwischen raus.