Posts Tagged: ‘8.5.3’

Quick-n-Dirty: Use your own Factory classes in XPages(2) – The VirtualPageTransformer

24. Oktober 2012 Posted by Sven Hasselbach

While playing a little bit with core XPages functionality I found the interesting VirtualPageTransformer interface. With this interface it is possible to implement “virtual” XPages, and this allows to do something which can be described like an url mapping (the $$OpenDominoDocument.xsp url for example was implemented this way).

To do create your own transformations you have to do the following:

1. Read the first article about using Factory classes in XPages and create the required /WEB_INF/com.ibm.xsp.factories.properties file in your database

2. In this file add a new entry for the page transformer class to use:

PageTransformer=ch.hasselba.factory.PageTransformer

You can choose every key name you want for the factory. The class will be identified from the XPages runtime by the implemented interface com.ibm.xsp.page.VirtualPageTransformer.

3. Create a java class which implements this interface:

package ch.hasselba.factory;

import com.ibm.xsp.page.VirtualPageTransformer;
import com.ibm.xsp.FacesExceptionEx;
import javax.faces.context.FacesContext;

public class PageTransformer implements VirtualPageTransformer {

    public boolean isVirtualPage(FacesContext fc, String pStr) {
        return (pStr.indexOf("$$VirtualPage$$") > (-1));
    }

    public String transformPageName(FacesContext fc, String pStr) {
        try {
            return "/Test.xsp";
        } catch (Exception e) {
            throw new FacesExceptionEx("Error! " + e.getMessage());
        }
    }
}

This adds the “virtual” page handler “$$VirtualPage$$” to your database.

This means that every request to your  database is checked if the keyword is contained in the url. For this test, the method isVirtualPage is called with the current url as parameter. If this method returns true, the method transformPageName is called; this method must return a string which identifies the XPage to use. In this case, it is the XPage “Test.xsp

If you open this URL…

http://localhost/Factories.nsf/$$VirtualPage$$.xsp/blahblahblah/blubb/blubb/?etc=etc

… the XPage “Test.xsp” is rendered instead.

You can add as much VirtualPageTransformers you want to a database.

P.S. Keep in mind that this article has been posted in the “Quick-n-Dirty” category.

Quick-n-Dirty: Disable Validation for FileDownload control

24. Oktober 2012 Posted by Sven Hasselbach

If you are using the file download control,  you sooner or later want to allow your users to delete an existing file. But if you have some required fields on your XPage, a deletion is not possible because the validation is always fired before the attachment is removed.

To disable to validation you can use this little SSJS snippet which sets the “disableValidators” property for all events of the UIFileDownload control. Just add the following code to the beforeRenderResponse event of your XPage and change the id of the component to fit your requirements.

<xp:this.beforeRenderResponse>
   <![CDATA[#{javascript:
      /***
       * disable validation for UIFileDownload control
       * 
       * @param UIFileDownload component
       * @author Sven Hasselbach
       * @category SSJS
       * @category UI
       * @version 0.2
       */
      function disableFileDownloadValidation( fDownload:com.ibm.xsp.component.UIFileDownload ){
         if( fDownload === null )
            return;

         rekDisableFileDownloadValidation( fDownload );
      }

      function rekDisableFileDownloadValidation( component:javax.faces.component.UIOutput ){
         try{
            var children:java.util.List = component.getChildren();
            var it:java.util.Iterator = children.iterator();
            var curChild:javax.faces.component.UIOutput;

            while( it.hasNext() ){
               curChild = it.next();
               if( typeof( curChild ) === 'com.ibm.xsp.component.xp.XspEventHandler' )
                  curChild.setDisableValidators( true );

               rekDisableFileDownloadValidation( curChild );
            }
         }catch(e){}    
      }

      disableFileDownloadValidation( getComponent( 'fileDownload1' ) );
   }]]>
</xp:this.beforeRenderResponse>

P.S. Keep in mind that this article has been posted in the “Quick-n-Dirty” category.

Quick-n-Dirty: Non Closable Dialog for ExtLib

