Designwechsel mit bestehender Config nicht möglich?

[swiss]

Mir ist gerade etwas aufgefallen...

Ich bin mal davon ausgegangen, dass sich die Designs ausschliesslich um das aussehen kümmern und nicht im Zusammenhang mit der Funktion der Widgets stehen.

Also sollte es doch jederzeit möglich sein, eine config z.B. des Metal Designs mit der änderung in der visu_config.xml auf z.B. pure in einem anderen Design darzustellen...

Doch wenn ich das mache, wird die Visu zwar erwartungsgemäss dargestellt aber hat keine Funktion mehr.

Eine Liste der Fehler, die mir auf die Schnelle aufgefallen sind:

- Navbar und Pagejump funktionierennicht
- Diagramme werden nicht dargestellt
- Werte werden nicht korrekt dargestellt (1 Wert woher auch immer wird eingelesen und auf allen Widgets dargestellt)

Ist das normal?? ...Oder wurde beim Metal Design so viel gebastelt, dass die Configs nur noch für Metal verwendet werden können? Wäre aber in meinen Augen der falsche Weg. Ich halte eine strikte Trennung zwischen Design und Funktion für ein absolutes Muss...

Im Anhang mal ein screenshot dass ein Teil derProblemeZeigt. Getestet habe ich mit meiner Metal-config auf pure.

[Chris M.]

Grundsätzlich sollte ein Design-Wechsel immer gehen - und zum schnellen Test kann man dazu auch an die URL einfach den Parameter "design" mit dem entsprechenden Namen als Wert anhängen. (Vgl. auch CometVisu/URL parameter/de - Open Automation)

Was dabei schlimmsten Falls passieren sollte, wäre dass die Config unter dem neuen Design seltsam aussieht (vgl. Demo-Config z.B. im Alaska-Design)

Vom allgemeinen nun zum konkreten:
Das Metal-Design hat die modernen Features der CV wunderbar genutzt - und Anwender sind dann gleich noch weiter gegangen und nutzen undefinierte Zustände aus, die aktuell gerade das tun was sie wollen (z.B. Spaltenbreiten die keine natürliche Zahl sind ; Null sehe ich hier auch nicht als natürliche Zahl an...)

D.h. wenn dieses Design sich auf undefiniertes Verhalten stützt, dann ist es gut möglich, dass es je nach Design unterschiedliches Verhalten bis hin zur Unbenutzbarkeit gibt.
Das ist dann aber ein Fehler in der Config! Es könnte auch bei jedem Update des Metal-Designs kaputt gehen!

Was auch noch sein könnte, ist das ein Design gewisse Features nicht umsetzt (daher die seltsamme Anzeige bei Alaska bei der Demo-Config - Alaska wurde vor den Navbars geschrieben und danach nicht angepasst) - aber da ist Pure immer die Referenz. Wenn etwas in Pure nicht geht, ist es kaputt. Wenn es in Pure aber nicht in einem anderen Design geht, ist das andere Design kaputt.
(Daher auch der Name Pure: es soll ein minimales Design sein, der kleinste gemeinsame Nenner, so dass man davon komplexeres ableiten kann aber immer eine Basis hat die als Referenz dienen kann. Such mal ob's ein Config, Struktur oder Design-Problem ist nur mit dem Planet Design, das munter eigene Elemente in den DOM schiebt und sehr kreativ mit den Positionen und Formatierungen umgeht... )

[swiss]

Ok. Ich habe mir das heute noch mal etwas genauer angesehen...

Dass die Werte nicht korrekt dargestellt werden war mein Fehler -> Falsche Config...

Was aber scheinbar nicht geht (dieses mal mit der richtigen Config) ist:

- Pagejump in der TopNavbar -> Da muss ich nochmal suchen
- Um die Group wird scheinbar kein Rahmen gezeichnet zur optischen Gruppierung -> Ist warscheinlich ein CSS Problem (oder gewollt )

[Chris M.]

Das mit dem "fehlenden" Rahmen um die Group ist Design und so gewollt. Wenn Du einen Rahmen bei Pure willst, musst Du ein Flavour vergeben (vgl. Demo-Config -> Erweiterte Widgets)

[peuter]

- Pagejump in der TopNavbar -> Da muss ich nochmal suchen

Soweit ich das sehe wird im Pure-Design der actor der Pagejumps mittels display=none ausgeblendet. Somit gibt es keinen anklickbaren Bereich und dadurch funktionieren die Pagejumps auch nicht. Da gibt es IMHO 2 Möglichkeiten das zu beheben:
1. In der Config deklariert man alle Pagejumps mit bind_click_to_widget="true" (oder gleich alle widgets mit demselben Attribute im pages-Element), dann wird der Actor nicht mehr benötigt, weil das komplette Widget anklickbar ist.
2. Damit die Pagejumps in den Navbars immer funktionieren müsste folgender CSS-Code zum Pure-Design hinzugefügt werden.

#navbarTop .navbar .widget, #navbarBottom .navbar .widget {
    position: relative;
}
.navbar .pagejump .actor {
    display: block !important;
    bottom: 0;
    left: 0;
    position: absolute;
    right: 0;
    top: 0;
    vertical-align: middle;
}
.navbar .pagejump .actor.switchUnpressed,.navbar .pagejump .actor.switchPressed {
    border: none;
}

- Um die Group wird scheinbar kein Rahmen gezeichnet zur optischen Gruppierung -> Ist warscheinlich ein CSS Problem (oder gewollt )

Das ist ja eine Design-Entscheidung und kein Fehler. Hab ich im Metal-Design so gelöst, das kann aber jedes Design anders lösen.

[swiss]

Hallo zusammen

Also ich bin jetzt etwas weiter...

