I posted an old question, but it was not well explained. Hopefully someone can help me this time
Subject of this post is copied from the first comment of this post
Follow up here
As I understand, his solution in the follow up is to cache the notesviewentry with java object, or else caching a notes resource directly in scopevariable will suffer from the same problem as here
or being explained in more detail under comment 4 in this post
but the problem is.....Xpages runtime wrapper is supposed to substitute java bean as data transfer object.....binding notes resource to java bean in this case feels just not right....
As binding a viewEntryCollection to a repeat control, without being wrapped.
<xp:repeat id="repeat1" rows="30" indexVar="rowIndex" var="row">
Entry that "row" refers to is lotus.domino.local.viewentry, instead of being com.ibm.xsp.model.domino.wrapped.DominoViewEntry
so back to the question........... How to write a wrapper that can handle request-safe retrieval of the underlying Notes object........so "row" will be wrapped with com.ibm.xsp.model.domino.wrapped.DominoViewEntry when
com.ibm.xsp.model.domino.DominoViewEntryCollectionDataModel is binded to com.ibm.xsp.component.xp.XspDataIterator
A little bit add on.....I tried dataContext from http://www.mydominolab.com/2011/03/xpages-difference-between-xpthisdata.html
but it seems that code (compute dynamically, not at load,returning documentcollection or a vector of documents in datacontext is allright, but not notesviewentrycollection )within dataContext runs in every lifecycle phrase, even slower then directly binding a viewentryCollection to repeatcontroll, ( it runs on apply_request_value and render_response)
and row within the repeat controll, which is binded to the dataContext, is just an instance of notesDocument
we have been binding notes resource directly to UIComponent without problem, is this datacontext something new that can solve my original problem? If not, please lead me to the right direction.