Neues aus der Enertex Werkstatt

[Jambala]

@Enertegus: Für mich passen im wesentlichen die 40 Buttons schon, aber die zählweise v.a. der Linien und Platzhalter zu den 40 macht es dann umständlich bzw. unübersichtlich.
Gerade bei 40 Buttons (5x8 (BreitexHöhe)) wären Linien extremst hilfreich...
Oder eine Auflockerung durch Leerfelder, die einem dann nicht die 40 Elemente verringern

Sorry Oliver, aber ob man die Zählweise verändert oder auf 60 Elemente aufstockt, ist letztendlich die identische Anforderung.

[Sandman60]

Hallo Michael,

im Prinzip schon und Du weißt ja, dass ich auch so meine liebe Not mit der aktuellen Reglementierung habe.
Die Frage ist doch wo bei Enertex das Limit herkam und m.W. kam das aus einer Speicherlimitierung.
Wenn es z.B. um die Speicherlimitierung von "aktiven" Elementen geht (Buttons) würde ich mit 40 aktiven Buttons z.B. hinkommen. 60-80 "aktive" Elemente halte ich dagegen schon wieder für unübersichtlich.
40 aktive und 40 passive (z.B. leere Felder aufgrund des Rastermaßes, Linien, übergroße Felder die wie 2 Felder zählen) wären genial und sollten m.E. auch nicht auf irgendwelche Limits laufen...
Daher der Punkt als "Kompromiss", auch wenn es in Summe dann zu 80 Elementen kommt.

@Enertegus: Der Einsatz eines Multischalter hilft meistens leider nicht, da dieser m.W. dann wieder breitere Buttons nach sich zieht und der WAF-Faktor auf einem Touchscreen des MP sich bei mir irgendwo in die Nähe des Kellers sich entwickelt....

[enertegus]

@Enertegus: Der Einsatz eines Multischalter hilft meistens leider nicht, da dieser m.W. dann wieder breitere Buttons nach sich zieht und der WAF-Faktor auf einem

Ein Multilement ist auch in einfacher Breite möglich.
Wir werden mal intern diskutieren, was möglich ist.

[Jambala]

Ich habe den Webserver so verstanden, dass die Gesamtressourcen limitiert sind und die Verteilung innerhalb der Ressourcen von Enertex vorgegeben werden kann.

Aktuell sind dies 100 Webpages mit jeweils 40 Webelementen, also in Summe 4.000 Webelemente.

Wenn die Anzahl der Webelemente pro Seite auf 60 erhöht würden, wären nur noch 66 Webpages möglich (4.000 max. Webelemente / 60 Webelemente pro Seite = 66,6 Webpages).

Bei 80 Webelementen pro Seite wären demnach nur 50 Webpages möglich.

Der Vorteil von 60-80 Webelementen pro Seite überwiegt m.E. sehr deutlich ggü. dem Nachteil "nur" noch 50-60 Webpages zu haben.

Mir fehlt die Vorstellungskraft, dass jemand >60 Webpages in der Praxis nutzt.

[bmx]

Vielleicht sollte enertex erstmal die Gründe nennen, warum es nun 40 Elemente waren. Vielleicht ist auf Grund des neuen Webservers diese Grenze so ja gar nicht mehr aktuell? Ich würde das nicht im vorhinein begrenzen, es sein denn es sprechen Kapazitäts oder Performancegründe dafür...

Gruß,
Bernd

[Sandman60]

Bei mir sind es aktuell 55 Webpages, Tendenz steigend.
Da einige der Pages auf einem Smartphone aufgrund der fehlenden Breite nicht darstellbar sind werde ich wohl noch 15 zus. Smartphone Pages erstellen müssen. Macht dann ca. 70...

[Jambala]

Vielleicht sollte enertex erstmal die Gründe nennen, warum es nun 40 Elemente waren. Vielleicht ist auf Grund des neuen Webservers diese Grenze so ja gar nicht mehr aktuell?

Hi Bernd,

das ist ja bereits geschehen.

Eine Limitierung des für den Webserver bereitgestellten Speichers und eine Umfrage in der Vergangenheit waren die Basis der 40 x 100 Entscheidung.

Bisher ist es nicht angedacht mit der neuen Firmware eine Änderung herbeizuführen.

Viele Grüße

Michael

[Jambala]

Eine kurze Off-Topic-Info:

Bisher hat mich die unflexible Lizenzpolitik davon abgehalten Command Fusion als EibPC Visu einzusetzen. Dies hat sich inzwischen offensichtlich geändert.

Es kann nun eine Lizenz bis zu drei Mal auf ein anderes Geräte übertragen werden.

Purchasing & Managing iViewer Licenses [CommandFusion Wiki]

This section shows all the devices you have licensed in the past. From here you can:

• Transfer a license (allowed up to 3 times per license only)
• View the transfer history of the license

[enertegus]

Bisher ist es nicht angedacht mit der neuen Firmware eine Änderung herbeizuführen.

Wir prüfen das zumindest.

[saft6luck]

das ist ja bereits geschehen.

Eine Limitierung des für den Webserver bereitgestellten Speichers und eine Umfrage in der Vergangenheit waren die Basis der 40 x 100 Entscheidung.

Stimmt doch gar nicht.

