Posts Tagged: ‘JSF’

Quick-n-Dirty: Hotfix for DateTimeHelper

12. Juni 2017 Posted by Sven Hasselbach

This weekend I stumbled over a bug of the DateTimeHelper: If the value of the field is empty, no actions and/or action listeners connected with a managed bean will be executed anymore.

Here is an example of a small XPage to illustrate the problem:

<?xml version="1.0" encoding="UTF-8"?><?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core">
 
    <xp:label 
        value="#{javascript:java.lang.System.currentTimeMillis()}" id="labelNow" />

     <xp:inputText id="inputTextDT" value="#{myBean.valueDT}">
         <xp:this.converter>
             <xp:convertDateTime type="date" />
         </xp:this.converter>
         <xp:dateTimeHelper />
     </xp:inputText>

    <xp:button id="button" value="OK">
        <xp:eventHandler
            event="onclick"
            submit="true"
            refreshMode="partial"
            refreshId="labelNow"
            actionListener="#{myBean.action}" />
     </xp:button>

</xp:view>

It does not matter if you set the disableValidators property for the text field to true, even an immediate=true won’t help here. The reason for the problem is that the renderer of the dateTimeHelper always uses the attached converter and fails with a null pointer exception if the value is empty (this infringes the JSF specification, but IBM has implemented it this way).

The workaround for this problem is to overwrite the existing renderer class and handle the NPE by yourself:

package ch.hasselba.xpages.renderer;

import javax.faces.component.UIComponent;
import javax.faces.context.FacesContext;
import javax.faces.convert.ConverterException;
public class DateTimeHelperRenderer
    extends com.ibm.xsp.renderkit.dojo.DateTimeHelperRenderer{

    public Object getConvertedValue(FacesContext fc, UIComponent uiComponent, Object obj)
        throws ConverterException  {

          Object result = super.getConvertedValue(fc, uiComponent, obj);

          if( result == null )
            return new Object();

          return result;
    }
}

The renderer must now be registered in faces-config.xml:

<?xml version="1.0" encoding="UTF-8"?><?xml version="1.0" encoding="UTF-8"?>
<faces-config>
  <render-kit>
    <renderer>
      <component-family>javax.faces.Input</component-family>
      <renderer-type>com.ibm.xsp.DateTimeHelper</renderer-type>
      <renderer-class>ch.hasselba.xpages.renderer.DateTimeHelperRenderer</renderer-class>
    </renderer>
  </render-kit>
</faces-config>

Now the problem is solved, the managed bean’s action get executed even if the value is empty.

Read full article |Kommentare deaktiviert
Tags: 9.0, bug, domino, Java, JSF, xpages
Categories: Allgemein

Things I never blogged about: XPages & Google’s EventBus

1. Dezember 2015 Posted by Sven Hasselbach

This is another topic I wanted to blog about for a long time: The use of Google’s EventBus in XPages applications. EventBus is a replacement for the Java in-process event distribution. It makes life a lot easier.

My first plan was to add the guava.jar into an OSGi plugin because of security reasons (otherwise you have to use the „grant{ permission java.security.AllPermission;}„) but I never had the time. That’s why I created a simple example which uses the jar in the lib/ext folder instead.

To use the EventBus in an application, you first have to define an event. This simple example has a message only, but you can add any properties you want.

package ch.hasselba.xpages;

public class FrontendEvent {

    private final String message;

    public FrontendEvent(final String message) {
        this.message = message;
    }

    public String getMessage() {
        return message;
    }

}

Then we need a subscriber. For this we have to add the annotation @Subscribe to a method of a managed bean which should handle an event. The class type of the parameter tells the EventBus what kind of event our method should handle.

This is a managed bean which stores the last message sent over the EventBus:

package ch.hasselba.xpages;

import com.google.common.eventbus.Subscribe;

public class EventSubscriber {

    private String message;

    @Subscribe
    public void handleEvent(FrontendEvent event) {
        this.message = event.getMessage();
    }

    public void getMessage(String msg) {
        this.message = msg;
    }

    public String getMessage() {
        return this.message;
    }
}

Then we have to create a managed bean which has an instance of EventBus, the FrontendEventBus. The bus has a managed property subscribers. As soon the bean is instantiated, the managed property is called and the list of objects is registered to the EventBus instance.

package ch.hasselba.xpages;

import java.io.Serializable;
import java.util.ArrayList;

import com.google.common.eventbus.EventBus;
import com.google.common.eventbus.SubscriberExceptionContext;
import com.google.common.eventbus.SubscriberExceptionHandler;

@SuppressWarnings("serial")
public class FrontendEventBus implements SubscriberExceptionHandler,
        Serializable {

    final EventBus eventBus = new EventBus();
    ArrayList<Object> subscribers;

    /**
     * registers all subscribing managed beans from faces-config.xml
     * 
     * @param subscribers
     *            ArrayList with references to managed beans
     */
    public void setSubscribers(ArrayList<Object> subscribers) {
        this.subscribers = subscribers;
        for (Object subscriber : subscribers) {
            register(subscriber);
        }
    }

    public void post(final Object event) {
        eventBus.post(event);
    }

    public void register(final Object object) {
        eventBus.register(object);
    }

    public void unregister(final Object object) {
        eventBus.unregister(object);
    }

    public final void handleException(Throwable exception,
            SubscriberExceptionContext context) {
        exception.printStackTrace();

    }

}

There is only one problem: If a bean is in a lower scope, the initialization will fail. In this case we have to do the opposite to attach a subscriber to the bus. Instead of telling the bus which subscriber we want to register, we are telling the subscriber which bus to attach to.

package ch.hasselba.xpages;

public class EventSubscriberRequestScope extends EventSubscriber {

    /**
     * registers the current instance to the event bus
     * 
     * @param eventBus
     *            the frontend event bus
     */
    public void setEventBus(FrontendEventBus eventBus) {
        eventBus.register(this);
    }

}

As soon the bean is instantiated, the managed property will have an instance of our FrontendEventBus and the bean can register itself.