19. Oktober 2012 Posted by Sven Hasselbach

I have created a dirty hack for dialogs which prevents users to close the dialog by pressing the escape key or the close button. In my first approach  (StackOverflow.com)the hack has overwritten all dialogs for the whole XPage. This version allows to enable / disable it per dialog.

To use this hack you have to add the CSJS library to your XPage and call the dialog with an additional parameter ‘nonclosable‘:

XSP.openDialog("#{id:dialogNonClosable}", {'nonClosable': true } );

The hack was tested with IE 9 and FF 16, ExtLib 8.5.3.20120605-0921. Here is the CSJS library you have to attach to your XPage:

/**
 * ExtLib Dialog Hack to enable NonClosable Dialogs
 * 
 * This function overrides the exsiting openDialog method of the XSP object. It
 * adds a new option named 'nonclosable'
 * 
 * To open a non closable dialog, you have to use it like this
 * 
 * XSP.dialog('#{id:dialog}', {'nonclosable': true } );
 * 
 * @category CSJS
 * @category ExtLib
 * @author Sven Hasselbach
 */

function injectExtLibHack() {
    XSP.openDialog = function xe_od(dialogId, options, params) {
        dojo.addOnLoad( function() {
            var created = false;
            var dlg = dijit.byId(dialogId);
            if (!dlg) {
                var type = XSP._dialog_type;
                try {
                    if (options['nonClosable'])
                        type = XSP._dialog_type_nonClosable;
                } catch (e) {
                }

                options = dojo.mixin( {
                    dojoType : type || "extlib.dijit.Dialog"
                }, options);

                dojo.parser.instantiate( [ dojo.byId(dialogId) ], options);
                dlg = dijit.byId(dialogId);
                created = true;
            } else {
                if (dlg.keepComponents) {
                    dlg.show();
                    return;
                }
            }

            var onComplete = function() {
                dlg.show();
            };
            var axOptions = {
                params : dojo.mixin( {
                    $$showdialog : true,
                    $$created : created
                }, params),
                onComplete : onComplete,
                formId : dialogId
            };
            dlg.attr("content", "<div id='" + dialogId + ":_content'></div>");
            XSP.partialRefreshGet(dialogId + ":_content", axOptions);
            if (dojo.isIE < 8) {
                dojo.query(".lotusDialogBorder").style("width", "500px");
            }
        });
    }

    dojo.provide("extlib.dijit.OneUIDialogNonCloseableDialog");
    dojo.require("extlib.dijit.Dialog");
    dojo.declare(
       "extlib.dijit.OneUIDialogNonCloseableDialog",
       extlib.dijit.Dialog,
       {
          baseClass: "",
          templateString: dojo.cache("extlib.dijit", "templates/OneUIDialog.html"),
          disableCloseButton: true,
          _onKey: function(evt){
          if(this.disableCloseButton &&
             evt.charOrCode == dojo.keys.ESCAPE) return;
             this.inherited(arguments);
          },
          _updateCloseButtonState: function(){
             dojo.style(this.closeButtonNode,
             "display",this.disableCloseButton ? "none" : "block");
          },
          postCreate: function(){
             this.inherited(arguments);
             this._updateCloseButtonState();
             dojo.query('form', dojo.body())[0].appendChild(this.domNode);
          },
          _setup: function() {
             this.inherited(arguments);
             if (this.domNode.parentNode.nodeName.toLowerCase() == 'body')
                dojo.query('form', dojo.body())[0].appendChild(this.domNode);               
          }        
       }
    );

    // This is used by the picker dialog to grab the correct UI
    XSP._dialog_type_nonClosable="extlib.dijit.OneUIDialogNonCloseableDialog";

}

XSP.addOnLoad( injectExtLibHack );

And here is an example XPage which demonstrates how to use the hack:

