[DOJO] - Performanceprobleme beim EDITIEREN

[eknori]

Ich habe heute an einem Modul in unserer Software gearbeitet, das man mir schon bei meinem Eintritt in die neue Firma als "problematisch"vorgestellt hatte.
Das Problem lag darin, daß sowohl das Öffnen im Designer als auch das Bearbeiten des Quellcodes nur mit erheblichen Verzögerungen möglich ist / war . Tastatureingaben dauerten von einigen Sekunden bis zu ein paar Minuten.

Da ich an diesem Modul arbeiten musste, habe ich mir die Sache einmal angesehen und versucht, den Fehler zu lokalisieren ( und zu beheben )

Das Problem sitzt in einem Custom Control. Dort wird ein Dojo.Grid aufgebaut. Die dojo resourcen sind in dem Custom Control eingebunden, ebenso wie die benötigten dojo css files.

Zusätzlich befindet sich noch ein custom css file in den Resourcen. Nach etwas Probieren habe ich dann die Ursache gefunden.

Kommentiert man das custom css aus, dann fluppt die Bearbeitung im Designer, wie gewohnt. Und zwar in allen XPages, die dieses custom control beinhalten.
Fügt man das css wieder ein, dann ist die Bremse sofort wirksam.

   <
...
xp:dojoModule name="dojox.grid.enhanced.plugins.Selector"></xp:dojoModule>
      <xp:dojoModule name="dojox.widget.PlaceholderMenuItem"></xp:dojoModule>
      <!--  -->
      <xp:styleSheet href="css_Grid.css"></xp:styleSheet>
      
      <xp:styleSheet href="/.ibmxspres/dojoroot/dojox/grid/enhanced/resources/EnhancedGrid.css"></xp:styleSheet>
      <xp:styleSheet href="/.ibmxspres/dojoroot/dojox/grid/enhanced/resources/tundraEnhancedGrid.css"></xp:styleSheet>

...

Zunächst hatte ich vermutet, daß die Datei einen Knacks hat und habe den Inhalt in ein neues CSS reinkopiert. Aber das hatte den gleichen Effekt.
Nächste Vermutung: Irgendwas an dem CSS selber ist faul. Also komplett den Inhalt gelöscht mit dem Ziel nach und nach die einzelnen Komponenten hinzuzufügen, bis der Fehler wieder auftritt.
Aber selbst ein komplett leeres, neu erstelltes css file zieht die Bremse an.

Irgendwie scheint es ein Problem mit der Kombination dojo css / custom css zu geben.

In der Firma entwickeln wir auf 8.5.2 ( FP3 ), aber ich kann das Verhalten auch mit 8.5.3 nachstellen.

Am CSS selber liegt es nicht; das habe ich in die einzelnen Elemente mit style="" versuchsweise einmal eingebunden.

Evtl. ja auch ein bekanntes Problem. Ich konnte selber bisher nichts dazu finden.

[ata]

Hallo Ulrich,

wie war das Verhalten, als du die Styles direkt implementiert hattest - normal oder auch mit der schlechten Performance?

Toni

[eknori]

Das war ganz normal

[ata]

... hast du die Reihenfolge beim Laden mal geändert

Toni

[eknori]

Ja, habe ich auch. Egal, wo ich das CSS File einfüge; sobald es da ist, bremst es die Bearbeitung.
Seltsamerweise hat es keine Auswirkung auf die Performance im Browser.
Es muss auch etwas mit der Kombination dojo modul / dojo css / custom css zu tun haben. Wir haben auch andere custom controls, die so aufgebaut sind, wo aber die Bremse nicht aktiv ist. Nur in diesem.

[ata]

... mysteriös - da scheint in dem custom control css etwas zu passieren, daß sich mit dem dojo beißt - wie du schon gesagt hast.

Ist das custom control css ein "normales" css, oder sind Hacks drin für IE?
Sind im CSS auch Funktionsaufrufe eingebunden?
Ist die Benamsung eventuell im Weg?
Besteht das Custom Control mit dem css nur aus diesem oder ist da auch noch was anderes drin - JavaScript
Ist Flash mit im Spiel => MultipleUpload?

[eknori]

Nein, im CSS ist nicht Besonderes drin, keine IE hacks o.Ä.

Ich habe es jetzt in dieser Form hinbekommen

      <xp:styleSheet
         href="/.ibmxspres/dojoroot/dojox/grid/enhanced/resources/tundra/EnhancedGrid.css" />
      <xp:script src="/lib.functions.Grid_SS.jss" clientSide="false" />
      <xp:script src="/lib.functions.Grid_CS.js" clientSide="true" />
      <xp:styleSheet
         contents="   .tundra .dojoxGridCell {border:none;}
                  .tundra .dojoxGridRow {border:1px solid #eee;}
                  .dojoxGridHeader {background-color:#dedede !important;border-top:1px solid #BFBFBF;}
                  .tundra   .dojoxGridHeader .dojoxGridCell {font-weight:bold;border:none;}" />
   </xp:this.resources>

[eknori]

Im DesignPartner Forum hatte einer der Entwickler eine einfache wie verblüffende Lösung

Could you try adding a forward slash to the url to the stylesheet

So change
<xp:styleSheet href="css_Grid.css"></xp:styleSheet>
to
<xp:styleSheet href="/css_Grid.css"></xp:styleSheet>

Without that forward slash, the Designer design time code should not be able to resolve the url to the file.

Every time you type in an opening or closing tag, or drop a control on the page, it will go and try to get the stylesheet and if that is taking a long time, then that might be why you are seeing this.

That goes for more than just StyleSheets though. We have seen other issues as well where it is incredibly slow to type in source, but it has improved somewhat in recent releases.

Take this example. If you decide to put an xp:panel around the entire contents of a page, the visualization for that needs to draw a panel and then all the controls on the page that are now in the panel, need to be redrawn inside the panel.

The same thing happens when you're in source. Basically, as you add tags in the source tab, it is creating all the Design time visualizations for them in the design tab. If you are at the top of very large file and start typing an opening tag, before the closing tag has been added, Designer thinks everything else on the page is now a child of that opening tag. So it refreshes the entire visualization for the page. Which can cause a noticeable delay.

...

[ata]

... kaum zu fassen 

[m3]

wow