The faces-config.xml looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<faces-config>

    <managed-bean>
        <managed-bean-name>frontendEventBus</managed-bean-name>
        <managed-bean-class>ch.hasselba.xpages.FrontendEventBus</managed-bean-class>
        <managed-bean-scope>session</managed-bean-scope>
        <managed-property>
            <property-name>subscribers</property-name>
            <list-entries>
                <value-class>java.lang.Object</value-class>
                <value>#{eventSubscriber}</value>
            </list-entries>
        </managed-property>
    </managed-bean>
    
    
    <managed-bean>
        <managed-bean-name>eventSubscriber</managed-bean-name>
        <managed-bean-class>ch.hasselba.xpages.EventSubscriber</managed-bean-class>
        <managed-bean-scope>session</managed-bean-scope>
    </managed-bean>
    
    
    <managed-bean>
        <managed-bean-name>eventSubscriberRequestScope</managed-bean-name>
        <managed-bean-class>ch.hasselba.xpages.EventSubscriberRequestScope</managed-bean-class>
        <managed-bean-scope>request</managed-bean-scope>
        <managed-property>
            <property-name>eventBus</property-name>
            <value>#{frontendEventBus}</value>
        </managed-property>
    </managed-bean>
    
</faces-config>

The first subscribing bean is in the same scope as the FrontendEventBus, but the second one is a request scoped bean.

Now it’s time to send an event. This can be realized by creating a new instance of our FrontendEvent we have created earlier and posting it to the bus.

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

    <xp:button
        id="button1" value="Click me">
        
        <xp:eventHandler
            event="onclick"
            submit="true"
            refreshMode="complete">
            <xp:this.action>
                <![CDATA[#{javascript:importPackage( ch.hasselba.xpages );
                    var msg = "Timestamp: " + java.lang.System.currentTimeMillis();
                    var se = new ch.hasselba.xpages.FrontendEvent( msg );
                    frontendEventBus.post( se );
                }]]>
            </xp:this.action>
        </xp:eventHandler>
    
    </xp:button>
    
    <br />
    <br />
    
    <xp:label
        value="#{eventSubscriber.message}"
        id="labelSubscriberMessage">
    </xp:label>
    
    <br />
    
    <xp:label
        value="#{eventSubscriberRequestScope.message}"
        id="labelSubscriberRequestScope">
    </xp:label>
    
</xp:view>

As soon the button is clicked, both beans are receiving the event and updating their message.

Hope someone finds it usefull.

Read full article |Kommentare deaktiviert
Tags: Java, JSF, xpages
Categories: Allgemein

XPages: SSJS, EL and Bindings

2. Juli 2015 Posted by Sven Hasselbach

Because of reasons you should already know I avoid the use of SSJS in my XPages applications, but there are still some parts which can be easy realized in SSJS, but with EL only with a lot of effort. One of this things is accessing properties of a component which has only a getter or a setter – this will not work when using a binding.