<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core"
    xmlns:xe="http://www.ibm.com/xsp/coreex">
    <xp:this.resources>
        <xp:script src="/dialogHack.js" clientSide="true"></xp:script>
    </xp:this.resources>

    <xp:button value="Show Dialog Closable" id="button1">
        <xp:eventHandler event="onclick" submit="false">
            <xp:this.script><![CDATA[
            XSP.openDialog("#{id:dialogClosable}");]]></xp:this.script>
        </xp:eventHandler>
    </xp:button>
    <xp:button value="Show Dialog Non Closable" id="button2">
        <xp:eventHandler event="onclick" submit="false">
            <xp:this.script>
                <![CDATA[
                    XSP.openDialog("#{id:dialogNonClosable}", {'nonClosable': true } );
                ]]>
            </xp:this.script>
        </xp:eventHandler>
    </xp:button>

    <xe:dialog id="dialogClosable" title="This is a closable dialog">
        <xe:dialogContent>
            You can close me via Escape or the close button.
        </xe:dialogContent>
        <xe:dialogButtonBar>
            <xp:button value="Ok" id="button3"
                styleClass="lotusFormButton">
                <xp:eventHandler event="onclick" submit="false">
                    <xp:this.script><![CDATA[XSP.closeDialog('#{id:dialogClosable}')]]></xp:this.script>
                </xp:eventHandler>
            </xp:button>
        </xe:dialogButtonBar>
    </xe:dialog>

    <xe:dialog id="dialogNonClosable" title="This is a non-closable dialog">
        <xe:dialogContent>
            Try to close me via Escape or the close button ;-) 
        </xe:dialogContent>
        <xe:dialogButtonBar>
            <xp:button value="Ok" id="button4"
                styleClass="lotusFormButton">
                <xp:eventHandler event="onclick" submit="false">
                    <xp:this.script><![CDATA[XSP.closeDialog('#{id:dialogNonClosable}')]]></xp:this.script>
                </xp:eventHandler>
            </xp:button>
        </xe:dialogButtonBar>
    </xe:dialog>

</xp:view>

This is the “standard” ExtLib dialog:

And this is the “non-closable” version:

P.S. Keep in mind that this article has been posted in the “Quick-n-Dirty” category.

Quick-n-Dirty: Use your own Factory classes in XPages

18. Oktober 2012 Posted by Sven Hasselbach

Here is a easy way to use your own factory classes in XPages:

1. Create a file named “com.ibm.xsp.factories.properties” in the WEB-INF-Folder of your NSF

 

 

2. In this file, define the factory classes you want to use in the format<NAME>=<Java Class>

HelloWorldFactory=ch.hasselba.factory.HelloWorld

3. Create a java class, in this example ch.hasselba.factory.HelloWorld

package ch.hasselba.factory;

public class HelloWorld 
{
   public HelloWorld(){
      System.out.println("Hello World Factory alive!");
   }

   public String getMessage(){
      return "Hello World!";
   }

}

The factory classes you are adding require a constructor. They will be instantiated during runtime.

4. After saving your java class and opening a XPage you should see the message on the server console (perhaps you have to do a clean first).

This means that the Factory is now accessible and is ready to use. The class will only be instantiated once during runtime.

5. To use your Factory, you have to do a lookup first, before you can use it. This can be done using the com.ibm.xsp.factory.FactoryLookup class which can be accessed via the current application (Please read the notice in the ExtAPI documentation!).

Here is a SSJS code snippet:

<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core">
   <xp:label id="labelHelloWorld">
      <xp:this.value>
         <![CDATA[#{javascript:
            var app = facesContext.getApplication();
            var facLookUp = app.getFactoryLookup();
            var hwFac = facLookUp.getFactory("HelloWorldFactory");
            hwFac.getMessage();
         }]]>
      </xp:this.value>
   </xp:label>
</xp:view>

The main difference between a managed bean and this approach is, that the class is instantiated as soon the JSF application starts running, not if you access the bean in your code for the first time. The factory class can do what you want, f.e. run a thread or whatever. The result of the operations can be accessed via the  factory lookup.

P.S. Keep in mind that this article has been posted in the “Quick-n-Dirty” category.

Quick-n-Dirty: Control Dojo generation for individual XPages

17. Oktober 2012 Posted by Sven Hasselbach