1. Michael (Enertex) hat eine Umfrage gemacht, in der bereits vielen Teilnehmern klar war, dass diese Limitierung wenig zielführend ist. Trotz der Diskussion wurde dann aber gegen das Wahlergebniss gehandelt, denn entgegen der "Vorgaben" für die Wahl werden alle Elemente gezählt, nicht nur die aktiven Objekte sondern auch "leere" Felder. (Schenkelklopfer!)

2. Die Gründe wurden nicht dargelegt, sondern nur diese Möglichkeit zu Entscheiden gegeben. Ob der Speicherplatz oder die Laufzeit oder die Art der Nummerierung ausschlaggebend ist, ist nicht klar! Naheliegende Vermutung ist "4000 Elemente".

Mir ist diese Beschränkung völlig unverständlich. Andere können das besser, was Michael bestimmt auch bewusst ist.

[bmx]

Eine Limitierung des für den Webserver bereitgestellten Speichers und eine Umfrage in der Vergangenheit waren die Basis der 40 x 100 Entscheidung.

Ich denke eher das interne Webseitendesign hat Einfluß auf diese Werte genommen. Man hat einfach eine Matrix dahergenommen um das in einer Tabelle gut abbilden zu können.
Da ich aber immer noch auf ein CSS-Layout hoffe, wären hier viele Dinge einfacher zu erstellen un damit wären solche Grenzen wie 40 Elemente pro Seite keine Design-Frage mehr sondern nur eine Frage der Speicherbegrenzung. Da wir als User da aber gar nicht im Thema sind, hatte ich eher auf eine Info von Enertex gewartet. Aber es ist ja noch nicht aller Tage Abend ;-)

Gruß,
Bernd

[enertegus]

Mir ist diese Beschränkung völlig unverständlich. Andere können das besser, was Michael bestimmt auch bewusst ist.

Also ist die Folgerung: Wenn Du es nicht versteht ist es sinnlos, schlecht gemacht oder zumindest falsch umgesetzt, oder wie?

@Alle
Der Hintergrund ist tatsächlich ein Mapping der internen Variablen und die möglichst effiziente Bearbeitung. Wir haben einen Ansatz gewählt, der etwas aufwändig in der Erstellung, aber doch sehr performant ist. Das hat nun mit dem Design, was der Anwender sieht, nichts zu tun, eben aber mit der fixen Vorgabe der Anzahl von Elementen.
Es gibt aber natürlich nichts, was man nicht besser machen kann. Allegemeine Weisheit, eh klar. Wir denken da nach, wobei ich noch nicht ganz klar bin, ob wir nicht erst mal den Webserver fertig releasen sollten und das erst fürs übernächste verändern.

[saft6luck]

Also ist die Folgerung: Wenn Du es nicht versteht ist es sinnlos, schlecht gemacht oder zumindest falsch umgesetzt, oder wie?

Das hat nichts mit mir zu tun. Eine derartige Beschränkung ist weder zeitgemäß noch sinnvoll, egal wie du es begründen willst. Weder ein Mapping, noch der Speicherplatz, noch die Performance ist da ausschlaggebend.

Mal unter uns:
Ein System, bei dem der Code kompliert wird, vor der Ausführung, hat alle Freiheiten, die man sich programmtechnisch vorstellen kann. Ganz bestimmt sind da keine fixen Grenzen von 100x40 bestimmend, sondern welche Schnittstellen man definiert. Jegliche Art von individueller Grenze wird dann zur Kompilzeit erkannt und gemeldet und die Grenzen setz ich nicht fix auf kindisch niedrige Werte, die schon euer Demobild (siehe Anhang) des Webservers nicht einhält (ja, da ist immer noch der alte Server zu sehen). Fixe Längen für Felder und den ganzen Rest sind Steinzeit.

Worum es aber ging:
Warum mir die Beschränkung unverständlich ist, ist die Grenze der 40 Elemente pro Seite. Jeder kann sich heute einen 24" Monitor kaufen und da locker 100 Elemente gut bedienbar, schön übersichtlich, klar lesbar platzieren, nur ... der eibPC füllt bei 12 Elementen pro Zeile nur 3 Zeilen aus.

Eine dynamische Grenze wäre z.B. "4000 aktive Elemente auf max. 100 Seiten verteilt", ohne "unsichtbare" oder statische Elemente.

[Jambala]

"4000 aktive Elemente auf max. 100 Seiten verteilt"

@Saftluck, auch wenn ich die Tonalität Deiner Beiträge nicht unbedingt hilfreich für die Sache empfinde, so ist Dein Vorschlag vermutlich der ideale Kompromiss.

Ein bisschen mehr Sachlichkeit würde hier helfen. Wir wollen doch alle eine konstruktive Diskussion mit Michael.

Bei Deinem Vorschlag würde Michael keine Bestandskunden mit vielen Webpages "verprellen", aber dennoch dem Bedarf nach mehr Gestaltungsfreiheit bedienen.

[enertegus]

Bei Deinem Vorschlag würde Michael keine Bestandskunden mit vielen Webpages "verprellen", aber dennoch dem Bedarf nach mehr Gestaltungsfreiheit bedienen.

Dass die dynamische Speicherverwaltung an dieser Stelle Vorteile hat, ist ja nun sehr offensichtlich. Allerdings ist aber nicht die Unkenntnis dieses Sachverhalts, sondern anderweite Implementierungsdetails die Ursache für die gewählte statische Speicherverwaltung.