I have a number of individually named Hashtables residing in the ApplicationScope space. I'm struggling with the Hashtable's GET(String) method when used in a different Class elsewhere in my app.
My syntax is yelling --> "The method get(String) is undefined for the type FooterLinkBean".
My JAVA code containing this error is --> packedString = gr_footerlink.get(searchKey); where the 'searchKey' is my 'Key' value that I'm attempting to query against my Hashtables named 'Gr_footerlink.get'.
I'm trying to retrieve the value (which is a pipe-delimited string of text values) that I'll later split into their individual components. Both my Hashtables 'Gr_footerlink.get' structure is built in the ApplicationScope space while my method I'm using to call it resides in a SessionScope Managed bean.
I can successfully query the Hashtable immediately after it is built and populated by virtue of writing debug messages into Greg's Xpages Debug Toolbar. However, when I attempt to query the same Hashtables "outside" from a different Class file, it starts yelling at me.
Clearly, I'm confused.
I've tried instantiating a object from by GR_footerlink Bean within my dialogBoxModal Class, thinking that would be enough to expose it's methods, although that seems logical, I am probably not executing it correctly (novice JAVA developer).
Related
I read that every POJO used in Groovy gets a MetaClass associated with it. These meta-classes are stored in the application wide metaclass registry. How are these meta-classes generated and placed in the meta-class registry? If each POJO gets its own meta-class, is there some sort of template that is used to generate these meta-classes?
I read that every POJO used in Groovy gets a MetaClass associated with
it.
FYI... It isn't just POJO. Every class has a meta class associate with it.
These meta-classes are stored in the application wide metaclass
registry.
That registry is represented in groovy.lang.MetaClassRegistry. You can get a reference to the registry from GroovySystem.html#getMetaClassRegistry().
How are these meta-classes generated and placed in the meta-class
registry?
There is no one way. You can write your own custom meta class and register it, Groovy registers default meta classes, you could replace a metaClass in the registry momentarily (while a unit test runs, for example) and then replace it with the original one after.
At runtime you could use methods like MetaClassRegistry.html#getMetaClass(java.lang.Class), MetaClassRegistry.html#setMetaClass(java.lang.Class,groovy.lang.MetaClass), and MetaClassRegistry.html#removeMetaClass(java.lang.Class) to manipulate the registry.
If each POJO gets its own meta-class, is there some sort of template
that is used to generate these meta-classes?
docs.groovy-lang.org/latest/html/api/groovy/lang/MetaClass is the closest thing to a template but aside from satisfying standard compile time restrictions of having to implement all the abstract methods, there could be any arbitrary logic in a meta class one might write.
What's the difference? When should I prefer one over another?
And some minor questions related to this:
if I have object data, when is saveObject called?
it looks like garbage collector recycles all my domino handles. I tried to downcast then clone it, but it didn't help (how does it know its still a domino object?). Is there a workaround?
if I create "var tmpVar = new package.TestClass()" from xPages, it gets recycled on update. But if I create java object from bean it stays there. Correct?
Managed beans are exactly that, managed by the XPages runtime. They are created as and when there is a first call to them. Although they have an empty constructor, managed-properties elements in the faces-config allow you to define values (and I believe you can add SSJS code to the faces-config to compute the values).
Object data sources allow you to handle what's created when, and it means they can be scoped to a smaller level than viewScope - to a Panel or Custom Control. The saveObject method is called by a Save All Datasources event. In reality, if you're coding object data sources, you'll code a button and call the relevant method rather than use a simple action.
Java variables can get recycled, but Domino objects are only recycled via two methods. The first is calling recycle() methods, the second is at the end of each request, when the session gets recycled. Because recycle() calls recycle all child elements, everything gets recycled at the end of a request. Which is why you can't store Domino objects in scoped variable or any other persisted object (i.e. a bean). Note that objects like DateTimes, RichTextStyles etc are children of the session, not of any more granular Domino object like a NotesItem or NotesRichTextItem.
var tmpVar = new package.TestClass() will only get persisted beyond the current request if you store tmpVar somewhere. If you're using that code in a crerateObject method, return tmpVar will pass that instance of TestClass into the Data Object.
I go back and forth on pure Managed Beans vs. Data Object. I was using a lot of Data Objects for a while but then ran into some issue with the JSF lifecycle I think that I just couldn't make work. Not sure if a repeat or custom control was involved. So I pretty much have gone back and given up on them for now.
Other then that problem I had I'm not sure there's a ton of difference. I think dataObject can tend to be a little more confusion. Since you can set it on an XPage - but you can change the scope of it to session or application I believe. But if you do then that seems messier and hard to find then making the bean in the faces-config.
I'm not sure about the saveObject part of your question.
You never want to put a pure domino object inside a bean, or scoped variable because they are not serializable and will be tossed by the garbage collector at some point that will likely be most inconvenient to you.
if you just do "var tmpVar = new package.TestClass()" then yeah that will get killed pretty quick because of limited life of that variable. if you want to create an object that way and keep it around longer put it in a true scope: viewScope.put("myObject", tmpVar);
I have a video where I tried to give examples of I think 4 ways to use java Objects. In the blog posting are some really good comments by Tim Tripcony which might give you further information.
http://www.notesin9.com/2013/08/01/notesin9-122-working-with-java-objects-in-xpages/
I have a bean which is initialized with some content (a collection with a few built-in elements). I'd like to ship this pre-configured bean with my library.
At the same time I'd like to give the user of the library the possibility to insert his or her own elements into this collection (currently done from code by calling an addDocument() function).
Is there a way to achieve this from the configuration? How is this problem addressed in other libraries?
Ok I know scope questions come up all the time but I'm interested in a slightly different approach to the solution. The #ViewScope is a fantastic bridge between the #RequestScope and the #SessionScope.
However there is still a common use case (at least for me) where I really don't want to use #SessionScope but I need the data over a couple of views. A really simple case is when I have multiple datatables chained together each one depending on previous selections.
It's perfectly possible to use <f:paramView> and pass a single or even a couple of pieces of data as params in the address and then retrieve everything from the database again. I am more interested in finding a way of creating a 'snapshot' of the beans state / variables, creating the new #ViewScope and then 'restoring' the 'snapshot state' to the new bean.
Does such a thing exist? Ideas? Opinions?
I don't know if this is the 'accepted solution' but I've implemented an idea that works for me. (Feedback appreciated!)
So I have created a #SessionScoped class with a couple of static maps:
private static Map<String, Object> objectVariableMap;
// Getters, setters and methods etc. are omitted for simplicity
The idea being that I have specified a map that accepts a String as the key and an Object as the value. I've specifically not set the type of object to allow me to store any type of object in there. The caveat is that you need to be sure of the type of object when retrieving it so you can cast it back into its original type.
Now comes the time to set the data from the first #ViewScoped. I generate a random UUID (or what ever you want) as the Map key and then set the value to the object I'm working with (ie. this, or indeed any other objects you might want to pass to the next view). Save the key, value into the map and set the URL param to the key.
I'm never keen on passing data like user id's etc. in URL params (even when its encrypted). This idea has the added benefit of offering disposable URL values that have a specifiable life span.
On the receiving end (ie. The new #ViewScoped bean, or any other scope for that matter) you read in the URL param (the map key) using <f:paramView> and then use a preRenderView event to retrieve and set the Object where working with.
At this point you can choose to remove the key pair from the Map and invalidate the ability to retrieve that object or you can keep keep the key pair for a longer duration by simply updating the object if there are any changes.
UPDATE: Conceptually this has been really successful (for me at least). I've created a handfull of useful methods and classes surrounding the concept to make it more universal. If anybody wants more specific instructions or I might even create a small library if anybody wants.
You can use the CDI "Conversation Scope" for this. This is narrower than the session scope but wider than the view scope.
If the pages between which you pass parameters are a unit, you can also make them a flow in JSF 2.2 and use the flow scope.
Projects like CODI offer various other scopes that can be used between pages.
I do not know that the question is right? Please do not take it your mind if it is crazy. Actually I am working on xpages application. There I need to do two things, that I want to add the picklist functionality and binding the dynamic data like field_1,field_2,field_3, ... upto n depands on customer choice.I am using the composite data for both custom controls. I can remove the picklist control's composite data and also I can do it by passing the scope variables. But that takes more time than the composite data.
I did not get any error. But the binded documents is not saving.
Is it possible to import the CCs that are having composite Data?
Code for first CC:-
<xc:viewpicklist datasrc="view1" dialogID="dialog1" dialogWidth="700px" dialogTitle="Pick this field value!!!">
<xc:this.viewColumn>
<xp:value>0</xp:value>
<xp:value>1</xp:value>
<xp:value>2</xp:value>
</xc:this.viewColumn>
</xc:viewpicklist>
Code for Second CC:-
<xc:BOM_Partinfo BOM_Partinfo="#{document1}"
TNUM="field#{index+1}" Desc="Desc#{index+1}" quan="Ea#{index+1}"
exp="exp#{index+1}" cap="cap#{index+1}" total="price#{index+1}"
RD="RD#{index+1}" m="manufact#{index+1}"
m_n="manufactnum#{index+1}">
</xc:BOM_Partinfo>
You can read information that is set in the properties of a custom control if it was static in the calling page:
var x = getComponent("yourcomponentid");
x.getPropertyMap().get("parametername");
but you want to propagate a data source from the outer control to the inner control...
You need to plan carefully. If you hand over the data source, then your custom control is dependent on a fixed set of fields in the data source (that would be a parameter of type com.ibm.xsp.model.DocumentDataSource). This would violate the encapsulation principles. So I would recommend you actually hand over data bindings - the advantage: you are very flexible what to bind to (not only data sources, but also beans and scope variables would work then). The trick is you provide the binding name as you would statically type it in (e.g. "document1.subject" or "requestScope.bla" ). In your control you then do
${"#{compositeData.field1}"}
${"#{compositeData.field2}"}
You need one for each field.
You cannot send a document data source to a custom control using composite data parameters.
You can try and use this script instead
http://openntf.org/XSnippets.nsf/snippet.xsp?id=access-datasources-of-custom-controls
Define data source in XP/CC where you want those CCs. Define parameter "dataSourceName" for both CCs. Inside each of them use EL "requestScope[compositeData.dataSourceName].fieldName" everywhere you want to bind to datasource.