Another interesting question has been asked on stackoverflow.com: How to enable or disable the Dojo libraries for individual XPages, not the whole application?

Just adding the parameter as shown below to the XPage won’t work:

<xp:this.properties> 
 <xp:parameter name="xsp.client.script.libraries" value="none" />
</xp:this.properties>

The workaround is to add a single line to beforePageLoad or beforeRenderResponse event:

facesContext.getRequestParameters().setJsLibrary(0);

The parameter can be set as the following

  • “0″ disables Dojo Framework
  • “1″ enables Dojo Framwork
  • “2″ enables Dojo Lite Framework

If you are using the ExtLib, there is still a problem with the automatically added CSJS libraries. These headers will be added automatically (it is the same result if you are disabling dojo application wide):

<script type="text/javascript">dojo.registerModulePath('extlib', '/xsp/.ibmxspres/.extlib');</script>
<script type="text/javascript" src="/xsp/.ibmxspres/.mini/dojo/@Eya.js"></script>

Edit:

This can only be removed by disabling the ressource aggregation or disabling the Extension Library for the whole application.

You can disable it f.e. by adding this to your XPage beforeRenderResponse event:

facesContext.getRequestParameters()
   .setProperty("xsp.resources.aggregate", "true")

XPages: Lost in Translation

18. September 2012 Posted by Sven Hasselbach

The localization feature is really nice and helps a lot, but you also can have some trouble using it. The first problem is that the language codes which are used in XPages are different from the language codes in java.util.Locale.

This SSJS code for example will not work:

var locale = new java.util.Locale( "fr_BE" );
context.setLocale( locale );
context.reloadPage();

It will not work because the java.util.Locale object returns “fr_be“, but the PageDetails are set to “fr_BE“, and that’s why the setting the language does not work.

<xp:text escape="true" id="computedFieldLocale">
   <xp:this.value>
      <![CDATA[#{javascript:
         var locale = new java.util.Locale( "fr_BE" );
         locale.getLanguage()}]]>
      </xp:this.value>
</xp:text>

[This SSJS Code returns "fr_be"]

[In PageDetails "fr_BE" is used]

But if you set the locale string manually with the setLocaleString() method of the context object, it works as designed.

The second problem I ran into is the aggressive transformation of all texts on a XPage. I copied a simple CSS Style definition from another database, but after copy/pasting it I was unable to see any changes in the browser, as soon I switched to another than the default language. The CSS style didn’t work anymore:

<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core">
   <style>
      .red { color:rgb(255,0,0 ) }
   </style>
   <p>TEXT</p>
</xp:view>

[Default Language, it worked]

[Other Language, not working anymore]

The CSS style was transformed by the localization feature and was now “translated”. In the generated HTML code, the tag looked like this:

<style>[en| .red { color:rgb(255,0,0 ) } ]</style>

Same result for directly copied JavaScript-Code, Text etc. (as shown in the screenshot above).

But I still love this feature. It makes developers life a lot easier.

XPages: The Outputstream and binary data

12. September 2012 Posted by Sven Hasselbach

If you want to get control over the outputstream of a XPage, you can use the response object from the ExternalContext:

var response = facesContext.getExternalContext().getResponse()

This will give you access to an object of type com.ibm.xsp.webapp.XspHttpServletResponse which allows some basic operations, but the response will always be encoded to UTF-8. You can not return any binary data directly.

But if you access the underlying LCDAdapterHttpServletResponse directly, it is possible to get the full control for the outputstream.

var exCon = facesContext.getExternalContext();
var response = exCon.getResponse().getDelegate();

This allows you to send any data you want to the browser. Here is an example for a JPEG rendered directly in the XPage:

1. The XPage

<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core" rendered="true">

   <xp:this.afterRenderResponse>
      <![CDATA[#{javascript:
         importPackage( ch.hasselba.xpages.demo );
         var exCon = facesContext.getExternalContext();
         var response = .getResponse().getDelegate();
         ch.hasselba.xpages.demo.JPEGGenerator.generate( response );
      }]]>
   </xp:this.afterRenderResponse>

</xp:view>

 

