EXTJS in XPages #8 – Selecting data from the grid and opening a document

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

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.

6 thoughts on “EXTJS in XPages #8 – Selecting data from the grid and opening a document

  1. 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!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s