I am writing an app in which the end user can mark documents as his favourites. I already have the necessary forms and views to save and read back the favorites, but I have one little problem: all is done in the back end (the favorites are displayed from a view, not a scoped variable) and there seems to be a sync issue between the click on the "add to favorites" link and the partial refresh that reloads the favorites: the newly added document only shows after a second refresh. No problem then, I then decided to move the favorites in a managed bean I already have for the session where I keep the language and other user's prefs.
The problem I now face is this: how can I trap the login event so I can build the favorites list in the bean? I looked at how the "xInvolve" control's favorite piece was built and I found that there is some code added to the custom control's beforePageLoad event. But I'm wandering if there's a better way of doing this. If I go that way, this means that each time a page loads, it will go in my session bean to look if it needs to build the favorites list. I feel it's a bit of an overload: I'd rather build the list once, when the user logs in.
Is that possible or I should keep the beforePageLoad code just as it is now? Any ideas/thoughts are appreciated.
Note this does NOT actually trap the login.. I'm not sure how to do that exactly but I'm not sure it's nexessary..
Just thinking out loud here.. but I would try this..
Assume you have a "UserObject" to hold the favorites for the user.. then the object gets loaded it reads them in etc...
What about an "App Bean".. a managed bean in app scope... basically a factory for your application... inside the AppBean you have a Map... so that's an easy way to get a hold of the userobject anytime and it lives throughout the app scope...
Now on each page.. you try to grab the UserObject... if it doesn't exist.. you load it once into the App Bean so it's there for later... if it exists.. it's already loaded... you then update the UserObject when the user adds/removes a favorite... make sure to go through the object in the app bean to keep it updated...
An advantage of this is if the user opens another browser or tab.. it all pulls from the AppBean...
Give that some thought and let me know if you need any help...
Also note: This is a java solution... it might be workable in SSJS though..
A standard login page is HTTP only, not XPages. HTTP identifies that a login is required, validates credentials, checks the URL that you're redirecting to exists and only then does the XPages runtime take over.
If you want to trap login, you need to have an XPage making an AJAX request to do the login.
You might want to have a look at XPages Help Application on OpenNTF. I built a favouriting function into that. Favourites are stored in the person's profile, but for the duration of the session held in memory in a Map. The person's profile is created with the hashed value of the username. There is a potential issue with renames, but that's not a significant issue.
You could use a SessionListener. In the sessionCreated method you can calculate the List and initialize your session scoped bean:
public class MySessionListener implements SessionListener {
public void sessionCreated(ApplicationEx arg0, HttpSessionEvent event) {
FavBean bean = new FavBean();
// create the favorites List
// and push it to your bean
// add the bean to session scope
event.getSession().setAttribute("favBean", bean);
}
public void sessionDestroyed(ApplicationEx arg0, HttpSessionEvent event) {}
}
Related
On a page I have some fields that I want to be "readonly" (in my meaning they can't be accessed but they will store values, read earlier question in this matter if issues...).
I use a client JS setting these attributes on page load:
$(".readonly").attr('readonly', true);
If I have a partial update on any of these fields the attribute is lost and the field is accessible.
What is the best practice to overcome this and make it work?
Every partial refresh has a oncomplete method bound to it. What you could do is add code to the oncomplete method so the item is being set readonly again. Another, better, approach would be not to change the attribute clientside but to have hidden fields which are used to store the data.
When you have an event bound to for instance an Link control you can change the oncomplete code by clicking in your source pane on the event tag. When you browse the events section in the properties pane you will see the onComplete, onError, onStart properties. You can add your own clientside script in these properties.
Before trying to overcome the "problem" You shoud try to understand what exactly partial refresh do and where the state of application is kept.
Unfortunately partial refresh is replacing current html content (or rather part of it) with a newly created one and only form fields that has backing controls will keep state.
I suggest You should try setting readonly property on controls which You would like to make readonly (if there is some logic here You can always use ssjs).
Optionally You can try to preserve the state on the client side by using csjs global variables but this is rather hard to manage.
And one more thing - try to use the technology to solve the problem(xpages) and try not to hack Your way through with use of stuff that You accidentally know (jquery).
I would agree with jjtbsomhorst on using onComplete event. But another alternative could be setting the readonly property via code like this:
var textField:com.ibm.xsp.component.xp.XspInputText = getComponent("inputText1");
var readOnlyAttr:com.ibm.xsp.complex.Attr = new com.ibm.xsp.complex.Attr("readonly", "readonly");
var list:java.util.ArrayList = new java.util.ArrayList();
list.add(readOnlyAttr);
textField.setAttrs(list);
You could call this on the afterPageLoad event of the XPage. But I really don't know whether this would be the best way to about!
I hope someone can help me solve a very serious problem we face at the moment with a business critical application losing data when a user works in it.
This happens randomly - I have never reproduced this but the users are in the system a lot more than me.
A document is created with a load of fields on it, and there are 2 rich text fields. We're using Domino 8.5.3 - there are no extension lib controls in use. The document has workflow built in, and all validation is done by a SSJS function called from the data query save event. There is an insane amount of logging to the sessionscope.log and also this is (now) captured for each user in a notes document so I can review what they are doing.
Sometimes, a user gets to a workflow step where they have to fill in a Rich Text field and make a choice in a dropdown field, then they submit the document with a workflow button. When the workflow button is pressed (does a Full Update) some client side JS runs first
// Process any autogenerated submit listeners
if( XSP._processListeners ){ // Not sure if this is valid in all versions of XPages
XSP._processListeners( XSP.querySubmitListeners, document.forms[0].id );
}
(I added this to try and prevent the RTF fields losing their values after reading a blog but so far it's not working)
then the Server-side event runs and calls view.save() to trigger QS code (for validation) and PS code to run the workflow agent on the server.
95% of the time, this works fine.
5% of the time however, the page refreshes all the changes made, both to the RFT field (CKEditor) and the dropdown field are reloaded as they were previously, with no content. It's like the save hasn't happened, and the Full Update button has decided to work like a page refresh instead of a submit.
Under normal circumstances, the log shows that when a workflow button is pressed, the QuerySave code starts and returns True. Then the ID of the workflow button pressed is logged (so I can see which ones are being used when I am reviewing problems), then the PostSave code starts and finally returns true.
When there is a problem, The QuerySave event runs, returns true if the validation has passed, or false if it's failed, and then it stops. The ID of the workflow button is also logged. But the code should continue by calling the PostSave function if the QuerySave returns true - it doesn't even log that it's starting the PostSave function.
And to make matters worse, after the failure to call the PostSave code, the next thing that is logged is the beforePageLoad event running and this apparently reloads the page, which hasn't got the recent edits on it, and so the users loses all the information they have typed!
This has to be the most annoying problem I've ever encountered with XPages as I can find no reason why a successful QuerySave (or even a failure because mandatory fields weren't filled in) would cause the page to refresh like this and lose the content. Please please can someone help point me in the right direction??
It sounds as if in the 5% use cases, the document open for > 30mins and the XSP session is timing out - the submit causes the component tree to be re-created, and the now empty page returned back to the user. Try increasing the time out for the application to see if the issue goes away.
I would design the flow slightly different. In JSF/XPages validation belongs into validators, not into a QuerySave event. Also I'd rather use a submit for the buttons, so you don't need to trigger a view.save() in code. This does not interfere with JSF's sequence of things - but that's style not necessarily source of your problem.... idea about that:
As Jeremy I would as a first stop suspect a timeout, then the next stop is a fatal issue in your QuerySave event, that derails the runtime (for whatever reason). You can try something like this:
var qsResult = false;
// your code goes here, no return statements
// please and if you are happy
qsResult = true;
return qsResult;
The pessimistic approach would eventually tell you if something is wrong. Also: if there is an abort and your querySave just returns, then you might run in this trap
function noReturn() {return; } //nothing comes back!
noReturn() == true; --> false
noReturn() == false; --> false
noReturn() != false; --> true!!!!
What you need to check: what is your performance setting: serialize to disk, keep in memory or keep latest in memory? It could be you running foul of the way JavaScript libraries work.
A SSJS library is loaded whenever it is needed. Variables inside are initialized. A library is unloaded when memory conditions require it and all related variables are discarded. so if you rely on any variable in a JS Function that sits inside a SSJS library between calls you might or might not get the value back, which could describe your error condition. Stuff you want to keep should go into a scope (viewScope seems right here).
To make it a little more trickier:
When you use closures and first class functions these functions have access to the variables from the parent function, unless the library had been unloaded. Also functions (you could park them in a scope too) don't serialize (open flaw) so you need to be careful when putting them into a scope.
If your stuff is really complex you might be better off with a backing bean.
Did that help?
To create a managed bean (or more) check Per's article. Your validator would sit in a application bean:
<faces-config>
<managed-bean>
<managed-bean-name>workflowvalidator</managed-bean-name>
<managed-bean-class>com.company.WfValidator</managed-bean-class>
<managed-bean-scope>application</managed-bean-scope>
</managed-bean>
</faces-config>
Inside you would use a map for the error messages
public Map<String,String> getErrorMessages() {
if (this.errorStrings == null) { // errorStrings implements the MAP interface
this.loadErrorDefinitions(); //Private method, loads from Domino
}
return this.errorStrings;
}
then you can use EL in the Error message string of your validators:
workflowvalidator.errorMessage("some-id");
this allows XPages to pick the right one directly in EL, which is faster than SSJS. You could then go and implement your own custom Java validator that talks to that bean (this would allow you bypass SSJS here). Other than the example I wouldn't put the notes code in it, but talk to your WfValidator class. To do that you need to get a handle to it in Java:
private WfValidator getValidatorBean() {
FacesContext fc = FacesContext.getCurrentInstance();
return (WfValidator) fc.getApplication()
.getVariableResolver()
.resolveVariable(fc, "workflowvalidator");
}
Using the resolver you get access to the loaded bean. Hope that helps!
My experience is that this problem is due to keeping page in memory. Sometimes for some reason the page gets wiped out of memory. I'm seeing this when there is a lot of partial refreshes with rather complex backend Java processing. This processing somehow seems to take the space from memory that is used by the XPage.
The problem might have been fixed in later releases but I'm seeing it at least in 8.5.2.
In your case I would figure out some other workaround for the CKEditor bug and use "Keep pages on disk" option. Or if you can upgrade to 9.0.1 it might fix both problems.
I have a session scoped managed bean, with a property current. If I have a method
public void resetCurrent() {
current = new Configuration();
}
in the bean, it gets called automatically every time I navigate to a new page in the application. Is this normal behavior? I am not calling the method anywhere in the code.
Considering that this approach to reset the session bean properties is, to say the least, less than ideal, which would be the right way to accomplish it?
Thank you.
JSF doesn't do that. It's your code which does that. Your view or another bean or maybe the bean itself is calling it. Putting a debug breakpoint on that line or adding Thread.dumpStack() should give you insights in who's calling it by reading the call stack. Or just rename the method to something else and check if you don't see compilation errors during build or get EL exceptions during runtime which should pinpoint the callers.
Considering that this approach to reset the session bean properties is, to say the least, less than ideal, which would be the right way to accomplish it?
Depends on the functional requirements. For example, if the bean is supposed to hold view scoped data, then put it in the view scope instead. Or if it is supposed to hold session scoped data (e.g. logged-in user) and you're basically logging out, then rather invalidate the session.
I have a xhtml page with Search criteria and search results. Clicking on search button will dynamically update the results on the same page. I have a controller for search/results xhtml in Page Scope.
There is an edit button in every record in the search results. Clicking on the edit button will open a new page(new controller in Page scope). Once I edit and save I want to come back to the search criteria page with search resutls.
I can store the search criteria in session and requery and display the results. I looked at conversation and I am not sure if I can use it in this scenario?
Any ideas other than dumping the data in session for this scenario?
Pass the search criteria to the edit view as well (but don't display them or something) and then let the edit view pass it back to the search view once editing is finished.
If you want to persist data between two pages, you have many ways:
1) String parameters
2) Session data
3) Long running Conversation
4) Serialize your data elsewhere (DB or other).
Since you are talking about "saving" I may think you are saving your data in a database. If you have persisted your data in the second page in some way you can just query for them.
Otherwise you can use session and conversation, the second has a "smaller" and defined scope. You can decide when to create one and to create destroy. Simply put a in the first page pages.xml and create a bean with conversation scope.
The session scope will keep your data in your session scoped component until you close your browser.
Hope this helps.
I would go with the session scoped bean. If you use a search bean you can go anywhere in your application and maintain your search state, also it lends itself to saving searches in the database (so users can save searches between sessions).
#Scope(ScopeType.SESSION)
#Name("someRandomSearch")
public class SomeRandomSearch {
private SearchObj1 userSelection1;
private List<SearchObj1> searchCriteriaList1;
private SearchObj2 userSelection2;
private List<SearchObj2> searchCriteriaList2;
private String randomUserInput;
// getters/setters, some helper classes, cascade dropdown stuff, etc.....
// clear search criteria
public void reset(){
this.userSelection1 = null;
this.userSelection2 = null;
this.randomUserInput = null;
}
}
Just make sure to implement equals method in your model classes - maybe that's obvious, but when I first started using Seam I missed this little tidbit and it took forever to figure out why we couldn't hold onto dropdown selections in our search pages.
If when you say "open a new page", you mean navigate to another page in the same browser window/tab, then a Conversation is the ideal method for storing the search state.
Depending on your detailed use case, you might prefer to setup nested conversations (when you click on the edit).
You might also want to setup a pageflow to manage that particular navigation logic.
See the official documentation.
Let's say I've got a register page & a register confirm page. I enter user
details into the register page, navigate to the register confirm page where
I can return back to the register page if there are any mistakes.
I'm going to use view parameters to make the registration data available
from the register page to the confirm page, and vice versa.
Supposing there are 20 items of data to be moving from page to page, that's
a lot of view parameters and a lot of setPropertyActionListeners, especially
as all the data is going to end up nicely packaged in a User object.
So what I want to do is input the data on the register page into the
properties of a User record and send a reference to it to the register
confirm page. What gave me an idea was seeing the BalusC WeakHashMap
converter. This is a JSF converter which has a static weak hash map and
generates a uuid as the value for a map entry and the object reference as
the key. So by specifying this as a converter for f:viewParam you send
the uuid in the query string.
This works fine. The issue I have is that on the register page I have to
get an instance of a User class with new. Then I can do:
<h:inputText value="#{bean.user.firstname}"/>
(etc...), and pass the user instance as a view parameter. It works fine from
the register to the confirm page. The issue is that when I perform the
reverse, sending the user reference back to the register page from the
confirm page I absolutely cannot prevent the register page backing bean
from re-instantiating the user object, after the setter has been called
as a result of the view parameter.
So the converter does it's job and retrieves the User object from the
hash map, calls setUser() in the backing bean, and then I see the
constructor for the User class firing.
I've tried calling new User() from the bean constructor, in #PostConstruct,
in a preRenderView (also checking if an ajax request), but nothing I try
prevents the work of the view parameter from getting wiped out if new is
involved. I'm sure there's a simple solution but I just can't see it right
now.
I'd be grateful for any suggestions for how to solve this problem.
The issue I have is that on the register page I have to get an instance of a User class with new.
So what code is initially creating this new User instance then? If you do this in the preRenderView handler, then you can simply check for null, can't you?
If the view parameter and converter haven't done their job, user would still be null and you create a new instance. The bean constructor and #PostConstruct won't do you any good here, since they both run before the view parameter does its thing, but the preRenderView event is guaranteed to run after it.
#ManagedBean
public class Bean {
private User user;
public void onPreRenderView() {
if (user == null) {
user = new User();
}
}
}
(Something to additionally consider is that the conversation scope already does exactly what you're trying to do here. This is part of CDI not JSF, but if you're running in a Java EE 6 Web Profile compliant AS (JBoss AS 6 or 7, Glassfish V3, Resin 4, ...) you already have it. Otherwise it's just an extra jar.)
After several attempts over more than a year to find a solid long term solution
to this problem, at last! I've found one. The solution comes in the form of the
Apache Myfaces CDI extensions project, aka Myfaces CODI.
This provides additional scopes such as the #ViewAccessScoped which ensures that
if a bean is referenced by a page then it is available for that page. Also
provided is support for conversation groups. In the scenario where I want to
pass an object reference from a register page to a register confirm page, the
confirm page can just access the registerView bean directly on the next request.
Alternatively you can #Inject one bean into another and access it on the next
request, or use f:setPropertyActionListener from the source page.
Myfaces CODI works fine with Mojarra and also with ajaxified component libraries
such as primefaces. The concept is similar to what is provided by Jboss Seam,
though I've found the additional scope support to be better thought out and I've
tested this on glassfish 3.1.1 with no problems.
If you're using #ManagedBean and scope annotations from the javax.faces.bean
package in your code, codi intercepts these annotations and uses it's own
CDI based versions, so you can convert to CDI simply by adding codi as a
dependency to your project and not changing any code.
For me this is like moving from black and white TV to colour TV, I wish I'd
found this stuff sooner.
CODI documentation