XPages Performance


Published on

Slides from session at EntwicklerCamp 2013 ( 13-MAR-2013 )

Published in: Investor Relations
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Change the server page persistence setting to keep the current page in memory. Strictly speaking, keeping all pages in memory provides the best performance, but it tends to be downright wasteful of memory. When only the current page is kept in memory, as a user navigates from page to page (as opposed to firing events against the page they're already on... even if it's a full refresh event), it serializes the state of the previous page to disk. If a subsequent event is fired against that previous page, then that page's state is retrieved from disk and loaded back into memory.  But this scenario only occurs if the application loads a new page in a new window or tab, and the user later switches back to the original window and interacts with it again. In typical navigation scenarios, once the user has opened a new page, the previous page instance no longer exists... even if they navigate back to the same page again, it's a new instance   of that page. Hence, keeping all pages in memory essentially guarantees at least a temporary memory leak. All of that storage is eventually released, of course, but in the meantime the server is consuming memory it will never need again that would be better served storing whatever you're explicitly caching in scope variables.
  • JavaScript/CSS Aggregation feature For performance reasons, the XPages runtime now features a new option that dynamically aggregates multiple Dojo modules, or multiple CSSs into a single file. This results in the following performance improvements:a decrease in requests sent from the browser to the server an increase in user performance, particularly in the context of networks with high latency an increase in the speed of JS/CSS parsing from the browser the freeing up of server connections to fulfill other requests As an extreme example of the saving, let's say the XPages Extension Library is using the page DWA_ListView.xsp. Without the aggregator enabled, 82 requests are made to the server. With the aggregator enabled, the count decreases to 6 requests, including the Ajax request that gets the data. Also, a test run on processing time might see changes from ~4 sec to ~800 ms. To allow you to actvate this option, XPages now feature a new runtime option, which can be set in xsp.properties (database or server level). This option is xsp.resources.aggregate=true It can also be set in Domino Designer from the Application Properties - XPages tab by checking the Use runtime optimized JavaScript and CCS resources option.
  • XPages Preload options New options designed to improve the startup performance of XPages applications have been added to this release. A preference can be set that preloads the XPages runtime on the Domino server and Notes client. Additionally, specific XPages applications may also be preloaded. The preferences are set as entries in the NOTES.INI file and have the following form: XPagesPreload=1 XPagesPreloadDB=myServer!!myDb.nsf/myXPage.xsp,myLocalDb.nsf/test.xsp The XPagesPreload entry causes an extensive list of XPages runtime Java classes to be preloaded, so they are available in memory when an application is opened by a user. The XPagesPreloadDB preference lets a comma separated list of applications be specified, with or without a specific XPage extension. Again, any required classes are loaded when the server or client starts up and are thus available as soon as any declared application is accessed by a user. The benefit of this may be more evident when running in remote mode on the Notes client, i.e. the XPages is running on the client but the application itself resides on a remote server. In this instance, the Java classes in the application (XPages, custom controls) need to be loaded across the network in order to be executed in the local XPD web container. Preloading such applications produces more responsive initial user experience.
  • First and foremost, become intimately familiar with the so-called "scope variables". The nature and use of these are documented in detail elsewhere, so I won't belabor that here. But the better you understand what information is appropriate to store in each scope - and that you can store complex object structures, not just "string-to-string" mapping - and the more you take advantage of this, the faster the application's response will be. This is because you're limiting disk I/O as much as possible... the more frequently the application can just pull whatever data the user is requesting from RAM, instead of querying the database every time, the faster the application will be. This is why you want lots and lots of RAM. :) Of course, you don't want to be gratuitous with your memory storage, which is why it's crucial to understand which scope is appropriate for which type of data... when you get the hang of this, Domino will clean up these memory caches for you automatically.  If you find that you're running out of memory, but you're confident your scope storage is reasonably optimized, tweak the application properties to clear the application scope periodically. The higher the frequency you set, the more you can cache in all the scopes without bursting the heap... but if you find you're needing to set this to a frequency of less than an hour, revisit what you're actually storing, because it's probably out of control.
  • Minimize the use of SSJS (server-side JavaScript). Every time any SSJS expression is evaluated, Domino parses the expression in realtime into an abstract syntax tree, then runs Java code that is a rough approximation of how the JavaScript specification states that code matching the detected syntax should run. The more you move your logic directly into true Java classes, the less expensive it is to execute, so it runs faster. Each time, this differential is minuscule, but aggregated over the entirety of a complex application, it adds up enough to be perceptible to end users. Even without moving your code to Java, however, you can reduce SSJS usage simply by making the most of EL (expression language). For instance, rather than binding an image's src attribute to:  "#{javascript:return '/' + database.getFilePath() + '/images/' + currentDocument.getUniversalID() + '/$FILE/' currentDocument.getItemValueString('thumbnail');}" ...you can intersperse standard EL expressions throughout an otherwise hardcoded string: "/#{database.filePath}/images/#{currentDocument.universalID}/$FILE/#{currentDocument.thumbnail}" Not only does this reduce (and, often, eliminate) the amount of quote escaping required, making the code easier to maintain, it's more efficient for the server to evaluate each expression. In the above example, it's actually slightly faster to evaluate those three separate EL expressions than to evaluate the single SSJS expression they replaced.
  • Designer - JAR design element ­ A new JAR design element has been introduced in this release. The JAR design element gives you the ability to work with packaged Java code/libraries that are included in the application NSF. ­ This design element is only available to XPages applications, where the JAR is automatically loaded by the XPages runtime. This feature frees you from having to deploy the JARS to a server and/or include the source files uniquely in the application database. ­ While JAR files can be added to the NSF through the virtual system, the JAR design element automatically manages the classpath and places the JAR file into web-inf/lib, which is the recommended location for JAR files used in a J2EE application. ­ The JAR design element is found in the Application Navigator under Code, right next to the Java element.
  • Wherever possible, change your expressions from dynamic bindings to page load bindings. This is just a fancy way of saying that ${database.title} is always better than #{database.title}. The $ means that the expression is only calculated once per page instance... # means it's recalculated as often as needed - sometimes several times within the same request, depending upon what value is bound to the expression. So obviously you can't just change all your expressions to $... input controls bound to form items, for instance, should remain #. But if you have computed text displaying the application's title (as in the above example), that value is obviously unlikely to change during any given page instance, so change it to a $ expression, and then the server only has to evaluate it once. Combine this optimization with thorough scope caching, and it's easy to see how this can really speed up page load times and event execution response. This gets particularly noticeable when dealing with repeat controls: each time a user navigates to the next page of a repeat, if that repeat's value is a # binding, it has to recalculate that value... change it to a $, and it only loads the collection once. Even if the event the user triggered has nothing to do with the repeat, the server has to recalculate all # bindings, so if the repeat's value is a #, it still has to pull the collection again even though the user wasn't explicitly interacting with the repeat.
  • Restore View Um das Eingangs erwähnte Dialoggedächtnis zu realisieren ist es notwendig die (Formular)Zustände zu speichern und wiederherzustellen. Dabei werden zwei Fälle unterschieden: Beim erstmaligen Abruf einer Seite existiert noch kein View-Objekt. Daher muss eines erzeugt werden, in dem ein leerer Komponentenbaum angelegt und im FacesContext einhängt wird. Danach kann sofort zur Render Response-Phase gesprungen, da keine Verarbeitung von übergebene Werten etc. nötig ist. Sollte bereits ein Komponentenbaum im FacesContext existieren, so wird dieses View-Objekt geladen und mit Validatoren, Konvertern und Listenern verknüpft. Apply Request Values In dieser Phase werden die übertragenen Werten des Requests (also die Daten des abgeschickten Formulars) in den Komponentenbaum übernommen, also in den entsprechenden Komponenten gesetzt. ActionEvents werden hier generiert, z.B, das Drücken des Buttons durch den der Request erzeugt wurde. Dabei ist wichtig dass hier noch keine Änderung des Modells erfolgt, sondern nur die String-Werte vorbereitet werden. Process Validation Anhand von Konvertern (aber auch Renderern) werden die gespeicherten Werte der vorherigen Phase in die Zielformate (Modelldatentypen) überführt. Anschließend werden alle Werte der Komponenten mittels registrierter Validatoren überprüft. Im Fehlerfall werden dabei üblicherweise komponentenbezogene Meldungen generiert und es wird mit der Render Response-Phase fortgefahren. Wodurch dieselbe Seite gerendert wird, da ihr Komponentenbaum noch FacesContext liegt. Update Model Values Wenn bis hier hin kein Fehler auftrat, so werden die überprüften Werte in das Modell übernommen. Dabei werden ValueChangeEvents generiert, falls sich ein Wert geändert hat. Nach dieser Phase werden die registrierten Listener über Wertänderungen informiert. Invoke Application Alle Ereignisse der Anwendungsebene werden verarbeitet. So wird z.B. die nachfolgende Seite ermittelt und ihr Komponentenbaum im Kontext abgelegt. Nach dieser Phase werden alle registrierten ActionListener benachrichtigt. Render Response Der im Kontext befindliche Komponentenbaum wird ausgegeben. Dazu wird die encode-Methode jeder Komponente ausgeführt. Wird also die Phase Invoke Application übersprungen so erfolgt das Rendern derselben Seite. Process Events Zum einen werden die für Events registrierte Listener benachrichtigt, als auch PhaseListener benachrichtigt. Letztere können den Ablauf beeinflusse oder nebenläufige Tätigkeiten angestoßen (z.B. Logging). Generell wird bei schweren Fehlern die Verarbeitung abgebrochen (Response Complete) oder vorzeitig eine Ausgabe erzeugt (Render Response).
  • will tend to see out-of-date values. To see up-to-date but not-converted values use: var editBox1 = getComponent('editBox1'); var value = editBox1.getSubmittedValue(); if( null == value ) value = editBox1.getValue();
  • XPages Performance

    1. 1. Entwicklercamp 2013Full Speed XPagesPerformanceoptimierung11. – 13..03.2013Maritim Hotel, GelsenkirchenUlrich Krause, BCC Unternehmensberatung GmbH
    2. 2. Über: Ulrich Krause Lotus Notes / Domino Administrator & Entwickler seit 1993 Senior Software Architect OpenNTF Contributor OpenNTF Board of Directors IBM Champion 2011/2012/2013 Blog http://www.eknori.de Notes Forum (http://www.atnotes.de)
    3. 3. Agenda Performance, was kann bremsen ? Java vs. JavaScript Daten vorbereiten, ViewNavigator vs. GetNextDocument Stringbuilder vs. Concat (+) JSF Lifecycle Listener Partial Update / Partial Execute Variable Resolver Werkzeuge
    4. 4. XPages Request
    5. 5. Hardware Die verwendete Hardware hat einen nicht unerheblichen Einfluß auf die Performance. Es gibt 3 Kernelemente • CPU • Arbeitsspeicher • Festplatten
    6. 6. Hardware CPU • Anzahl Kerne / Taktrate / Cache •  Schlechte Antwortzeiten Arbeitsspeicher • Obergrenze durch das Betriebssystem vorgegeben •  Skalierbarkeit Schwache CPU und zu kleiner Arbeitsspeicher führen zu • Schlechter Gesamtperformance • Schlechten Antwortzeiten • Server “hängt”
    7. 7. Netzwerk Bandbreite • Geschwindigkeit, mit der Daten übertragen werden Latenz • Beanspruchte Zeit einer Datenübertragung zwischen mehreren Computer an einem Netzwerk Je größer die Bandbreite und je kleiner die Latenz desto "besser" ist die Verbindung
    8. 8. Client & Browser Hardware Wie viele Daten requests / responses werden übertragen Wie viele Daten werden übertragen ( Größe ) Wie werden Resourcen gecached Wie viel CSJS wird ausgeführt Größe / Komplexität des CSS Komplexität des Seitenaufbau
    9. 9. XPages Design Optimizations Berechnungen während der JSF Lifecycle Phasen reduzieren • Wenn möglich, partial update verwenden • Wenn möglich, partial execute verwenden • Wenn möglich, disableValidators & immediate verwenden Berechnungen für „Sichtbar“ reduzieren • „Loaded“ Eigenschaft verwenden um „Rendered“ zu berechnen • Ergebnis der Berechnung zwischenspeichern ( scopedVariable) • VariableResolver verwenden Repeats & Views • viewEntry.getColumnValue antelle von viewEntry.getDocument.getColumn • View data source dataCache property
    10. 10. Performancebeeinträchtigungen Browser / HTTP Server • Netzwerk: Latenz, Bandbreite, Dateigröße • Browser: Anzahl gleichzeitiger Downloads (IE7 = 2 , IE8 = 6 ) HTTP Server / App Server • HTTP Server JVM Memory Allocation (heap size) & Garbage Collector • CPU Time • Anzahl Threads, DEFAULT: 40 , konfigurierbar in Domino Administrator App Server / Domino context • Lesen von Designelementen (Xpage, .class files, jar files, etc) • Je mehr Design Elemente, desto mehr Netzwerkanfragen • Anzahl Backend API Calls, insbesondere bei großen Datenmengen
    11. 11. Performancebeeinträchtigungen Servlet / JSF Lifecycle • Persitence mode  Zugriffe auf das Dateisystem • Serialisierung von Anfragen ( multiple partial update ) • Neuberechnung von Werten in allen Phasen des JSF Lifecycle Browser/ Client JavaScript/ Dojo • Inline JavaScript verhindert die Ausführung von weiteren HTML • AJAX requests an Dojo Module, die nicht geladen sind
    12. 12. General Performance options notes.ini • HTTPJVMMaxHeapSizeSet=1 • HTTPJVMMaxHeapSize=256M • sollte auf ¼ des verfügbaren RAM gesetzt werden Domino Administrator • HTTP server "Enable logging to" disabled • HTTP server thread count – defaults to 40  Generell hat das Debug Einfluß auf die Performance • JavaEnableDebug=1 • JavaDebugOptions=transport=dt_socket,server=y,suspend=n,address=800 0 • JavascriptEnableDebug=1 ( ab Version 9 )
    13. 13. Reducing Memory Utilization xsp.persistence.mode= Defines the persistence mode for the JSF pages • file: All the pages are persisted on disk • fileex: All the pages are persisted on disk except the current one, which stays in memory • <else>: All the pages stay in memory (tree mode)
    14. 14. XPages Design Optimizations Loadtime vs Runtime • Loaded vs Rendered • ExtLib Dynamic Content • allows partial re-loading so more use of load-time optimizations CSS & browser JS • Kein inline CSS / JS • Auslagern in entsprechende Designelemente • Dateien so klein wie möglich halten Bilder • Größe nicht zur Laufzeit berechnen • CSS Image Sprites verwenden, wenn möglich
    15. 15. JavaScript/CSS Aggregation Faßt mehrere DOJO Module, CSS / JS files in einer einzigen Datei zusammen • Weniger Anfragen vom Browser an den Server • Wirkt sich in Netzwerken mit hoher Latenz Performance steigernd aus • Performanteres Parsen von CSS / JS • Weniger Verbindungen zum Server Auf dem Server: xsp.properties: xsp.resources.aggregate=true
    16. 16. JavaScript/CSS Aggregation
    17. 17. XPages Pre-Load XPagesPreload=1 Neues Feature in Notes / Domino 8.5.3 Server und Client Java classes from the XPages runtime plug-ins • loaded from a fixed list of runtime classes ( 435 in ND 8.5.3 ) • com.ibm.xsp.core, common utility, JS wrapper, FSF runtime classes Java classes referenced in *-faces.config.xml • XPages control renderer, data sources, complex types
    18. 18. XPages Pre-Load• XPagesPreloadDB=Server!!Db.nsf/XPage.xsp, myLocalDb.nsf • Arbeitet auf Applikationsebene • Die Anwendung wird beim Client/Serverstart in den Speicher geladen. Dies passiert auch, wenn die Anwendung erstmalig im Browser geöffnet wird • Für jeden Eintrag in der notes.ini Variable wird eine XPage URL generiert und an den Server geschickt • Die Anwendung wird geladen und das HTML generiert • Die XPages Runtime verwirft das HTML, behält aber die Anwendung im Speicher
    19. 19. Scoped Variables applicationScope • Are visible for all users of one application. Expires some time after the last user used an applicationScope variable. That means applicationScope variables are NOT persistent forever. sessionScope • Is valid through the session of the current user. A user session expires after some time of inactivity. Uses dont have access to the sessionScope variables of other users. viewScope • Is visible for views on the current page only. Useful for transporting a search query to a view. requestScope • Is valid through one request of the current user. That includes refreshing of a page.
    20. 20. Caching und Application Scope
    21. 21. JAVA Design Element (8.5.3) A Java design element is created just like you create any other design element. Categorization in the Designer views is shown by using the "/" character to demark levels In the virtual file system, the class file appears separate from the .java file, under WebContentWEB-INFclasses
    22. 22. JAR Design Element ( V9 ) Work with packaged Java code/libraries that are included in the application NSF Frees you from having to deploy the JARS to a server and/or include the source files uniquely in the application database Automatically manages the classpath and places the JAR file into web-inf/lib Only available to XPages applications • automatically loaded by the XPages runtime
    23. 23. When to Execute - # vs $ # • Wird jedes Mal ausgeführt, wenn die Seite gerendert wird • Wenn Werte sich ändern. (Computed values / Abhängigkeiten ) $ • Wird nur beim ersten Seitenaufbau ausgeführt. • Wenn sich Werte nicht ändern ( Label )
    24. 24. DataContext dataContexts can be thought of as global variables dataContexts value can be computed dynamically or on page load • So you can use ${javascript:@Today()} and run it once rather than running a function each time. dataContexts can be scoped to any level that datasources can • XPage, Custom Control or Panel • you can set a dataContext in a panel in a repeat control, to avoid multiple references to a NotesDocuments item dataContexts are referenced using EL • So at no point in the references do you run SSJS, so its not having to go through the SSJS parser
    25. 25. DataContext - Pitfall Problem beim data context und dynamischen binding • They will be recomputed again and again, even when in Partial Execution mode and if they are not in use (http://hasselba.ch/blog/?p=1112)
    26. 26. DataContext - Pitfall
    27. 27. JSF Lifecycle
    28. 28. XPages Masterclasshttp://www.openntf.org/internal/home.nsf/project.xsp?action=openDocument&name=XPages%20Masterclass
    29. 29. XPages Lifecycle Listener Was passiert in den einzelnen Phasen des JSF Lifecycle Ulrich Krause: http://openntf.org/XSnippets.nsf/snippet.xsp?id=a-simple-lifecyclelistener-
    30. 30. Partial Refresh / Update (Pro) Reduzierung der Berechnungen im renderResponse • Weniger Rechenaufwand auf dem Server Kleinere Datenmengen, die vom Server übertragen werden • Reduzierung der Datenmenge im Netzwerk Bessere User / Browser experience • Während der Aktualisierung bleibt die Seite weiterhin sichtbar • Das Aktualisieren von nur kleinen Bereichen einer Webseite ist schneller als der vollständige Neuaufbau
    31. 31. Partial Refresh / Update (Contra) Abhängigkeiten ausserhalb der refreshID • Bereiche, die eine Abhängigkeit zu dem neu berechneten Bereich haben, werden nicht aktualisiert • Vorsicht, wenn das partial Update für Bereiche aktiviert wird, die bisher vollständig aktualisiert wurden Es kann nur eine refreshID angegeben werden • Diesem Restriktion kann mit CSJS umgangen werden, allerdings werden die einzelnen Aktualisierungen seriell abgearbeitet http://www.timtripcony.com/blog.nsf/d6plinks/TTRY-84B6VP
    32. 32. Partial Execution Reduced control processing in the 3 data-processing phases • Means less work on the server, faster response times Dependancy on Edit Box values outside of the exec area • Submitted values from Edit Boxes and/or other input controls in other areas of the control tree are not processed, so any control values and document fields in those other areas will not be updated. Enabling Partial Exec where it was previously full execution may lead to functional problems where values are out-of date in the onclick script or in the redisplayed page. onclick Event Handler must be in the exec area • The applyRequestValues phase prepares for the invokeApplication phase.The onclick simple action or SSJS script wont occur if outside the partial exec area
    33. 33. Partial Execution execMode erst ab 8.5.1 Setzen der execId in V8.5.1 und V9
    34. 34. disableValidators / immediate disableValidators • JSF Lifecycle durchläuft alle Phasen (1-6) • es findet aber keine Validierung der Daten statt • Converters funktionieren weiterhin. • Items in Dokumenten werden aktualisiert • Sven Hasselbach – “Disable all validators at once” (http://hasselba.ch/blog/? p=1106) Immediate • JSF Lifecycle durchläuft nur Phasen (1, 2, 6) • Keine Datenverarbeitung • Items in Dokumenten werden nicht aktualisiert • Event Handler onclick scripts und renderResponse Berechnungen werden ausgeführt
    35. 35. Minimize work in rendered/ visible computation Most properties, like CSS “style” are only computed in the renderResponse Edit Box and input “value” properties are used in Data Processing phases & renderResponse Data Source properties are computed during renderResponse & results are cached for the next requests Data Processing & invokeApplication phases
    36. 36. Minimize work in rendered / visible computation The rendered property is computed in all 5 lifecycle phases Avoid re-computing values in every rendered property • @DbLookup, @DbColumn, getDocumentByKey • In the rendered property, save the computed boolean to a viewScope variable
    37. 37. Using loaded vs rendered Loaded • is only computed once in the createView phase • not re-computed in the 5 usual phases • false means the control is not created. So it can never be rendered. • true means the control is added to the control tree. • You can still compute rendered when loaded evaluates to true. Compute the loaded property on conditions • where you could compute the rendered property and save it to the view scope • it would never need to be recomputed for the rest of the interaction with this page
    38. 38. Images Use correct file type depending on content • JPEG for complexed detailed images • PNG/GIF for simple images, fonts, transparencies • Use the HTML <img tag “width” and “height” attributes • For faster HTML layout in the browser • Size the image to size you intend to use • Resizing using html attributes height and width will delay the rendering of your page • Images larger than necessary will waste bandwidth
    39. 39. CSS Image Sprites Use CSS Image Sprites • If you have multiple small images, make a single larger image containing the smaller images • And use CSS to display just the relevant subset image at a llocation in the page • For semantically significant sprites, provide an accessibility “title” attribut (as sprites dont use the IMG “alt” attribute, but you still want to assist blind users) • Theres no specific XPages support for sprites, but theyre used in the XPages OneIU themes
    40. 40. CSS Image Sprite Samplehttp://www.w3schools.com/css/tryit.asp?filename=trycss_sprites_img
    41. 41. XPages Toolbox XPages based Application • Runs on the Domino server or the Notes client • An NSF needs to be installed on the Domino server/Notes client • A profiler jar file should be added to the JVM launch options Measures the CPU performance and the memory allocation Available from OpenNTF.org • Free open source project • Search for “XPages Toolbox” Extended in 8.5.2 to support Backend classes profiling http://www.openntf.org/internal/home.nsf/project.xsp?action=openDocument&name=XPages%20Toolbox
    42. 42. XPages Toolbox
    43. 43. XPages Toolbox Generate a heap dump of the JVM running in the HTTP task • A button in the XPages profiler generates the heap dump • From the Domino console • tell http xsp heapdump (triggers com.ibm.jvm.Dump.HeapDump()) • tell http xsp javadump (triggers com.ibm.jvm.Dump.JavaDump()) Analyze the heap dump using the Eclipse memory analyzer • http://www.eclipse.org/mat/ • http://www.ibm.com/developerworks/java/jdk/tools/dtfj.html HTTPJVMMaxHeapSizeSet=1 HTTPJVMMaxHeapSize=256M
    44. 44. Heapdump / Javadump Analyzer
    45. 45. More Tools Print statements • In rendered/visible computations to see how often executed – print("panel2 evaluating rendered property"); • In the XPages root control events: – before/afterPageLoad, afterRestoreView, before/afterRenderResponse. • Custom control root events: – before/afterPageLoad. • In the document data source events: – queryNewDocument, postSaveDocument, etc. Task Manager and/or Process Explorer • Shows CPU usage & process memory usage as it happens • Heap memory usage will be a subset of process memory, but heap dumps are only a snapshot
    46. 46. More Tools Browser developer tools • for watching network transactions, partial updates, response times • BROWSER: Firebug, Developer Tools • XPiNC: FirebugLite from ExtLib Java / Javascript Debugging • Degrades performance but can inspect objects, step into code. • Use the Eclipse Java debugger. • In Dominonotes.ini add these 2 options: • JavaEnableDebug=1 • JavaDebugOptions=transport=dt_socket,server=y,suspend=n,address=8000
    47. 47. Demo
    48. 48. JSON Daten { "@unid":"00065A23B16A0E5EC1257AEB00315D53", "FirstName":"Concetta", "LastName":"Galloway", "State":"AZ", "City":"Mesa" }, { "@unid":"000C0B447A8D3FEBC1257AEB00314648", "FirstName":"Annmarie", "LastName":"Crosby", "State":"TX", "City":"El Paso" }, ...
    49. 49. XAgent – SSJS Get all „Contacts“ into a NotesDocumentCollection, loop the collection and build the JSON by reading the values from items in the document
    50. 50. XAgent – SSJS
    51. 51. XAgent – SSJS – UNID from Item Get all „Contacts“ into a NotesDocumentCollection, loop the collection and build the JSON by reading the values from items in the document. Also UNID is stored in document
    52. 52. XAgent – SSJS – UNID from Item
    53. 53. XAgent – SSJS - SingleItem Get all „Contacts“ into a NotesDocumentCollection, loop the collection and get the JSON from an item on the document. The JSON is calculated on document save
    54. 54. XAgent – SSJS - SingleItem
    55. 55. XAgent – SSJS – ViewNavigator loop thru a view and get the JSON from a view column.
    56. 56. XAgent – SSJS – ViewNavigator
    57. 57. StringBuilder vs String.concat Concatenation of Strings is very easy in Java - all you need is a +‘ Each time you append something via + (String.concat()) a new String is created, the old stuff is copied, the new stuff is appended, and the old String is thrown away. The bigger the String gets the longer it takes - there is more to copy and more garbage is produced. Accordingly to Arno Unkrig the optimal strategy is to use String.concat() for 2 or 3 operands, and StringBuilder for 4 or more operands String text= System.out.println("x:"+x+" y:"+y); "line 1n"+ "line 2n"+ "line 3";
    58. 58. StringBuilder vs String.concat When to use StringBuilder over + (String.concat()) ? • use StringBuilder whenever you assemble a String in a loop • Just keep in mind that + isnt always a good idea http://kaioa.com/node/59
    59. 59. XAgent – SSJS – ViewNavigator + StringBuilder loop thru a view and get the JSON from a view column. Use a StringBuilder to concat the JSON
    60. 60. XAgent – SSJS – ViewNavigator + StringBuilder
    61. 61. XAgent – Java loop thru a view and get the JSON from a view column. Use a StringBuilder to concat the JSON + use Java instead of SSJS
    62. 62. XAgent – Java
    63. 63. Themes Single Document Containing References to all your CSS Resources • resource sections reference the CSS files used • control section define what CSS classes are applied to specific controls XML Based and Easy To Learn • creating a new theme document prefills sample content Can Extend Other Themes • <theme extends="webstandard"> • will automatically include all the resource and control definitions from that theme • built-in themes to extend • webstandard, notes, oneUI
    64. 64. Themes Create your own themes from scratch. Creating a theme that extends from the webstandard or another supplied theme will include extra stylesheets and styles that you might not need. Be prepared to spend more time writing css though
    65. 65. Ressourcen im Theme laden Global Application / Configuration properties
    66. 66. Q+A• Mail: eknori@eknori.de• Blog: http://www.eknori.de• Sametime: bleedyellow.com• Twitter: eknori