Let’s look for example at repeat control which is bound to the variable repeat. It can be easily accessed everywhere in SSJS, EL or Java, and it is much faster then searching the component in the tree. Here it is accessed in a label:

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

    <xp:label
        value="#{repeat.rowCount}"
        id="labelCount">
    </xp:label>
    
    <xp:repeat
        id="repeatDemo"
        rows="30"
        binding="#{repeat}">
        <xp:this.value><![CDATA[#{javascript:[1,2,3,4,5]}]]></xp:this.value>
    </xp:repeat>
    
</xp:view>

But this will lead into an error, because the XspDataIterator component has only a getter method for the rowCount property, not a corresponding setter.

When changing the code to a SSJS method call, it works without any problems:

    <xp:label
        value="#{javascript:repeat.getRowCount()}"
        id="labelCount">
    </xp:label>

The reason for this behaviour can be found deep down in the underlying JSF classes: The BeanInfoManager ignores all methods without a “valid” getter/setter methods pair during the inspection of a class, and doesn’t add it to the available properties for the PropertyResover. The rows property for example has a pair of those methods, that’s why this works without any problem:

<xp:label
    value="#{repeat.rows}"
    id="labelCount">
</xp:label>

Read full article |Kommentare deaktiviert
Tags: 9.0, Allgemein, domino, JSF, xpages
Categories: Allgemein

XPages: An optimized JavaScript Resource Renderer

21. Juni 2015 Posted by Sven Hasselbach

Ferry Kranenburg created a nice hack to solve the AMD loader problem with XPages and Dojo, and because of the missing ability to add a resource to the bottom of an XPage by a property, I have created a new JavaScriptRenderer which allows to control where a CSJS script will be rendered.

The renderer has multiple options:

NORMAL – handles the CSJS resource as always
ASYNC – loads the script in an asynchronous way (with an own script tag)
NOAMD – adds the no amd scripts around the resource
NORMAL_BOTTOM – adds the script at the bottom of the <body> tag
ASYNC_BOTTOM – async, but at the end of the generated HTML page
NOAMD_BOTTOM – at the end, with the surrounding no amd scripts

To use the normal mode, you don’t have to change you resource definition. If you want to use the other modes, you have to change the content type of the resource with one of the entries in the list above. This for example would add a script block to the end of the page, including the non amd script blocks around it:

<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core">
    <xp:this.resources>
        <xp:script clientSide="true" type="NOAMD_BOTTOM">
            <xp:this.contents><![CDATA[alert("Hello World!");]]></xp:this.contents>
        </xp:script>
    </xp:this.resources>
</xp:view>

Here is the code for the resource renderer:

package ch.hasselba.xpages;

import java.io.IOException;
import java.util.Iterator;
import java.util.Map;

import javax.faces.component.UIComponent;
import javax.faces.context.FacesContext;
import javax.faces.context.ResponseWriter;

import com.ibm.xsp.component.UIViewRootEx;
import com.ibm.xsp.renderkit.html_basic.ScriptResourceRenderer;
import com.ibm.xsp.resource.Resource;
import com.ibm.xsp.resource.ScriptResource;
import com.ibm.xsp.util.JSUtil;

public class OptimizedScriptResourceRenderer extends ScriptResourceRenderer {
    private static final String TYPE = "type";
    private static final String SCRIPT = "script";
    private static final String CSJSTYPE = "text/javascript";
    private boolean isBottom = false;
    
    private static enum Mode {
        NORMAL, ASYNC, NOAMD, ASYNC_BOTTOM, NOAMD_BOTTOM, NORMAL_BOTTOM
    }

    public void encodeResourceAtBottom(FacesContext fc,
            UIComponent uiComponent, Resource resource) throws IOException {
        isBottom = true;
        encodeResource(fc, uiComponent, resource);
        isBottom = false;
    }

    @Override
    public void encodeResource(FacesContext fc, UIComponent uiComponent,
            Resource resource) throws IOException {

        ScriptResource scriptResource = (ScriptResource) resource;
        ResponseWriter rw = fc.getResponseWriter();
        String type = scriptResource.getType();
        String charset = scriptResource.getCharset();
        String src = scriptResource.getSrc();

        Mode mode = Mode.NORMAL;
        try{
            mode = Mode.valueOf( type );
        }catch(Exception e){};

        if (mode == Mode.NORMAL || mode == Mode.NORMAL_BOTTOM ) {
            normalBottomJSRenderer( fc, uiComponent, scriptResource, (mode == Mode.NORMAL_BOTTOM), type );
        } else {
            if (mode == Mode.ASYNC || mode == Mode.ASYNC_BOTTOM) {
                asyncJSRenderer(fc, uiComponent, scriptResource, (mode == Mode.ASYNC_BOTTOM), rw, type,
                        charset, src );
            }else if (mode == Mode.NOAMD || mode == Mode.NOAMD_BOTTOM ) {
                noAMDJSRenderer(fc, uiComponent, scriptResource, (mode == Mode.NOAMD_BOTTOM) , rw, 
                        type, charset, src);
            }

        }

    }

    private void normalBottomJSRenderer(FacesContext fc,UIComponent uiComponent,
            ScriptResource scriptResource, final boolean addToBottom, final String type ) throws IOException {
        
        if( addToBottom && !isBottom )
            return;
        scriptResource.setType(null);
        super.encodeResource(fc, uiComponent, scriptResource);
        scriptResource.setType(type);
        
    }
    private void asyncJSRenderer(FacesContext fc,
            UIComponent uiComponent, ScriptResource scriptResource, 
             final boolean addToBottom, ResponseWriter rw, final String type, final String charset,
            final String src) throws IOException {
        
        if( addToBottom && !isBottom )
            return;
        
        Map<String, String> attrs = null;
        String key = null;
        String value = null;
        String id = "";

        if (scriptResource.getContents() == null) {
            attrs = scriptResource.getAttributes();
            if (!attrs.isEmpty()) {
                StringBuilder strBuilder = new StringBuilder(124);
                for (Iterator<String> it = attrs.keySet().iterator(); it
                        .hasNext();) {
                    key = it.next();
                    value = attrs.get(key);
                    strBuilder.append(key).append('(').append(value)
                            .append(')');
                }
                id = strBuilder.toString();
            }

            // check if already added
            UIViewRootEx view = (UIViewRootEx) fc.getViewRoot();

            String resId = "resource_" + ScriptResource.class.getName() + src
                    + '|' + type + '|' + charset + id;
            if (view.hasEncodeProperty(resId)) {
                return;
            }
            view.putEncodeProperty(resId, Boolean.TRUE);

        }
        if (!scriptResource.isClientSide()) {
            return;
        }

        rw.startElement(SCRIPT, uiComponent);
        JSUtil.writeln(rw);
        rw.write("var s = document.createElement('" + SCRIPT + "');");
        JSUtil.writeln(rw);
        rw.write("s.src = '" + src + "';");
        JSUtil.writeln(rw);
        rw.write("s.async = true;");
        JSUtil.writeln(rw);
        rw.write("document.getElementsByTagName('head')[0].appendChild(s);");
        JSUtil.writeln(rw);
        rw.endElement(SCRIPT);
        JSUtil.writeln(rw);
    }

    
    private void noAMDJSRenderer(FacesContext fc,
             UIComponent uiComponent,ScriptResource scriptResource,
            final boolean addToBottom, ResponseWriter rw, final String type, final String charset,
            final String src ) throws IOException {
        
        if( addToBottom && !isBottom )
            return;

        // write the "disable AMD" script
        rw.startElement(SCRIPT, uiComponent);
        rw.writeAttribute(TYPE, CSJSTYPE, TYPE);
        rw.writeText(
                        "'function'==typeof define&&define.amd&&'dojotoolkit.org'==define.amd.vendor&&(define._amd=define.amd,delete define.amd);",
                        null);
        rw.endElement(SCRIPT);
        JSUtil.writeln(rw);

        // write the normal CSJS
        scriptResource.setType(null);
        super.encodeResource(fc, uiComponent, scriptResource);
        scriptResource.setType(type);
        // write the "reenable AMD" script
        rw.startElement(SCRIPT, uiComponent);
        rw.writeAttribute(TYPE, CSJSTYPE, TYPE);
        rw
                .writeText(
                        "'function'==typeof define&&define._amd&&(define.amd=define._amd,delete define._amd);",
                        null);
        rw.endElement(SCRIPT);
        JSUtil.writeln(rw);

    }
}

The ViewRenderer must also be modified, otherwise it is not possible to add the resources at the bottom of the <body> tag:

package ch.hasselba.xpages;

import java.io.IOException;
import java.util.List;

import javax.faces.context.FacesContext;
import javax.faces.context.ResponseWriter;
import javax.faces.render.Renderer;

import com.ibm.xsp.component.UIViewRootEx;
import com.ibm.xsp.render.ResourceRenderer;
import com.ibm.xsp.renderkit.html_basic.ViewRootRendererEx2;
import com.ibm.xsp.resource.Resource;
import com.ibm.xsp.resource.ScriptResource;
import com.ibm.xsp.util.FacesUtil;

public class ViewRootRendererEx3 extends ViewRootRendererEx2 {

    protected void encodeHtmlEnd(UIViewRootEx uiRoot, ResponseWriter rw)
            throws IOException {
        FacesContext fc = FacesContext.getCurrentInstance();

        List<Resource> resources = uiRoot.getResources();
        for (Resource r : resources) {
            if (r instanceof ScriptResource) {
                ScriptResource scriptRes = (ScriptResource) r;
                if (scriptRes.isRendered()) {
                    Renderer renderer = FacesUtil.getRenderer(fc, scriptRes.getFamily(), scriptRes.getRendererType());
                    ResourceRenderer resRenderer = (ResourceRenderer) FacesUtil.getRendererAs(renderer, ResourceRenderer.class);
                    if( resRenderer instanceof OptimizedScriptResourceRenderer ){
                        ((OptimizedScriptResourceRenderer) resRenderer).encodeResourceAtBottom(fc, uiRoot, r);
                    }
                }
            }
        }

        rw.endElement("body");
        writeln(rw);
        rw.endElement("html");
    }

}

To activate the new renderes, you have to add them to the faces-config.xml:

<?xml version="1.0" encoding="UTF-8"?>
<faces-config>
  <render-kit>
    <renderer>
      <component-family>com.ibm.xsp.resource.Resource</component-family>
      <renderer-type>com.ibm.xsp.resource.Script</renderer-type>
      <renderer-class>ch.hasselba.xpages.OptimizedScriptResourceRenderer</renderer-class>
    </renderer>
    <renderer>
      <component-family>javax.faces.ViewRoot</component-family>
      <renderer-type>com.ibm.xsp.ViewRootEx</renderer-type>
      <renderer-class>ch.hasselba.xpages.ViewRootRendererEx3</renderer-class>
    </renderer>
  </render-kit>
</faces-config>

Needless to say that this works in Themes too.

Read full article |Kommentare deaktiviert
Tags: 9.0, Java, Java Script, JSF, xpages
Categories: Allgemein

XPages: WebContent Files (3) – Create a Minimizer Servlet

26. November 2014 Posted by Sven Hasselbach

Read full article |Kommentare deaktiviert
Tags: domino, Java, Java Script, JSF, web, xpages, XSP
Categories: Allgemein

XPages: Execute Events with HTTP Get

30. September 2014 Posted by Sven Hasselbach

To execute an event on the server, you normally have to send a POST request, because actions will be executed in the Invoke Application phase of the JSF lifecycle. A GET request will only process the Restore View and the Render Response phase, that why you can not execute an event with a GET request.

But with the help of a PhaseListener, the execution can be done earlier in the Restore View phase:

package ch.hasselba.xpages.util;

import javax.faces.event.PhaseEvent;
import javax.faces.event.PhaseId;
import javax.faces.event.PhaseListener;
import com.ibm.xsp.component.xp.XspEventHandler;
import javax.faces.context.ExternalContext;
import javax.faces.context.FacesContext;
import com.ibm.xsp.util.FacesUtil;

public class ExecuteOnServerPhaseListener implements PhaseListener {

    private static final long serialVersionUID = 1L;

    public void beforePhase(PhaseEvent event) {}

    public PhaseId getPhaseId() {
        return PhaseId.RESTORE_VIEW;
    }

    public void afterPhase(PhaseEvent event) {
        
        FacesContextExImpl = FacesContextExImpl.getCurrentInstance();
        ExternalContext ec = fc.getExternalContext();
        String url = ec.getRequestPathInfo();
        String[] pathes = url.split( "/" );
        
        try{
            if( pathes.length > 2 ){
                if( "executeOnServer".equals( pathes[pathes.length -2 ] ) ){
                    String[] fullId = pathes[ pathes.length - 1 ].split(":");
                    String actionId = fullId[ fullId.length - 1 ];
                    XspEventHandler eventHandler = (XspEventHandler)
                        FacesUtil.findComponentWithFullId( fc.getViewRoot(), actionId );
                    if( eventHandler != null ){
                        eventHandler.getAction().invoke( fc, null );
                        fc.responseComplete();
                    }
                }
            }
        }catch(Exception e){
            e.printStackTrace();
        }
        
    }

}

To activate the PhaseListener, it has to be enabled in the faces-config.xml:

<?xml version="1.0" encoding="UTF-8"?>
<faces-config>
   <lifecycle>
      <phase-listener>ch.hasselba.xpages.util.ExecuteOnServerPhaseListener</phase-listener>
   </lifecycle>
</faces-config>

The following Javascript snippet extends the XSP object and adds the new function executeOnServerGet to it. The parameter is the if of the event to invoke.

XSP.executeOnServerGet = function( eventId ){
    var viewId = dojo.query('[name="$$viewid"]')[0].value;
    var url = document.forms[0].action;
    url += "/executeOnServer/" + eventId;
    url += "?$$viewid=" + viewId;
    url += "&$$ajaxid=@none";
    dojo.xhrGet({url: url});
}

When calling the function, it sends a GET request and adds the current view id to the request. With the parameter $$ajaxId set to @none, the XPages Engine is forced to send no HTML code back to the client.

And here is an example XPage:

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

    <xp:eventHandler id="helloworld" event="helloworld" submit="false">
        <xp:this.action>
            <![CDATA[#{javascript:
               print("hello world " + java.lang.System.currentTimeMillis() );
            }]]>
        </xp:this.action>
    </xp:eventHandler>


    <xp:scriptBlock id="scriptBlock1">
        <xp:this.value><![CDATA[
            dojo.addOnLoad( function(){
                XSP.executeOnServerGet = function( eventId ){
                      var viewId = dojo.query('[name="$$viewid"]')[0].value;
                    var url = document.forms[0].action;
                    url += "/executeOnServer/" + eventId;
                    url += "?$$viewid=" + viewId;
                    url += "&$$ajaxid=@none";
                    dojo.xhrGet({url: url});
                  }
            });
        ]]></xp:this.value>
    </xp:scriptBlock>
    
    <xp:button value="Execute" id="button1">
        <xp:eventHandler event="onclick" submit="false">
            <xp:this.script>
                <![CDATA[XSP.executeOnServerGet( "#{id:helloworld}" );]]>
            </xp:this.script>
        </xp:eventHandler>
    </xp:button>
</xp:view>

When clicking the button, the following URL is opened in the background:

http://example.com/db.nsf/EventGet.xsp/executeOnServer/view:_id1:helloworld?$$viewid=!dwjldz64w0!&$$ajaxid=@none

A GET request was sent to the server:If you look on the server console, you will see that the Action was invoked:

Read full article |Kommentare deaktiviert
Tags: 8.5.3, 9.0, Dojo Toolkit, domino, HTTP, Java, Java Script, JSF, Performance, xpages, XSP
Categories: Allgemein

XPages: Set a Theme for a single XPage

14. März 2014 Posted by Sven Hasselbach

… or how you can use your own FacesContext implementation.

What we need first is our own FacesContext implementation with new methods to set the StlyeKitId (which is the name of the Theme) for initializing the StyleKit instance:

package ch.hasselba.xpages;

import javax.faces.context.FacesContext;
import com.ibm.xsp.application.ApplicationExImpl;
import com.ibm.xsp.context.FacesContextExImpl;
import com.ibm.xsp.stylekit.StyleKit;

/**
 * ThemeSwitcherFacesContext
 * allows to switch the theme during runtime
 * 
 * @author Sven Hasselbach
 * @version 0.1
 */
public class ThemeSwitcherFacesContext extends FacesContextExImpl {

    private StyleKit styleKit;
    private String styleKitId;
    private FacesContext delegated;
    /**
     * constructor
     * 
     * @param fc
     *     delegated javax.faces.context.FacesContext
     */
    public ThemeSwitcherFacesContext(FacesContext fc) {
        super(fc);
        this.delegated = fc;
    }

    /**
     * returns current StyleKit
     * 
     * @return com.ibm.xsp.stylekit.StyleKit
     *      the StyleKit used for rendering the view
     */
    public StyleKit getStyleKit() {
        if (this.styleKit == null) {
            this.styleKit = super.getStyleKit();
        }
        return this.styleKit;
    }

    /**
     * sets the StyleKit
     * 
     * @param stlyeKit
     *     the com.ibm.xsp.stylekit.StyleKit to use 
     */
    public void setStyleKit(final StyleKit styleKit) {
        this.styleKit = styleKit;
    }

    /**
     * returns the current StyleKitId (aka Theme name)
     * 
     * @return String
     *     the id of the StyleKit
     */
    @Override
    public String getStyleKitId() {
        if (this.styleKitId == null) {
            this.styleKitId = super.getStyleKitId();
        }
        return styleKitId;
    }

    /**
     * sets the StyleKitId
     * 
     * @param styleKitId
     *     the id of the StyleKit
     */
    public void setStyleKitId(final String styleKitId) {
        this.styleKitId = styleKitId;
    }

    /**
     * initializes the StyleKit for the current view
     */
    public void loadStyleKit() {
        this.styleKit = ((ApplicationExImpl) getApplication())
                .getStyleKit(this.styleKitId);
    }
}

But you cannot register the FacesContext implementation directly. That’s why we have to build our own FacesContextFactory to inject our FacesContext instance this:

package ch.hasselba.xpages;

import javax.faces.FacesException;
import javax.faces.context.FacesContext;
import javax.faces.context.FacesContextFactory;
import javax.faces.lifecycle.Lifecycle;
import com.ibm.xsp.FacesExceptionEx;
import com.ibm.xsp.context.FacesContextFactoryImpl;

/**
 * ThemeSwitcherFacesContextFactory
 * 
 * @author Sven Hasselbach
 * @version 0.1
 */
public class ThemeSwitcherFacesContextFactory extends FacesContextFactory {

    private FacesContextFactory delegate;

    @SuppressWarnings("unchecked")
    public ThemeSwitcherFacesContextFactory(){
        try{
            Class clazz = Class.forName( "com.sun.faces.context.FacesContextFactoryImpl" );
            this.delegate = (FacesContextFactory) clazz.newInstance();
        }
        catch (Exception e){
          throw new FacesExceptionEx(e);
        }
    }

    public ThemeSwitcherFacesContextFactory(FacesContextFactory fcFactory){
        this.delegate = fcFactory;
        if ((this.delegate instanceof FacesContextFactoryImpl)) {
            this.delegate = ((FacesContextFactoryImpl)this.delegate).getDelegate();
        }
    }

    public FacesContext getFacesContext(Object param1, Object param2, 
        Object param3, Lifecycle paramLC) throws FacesException {
        FacesContext fc = this.delegate.getFacesContext(param1, param2, param3, paramLC);
        return new ThemeSwitcherFacesContext(fc);
    }
}

Now, you have to add the FacesContextFactory to the faces-config.xml to activate it:

<?xml version="1.0" encoding="UTF-8"?>
<faces-config>
  <factory>
    <faces-context-factory>
        ch.hasselba.xpages.ThemeSwitcherFacesContextFactory
    </faces-context-factory>
  </factory>
</faces-config>

If you open the XPage, an error will occur:

This happens because there are some java security restrictions with the class loader of the delegated classes. You have to modify the java security in the java.policy file (you can limit the the grant to specific database if you want).

grant {
    permission java.security.AllPermission;
};

Then you can add a Theme to your XPage, f.e. this one:

<theme
    extends="webstandard" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xsi:noNamespaceSchemaLocation="platform:/plugin/com.ibm.designer.domino.stylekits/schema/stylekit.xsd" >
    <control>
        <name>ViewRoot</name>
        <property>
            <name>style</name>
            <value>background-color:rgb(255,255,0)</value>
        </property>
    </control>
</theme>

To use the ThemeSwitcher, you have to add some code in the beforePageLoad event:

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

    <xp:this.beforePageLoad>
        <![CDATA[#{javascript:
            importPackage( ch.hasselba.xpages );
            var fc:ch.hasselba.xpages.ThemeSwitcherFacesContext = facesContext;
            fc.setStyleKitId( "ThemeA");
            fc.loadStyleKit();}
        ]]>
    </xp:this.beforePageLoad>

    Switched Theme

