In this article I will show you how to get data upon selecting a document – I will then demonstrate how we open a document from the grid.
EXTJS in XPages series
Here are links to all of the previous articles in this series
- EXTJS in XPages #7 – Doing an @Unique(@DbColumn) equivalent in the grid
- EXTJS in XPages #6 – remote sorting using the REST service
- EXTJS in XPages #5 – Infinite scroller
- EXTJS in XPages #4 – Adding a Pager
- EXTJS in XPages #3 – Creating a basic grid from a Custom Control
- EXTJS in XPages #2 – Basic Grid capabilities
- EXTJS in XPages #1 – Starting from scratch (the first grid)
Demonstration
The EXTJS in XPages demonstration database can be found at http://demo.xomino.com/xomino/Extjs.nsf/xGridOpenDocument.xsp
Download
The sample database that will accompany this series is available from the menu in the live demo database from this link – http://demo.xomino.com/xomino/Extjs.nsf
Selection Model
The selection model for a grid is very easily retrieved using the dblclick event within the grid:
var selection = grid.getSelectionModel().getSelection(); var fieldValue = selection[0].data.fieldname
Listeners
To detect the double click event we have to add a listener to the grid. There are many listeners for the grid and more information on them can be found here in the Sencha help files
grid = Ext.create('Ext.grid.Panel', {
listeners: { //listener config setting for the grid
events HERE.....................
}
}
Getting the UNID
In out view we are going to add a new column docid – very simple @Text(@DocumentUniqueID) column formula. But this column is not going to be displayed in the view – it is going to be hidden.
We add the new column and add the “hidden: true” property to it in the grid so that it is not visible to the user. But this does mean that it is available to us programmatically.
{
text: 'docid',
width: 10,
dataIndex: 'docid',
hidden: true
},
(Note: the @UNID property is passed in by the REST service and *yes* we could use that instead of adding a new column – however I feel that this is easier to explain and does not require a discussion regarding the usage of a property of the REST service JSON array )
Opening the document
In our example grid we are simply going to open our document by getting the docid field from the hidden column and opening a window using a manually generated URL string
So all together or grid code now looks like this:
grid = Ext.create('Ext.grid.Panel', {
renderTo: 'gridHere',
frame: true,
features: [filters],
height: 400,
title: 'Users',
store: store,
iconCls: 'icon-user',
listeners: { //listener config setting for the grid
itemdblclick: function(dataview, record, item, index, e) {
console.log('dblClick Event')
var selection = grid.getSelectionModel().getSelection()
window.open('xPerson.xsp?action=readDocument&documentId='+selection[0].data.docid)
}
}
}
As you can see from the example page this is simple, effective and completely poor as a user experience – but this article was about getting data from the grid – not about making a cool application 🙂
Conclusion
Programmatically accessing data in the grid is a very powerful technique when attempting to manipulate the EXTJS grids and insert them into your application.
Xomino 
Two questions:
1. what if we want to use the @unid item in the REST response? I didn’t try but I don’t even dare to write selection.data.@unid as it looks strange…
2. why is it “poor” to open a new window for the document? I think it’s more convenient than opening the doc in the same window so the user loses the focus on the “view”. What is you way to open documents in a browser?
In the fields use ‘@unid’ and then get the unid using selection[0].data[“@unid”]
@ symbols are used to designate “properties” of the JSON feed and as such are not a field within the array. That is why you can’t say selection[0].data.@unid. It is severe personal pet peeve of mine that IBM have been doing this since R7.whateverItWas with the readViewEntries&OutputFormat=JSON. It is a very badly conceived idea IMHO – I can only assume to help the poor domino developer which is unfamiliar with JSON and web concepts – but years later it smacks to me of a lack of forethought and just makes every developer’s life harder. If there was one single feature within DominoWeb development I would want changed this is it. Use unid as a field name – I guarantee you everyone would be ok with that.
Anyway – I think it is always a poor user experience when a new window opens for multiple reasons. 1) inconsistent navigation confuses the user 2) you do not have control over the browser any more – the user can designate a popup window or tab for the new window – harder for the helpdesk – harder on the user. 3) does the user then have to close the document to go back to the view? what if they click on a link in the document and open the view again – window after window after uuurgh replication save conflict just waiting to happen.
I completely agree that opening the document in the same window is also bad form and an ugly user experience – sooooo there must be something else – coming soon to a blog near you 🙂
thanks for commenting Oliver – I really appreciate the discussion 🙂
Yes, the @-naming is really bad. I thought of the field notation, I will try it later.
My approach of opening a document w/o opening a new window was once a jquery dialog with an iframe. It was a bit tricky to control the content from the main window (and so was it vice versa), but it works. The disadvantage is in my case that you are able to edit only one document at a time. The second approach could be the usage of tabbed “windows”, like the tab-panel elements in ExtJS. Here is a demo of what I mean:http://mardou.dyndns.org/extjs.nsf/index.html
Click on the menu “Hauptmenü” top left and open the log view. Doubleclick on an entry and a new tab will open. It is programmed that you cannot open a document two or more times. If you click an entry of a document that is already open then just the corresponding tab is activated. 🙂
Well seeing as you brought it up – Great minds think alike – I have used that method with the jQuery dialog except I ajax’d everything into the dialog and posted the inner form back via ajax. That was not XPages though – traditional domino
Tabbed interface is that is EXACTLY where I was going with my comment though – that is a sweet demo congrats !!
Thank you Mark! It’s really a joy to discuss such “nerdy” things on that high level with someone who is also very deeply involved with the matter.Unfortunately the moments to deal with all the “cool” stuff like XPages, Java, framework etc. are very rare in my working time as most of our customers use Notes still in a very “basic” and traditional way. To space for experiments 😦
The demo is actually the basis of a customer project I did last year. ExtJS is also my topic on this spring DNUG in Berlin. I am very curious how your approach will look when dealing with “intelligent” tab panels for document edit actions and so on 🙂 Keep up the nice work!
EDIT says: “NO space for experiments” I mean…