RSS(log) oder Eventanzeige in der CometVisu uvm.

[alexbeer]

Hallo,
Auf nem PC mit Firefox oer Chrome klappt die Anzeige des Rsslog prolemlos- auf nem iPad mit Safari sieht es wie im Anhang aus. Mir war es leider noch nicht möglich weiter auf Fehlersuche zu gehen - habt ihr ne spontane Idee, wo ich weitersuchen sollte? Bearbeitet man die Einstellungen zudem mit dem Editor, dann ist aus dem xml das label Attribut entfernt und die Anzeige funktioniert nicht mehr.

P.S.
rev ist 708

[Chris M.]

Was mich genau wieder zu meinem persönlichen Problem bringt: Ich nutzt Javascript schon so lange, dass ich lieber mit getElementbyId arbeite, statt das entsprechend jQuery zu nutzen.

Ich hatte jQuery auch zuerst verworfen, da es für mich sehr verworren und unübersichtlich ausgesehen hat. Alleine die "magische" Bedeutung vom $ hat mach nachhaltig verwirrt, da ich ja schon BASIC und PERL kannte...

Als es aber dann darum ging entweder selber um alle Browser-Inkompatabilitäten herum zu programmieren oder etwas fertiges zu nehmen, bin ich wieder bei jQ gelandet - und habe nach und nach die Genialität und Stärke dieser Lib kennen gelernt.

Mit jQ ist man gleich deutlich produktiver JavaScript zu schreiben!

Als Referenz nehme ich nur das, was auf deren Homepage steht.

[NetFritz]

Hallo

Main Page - jQuery JavaScript Library
und in Deutsch
TU Chemnitz: URZ: Kurse: Unterlagen: jQuery: Einfhrung

Gruß NetFritz

[netsrac]

Gerade mal die Version aus dem SVN gezogen...interessantes feature:

$row.addClass(' rsslog_prevday');

So geht das also Ich hatte das ja ohne jQuery gelöst...

Was mich genau wieder zu meinem persönlichen Problem bringt: Ich nutzt Javascript schon so lange, dass ich lieber mit getElementbyId arbeite, statt das entsprechend jQuery zu nutzen.

Gibt es eigentlich irgendwo eine gut gelistete Funktionsreferenz für jQuery?

Bei PHP gehe ich auch immer auf php.net und suche durch die Funktionen wenn ich was ausgefallenes machen will. Für mich der beste Weg etwas zu lernen, da man das Grundprinzip ja kennt. :-)


Netsrac

[netsrac]

Ich fände gut, wenn wir für einzelne Teile "Maintainer" festlegen, mit denen zumindest alles was über einen reinen Bugfix hinausgeht besprochen wird. Das betrifft insbesondere die CSS-Files der Designs und die Plugins.

Naja, vielleicht wäre es schonmal ein guter Start in jedem File oben ein Kommentar zu machen, wer das File erstellt hat. So weiß man im Ernstfall, wen man kontaktieren muss:

// Created by JNK for CometVisu :-)

Ich persönlich schreiben in meinen eigenen Codes auch oben immer ein kleines ChangeLog, so dass man sehen kann, wann das File das letzte Mal geändert wurde und wieso. Bei mehreren Maintainern könnte man auch noch das Namenskürzel mit einpacken.

[Chris M.]

Das Problem mit dem "Mitmachen" ist vorallem ein zeitliches Problem. Im Moment macht es mir Spaß und ich kann da mal ein oder zwei Stündchen freischaufeln, aber ich kann nie garantieren, wie lange das so bleibt.

Das ist gar kein Problem. Das geht hier vielen so. Außer einem macht's hier wohl jeder nur als Hobby und bei dem einen ist's wohl auch mehr Hobby als Broterwerb.

Was das Committen angeht - danke für die Blumen - ich habe schon größere Software-Projekte geleitet und da war es eigentlich immer ein no-go, in dem Code eines Anderen neue Features einzubauen, ohne das mit dem ursprünglichen Author abzusprechen. Lediglich Fehler durften / mussten gefixed werden.

Da wir eine Versionsverwaltung haben, ist jeder "Fehler" einfach sichtbar und behebbar. Daher halte ich mehr von Peer-Kontrolle als von eingeschränkten Rechten und bin daher mit SVN-Schreibzugriff ziemlich liberal.

Wir haben auch noch genug Ecken, wo man sich ohne Rücksicht austoben kann.

Und bei bestehenden Teilen, hat bisher eine kurze Nachfrage meist schnell ergeben, was man gerade ändern kann, ohne um jemanden auf die Füße zu steigen. Einem "Verbot" lag eigentlich immer nur zu Grunde, dass man gerade selbst intensiv an dieser Stelle gearbeitet hat - und das Mergen der Versionen vermeiden möchte.
Im Gegenteil, z.B. beim Editor gab's einen expliziten Aufruf zu helfen.

Zwar funktionieren meine Patches, dennoch sollen man doch schauen, das es nicht gegen die Ideen, Wünschen und geplanten Features des ursprünglichen Erstellers arbeitet. So gesehen würde ich eigentlich immer lieber einen Patch posten, statt still und heimlich eine Änderung zu submitten.

Große Änderungen kann man gerne hier absprechen, aber kleine IHMO gerne auch gleich comitten.

Zum "im Code anderer rumpfuschen": Das ist so eine Sache, ich trau mich da auch an manchen Stellen nicht so richtig ran. Insbesondere, wenn es um "Design-Fragen" geht. Was weiss ich, ob das ästhetische Empfinden des Design-Erstellers left-aligned Button-Labels toll findet oder ob das schlicht vergessen wurde auf center-aligned zu setzen.

Designs sind in der Tat speziell, da es dabei um Geschmack geht.
Technische Änderungen (z.B. Aufräumen von Klassennamen die durch eine andere Änderung bedingt sind) sollten unkritisch sein. Optische Änderungen sollte man vorher durchsprechen.

Ich fände gut, wenn wir für einzelne Teile "Maintainer" festlegen, mit denen zumindest alles was über einen reinen Bugfix hinausgeht besprochen wird. Das betrifft insbesondere die CSS-Files der Designs und die Plugins.

Ja, das macht Sinn. Und inzwischen haben wir genug aktive Entwickler dass sich dieser Schritt zu mehr Formalität lohnen kann.

[JNK]

zum Separator: Ich habe das noch etwas umgebaut, wird prinzipiell aber im nächsten commit enthalten sein.

Zum "im Code anderer rumpfuschen": Das ist so eine Sache, ich trau mich da auch an manchen Stellen nicht so richtig ran. Insbesondere, wenn es um "Design-Fragen" geht. Was weiss ich, ob das ästhetische Empfinden des Design-Erstellers left-aligned Button-Labels toll findet oder ob das schlicht vergessen wurde auf center-aligned zu setzen.

Ich fände gut, wenn wir für einzelne Teile "Maintainer" festlegen, mit denen zumindest alles was über einen reinen Bugfix hinausgeht besprochen wird. Das betrifft insbesondere die CSS-Files der Designs und die Plugins.

Gruss,

der Jan

[netsrac]

Klingt gut!
Wiegesagt, wenn Du ein bisschen weisst, was du da machst (sieht so aus) und die Sachen sauber testest ist es auch kein Thema, Schreibzugriff aufs SVN zu bekommen, eMail an Chris oder mich.
Wir freuen uns über jeden, der mitarbeiten will! ob mit oder ohne WG..

Naja, es ist immer besser keine Ahnung von was zu machen, aber ich kann davon leben :-)

Das Problem mit dem "Mitmachen" ist vorallem ein zeitliches Problem. Im Moment macht es mir Spaß und ich kann da mal ein oder zwei Stündchen freischaufeln, aber ich kann nie garantieren, wie lange das so bleibt.

Was das Committen angeht - danke für die Blumen - ich habe schon größere Software-Projekte geleitet und da war es eigentlich immer ein no-go, in dem Code eines Anderen neue Features einzubauen, ohne das mit dem ursprünglichen Author abzusprechen. Lediglich Fehler durften / mussten gefixed werden.

Zwar funktionieren meine Patches, dennoch sollen man doch schauen, das es nicht gegen die Ideen, Wünschen und geplanten Features des ursprünglichen Erstellers arbeitet. So gesehen würde ich eigentlich immer lieber einen Patch posten, statt still und heimlich eine Änderung zu submitten.

Müsste jetzt an den Anfang vom Thead scrollen um zu schauen, wer das war :-)

Gruß, Netsrac

[makki]

Wem diese Nachvollziehbarkeit so wichtig ist (und ich verstehe, dass es diese Fälle gibt!), der möge bitte auch mit User-Berechtigungen beim DB Zugriff arbeiten.

In meinem "normalen" Arbeitsumfeld gebe ich dir 100% Recht!
Aber wenn ich jetzt die geistige Anpassung an die Gebäudetechnik vornehme (Security wird - wenn überhaupt - durch "geheime" URLs gemacht) dann denke ich mir: so schlecht sind wir hier ja garnicht.
Der Unterschied ist: wir könnten jederzeit, wenn wir wollten
Aber hier ist über die Jahre auch eine gewisse Ernüchterung eingekehrt: der Kunde will es nicht (verstehen/wollen) also: for what!?
Der zweite Punkt ist: zuwas soll ich ein System (z.B. Logeinträge die von KNX-Gruppenadressen kommen) mit mehrstufiger AAA absichern, wo vorher das auslösende Telegramm mit --A übers LAN huscht? (das letzte A, Accounting, also Loggen, macht auch nur das WG)

Wirkliche Sicherheit wird eine individuelle Lösung bleiben, wo man jemanden Fragen muss, der sich damit auskennt; Die Security ist immer nur so stark wie das schwächste Glied.. Was hilft es perfekte Rechte am Webserver zu haben, wenn hanni&nanni mit einem statischen, 5stelligen PW aus Brasilien druff können..
Ergo, das ist in dem Kontext IMHO vergebene Liebesmüh, wieso sollte ich mir
Mühe geben die DB zu schützen, wenn der komplette Rest offen wie ein Scheunentor ist? In dem Kontext: wer an VdS-Alarmanlagen glaubt: selber mumpitz, nur anders verpackt..

Vorgestern erst gemacht, Zertifikatsbasierte Authentisierung für 14 User die intern &extern nur eben die Visu-Seite aufrufen können die sie sollen.. Das sind halt mal 248 Zeilen Apache-config (90% gescripted aber trotzdem nicht "einfach")

Okay...statt Wünsche zu äußern, habe ich mich mal selber rangesetzt...

Klingt gut!
Wiegesagt, wenn Du ein bisschen weisst, was du da machst (sieht so aus) und die Sachen sauber testest ist es auch kein Thema, Schreibzugriff aufs SVN zu bekommen, eMail an Chris oder mich.
Wir freuen uns über jeden, der mitarbeiten will! ob mit oder ohne WG..

Makki

[netsrac]

Okay...statt Wünsche zu äußern, habe ich mich mal selber rangesetzt...vielleicht hat ja jemand Lust, die folgenden Änderungen zu committen:

*** structure_plugin.js.org    2012-02-15 21:20:46.000000000 +0100
--- structure_plugin.js    2012-02-15 22:08:37.000000000 +0100
***************
*** 182,188 ****
              var row = 'rsslogodd';
              var last = itemoffset+displayrows;
              last = (last>itemnum) ? itemnum : last;
!             
              for (var i=itemoffset; i<last; i++) {  
                var idx = i;
                idx = (i>=itemnum) ? (idx = idx - itemnum) : idx;
--- 182,192 ----
              var row = 'rsslogodd';
              var last = itemoffset+displayrows;
              last = (last>itemnum) ? itemnum : last;
!            
!             var separatordate     = 0;
!             var separatoradd      = false;
!             var separatorprevday  = false;
! 
              for (var i=itemoffset; i<last; i++) {  
                var idx = i;
                idx = (i>=itemnum) ? (idx = idx - itemnum) : idx;
***************
*** 196,207 ****
                  itemHtml = (o.timeformat) ? 
                    (itemHtml.replace(/{date}/, entryDate.strftime(o.timeformat) + '&nbsp;')) : 
                    (itemHtml.replace(/{date}/, entryDate.toLocaleDateString() + ' ' + entryDate.toLocaleTimeString() + '&nbsp;'));
                } else {
                  itemHtml = itemHtml.replace(/{date}/, '');
                }
!                             
!               var $row = $('<' + o.wrapper + ' class="rsslogRow ' + row + '">').append(itemHtml);
!                             
                var title = item.find('title').text();
                var itemClasses = title.substring(title.search(/\[/)+1,title.search(/\]/)).replace(/\,/g, ' ');
                if (itemClasses) {
--- 200,219 ----
                  itemHtml = (o.timeformat) ? 
                    (itemHtml.replace(/{date}/, entryDate.strftime(o.timeformat) + '&nbsp;')) : 
                    (itemHtml.replace(/{date}/, entryDate.toLocaleDateString() + ' ' + entryDate.toLocaleTimeString() + '&nbsp;'));
+ 
+                 thisday = entryDate.strftime('%d');
+                 separatoradd = ((separatordate > 0) && (separatordate != thisday));
+                 separatordate = thisday;
                } else {
                  itemHtml = itemHtml.replace(/{date}/, '');
                }
!    
!               tmprow = row;
!               if (separatoradd) { tmprow += ' rssseparator'; separatorprevday = true; }
!               if (separatorprevday == true) { tmprow += ' rssprevday'; }
!                        
!               var $row = $('<' + o.wrapper + ' class="rsslogRow ' + tmprow + '">').append(itemHtml);
!                            
                var title = item.find('title').text();
                var itemClasses = title.substring(title.search(/\[/)+1,title.search(/\]/)).replace(/\,/g, ' ');
                if (itemClasses) {

Es passiert folgendes:

Beim Datumssprung wird ein "rssseparator" gesetzte und alle nachfolgenden Einträge bekommen dann ein "rssprevday".

Mittels folgenden zwei Elementen im rsslog.css:

.rssseparator {
  border-top-style: dotted;
}

.rssprevday {
  opacity: .5;
  filter: alpha(opacity=50);
}

Kann man z.B. eine Linie als separator ziehen, zusätzlich werden alle Einträge vom Vortag schwächer angezeigt.

Hoffe es gefällt...

Gruß, Netsrac

[netsrac]

Ich überlege gerade, ob es nicht sinnvoll wäre, z.B. eine Leerzeile oder ein <hr> bei Tagessprung zu machen.

So könnte man sich eventuell das Datum sparen und würde dennoch leicht erkennen, was von heute und was von gesern war.

Prinzipiell muss man ja nur "%d" von aktuellen und vorherigen Eintrag vergleichen und beim Unterschied eine Leerzeile einfügen.

Ich denke mal, dass man das geschickterweise einfach mit einem CSS-Eintrag macht, wo man das Verhalten definieren kann....

...oder andere Ideen?

[Chris M.]

Edit: Beim (nicht) löschen geht es übrigens um was anderes als den Speicherplatz:
Nachvollziehbarkeit!

Je nach dem.
Löschen+Optimieren ist eine reine Laufzeit-Frage.
Nachvollziehbarkeit die des Audit-Trails.
=> Beides kann wichtig sein, ist aber sicher jeweils ein anderer Kontext.

Wem diese Nachvollziehbarkeit so wichtig ist (und ich verstehe, dass es diese Fälle gibt!), der möge bitte auch mit User-Berechtigungen beim DB Zugriff arbeiten. Und da würde dann einfach nur ein INSERT erlaubt werden, denn ändern ist dann auch nicht. Bzw. man arbeitet per Trigger, etc. pp. für's Log.
=> Alles schön und gut, hier müssen wir einen simplen und billigen Weg für die meisten finden, der aber auch für's Geschäftsumfeld geeignet / kompatibel ist.
(Vermutlich würde dann auch kein SQLite eingesetzt werden, sondern ein remote eh vorhandener DB Server mit geeigneter Backup-Strategie)

aber mit dem normalisieren von Datenbanken verschreckt man halt auch schnell normale Menschen

Wen's da verschreckt, der darf keine DBs programmieren.
Wir heben ja genug außenrum, wo man sich austoben kann und darf.

[ZeitlerW]

Hallo Jan,

vielleicht könntest Du in der SVN - Version 703 in der rsslog_correct.pl folgendes ändern

-my $logdb = '/var/www/rsslog.db';
+my $logdb = '/etc/wiregate/rss/rsslog.db';

Dann paßt es auch zur rsslog.php und zur rsslog.pl

vG
Wolfgang

[JNK]

Nein, das Problem ist, dass dein rsslog.php noch nicht upgedatet ist (commit folgt) und Du die Datenbank noch "konvertieren" musst. Script folgt im SVN ebenfalls heute.

Gruss,

der Jan

[netsrac]

Gerade mal meine rsslog Einträge auf Tags umgebaut. So weit so gut. Allerdings will nun die Anzeige in der CV nicht mehr:

itemClasses.match(/id=[0-9]*/) is null
[Break On This Error]     

var id = itemClasses.match(/id=[0-9]*/)[0].split('=')[1];

structure_plugin.js: Line 209

das zugehörige RSS sieht so aus:

<?xml version="1.0"?><rss version="2.0">   <channel>     <title>RSS supplied logs</title>     <link>http://myhome.eismond.net/rsslog/rsslog.php</link>     <description>RSS supplied logs</description>   <item><title> [mytag2,Mytag1]</title><description>Content</description><pubDate>2012-02-13T11:04:02+01:00</pubDate></item>   </channel> </rss>

Classes sind für die Tags noch nicht im CSS definiert. Vielleicht liegt hier das Problem?!

Danke..Netsrac