</xp:view>

When the XPage is opened in the browser, the Theme is changed:

All other pages in the NSF are stil using the default Theme:

Read full article |Kommentare deaktiviert
Tags: 9.0, domino, Java, JSF, web, xpages
Categories: Allgemein

XPages: Add an attribute to the BODY-Element

9. März 2014 Posted by Sven Hasselbach

Today I wanted to add an attribute to the <BODY> element of my XPage. My goal was to generate HTML code like this:

<body role="document">

After some testing I found a solution by overwriting the method encodeHtmlBodyStart. To do this, you have to extend the class ViewRootRendererEx2:

package ch.hasselba.xpages;

import java.io.IOException;
import javax.faces.context.FacesContext;
import javax.faces.context.ResponseWriter;
import com.ibm.xsp.component.UIViewRootEx;
import com.ibm.xsp.renderkit.html_basic.ViewRootRendererEx2;

public class MyViewRootRenderer extends ViewRootRendererEx2 {

    @Override
    protected void encodeHtmlBodyStart(FacesContext fc, UIViewRootEx uiRoot,
            ResponseWriter writer) throws IOException {

        writer.startElement("body", uiRoot);
        writer.writeAttribute("role", "document", "role");
        writeln(writer);
    }

}

To activate it you have to change the renderer class in the faces-config.xml:

<faces-config>  
  <render-kit>
    <renderer>
      <component-family>javax.faces.ViewRoot</component-family>
      <renderer-type>com.ibm.xsp.ViewRootEx</renderer-type>
      <renderer-class>ch.hasselba.xpages.MyViewRootRenderer</renderer-class>
    </renderer>
  </render-kit>
</faces-config>

Now, the attribute is added correctly to my HTML code:

Read full article |Kommentare deaktiviert
Tags: 9.0, domino, HTML, Java, JSF, xpages
Categories: Allgemein

XPages: Use a Method Binding as Converter

8. März 2014 Posted by Sven Hasselbach

I accidentally found a way to add a method binding as a converter to a component, because I have added a managed bean as a converter directly in the source code. The DDE does not support this.

If you go to the converter property of a component, you can only add one of the predefined converters:

But you can go to the source and add a method binding to the option, in this case my bean which implements my converter functionality.

<xp:inputText
    id="inputText1"
    value="#{sessionScope.inputText1}"
    converter="#{myConverterBean}" />

If you now reopen the saved XPage, the converter property is filled in, but cannot edited / changed anymore.

You must remove the property in the source code to get the old behaviour back.

Tested in 8.5.2, 8.5.3 & ND 9

Read full article |Kommentare deaktiviert
Tags: 8.5.2, 8.5.3, 9.0, Designer, domino, Expression Language, Java, JSF, xpages
Categories: Allgemein