2. The Java object to generate a JPEG

package ch.hasselba.xpages.demo;

import javax.servlet.ServletOutputStream;
import javax.servlet.http.HttpServletResponse;
import java.awt.Graphics;
import java.awt.image.BufferedImage;
import java.io.IOException;
import com.sun.image.codec.jpeg.ImageFormatException;
import com.sun.image.codec.jpeg.JPEGCodec;
import java.awt.Color;
import java.awt.Font;

/**
 * JPEG Generator for a simple demonstration of controlling the
 * HttpServletResponse output
 * 
 * @author Sven Hasselbach
 * @category Demo
 * @category Servlet
 * @category Image
 * @version 1.0
 */

public class JPEGGenerator {

    private static final long serialVersionUID = 1L;
    private static final int WIDTH = 800;
    private static final int HEIGHT = 200;
    private static final Color BACKGROUND_COLOR = new Color(224, 224, 224);
    private static final Color COLOR = new Color(0, 0, 0);
    private static final Font FONT = new Font("Times New Roman", Font.BOLD, 46);

    /**
     * generates a JPEG image and sends the result to the outputstream of the
     * HttpServlet
     * 
     * @param response
     *            HttpServletResponse
     * @author Sven Hasselbach
     * @version 1.0
     */
    public static void generate(final HttpServletResponse response) {
        ServletOutputStream out = null;
        try {

            // set the content type for JPEG
            response.setContentType("image/jpg");

            // get the ouput stream
            out = response.getOutputStream();

            // generate a image to convert
            BufferedImage img = createImage();

            // convert image to jpeg and send to output
            JPEGCodec.createJPEGEncoder(out).encode(img);

        } catch (ImageFormatException e) {
            e.printStackTrace();
        } catch (IOException e) {
            e.printStackTrace();
        }

    }

    /**
     * creates a simple "Hello World" image
     * 
     * @return BufferedImage
     * @author Sven Hasselbach
     * @version 1.0
     */
    public static BufferedImage createImage() {
        BufferedImage image = new BufferedImage(WIDTH, HEIGHT,
                BufferedImage.TYPE_BYTE_INDEXED);
        Graphics graphics = image.getGraphics();
        graphics.setColor(BACKGROUND_COLOR);
        graphics.fillRect(0, 0, image.getWidth(), image.getHeight());
        graphics.setColor(COLOR);
        graphics.setFont(FONT);
        graphics.drawString("Hello World!", 10, HEIGHT / 2);

        return image;
    }

}

There is no need for splitting this example in a separated Java class. You can directly access the output in SSJS and send your binary data directly via write method of the ServletOutputStream.

Security: Another XSS Vulnerability in Domino

11. September 2012 Posted by Sven Hasselbach

Stephan Wissel wrote about a XSS vulnerabilty for Domino servers (< 8.5.4) and in his post you will get an advise how to protect your domino server against this attack. Thanks for this! Works great!

But there is still a problem with another URL pattern:

