I was trying to get the selected values from a check box group, but I failed miserably…

Almost when I gave up I got an error and then I found this site:
the XPages Extensibility API Documentation

via the class XspSelectManyCheckbox I then figured I had to search for the JSF API.

There I found this:
java.lang.Object[] getSelectedValues() 
Return the currently selected values, or null if there are no currently selected values.

which basically means:

getComponent(“myCheckBoxGroupID”).getSelectedValues() will return an ARRAY!!! checkout the [] at the end the object.

so finally it was easy to parse the selected values:
var valueArray = getComponent(“myCheckBoxGroupID”).getSelectedValues();
// valueArray[0] contains the first value
// valueArray[1] contains the second value etc.

can you believe it how stupid I am? and how relieved to finally have found a way to read the selected values with SSJS?

It’s really simple:

Drag’n drop a tooltip control from the extension library controls onto your page and set the appropriate properties:

XML source code:

<xe:tooltip id=”tooltip1″ for=”id_of_object_for_which_this_tooltip_displays” label=”text to display in the web page while hovering the target object”></xe:tooltip>

Result:

The only thing left is to add proper styling. As soon as I have themes working the way I require I will post more on this here

I don’t know about you.. I was for quite some time not quite getting the hang on “requestScope” and “viewScope” variables.

I did understand the “sessionScope” and the “applicationScope” variables.

after a few weeks of playing around with xPages, getting quite deep into JSF  framework etc, I had today finally (maybe only to me) a stupid revelation:

why a requestScope and a viewScope variable is called this way, and thus understand properly how it works

requestScope
Say you have a webpage open and you now click a button (ie. to save a document). The page (or parts of it) are sent back to the server (mostly via post, sometimes via a get HTTP request). When you in this button now set a requestScope variable you can actually use this value in the next page to be opened. I personally will use this to detect which view is most likely to be opened after a document has been submitted.

There is a little tweek to be made to get this working properly, see my other post.

viewScope
the viewScope is only valid as long as you stay on the same page! and if you know that an xPage is essentially (in JSF terms) a “view” you now also know the reason why it’s called a “viewScope” variable.

Use case why I would use  viewScope variable I don’t really have, but you could use it example to track how many times a user has refreshed the current webpage, say to switch between tabs etc. This could help you to track down bottlenecks in your layout.

What are your most urgent issues regarding development with XPages?

let me know and write a comment.

Why I would like to know?

Well in the past few weeks when I tried to get the XPages framework for our company up and running, I spent countless hours doing research on the internet. And mostly I either didn’t find the information I was looking for at all, or it took me too long and I had to “syndicate” bits and pieces from various sources into a model which would work for me…

just take the example of “scoped variables”. In every XPage session/training I attended so far they tell you about the application/session/view/request scope variables.

No-one can really tell you exactly what the difference between view and request scope variable is.

and No-one can actually tell you how you get the request scope variables to work! Most XPage developers think they don’t work at all.

The reason for this is: we (yes, I include myself as well into that group of people) lack a good amount of necessary background knowledge how HTTP and JSF really work.

As soon as you get the chance to talk to certain people who know more about those topics, you start to realize things and suddenly the puzzle pieces fit together and form a quite nice image.

yours

Michael

wow…

so… as you can see.. I was struggling lately a lot with how I could my validation work the way I want it…

I would like to setup some configuration documents where I can define certain criteria upon which my documents (ie. xPages) are validated….

so the simple (required/threshold/regex pattern) ones I got (at least as a prototype) working…

what was still missing was a way to inject “logic” into my validation via setup document..

With LotusScript you could simply use “Evaluate” and the code provided in the setup document would be “evaluated” (ie executed)..

But how the hell can you achieve something similar in xPages? Well working with JavaScript it would be a breeze… as there exists also an “eval” statement.

But as I was/am trying to get our framework working based as much as I can on Java language some other mechanism should be applied.

As I cannot just simply inject some code into a running (already compiled Java class) this would not be so easy. A colleague mentioned 3 methods.
One method I forgot, the other were: use an own class loader and load a full class on the fly. Might work, but I am 100% sure the Notes JVM security model would cough on it.
The third was to use EL expressions with an ExpressionFactory. Would have been a way to go…

But lazy as I was I was trying to figure out a way how I could inject JavaScript into running Java code.

and guess what.. I was lucky and figured it out:

here’s the code:

FacesContext facesContext = FacesContext.getCurrentInstance();
PageExpressionEvaluator eval = new ExpressionEvaluatorImpl(facesContext);

MethodBinding method = eval.createMethodBinding(
facesContext.getViewRoot(),
“#{javascript:var c = getComponent(“field1”);document1.replaceItemValue(“test”,c.getValue()); document1.save()}”,
null, null, null);

// other examples of JavaScript code to “experiment”
// “#{javascript:print(“hello world”)}”
// “#{javascript:return true}”

method.invoke(facesContext, null);

As you can see the interesting stuff is going on in the second parameter of the method createMethodBinding. There you can inject JavaScript code. Just enter your code into a button and then copy the relevant piece out of your xPage XML source code! In our framework this code will be read from the configuration document!

I admit.. the solution is “semi-optimal” cause I wanted to get rid of JavaScript as much as I can. But then hey: I don’t use those “formulas” very often, and for those rare cases I think I can accept the performance dip.

dip? indip? INDispensabletIP!

a side-dip: any ideas how I got the idea of how to get this working?

check this out:

in the package explorer view under Localxsp you will find the source code for all your xPages and custom controls! Just create a simple xPage with a button, add some JavaScript to the button and you basically get the code I posted above!