XPages: Optimized Partial Refreshs (2)

7. März 2014 Posted by Sven Hasselbach

With the Optimized Partial Refresh you can do a lot of nice things: If only a part of the form is sent to the server, only this part of the components in the JSF component tree will be processed. This means that only submitted values are applied, coverted and validated, which can result in less server usage and a better performance.

Normally, if you have two required fields on you XPage and do a Partial Refresh, both fields will have a validation error:

But with this technique, you can choose which component should be refreshed. When clicking of Button Refresh 1, only the first field is marked as a required field:

When filling in the first field, but clicking on Refresh 2…

… the value of the first field gets lost, because it was not sent to the server (if a value was already stored there, it won’t get lost). And the second field is marked as required:

This is the example XPage, the CSJS code is moved to the Custom Control ccOptimizedPR.

<?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">

    <xc:ccOptimizedPR />

    <xp:div id="refreshMe">
        <xp:messages id="messagesError" />
        <xp:inputText
            id="inputText1"
            value="#{sessionScope.inputText1}">
            <xp:this.validators>
                <xp:validateRequired message="Field 1 is empty!" />
            </xp:this.validators>
        </xp:inputText>
        <xp:inputText
            id="inputText2"
            value="#{sessionScope.inputText2}">
            <xp:this.validators>
                <xp:validateRequired message="Field 2 is empty!" />
            </xp:this.validators>
        </xp:inputText>
    </xp:div>

    <xp:button
        value="Normal Refresh"
        id="buttonNormal">
        <xp:eventHandler
            event="onclick"
            submit="true"
            refreshMode="partial"
            refreshId="refreshMe">
        </xp:eventHandler>
    </xp:button>

    <xp:button
        value="Refresh 1"
        id="buttonCleaned1">
        <xp:eventHandler
            event="onclick"
            submit="false">
            <xp:this.script>
                <![CDATA[
                    XSP.partialRefreshPost(
                        '#{id:refreshMe}',{
                            clearForm: true,
                            additionalFields: ['#{id:inputText1}' ]
                        }
                    );]]>
            </xp:this.script>
        </xp:eventHandler>
    </xp:button>
    <xp:button
        value="Refresh 2"
        id="buttonCleaned2">
        <xp:eventHandler
            event="onclick"
            submit="false">
            <xp:this.script>
                <![CDATA[
                    XSP.partialRefreshPost(
                        '#{id:refreshMe}',{
                            clearForm: true,
                            additionalFields: ['#{id:inputText2}' ]
                        }
                    );]]>
            </xp:this.script>
        </xp:eventHandler>
    </xp:button>

</xp:view>

Read full article |Kommentare deaktiviert
Tags: 9.0, Dojo Toolkit, domino, Java, Java Script, JSF, Partial Refresh, Performance, Server, xpages, XSP
Categories: Allgemein

XPages: Events, ActionListeners & Parameters

2. März 2014 Posted by Sven Hasselbach

To access the event parameters of an event within your actionListener, you have to access the source object of your actionEvent object:

package ch.hasselba.xpages;

import java.util.List;
import javax.faces.event.AbortProcessingException;
import javax.faces.event.ActionEvent;
import com.ibm.xsp.complex.Parameter;
import com.ibm.xsp.component.xp.XspEventHandler;

public class MyActionListener implements javax.faces.event.ActionListener {

    public void processAction(ActionEvent event)
            throws AbortProcessingException {
        XspEventHandler eventHandler = (XspEventHandler) event.getSource();
        List<Parameter> params = eventHandler.getParameters();
        for (Parameter p : params) {
            System.out.println(p.getName() + " -> " + p.getValue());
        }
    }
}

Here is an example XPage:

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

    <xp:button
        value="Label"
            id="buttonAction">
        <xp:eventHandler
            event="onclick"
            submit="true"
            immediate="true" refreshMode="norefresh">
            <xp:this.parameters>
                <xp:parameter
                    name="param"
                    value="#{javascript:java.lang.System.currentTimeMillis()}">
                </xp:parameter>
            </xp:this.parameters>

                <xp:this.actionListeners>
                    <xp:actionListener type="ch.hasselba.xpages.MyActionListener" />
                </xp:this.actionListeners>
            </xp:eventHandler>

    </xp:button>

</xp:view>

You can see the result on the console when the button is clicked:

When doing the same for an action, you have to access the UIComponent from the actionEvent:

package ch.hasselba.xpages;
import java.util.List;
import javax.faces.event.ActionEvent;
import com.ibm.xsp.complex.Parameter;
import com.ibm.xsp.component.xp.XspEventHandler;

public class MyActionListener {
public void execute(ActionEvent event) {
        XspEventHandler eventHandler = (XspEventHandler) event.getComponent();
        List<Parameter> params = eventHandler.getParameters();
        for (Parameter p : params) {
            System.out.println(p.getName() + " -> " + p.getValue());
        }
     }
}

Here is an example XPage, the method execute is contained by the managed bean myAction:

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

    <xp:button
        value="Label"
            id="buttonAction">
        <xp:eventHandler
            event="onclick"
            submit="true"
            immediate="true"
            refreshMode="complete"
            actionListener="#{myAction.execute}">
            <xp:this.parameters>
                <xp:parameter
                    name="param"
                    value="#{javascript:java.lang.System.currentTimeMillis()}">
                </xp:parameter>
            </xp:this.parameters>
        
        </xp:eventHandler>
            
    </xp:button>
    
</xp:view>

Read full article |Kommentare deaktiviert
Tags: 8.5.3, 9.0, domino, Java, JSF, xpages
Categories: Allgemein

Quick-n-Dirty: Disable Validation for FileDownload control (2)

19. Februar 2014 Posted by Sven Hasselbach

Because my old snippet does not work anymore for ND9 (the IBM changed the internal methods / objects) I had to create a new way to disable the validation of the FileDownload control. Now I have switched to a PhaseListener which waits for to any XspEventHandler and checks if this event handler is a child of the FileDownload control. If so, it skips the validation.

Here is the code for the PhaseListener:

package ch.hasselba.xpages;

import java.util.Iterator;
import java.util.Map;

import javax.faces.component.UIComponent;
import javax.faces.context.FacesContext;
import javax.faces.event.PhaseEvent;
import javax.faces.event.PhaseId;
import javax.faces.event.PhaseListener;

import com.ibm.xsp.component.UIViewRootEx;
import com.ibm.xsp.component.xp.XspEventHandler;
import com.ibm.xsp.component.xp.XspFileDownload;
import com.ibm.xsp.context.FacesContextExImpl;
import com.ibm.xsp.util.FacesUtil;

public class FileDownloadPhaseListener implements PhaseListener {

    /**
     * FileDownloadPhaseListener
     * 
     * by Sven Hasselbach, 19.12.2014
     */
    private static final long serialVersionUID = 1L;

    public void afterPhase(PhaseEvent arg0) {}

    public void beforePhase(PhaseEvent arg0) {
        try{
            FacesContextExImpl fc = (FacesContextExImpl) FacesContext.getCurrentInstance();

            // get client id
            String clientId = FacesUtil.getHiddenFieldValue(fc); 

            // extract last id 
            String[] ids = clientId.split(":");
            String id = ids[ ids.length  - 1 ];

            boolean found = false;

            // search for the component
            UIViewRootEx uiRoot = (UIViewRootEx) fc.getViewRoot();
            UIComponent cmp = FacesUtil.getComponentFor(uiRoot,  id );

            if( cmp instanceof XspEventHandler ){

                while( cmp != null || found == false ){

                    // found the download control?
                    if( cmp instanceof XspFileDownload ){
                        // disable validation & quit the process
                        fc.setDisableValidators( true );
                        found = true;
                    }
                    // climb up the component tree    
                    cmp = cmp.getParent();
                }
            }

        }catch(Exception e){}
    }

    public PhaseId getPhaseId() {
        return PhaseId.PROCESS_VALIDATIONS;
    }
}

When using it on a XPage…

… you can now delete a File …

… but cannot submit a form with the required field:

This is the required faces-config.xml:

<?xml version="1.0" encoding="UTF-8"?>
<faces-config>
  <lifecycle>
    <phase-listener>ch.hasselba.xpages.FileDownloadPhaseListener</phase-listener>
  </lifecycle>
</faces-config>

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

Read full article |Kommentare deaktiviert
Tags: 9.0, domino, Java, JSF, xpages
Categories: Allgemein

XPages: Use a PhaseListener for global URL commands

11. Juli 2013 Posted by Sven Hasselbach

One of my customers wanted an easy way for printing XPages in different formats and with different content, depending of the current XPage opened in the browser. It was a requirement to develope a global solution for every XPage-based application in his company. That is why I created a global Java class which does not require to modify the existing applications at all. But it allows to customize and configure the output for the different needs of the departments and their required reports and print outs.

I decided to use a special PhaseListener to hook into the different applications. This allows the PDF generation depending on some URL parameters, and only runs if the URI contains a special command for printing the current XPage (but works for thw whole application).

The example code is what I have created:

package ch.hasselba.xpages.util;

import java.util.Map;
import javax.faces.context.FacesContext;
import javax.faces.event.PhaseEvent;
import javax.faces.event.PhaseId;
import javax.faces.event.PhaseListener;
import javax.servlet.ServletOutputStream;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class PhaseListenerPDFGenerator implements PhaseListener {

    private static final long serialVersionUID = 1L;
    private static final String GENERATE_PDF = ".PDF";
    private static final String URL_PARAMETER_FILENAME = "filename";
    private static final String URL_PARAMETER_PDFTYPE = "type";
    private static final String HTTP_HEADER_CONTENTTYPE = "application/pdf";

    public void beforePhase(PhaseEvent event) {}

    public PhaseId getPhaseId() {
        return PhaseId.RESTORE_VIEW;
    }

    public void afterPhase(PhaseEvent event) {

        FacesContext facesContext = event.getFacesContext();

        HttpServletRequest req = (HttpServletRequest) facesContext
                .getExternalContext().getRequest();
        String uri = req.getRequestURI();

        if (uri.endsWith(GENERATE_PDF) == true ) {
            servePDF(facesContext);
        }
    }

    private void servePDF(FacesContext facesContext) {
        Map requestMap = facesContext.getExternalContext()
                .getRequestParameterMap();

        String pdfName = getPDFName(requestMap);
        String pdfType = getPDFType(requestMap);

        HttpServletResponse response = (HttpServletResponse) facesContext
                .getExternalContext().getResponse();

        try {

            response.setContentType( HTTP_HEADER_CONTENTTYPE );
            response.setHeader( "Content-Disposition", "attachment; filename="
                      + pdfName );
            response.setStatus(200);
            ServletOutputStream outputStream = response.getOutputStream();

            // Generate the PDF here
            // and send the data to the outputStream
            //
            //outputStream.write( PDFDATA );
            outputStream.flush();
            outputStream.close();
            facesContext.responseComplete();

        } catch (Exception exception) {
            exception.printStackTrace();
        }
    }

    public static String getPDFName(Map requestMap) {
        String pdfName = (String) requestMap.get( URL_PARAMETER_FILENAME );
        return pdfName;
    }
    public static String getPDFType(Map requestMap) {
        String pdfName = (String) requestMap.get( URL_PARAMETER_PDFTYPE );
        return pdfName;
    }

}

The PhaseListener scans the URI every time a request is sent to the server. As soon the URI ends with .PDF, the parameters fileName and type are extracted. The correct PDF template is identified and the requested PDF can be generated (Code for generating is not included in this example).

After generating the PDF, the output is written, and the response is completed. The file download headers are added to the response. The user receives a file download dialog and can open the generated PDF (and print it if required).

When this PhaseListener is enabled in the faces-config.xml, every XPage can use the URL command. For example if your XPage is named “MyXPage.xsp” the URL to enable the PDF generation instead the generation of the XPage looks like this:

http://example.com/path/to/db.nsf/MyXPage.xsp/.PDF?filename=test.pdf&type=exportAll

This returns a PDF with the filename test.pdf which is generated from the PDF template exportAll, containing the data of the current XPage. It is easy to add a link like this to your application to enable the PDF generation.

This is how the faces-config.xml has to look like:

<?xml version="1.0" encoding="UTF-8"?>
<faces-config>
  <lifecycle>
      <phase-listener>ch.hasselba.xpages.util.PhaseListenerPDFGenerator</phase-listener>
  </lifecycle>
</faces-config>

Read full article |Kommentare deaktiviert
Tags: 8.5.2, 8.5.3, 9.0, domino, HTTP, infrastruktur, Java, JSF, tipp, web, xpages
Categories: Allgemein

XPages: Create your own Required Validators

20. Juni 2013 Posted by Sven Hasselbach