Wegen den Rahmen um die Groupe. Naja ohne Rahmen machendie Group ja fast keinen Sinn dennman kann ja die Widgets auch mit colspan gruppieren. eine Groupsollte aber nachmeinem Verständniss eine optische gruppierung ermöglichen. Das mit flavour werde ich testen -> danke

Zum Pagejump...

Danke für den CSS Code. Damit funktioniert schon mal die Topnavbar. Leider funktioniert die Navbar left noch nicht. Und der Inhalt der Page wird nicht dargestellt.

Kann es sein, dass das Design Pure einfach noch nicht für Pagejump angepasst wurde? Und wesshalb sind solche Funktionen vom Design abhängig? Das dürfte doch nicht sein. oder? Was hat die Funktion von pagejump mit dem Design am Hut? Müsste man demnach auch alle anderen Designs aufrüsten? Ein Designwechsel dürfte doch NIE dazu führen, dass die Visu nicht mehr geht...

[Chris M.]

Wegen den Rahmen um die Groupe. Naja ohne Rahmen machendie Group ja fast keinen Sinn dennman kann ja die Widgets auch mit colspan gruppieren.

Nicht ganz. Denn gerade in Verbindung mit rowspan braucht man manchmal einfache eine Dummy-Gruppe.
Andere Designs wollten unbedingt Gruppen darstellen und haben folglich das nowidget benötigt, das spart sich Pure

eine Groupsollte aber nachmeinem Verständniss eine optische gruppierung ermöglichen. Das mit flavour werde ich testen -> danke

Aber deswegen gibt's doch die Möglichkeit das per Flavour zu machen?!?

Neben dem Basis-Design das immer funktionieren sollte, sollte Pure eben auch ein optisch möglichst schlichtes Design sein. Daher pauschal erst mal keinen Rahmen um Groups oder gar Widgets...
Wer das nicht mag und auch keine Flavours darf gerne andere Designs verwenden - genau dazu sind die da! Z.B. wäre da das Discreete Design zu nennen.

Zum Pagejump...

Danke für den CSS Code. Damit funktioniert schon mal die Topnavbar. Leider funktioniert die Navbar left noch nicht. Und der Inhalt der Page wird nicht dargestellt.

Wie Du schon schreibst: der CSS ist so noch nicht ganz vollständig.

Kann es sein, dass das Design Pure einfach noch nicht für Pagejump angepasst wurde?

Pure funktioniert wunderbar mit Pagejumps.
Und auch die Metal-Demo-Config mag mit dem Pure-Design (die hat aber auch bind_click_to_widget="true" gesetzt...)

Und wesshalb sind solche Funktionen vom Design abhängig? Das dürfte doch nicht sein. oder? Was hat die Funktion von pagejump mit dem Design am Hut? Müsste man demnach auch alle anderen Designs aufrüsten? Ein Designwechsel dürfte doch NIE dazu führen, dass die Visu nicht mehr geht...

Ruhig brauner! Das gesetzte bind_click_to_widget="true" hatte mich bei meinen Tests glauben lassen, dass das Pure Design mit Metal inspirierten Configs gut umgehen kann.
=> Ist ein Bug in Pure, an dem ich jetzt gerade dran bin.

Was mir etwas mehr Sorgen macht, sind die anderen Designs, namentlich Discreet und Alaska. Die müssten ihre "Besitzer" auch auf aktuellen Stand bringen...
(Und Planet mag mit der Metal-Demo-Config gar nicht )

[swiss]

Ich wäre ja nie auf die fixe Idee gekommen meine Metal-config auf Pure umzustellen wenn ich nicht hätte testen wollen, ob das Scrollproblem auf meinem FF Mobile auch da besteht (bzw. ob das Problem Design abhängig ist). Dass dies aber scheinbar nicht so einfach ist, hätte ich nicht gedacht. Desshalb ja der Fred, um über ein paar Dinge die mir aufgefallen sind zu diskutieren. Das ist kein Vorwurf ich hätte bloss nicht erwartet, dass die Umstellung schwieriger ist als angenommen.

Und mal unter uns... Wie viele haben bis jetzt ihre produktive Config auf mehreren Designs getestet um Inkompatiblitäten festzustellen? Ich fände das gerade eine günstige Gelegenheit dies auch mal durch zu testen. Ich mache mal noch ein paar Tests mit den anderen Designs in der Hoffnung, dass zum nächsten Releas die meisten Designs (funktional nicht optich) zu einander kompatibel sind.

[Chris M.]

Ich teste immer mit mehreren Designs - hatte aber diesen Globalen Switch übersehen...

Probier jetzt mal Pure ab Revision 1569

[swiss]

Hallo Chris

Hmm... Hat leider nicht ganz funktioniert. Wenn ich Top und left navbar habe, wird der Inhalt der Page nicht dargestellt und die Navigation in der left navbar funktioniert bei mir leider auch noch nicht.

Gleiches Bild wie im Screenshot in meinem vorletzten Beitrag.

[Chris M.]

Hast Du forceReload=true genommen?
Und passiert das auch bei der Metal-Demo-Config wenn Du die per URL als Pure darstellst?

[swiss]

Ups. Ja hab ich auch bemerkt. Also pagejump in der left navbar funktioniert nun aber der Inhalt der Page wird weiterhin nicht dargestellt

[Chris M.]

Bei mir mag http://wiregate/visu_svn/?config=metal&design=pure sowohl mit FireFox als auch mit Chrome...

[swiss]

Willst du mal meine config testen? Vieleicht habe ich da eine Konstellation die das Problem auslöst...

Die Pages werden nur dann nicht angezeigt, wenn ich top UND left navbar habe. Sonnst funktioniert es.

[Chris M.]

Auch das geht bei mir, vgl. Screenshot.

Ja, schick mal Deine Config, dann probier ich die mal aus.