For my current home project I’m busy exploring the Java side of xPages more and more because of my general love for this language. The project involves a little website that should display the current standings and results of hockey teams ( wheelchair hockey ) during the season.

A little feature list

– Support for seasons: Create seasons add teams to a season
– Support for teams: basic crud actions
– Support for competition days and games: basic crud actions
– A list of current standings and results: Realtime calculations for teams etc.

I wanted to use the objectdata datasource for this one. So I searched a bit on the net, remembered the splendid presention from Thimo Janssen and wrote a little code.

Because I didn’t want to fill my pojo’s with the code about how to read and save them I decided to write something called a Repository class. A Repository class is a class that knows all about saving/retrieving an object to and from an datasource for instance a Domino database!

This way we can keep the Object (pojo) itself neat and clean. Now for some code:

I’ll start by showing you the code for the xPage

In the above piece of code you can see the createObject and saveObject properties who are both using the same object called  “seasonService”. This service is the so called Repository class. As said this object is responsible for retrieving and saving an object to the database ( in this case Domino ).

Lets have a look at the code of the Repository Object.

The most important parts for now are the GET and the SET methods. As you can see the GET method is capable of retrieving an entry by Key or create a new object (and what you also see is that when an object by key is not found a new object is created… #bug!). If no key is provided a new empty instance of the season class is returned.

When a key is provided the code will do a getentrybykey search on a predefined view. With this retrieved entry the season object is constructed using the fromEntry method. The fromEntry method is there because on another place in the code we want to retrieve data using a view entry as well. Namely the getAll Method. This retrieves ALL season objects using a predefined key / view name and from every viewentry a season object is constructed. Because I’m lazy and don’t want to write / update the same code on several places I created the fromEntry method.

Secondly the SET method. The set Method accepts an Entity object ( because we defined an interface for the repository object. We will talk about them later in another post.. maybe ). At the beginnning we check if the given object is of type Season. If so we create or update the datastore ( aka the notesdocument ). The update takes place only when the object is not new in other words when a key ( uniqueid ) is provided in the object. If the object doesn’t have such a key we assume the object is new and create a new document and save it. When the save succeeds the universalid of the document is saved into the season object. At last the season object is returned.

This code is not perfect. For instance what to do when the update/save of the season creates an error? Should we throw an error or should we return a null reference to tell the ui the code made a booboo? Anyways.. all comes to an end so this will conclude this little post about Java and xPages. I will , when the project progresses add some more info about Java and xPages. In the meantime. Stay tuned!

A few months ago there was a little fuzz going on in the openntf / domino community. There where some guys who wanted to go where IBM didn’t want to go. Updating the JAVA api that was available to us notes developers.

Since that moment there have been a few releases of the org.openntf.domino api and I decided to take a look and work with it on a little home project. One of my biggest hobbies is playing Wheelchair floorball. Every year it is a little challenge to keep track of the results, the current standings and so on because everything is kept in excel sheets that are downloadable from the official website. I want to have it on a website which gives me a direct overview of where my team is standing in the competition and for other people to see if their team is winning.  So why not create a xpage application from it. From the start I made the decision to use the new org.openntf.domino api to see how it works.

My first impression is.. wow. 

Of course there is the obvious ‘where did my .recycle’ go. The API takes care for that of us. Somehow ( have to check the source for it ) it keeps track of every object you create and recycle’s it when needed.

Secondly there is the iterator support on collections. If you have a NotesDocumentCollection or a ViewEntryCollection you are able to iterate over it using the usual iterator’s as many java developers are accustomed to.

Because I’m still playing around with the new JAVA api I will keep it at these two points. When my project has advanced a bit more I will write another blog about it.

oh btw.. there is a small thing I would like to be added to the API.

ViewEntry.getColumnValue(String name);

In a view you can add the programmatic name. The xsp wrapper of a viewentry is able to retrieve the data from a column by name. For some reason this Api won’t allow it. I think that it would be really nice asset because it makes the code a bit more readable (and that’s what it is all about.. ) see for yourself:

This could be possible because inside the viewentry object you can call its parent. Retrieve all the column names and chekc if the given column was found in the namesvector. If so retrieve its index and do a simple getColumnValues().get(index);

I planned to write the 3th parth in these series in the next couple of days but something unfortunate has happened. By windows 7 install decided to crash. And ofcourse I didn’t backup my domino 9 beta data directory.. So the work I had done was lost. I appologize for this :(.

The upcoming weeks I will use to prepare a new box with domino 9 and to prepare for the 3th part of this series.

I justed reïnstalled my windows 7 notebook. One of the many drivers I need to install are the drivers for my nvidia graphics card.

When started it askes the user where to extract the setup files. So I set the directory to %temp%/nvidia .  The etraction process began and after it completed the installer returned with an error stating it could’nt find the installation files.

I was wondering two things

1) Why does the installer have to ask me where to put the extracted files if we the OS offers a TEMP directory

2) And secondly if you change the default path, why did the installation program got lost?