If you try to implement your own JSF Validator (by implementing javax.faces.validator.Validator), you will notice that you are unable to check for an empty value. The reason for this is rather simple: The method validate() is only called, if there is something to do. If the value is empty, there is nothing to do, that’s why nothing happens.

But wait! What about the available required validator for XPages?

<xp:inputText id="inputText1">
   <xp:this.validators>
      <xp:validateRequired></xp:validateRequired>
   </xp:this.validators>
</xp:inputText>

And yes, this is a validator, but the IBM implemented a workaround for their UIComponents: If the UIComponents required property is set to true, the UIComponent knows that she needs to be filled in. Or a validator has to be attached to the UIComponent which implements the com.ibm.xsp.validator.FacesRequiredValidator interface.

Here is an example:

package ch.hasselba.xpages.core;

import javax.faces.component.UIComponent;
import javax.faces.context.FacesContext;
import javax.faces.validator.ValidatorException;
import com.ibm.xsp.validator.FacesRequiredValidator;

public class RequiredValidator implements FacesRequiredValidator {

    public String getRequiredMessage() {
        return "Error! Required field is empty!";
    }

    public void validate(FacesContext facesContext, UIComponent uiComponent,
            Object obj) throws ValidatorException {

    }

}

When processing the UIComponent data, the attached validators are checked if they are an instance of FacesRequiredValidator, and this is the reason why you cannot attach this validator to a component in the DDE directly: Because if you define the validator in the faces-config.xml and add it to the UIComponent with the validator id…

<xp:inputText id="inputText1">
   <xp:this.validators>
      <xp:validator validatorId="myValidator" />
   </xp:this.validators>
</xp:inputText>

… the XPages engine attaches a validator which is not implementing the FacesRequiredValidator interface. Instead, an instance of com.ibm.xsp.validator.ValidatorImpl is attached.

You have to do this by your own, for example in the beforeRenderResponse event:


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

   <xp:this.beforeRenderResponse>
      <![CDATA[#{javascript:getComponent('inputText1').addValidator(
         new ch.hasselba.xpages.core.RequiredValidator()
      );}]]>
   </xp:this.beforeRenderResponse>

   <xp:button
      value="Label"
      id="button1">
      <xp:eventHandler event="onclick" submit="true"
         refreshMode="complete" immediate="false" save="true" />
   </xp:button>

   <xp:br />

   <xp:messages id="messages1"></xp:messages>

   <xp:br />

   <xp:inputText id="inputText1" />

</xp:view>

[This example is just for a demonstration. It contains a bug, the validator will attached over and over again, so you have to check if the validator is already attached or not]

If you now open the XPage, your validator will work as expected:

Read full article |Kommentare deaktiviert
Tags: 9.0, Designer, domino, Java, JSF, ServerSide JavaScript, xpages
Categories: Allgemein

In Ya Facet!

20. Februar 2013 Posted by Sven Hasselbach

Using Facets in XPages is very nice, because it gives you an easy way for a global design of your application (and much more). It can be used in all XPages and their custom controls. The xp:callback element defines a section, and this section can be filled in by the parent component with the xp:key attribute.

Take a look at this custom control:

<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core" style="margin: 16px;">
   <xp:text escape="true" id="computedFieldTitle"
        value="#{javascript:compositeData.title}" tagName="h1" />
   <xp:callback facetName="TabAreaCallback" id="callbackTabArea"
        xp:key="TabAreaCallback" />
</xp:view>

It has a single callback area (I will never understand why it is called “Editable Area” in the DDE), and a xp:text which is filled in with the value of the property title of the custom control.

This CustomControl (ccFacet) can now be used in another custom control (ccMain) by using the xp:key attribute:

<?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">

    <xc:ccFacet title="Hello World!" >
        <xp:this.facets>
            <xp:div xp:key="TabAreaCallback">
                <p>Hello World!</p>
            </xp:div>
        </xp:this.facets>        
    </xc:ccFacet>

</xp:view>

The <xp:div> element calls the facet of the embedded custom control back (with the xp:key as the phone number), and the content of the calling component will be inserted in the defined placeholder. Added to a XPage the result looks like this:

If you change now the design in the ccFacet, the design will be changed on every XPage automatically. Or you can add new buttons, footers, etc. which will be automatically used in all other XPages which are using the custom control.

OK? OK!

But what will happen if we are using the compositeData object?

Let’s add the property “foo” to the ccMain custom control:

<?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">

    <xc:ccFacet title="Hello World!" >
        <xp:this.facets>
            <xp:div xp:key="TabAreaCallback">
                <p>Hello World!</p>
                <xp:text escape="true" id="computedFieldFoo"
                                        value="#{compositeData.foo}" />
            </xp:div>
        </xp:this.facets>        
    </xc:ccFacet>

</xp:view>

The custom control definition in the XPage is changed to this…

<xc:ccMain foo="bar"></xc:ccMain>

… but in the browser you will see nothing:

If you remove the ccFacet definition from ccMain, you will see that the compositeData works as expected:

<?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">

<!--    <xc:ccFacet title="Hello World!" >-->
<!--        <xp:this.facets>-->
            <xp:div xp:key="TabAreaCallback">
                <p>Hello World!</p>
                <xp:text escape="true" id="computedFieldFoo"
                                       value="#{compositeData.foo}" />
            </xp:div>
<!--        </xp:this.facets>-->        
<!--    </xc:ccFacet>-->

</xp:view>

What happened to the compositeData object? Is it broken? No, it is still working correctly and refers to the compositeData of the current custom control – but the custom control is no longer the same. It was moved to another node in the component tree, and that’s why the compositeData cannot be found anymore (see here for some details).

If you print the client id of the component and the variable in the beforePageLoad event to the console, you will see the id of the custom control before it is moved:

But if you take a look in the generated source of the XPage, you will see that the client ids of the elements have been moved a node deeper in the tree:

<span id="view:_id1:_id2:_id3:callbackTabArea:computedField1" class="xspTextComputedField"></span>

If you want to use the data from the compositeData object, you have to add all the properties to the ccFacet too (and create the property in the custom control):

<xc:ccFacet title="Hello World!" foo="#{compositeData.foo}">

That’s a really annoying and reduces the usability of compositeData – but it seems to be the only usable workaround for this problem.

Read full article |Kommentare deaktiviert
Tags: 8.5.3, Allgemein, domino, JSF, xpages
Categories: Allgemein

PlanetNTF

Aggregator für deutschsprachige Blogs zum Thema HCL Collaboration Solutions

Powered by hedersoft