CometVisu - (interner) Beta-Test

[Chris M.]

@Nils der workaround funzt!

Ein vermutlich noch "besserer" (eigentlich hässlicherer...) Workaround wäre, ein Phantasie-Tag zu verwenden, z.B.

<schiessmichtot />

Aber damit wir das nicht brauchen, gibt's jetzt <break /> im Subversion - aber dass brauch ich ja keinem erzählen, da ja sicher jeder die SVN-Commit Mailingliste Abonniert hat...

[vento66]

aber dass brauch ich ja keinem erzählen, da ja sicher jeder die SVN-Commit Mailingliste Abonniert hat...

Naja jetzt schon

[vento66]

der Break fügt in der Zeile in der 2. Spalte einen Platzhalter mit Rahmen ein, in der 2.Zeile einen Platzhalter ohne Rahmen. Damit verschiebt sich das Element wieder in die nächste Spalte.

[Chris M.]

image und/oder webcam (wie image aber mit automatischem Reload)

Initales <image> ist jetzt drinnen, "width" und "height" sind als optinale Attribute bekannt.

Was braucht's noch für den universellen Einsatz?

Ein "refresh" wäre leicht möglich. Braucht's evtl. noch ein "trigger" bzw. "address" das das Bild bei eintreffen eines Paketes neu lädt?
Oder gar ein "dynamisches" Bild, bei dem der "src" per Bus-Paket ganz oder teilweise verschickt wird?

Da sind jetzt Leute mit Visu-Erfahrung gefragt...

[netzkind]

Hola, jetzt gehts langsam rund

Damit der Editor eine Chance hat mitzuhalten denke ich sollte er dynamischer werden. Dazu brauchts eine zentrale Definition welche widgets alles erlaubt sind, und welche Attribute die haben. Ich denke spontan an ein XSD, wobei das für den User der seine Visu selbst um eigene Widgets erweitern will dann erst mal ein hartes Brot wird.

Gegenvorschläge?

Ohne zentrale Definition wüsste ich nicht wie ein Editor widgets kennen sollte die der User nicht selbst in seiner visu_config.xml nutzt.

Grüße,
Julian

[Chris M.]

Hola, jetzt gehts langsam rund

Damit der Editor eine Chance hat mitzuhalten denke ich sollte er dynamischer werden.

Meine Rede

Dazu brauchts eine zentrale Definition welche widgets alles erlaubt sind, und welche Attribute die haben.

Ich sehe durchaus die Möglichkeit das im Code zu hinterlegen. Z.B. in extra Einträgen im .data() - die halt nur dann mit abgelegt werden, wenn auch Editieren erlaubt ist.

Vorschlag wäre ein Eintrag namens "meta" oder "edit" der seinerseits ein Objekt/Hash mit allen möglichen Attributen enthält und die wieder aus einem Objekt/Hash bestehen mit den Meta-Informationen wie ob es optional ist, Datentyp, Wertebereich, ...

[makki]

Hola, jetzt gehts langsam rund

Damit der Editor eine Chance hat mitzuhalten denke ich sollte er dynamischer werden. Dazu brauchts eine zentrale Definition welche widgets alles erlaubt sind, und welche Attribute die haben.

Klingt schlüssig, eine (wie auch immer geartete) "Definitionsdatei" für Widgets macht IMHO Sinn, damit man das nicht immer in Visu&Editor doppelt pflegt.

Ich denke wer widgets selbst entwickelt ist entweder eh so drauf so drauf wie ihr und findet X* "normal"
oder hat schon verdammt viel trocken Brot vor bzw. hinter sich, ein XSD macht hier das Kraut nicht fett (ausserdem wird man sich das von vorh. Widgets ja abschauen können..)

Makki

[netzkind]

[IMG]
Ich sehe durchaus die Möglichkeit das im Code zu hinterlegen. Z.B. in extra Einträgen im .data() - die halt nur dann mit abgelegt werden, wenn auch Editieren erlaubt ist.

Ich glaub wir reden hier aneinander vorbei.
Ich meine eine Liste aller widgets (slider, image) welche die Template-Engine unterstützt - egal ob der User sie bislang schon nutzt oder nicht.

Deinen Vorschlag verstehe ich eher als eine Auflistung der bislang in der config genutzten widgets/Aktoren.

Unabhängig vom gegenseitigen verstehen stopf ich mein Hirn grade mit XSD voll und schraub da mal was zusammen. Netter Nebeneffekt: wenn einem versierten User die Visu mal nicht geht, kann er seine Config gegen das XSD parsen und schauen wo der Hase im Pfeffer ... oder wir stellen dafür ein webif zur Verfügung (mit PHP/DOMDocument ein leichtes).
Gilt natürlich nur solange die Config nicht doch mal in eine DB umzieht