I see this much to often. Software that isn’t using the %temp% directory when it should be. If more software would utilize this shortcut it would be much much easier to keep your pc neat and clean..

>> EOF

In this article I will describe how I converted. We will concentrate on how to use a restService control and how to get the data needed to load the first categories in the tree.

This	in This

In the previous part of the series I explained a bit about how to create a simple dijit.tree and how it works. Now in this part I will explain how I used the restservice component from the extLib to generate a JSON structure which is compatible with the dijit.tree.

note: for these series you will need a copy of the fakenames.nsf file.

For those who are not familiar with the RestService control from Extlib. This control gives you the ability to create fairly easy an restfull service. I contains lots of default service types but for this tutorial we are going to write the Get method ourselves.We start by placing the following control on our xpage.

Configure the rest control

When we open up the properties pane we will see that the control offers a great deal of properties. The first one we will look at is the pathInfo property.

This property will tell the service when it should be rendering. A rest service typicaly is accessed by an http get, post, put or delete call. Therefore it needs an url identifier. Lets say we named the xpage api.xsp. And we define /names/  as the pathInfo. This way we can access the restService with the following url

http://yourdomain/database.nsf/api.xsp/names/

Now lets try it. You will notice that the service returns an empty string page ( among some header information). This is ofcourse because we told the service when to render but we didn’t tell it what to render. For this series it is enough to add the code that should be used in the Get call.

In the properties list expand the following path basic / service.  There are lots of properties but for now the following are the most important.

Lets fill the doGet method. Open up the SSJS editor of this property and add the following code:

Now add a SSJS library to your application and add the following lines of code:

As you can see this code is fairly easy. It first checks if the request made is a category only request (currently it defaults to true ). Next on it will retrieve all categories from the view on the first level. ( See fakenames.nsf for details of the view ). Last but not least add this library to your xPage.

When we visit http://yourdomain/database.nsf/api.xsp/names/ you will get a result which looks like like:

Creating the dijit.tree

With this response we can start to customize the dijit control we saw in party 1. Open up the xPage where you pasted the dijit.tree code from part 1 on. Or create a new xPage with the code from part 1. We have to make the following adjustments to the code.

As you can see we replaced the store with an instance of JSONRestStore. Since we retrieve our data from a RestService we need to have a correct way to interact with it. A JSONRestStore retrieves its data a restfull way. This means it will read /api.xsp/names/ and when we click a node it will read /api.xsp/names/A till Z ( depends on the node ofcourse ).

Next we create a new TreeModel. In this model we define the rootId ( undefined since there is none..) and we set the default name of the root. The last attribute tells the tree at which attribute name in the JSON it should check for children.

This concludes the second part of this series. We have a nice little dijit tree which only shows the first categories as nodes. I showed you how to create a simple RestService using the RestService control and some lines of SSJS and how we can use this data to populate a dijit.tree.

In the next part I will explain how we can change the SSJS so it will retrieve leaves ( aka content of a category ) when the tree needs it and I will show you how to add lazy loading.

update: Changed code for the getCategories call . It should be isCategory = false