*/xsp/.ibmmodres/*

This resolves resources from databases, that’s why it only works in a database URL. But normally domcgf.nsf is reachable from outside.

Update:

The blog post was updated on wissel.net. Please update your server configuration!

XPages: Additional Facets for Viewpanels

16. August 2012 Posted by Sven Hasselbach

Today I found some additional facets / sections for a normal view panel component which can help to design a layout of an application. They are named like the wind directions and  are equivalent to the position information for the relevant content.

The following screenshot shows all facets in use. In the center you can see the content of the view panel. The pagers are not used, only place holders for a better demonstration:

As you can see there is some HTML source code in the top of the page visible. This happens if you are using the “north” facet. I don’t know why this happens.

Here is the source code of the demo XPage:

<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core"
    xmlns:xc="http://www.ibm.com/xsp/custom">

    <xp:viewPanel rows="10" id="viewPanel1">
        <xp:this.facets>
            <xc:ccDisplayer name="headerPager" color="255,0,0" xp:key="headerPager" />
            <xc:ccDisplayer name="footerPager" color="0,255,255" xp:key="footerPager" />
            <xc:ccDisplayer name="viewTitle" color="255,0,255" xp:key="viewTitle" />
            <xc:ccDisplayer name="south" color="0,255,0" xp:key="south" />
            <xc:ccDisplayer name="southWest" color="96,96,96" xp:key="southWest" />
            <xc:ccDisplayer name="west" color="128,128,128" xp:key="west" />
            <xc:ccDisplayer name="northWest" color="160,160,160" xp:key="northWest" />
            <xc:ccDisplayer name="north" color="255,255,0" xp:key="north" />
            <xc:ccDisplayer name="northEast" color="192,192,192" xp:key="northEast" />
            <xc:ccDisplayer name="east" color="224,224,224" xp:key="east" />
            <xc:ccDisplayer name="southEast" color="255,255,255" xp:key="southEast" />
        </xp:this.facets>
        <xp:this.data>
            <xp:dominoView var="view1" viewName="DemoView"></xp:dominoView>
        </xp:this.data>
        <xp:viewColumn columnName="Col1" id="viewColumn1">
            <xp:viewColumnHeader value="DocUNID" id="viewColumnHeader1"></xp:viewColumnHeader>
        </xp:viewColumn>
    </xp:viewPanel>
</xp:view>

And here is the custom control used.

<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core">
    <xp:this.style>
       <![CDATA[#{javascript:"height:100.0px;width:100.0%;background-color:rgb(" + compositeData.color + ")"}]]>
    </xp:this.style>
    <xp:label value="#{javascript:compositeData.name}" id="labelName">
    </xp:label>
</xp:view>

XPages: Access a datasource from one custom control in another one

5. August 2012 Posted by Sven Hasselbach

On stackoverflow.com, a very interesting question was asked: How can you access a document datasource from one custom control in another custom control. And here comes my solution in a small SSJS function.

First you have to add an id to the custom control which contains the datasource. This gives you a handle for other custom controls:

<xc:ccDS1 id="idDSComponent"></xc:ccDS1>

Now it is possible to get the custom control by using the SSJS function getComponent(). The datasources are stored in the data attribute of the custom control. You just have to iterate through them and check every entry for the name you are looking for.

And here is the code snippet to access the datasource in another custom control:

/***
 * getDatasource
 * Resolves a datasource from a custom control
 * 
 * @param componentId    id of the component containing the datasource
 * @param dsName    name of the datasource in the component
 * @author Sven Hasselbach
 */
 function getDatasource( componentId:String, dataSourceName:String ):com.ibm.xsp.model.domino.DominoDocumentData {
    try{
       var data:java.util.ArrayList = getComponent( componentId ).getAttributes().get("data");
       if( data == null )
          return null;
                    
       var it:java.util.Iterator = data.iterator();
       var obj = null;
       while( it.hasNext() ){
          obj = it.next();
          if( obj.getVar() == dataSourceName )
             return obj;
       }
    }catch(e){
       print( e );
    }
}

To use the function you have to use it like this:

getDatasource( "idDSComponent", "document1" )

Here is the link to the original question: How to get document datasource in another Custom Control?

XPages: Access resources and their content (2)

17. Juli 2012 Posted by Sven Hasselbach

By using the same code as described in the previous article you can access the complied java classes. To get the correct path you have to do the following:

1. Select the java element you want to access

2. Have a look inside the “$ClassIndexItem” field

3. This is the path of the compiled Java class:

4. Change the variable url to the specific path

var url = "WEB-INF/classes/ch/hasselba/jsf/servlet/MyServletFactory.class";

The first 30 Bytes of the resulting output are for internal use only and have to be skipped. They contain header informations like the length of the java class. The compiled java class starts from &HCAFEBABE.

It is even possible to access the generated XPages code. In this case there are multiple classes in a design document. For the XPage “Demo.xsp” the two generated classes are:

var url = "WEB-INF/classes/xsp/Demo.class"

and

var url = "WEB-INF/classes/xsp/Demo$DemoPage.class"

XPages: Access resources and their content

15. Juli 2012 Posted by Sven Hasselbach