Grüße,
Julian

[Chris M.]

Ich meine eine Liste aller widgets (slider, image) welche die Template-Engine unterstützt - egal ob der User sie bislang schon nutzt oder nicht.
[...]
Unabhängig vom gegenseitigen verstehen stopf ich mein Hirn grade mit XSD voll und schraub da mal was zusammen.

Oh man, sag doch das Du XML Schema meinst - meiner einer ist auf DTD stehen geblieben...

Netter Nebeneffekt: wenn einem versierten User die Visu mal nicht geht, kann er seine Config gegen das XSD parsen und schauen wo der Hase im Pfeffer ...

Richtig. Sauberes Programmieren würde eh einen Check der XML gegen ein Schema / DTD erzwingen - denn dann muss man sich diesbezüglich nicht um Fehler kümmern

Gilt natürlich nur solange die Config nicht doch mal in eine DB umzieht

Das sehe ich nicht kommen - da sehe ich nämlich keinen Vorteil drinnen.

Nichts desto trotz könnte ich mir trotzdem sehr vorstellen, dass ich noch eine interne Datenstruktur erzeuge, die alle erlaubten Widget aufführt. Die

function create_pages( page, path )

in templateengine.js ist nämlich inzwischen bei Licht betrachtet Müll, da redundant (Redundanz ist genau so böse wie frühzeitige Optimierungen).
Hier ein Objekt das Function-Calls zu den Create-Funktionen hat und das der Endanwender um eigene Werte erweitern kann dürfte wohl für alle (normale CometVisu, der Editor und der erweiterungswillige Anwender) ein Fortschritt sein.
Oder gibt's dazu andere Meinungen?

[netzkind]

Oh man, sag doch das Du XML Schema meinst - meiner einer ist auf DTD stehen geblieben...

Ich hab das XSD mal ins SVN gecheckt. Es sollten eigentlich alle möglichen Widgets enthalten sein - es sei denn ich hab was übersehen. Das XSD könnte dann die Basis bieten für einen dynamischen Editor.

Wer das testen will kann schon mal seine visu_config.xml anpassen:

<pages
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="visu_config.xsd">

Ums auf dem Wiregate einfach per PHP zu testen geht ein einfacher Code wie

<?php

$dom = new DomDocument();
$dom->load("visu_config.xml");

if ($dom->schemaValidate("visu_config.xsd")) {
    print ("config is valid XML");
} else {
    print ("config is NOT valid XML");
}
?>

Das dann auch der shell aufrufen per php5-cgi oder halt im Webserver. Da error_reporting aktiv ist werden einem die ganzen XML-Fehler erst mal um die Ohren geblasen. Das sollte man dann noch schön einpacken wenn man das als Feature verkaufen will (deshalb ist der PHP-Code auch noch nicht im SVN).

Hier ein Objekt das Function-Calls zu den Create-Funktionen hat und das der Endanwender um eigene Werte erweitern kann dürfte wohl für alle (normale CometVisu, der Editor und der erweiterungswillige Anwender) ein Fortschritt sein.
Oder gibt's dazu andere Meinungen?

Das muss ich sehen ums zu verstehen
Ich finde das Thema der Events und trigger bei jQuery extrem praktisch, um ohne konkrete Funktionsnamen zu kennen beliebige Aktionen ausführen zu können. So können sich auch ein Editor oder eine customization an ein Event hängen, ohne dass etwas überladen werden braucht.

Grüße,
Julian

[makki]

Das muss ich sehen ums zu verstehen

100% Ack

Ich finde das Thema der Events und trigger bei jQuery extrem praktisch, um ...

Jep, schon wieder "Endstation Hauptbahnhof, bitte alles aussteigen"
-> Ihr sagt einfach bescheid, wenn es ein neues .deb Release geben soll, svn co und dpkg-buildpackage kann ich mittlerweile ganz gut (und bis dahin les ich mir das nochmal im Detail durch - /usr/local wirds sicher nicht..)

Man muss ja zum Glück keine Eier legen können um faule (bzw. in diesem Fall IMHO definitiv nicht faule sondern eher g***) zu erkennen

Makki

P.S., nochmal: SVN-commitlog per eMail ist ne sehr feine Sache!

[teichsta]

haben wir eigentlich schon paar Screenshots parat?

[Chris M.]

Nein, aber wir bräuchten welche

Und am besten auch eine Demo visu_client.xml die zeigt, was alles möglich ist und dabei nach etwas aussieht. Die könnte dann wunderbar für Screenshots dienen

[teichsta]

bei mir läuft die Visu leider noch nicht ...

[EIB-TECH]

Hi Jungs,

kann mich einer mal auf die Comet Visu druff lassen, ich würde mir die Sache mal gerne ansehen