Xpage extlib Dialog keepComponents true and JSF component -

i have problem dialog control extention library:

i have created java custom control wich searches views, collects data , displays it. works nice if place on xpage.

but want display data in dialog used dialog control extention library. using dialog control without configuration works fine takes time control search views , display data every time open dialog.so reduce waiting time user wanted use option "keepcomponents="true" dialog control.

now if open dialog first time perfekt if open secound time displays content first opening in addition error controlrenderer wich tells me not viewname control. error stacks every time open , close dialog.

i found post on openntf had same issue multiple content in dialog when using option didnt answers question. bug of component? should forget option , cache data in bean? why can't renderer viewname component?

the answer follows assumes phrase "java custom control" in question refers jsf component developed; in xpages, term "custom control" refers instance of custom control design element, ibm's implementation of jsf notion of "composite components".

you've stated component behaves intended fails on subsequent requests. typically indicates restorestate , savestate methods of component have not been implemented.

when default serialization options enabled application, component state written disk @ end of each request, , read memory @ beginning of next. these 2 operations handled, respectively, savestate , restorestate methods of each component.

for example, suppose defined component adding html canvas tags xpage, , decided support gesture , touch events associated element. component class contain fields store code bound events:

private string ongesturechange; private string ongestureend; private string ongesturestart; private string ontouchcancel; private string ontouchend; private string ontouchmove; private string ontouchstart; 

each of fields typically have associated "getter" , "setter" method:

public string getongesturechange() {     return getstringproperty("ongesturechange", this.ongesturechange); }  public void setongesturechange(string ongesturechange) {     this.ongesturechange = ongesturechange; } 

when instance of component initialized, "setter" method associated each attribute defined component instance passed value defined attribute. remainder of initial page request, then, private field each defined attribute store value set. @ end of request, savestate method writes values of these fields disk. typical savestate method looks similar following:

@override public object savestate(facescontext context) {     object[] properties = new object[8];     int idx = 0;     properties[idx++] = super.savestate(context);     properties[idx++] = this.ongesturechange;     properties[idx++] = this.ongestureend;     properties[idx++] = this.ongesturestart;     properties[idx++] = this.ontouchcancel;     properties[idx++] = this.ontouchend;     properties[idx++] = this.ontouchmove;     properties[idx++] = this.ontouchstart;     return properties; } 

the call super.savestate() executes same method, using version of method defined in parent class. on-disk representation of each component nested array: each layer in hierarchy stores properties inherits parent class in first element of array, stores properties defines in additional array elements.

when component tree restored on subsequent requests, each component uses restorestate method reconstitute values of fields. typical restorestate method looks similar following:

@override public void restorestate(facescontext context, object state) {     object[] properties = (object[]) state;     int idx = 0;     super.restorestate(context, properties[idx++]);     this.ongesturechange = ((string) properties[idx++]);     this.ongestureend = ((string) properties[idx++]);     this.ongesturestart = ((string) properties[idx++]);     this.ontouchcancel = ((string) properties[idx++]);     this.ontouchend = ((string) properties[idx++]);     this.ontouchmove = ((string) properties[idx++]);     this.ontouchstart = ((string) properties[idx++]); } 

this hierarchically reads on-disk data in: each class passes set of properties parent class, assigns remaining array elements fields associated when component state saved.

this process provides easy way maintain component state across requests -- each layer of inheritance need concern new properties layer defines -- these state maintenance methods easy forget implement. if either method omitted component implementation, page "forgets" property values on subsequent requests, because either never written disk, or not loaded memory, or both.

assuming root cause of problem, reason problem not occur when component inside dialog default (false) value keepcomponents because default dialog behavior remove children component tree entirely when dialog closed. behavior performance reasons: there's theoretically no benefit gained storing server-side representation of components exist inside dialog user not interacting with. when dialog opened again, new instance of each child component created using original property values. in scenario, wouldn't matter component isn't saving state, because each time it's used, new instance created. if dialog told keep children in component tree, component must maintain own state... otherwise property values discarded @ end of each request , subsequent requests unaware of previous values.

in summary, yes, data you're displaying should cached in bean (or data source) if data unlikely change enough between requests justify obtaining data again during every single event. reason specific behavior you're describing because component implementation not maintaining own state.