To access XPages resources during runtime and to get their content as a string, you can use the following SSJS code snippet:

<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core">

    <xp:label id="label1">
        <xp:this.value><![CDATA[#{javascript:
            var url = "/WEB-INF/faces-config.xml";
            var data = facesContext.getExternalContext().
                getResourceAsStream( url );
            var txt = "";
            while( data.available() ){
                txt += @Char(data.read());
            }
            txt}]]>
        </xp:this.value>
    </xp:label>

</xp:view>

[This displays the current faces-config.xml]

By using the correct URL path it is for example possible to access the code of SSJS libraries or even the source code of java classes in the database. To access the source code of a XPage, just use the name of the XPage itself. Same procedure for SSJS libraries, just add a “.jss” at the end of the library’s name. For accessing a java class, the “dots” in the package names have to be replaced with “slashes”.

To access f.e. the java file for class ch.hasselba.jsf.debug.ResourceUtil the url has to look like this:

var url = "ch/hasselba/jsf/debug/ResourceUtil.java";

DAOS Transparenz: Welches Attachment ist welchen .NLO Objekt zugeordnet?

10. Juli 2012 Posted by Noteshexe

Vorsicht, es handelt sich um eine nicht dokumentierte Debugging Funktion! Note that this is an undocumented feature! Ask the IBM Support! Step 1: Exampel: 1 document + 3 attachments (1 NoteID+3 Object-ID) benötigt wird die NoteID und Objekt-ID required the NoteID and Object-ID Tip: @noteID Step2: Server notes.ini: DEBUG_DAOS_DIAGNOSTICS=1 Serverneustart /restart server Console: tell daosmgr LISTNLO [...]

XPages: Run your own Servlets

9. Juli 2012 Posted by Sven Hasselbach

A really interesting article about running your own servlets on domino server can be found here: http://www.ibm.com/developerworks/cn/lotus/xpage-servlet/index.html

It’s chinese, but you can translate f.e. with Google’s Translator.

With 8.5.3 I had have some problems because the required interface IServletFactory could not be resolved in DDE.

To get the example running, you have to add a JAR to your build path. Open Project properties, select “Java Build Path” and click “Add External JARs“:

Now you have to add the file “lwpd.domino.adapter.jar“. This can be found in the following folder:

<NOTES>\framework\shared\eclipse\plugins\com.ibm.domino.xsp.adapter_<VERSION>

The <VERSION> string depends on your current installation and Server-Version.

After adding this JAR to the build path, the compilation problems should be resolved.

XPages application events: Create your own ApplicationListener (2)

7. Juli 2012 Posted by Sven Hasselbach

There is another interface available which provides the additional method applicationRefreshed. This event is always raised if the method refresh() of the Application-Object is fired.

Instead of implement the interface described in the previous posting, you have to use the interface named com.ibm.xsp.application.events.ApplicationListener2.

package ch.hasselba.jsf.debug;

import com.ibm.xsp.application.ApplicationEx;
import com.ibm.xsp.application.events.ApplicationListener2;

public class MyApplicationListener implements ApplicationListener2 {

    public void applicationCreated(ApplicationEx arg0) {
        System.out.println("applicationCreated()");
        System.out.println("ID: " + arg0.getApplicationId());
     }

    public void applicationDestroyed(ApplicationEx arg0) {
        System.out.println("applicationDestroyed()");
        System.out.println("ID: " + arg0.getApplicationId());
    }

    public void applicationRefreshed(ApplicationEx arg0) {
        System.out.println("applicationRefreshed()");
        System.out.println("ID: " + arg0.getApplicationId());
    }

}

You can fire the refresh of the application manually. Here is a simple example how to do this:

<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core">
   <xp:button value="Label" id="button1">
      <xp:eventHandler event="onclick" submit="true"
         refreshMode="complete">
            <xp:this.action>
               <![CDATA[#{javascript:
                  facesContext.getApplication().refresh()
               }]]>
            </xp:this.action>
        </xp:eventHandler>
   </xp:button>
</xp:view>

By clicking the button, the refresh is fired: