extlib

x$ – now a part of XPages Extension Library

Marky Roden Extension Library, jQuery, x$, XPages , , ,

I am very flattered to find out that not only is my x$ OpenNTF xSnippet being used more widely than I realized (over 600 downloads). It now being used in the latest release of the OpenNTF Extension library.

If you look here – http://bootstrap4xpages.com/xsp/.ibmxspres/.extlib/responsive/xpages/js/xsp-mixin.js and search for it you will find


//jQuery selector that works with XPages IDs
//See - http://openntf.org/XSnippets.nsf/snippet.xsp?id=x-jquery-selector-for-xpages
function x$(idTag, param){
	idTag = idTag.replace(/:/gi, "\\:") + (param ? param : "");
	return($("#" + idTag));
}

Who knew my first foray into the XPages community would have such an impact.

The lesson here boys and girls should be that you should *share* your work however small and insignificant you think it is. Like all scientific research, very little code is “a completely new way of doing things”. Generally everything grows incrementally and just because you don’t think something is significant, someone else might.

You are reading this – what have you shared recently?

🙂

 

Searching XPages REST service and returning the real count in the results.

Marky Roden Extension Library, EXTJS, REST, XPages , , ,

In this article I will show you how I managed to get the search results count into a REST service and why I wanted to do that.

Introduction

Back in August 2012 I posted this on Stackoverflow. I will answer the question there but I don’t feel like I have “answered” it, just worked around it.

How do I make the XPages REST control return the overall number of filtered matches?

http://stackoverflow.com/questions/11786930/how-do-i-make-the-xpages-rest-control-return-the-overall-number-of-filtered-matc

Problem

When you create a viewItemFileService REST service using the the ExtensionLibrary control you get a response which looks like this:

{
    "@timestamp":"2013-03-12T23:25:57Z",
    "@toplevelentries":1299,
    "items":
    [
      {
          "@entryid":"100-8DE5EBF5E35C17F285257B1B00254A8F",
          "@unid":"8DE5EBF5E35C17F285257B1B00254A8F",
          "firstname":"Benjamin",
          "lastname":"Imran",
          "address":"2112 Hall Street",
          "city":"Las Vegas",
          "state":"NV",
          "zip":89121,
          "country":"US",
          "email":"Benjamin.A.Wayman@mailinator.com"
      },

which is fine…and from that you can ascertain that there are 1299 documents in the view (@toplevelentries)

The problem is when you execute a search against this REST service (for example ‘[address] contains street’) you still get @toplevelentries: 1299

This causes me great angst when it comes to the EXTJS grids because I want to use the Infinite Scrolling capability. What that does is calculates based on the size of the view (1299) how large a scroll bar to create and then display 25 entries at a time and load them as necessary. This is really smart except after you have searched the REST service. The grid still thinks there are 1299 documents even when there is only a subset matching the search results. This causes a lot of blank scrolling 😦

In my example the search ‘[address] contains street’ returns 338 matches. But this causes the following to happen with the infinite grid

rest1

And that sucks. Also note 52 pages in the pager!!!!

The EXTJS code to get the number of documents in the service looks like this:

 var store = Ext.create('Ext.data.Store', {
        // allow the grid to interact with the paging scroller by buffering
        buffered: true,
        pageSize: 25,
        leadingBufferZone: 25,
        autoLoad: true,
        autoDestroy: true,
        autoSync: true,
        model: 'Person',
        proxy: {
            type: 'rest',
            url: 'xRestService3.xsp/marky?count=25',
            reader: {
                type: 'json',
                root: 'items',
                totalProperty : '@toplevelentries' // This is the determining value
            },
            writer: {
                type: 'json'
            }
        }
    });

And as you can see form the code @toplevelentries is always 1299

So how do we get the 338 number to the grid without causing:

  • Some major hacktastic, back end to front end, extra ajax calls, and  redrawing the grid on the fly shenanigans
  • Manually re-writting the REST service from scratch (which I could do but would cause much pain and suffering)
  • Performance issues with XPiNC connecting to the server
  • My eyes to bleed…..

This has baffled me for months and here’s how I got around it.

Solution

In the REST service you can create a custom column. In this case we are just returning the requestScope value for markyCount in the column “theRealCount”:

<xe:this.columns>
	<xe:restViewColumn name="theRealCount">
		<xe:this.value>
		<![CDATA[#{javascript: return requestScope.get("markyCount")}]]>
		</xe:this.value>
	</xe:restViewColumn>
</xe:this.columns>

And markyCount is going to be the 338 value from the search. So how do we get that?

The REST service has an id value which can be computed – and I really don’t care what the id is because I am not binding it to a control on the form. So I used the opportunity for some server side computation of the id to create a little FTSearch.

In the example below I am simply getting the view used by the REST service (byFirstName) doing an FTsearch on it and then putting the count in the markyCount requestScope.

<xe:this.id>
	<![CDATA[${javascript:
		var theView:NotesView = database.getView("byFirstName")
		var count = theView.FTSearch("[address] contains street");
		requestScope.put("markyCount", count)
		return "searchMe" //irrelevant value
		}
	]]>
</xe:this.id>

So what this does is create a REST service output which looks like this:

{
    "@timestamp":"2013-03-12T23:25:57Z",
    "@toplevelentries":1299,
    "items":
    [
      {
          "@entryid":"100-8DE5EBF5E35C17F285257B1B00254A8F",
          "@unid":"8DE5EBF5E35C17F285257B1B00254A8F",
          "firstname":"Benjamin",
          "lastname":"Imran",
          "address":"2112 Hall Street",
          "city":"Las Vegas",
          "state":"NV",
          "zip":89121,
          "country":"US",
          "email":"Benjamin.A.Wayman@mailinator.com",
          "theRealCount": 338  //this is the new column
      },

Note theRealCount column with 338 in it. This is then added to every column output by the REST service. So yes the downside is that we are adding computation and output data size to the feed but it appears to make an insignificant amount of difference to the output speed of the service.

We then change the EXTJS code to look at the theRealCount value in the first Item and not @toplevelentries

 var store = Ext.create('Ext.data.Store', {
        // allow the grid to interact with the paging scroller by buffering
        buffered: true,
        pageSize: 25,
        leadingBufferZone: 25,
        autoLoad: true,
        autoDestroy: true,
        autoSync: true,
        model: 'Person',
        proxy: {
            type: 'rest',
            url: 'xRestService3.xsp/marky?count=25',
            reader: {
                type: 'json',
                root: 'items',
                totalProperty : 'items[0].theRealCount' // This is the determining value
            },
            writer: {
                type: 'json'
            }
        }
    });

And we get this – no more blank lines and 14 pages in the pager 🙂

rest2

Dynamic TabPanel height with Dojo TabContainer in XPages

Marky Roden dojo, Extension Library, XPages , ,

In this article I will discuss how to make your Tab Panels dynamically resize to the size of their content. I will use the doLayout property of the dijit control, exposed through the extension library control properties in XPages Designer.

Introduction

The Extension Library provides us with many easy to use Dojo “containers” including the TabContainer and TabPanel. What is sometimes difficult to decifer though is how to configure the dojo container to bend to your will and meet your requirements.

The Problem

My problem was that I have a container with multiple tabs and some are really large and some are small. The out of box the box functionality provides the ability to size the TabContainer and it forces that size on all the panels. This leaves me with two options (see the demo):

  • Make all the boxes large enough to cover the largest panel
    • which looks daft on the panels with very little content
  • Make the overflow of the larger panels use a scroll bar
    • style=”overflow-y: auto”
    • This is “ok” but with a lot of scrolling it makes the panel difficult to use

The solution

So I was searching around Google and I could not find an answer to “dojo TabContainer dynamic resize” which was very frustrating – so I came upon the dojo documentation for the TabContainer. http://dojotoolkit.org/reference-guide/1.7/dijit/layout/TabContainer.html And experience has told me I am wasting my time with the Dojo documentation but I figured what the hey and clicked in……

Now I would rather stab my eyes out than read the dojo API documentation – but I have to hold my hand up and give them props for this one – it is right there in the demonstrations on the first page “A TabContainer with flexible height” – Brilliant!

The trick is to add doLayout=”false” to your dojo container – simple – and a working demonstration as well – well done sirs!!!

So then I went to the XPages designer to look and see if the property was there on the custom control – and yes it was – brilliant – and how absolutely 100% USELESS the help was for it……How is this helpful???

XPages designer help for the doLayout property of the TabContainer control
XPages designer help for the doLayout property of the TabContainer control

It would have been much more helpful to say “default=true – forces all the Tab Panels to be the same height as the TabContainer. Set to false to allow for flexible tab Panel height!”

The dojo API documentation says “If true, change the size of my currently displayed child to match my size” – written by closet programmers and not by real people, apparently.

Demo

Here is the simple demonstration of the difference – quite striking really

http://demo.xomino.com/xomino/xPlay.nsf/xTabContainer.xsp

Conclusion

Dojo reference guide actually helped………and I need to use it more often apparently.

(I still refuse to waste my time on the API documentation though)

The Moral

I think for me it is imperative to understand more about how the dojo containers work in their original environment – the CSJS library before attempting to use them in XPages. I realize this is contrary to the idea that we don’t “have” to understand them to use them in XPages – but actually – I now think it is essential

For more information check out the Dijit information – reference guide – real people speak!

http://dojotoolkit.org/reference-guide/1.7/dijit/info.html#dijit-info

XPages Extension Library Book – it just makes you better!

Marky Roden Extension Library, Just Marky, XPages ,

In this article I will review the new XPages Extension Library book by IBM Press.

Introduction

If you are using or going to use XPages in your organization you need to get the Extension Library – it is already included in 8.5.3 UP1 and in the future it is just going to be part of the standard install and we won’t even consider it an “add on”.

And if you are a developer using the Extension Library, like you should, then you NEED to buy this book and read it. I am not understating that fact, you need to buy it, otherwise you are doing yourself and your company a disservice. What I realized very quickly was that I thought I knew the Extension Library, when in fact I had only scratched the surface and how much more functionality I could be taking advantage of. I have used many parts of the Extension Library now for a few months and I have stolen re-used parts of the example database like the REST services and basically copied and pasted them. I never really understand what they were and how the worked, but didn’t need to either………my loss apparently.

So what’s it do for me?

It just makes you better – and unless you improve and get better, someone else’s going to be doing your job for you!

What this book does is it breaks down all those sections you see every day in the Control Palette and explains it in simple to understand manner.

Extension Library controls in your Designer Control Palette
Extension Library controls in your Designer Control Palette

For example…

  • Chapter 2 – Installation and deployment, written from the perspective of someone who’s had to do it, a LOT and you know they know what they are talking about.
  • Chapter 4 – Forms Dynamic Content and More contains a section on the Dynamic Content control – that is the equivalent of computed Subforms – who knew!! Excellent !!
  • Chapter 5 – Dojo made easy– this does an excellent job of explaining how dojo is integrated into the XPage designer client with good examples!!
    • and I still prefer jQuery, but now I have an even better understanding of why 🙂
  • Chapter 9 – The Application’s Layout has a history of OneUI and while I still think it is massively over complicated for what it needs to be, there are clear explanations of how it breaks down and how you can manipulate each separate section for your evil needs
  • Chapter 11 – REST services took my knowledge from 10% to 90% in an hour. Soooooo many applications for this capability, I *really* wish I had had this 10 years ago!
  • Chapter 12 – XPages gets relational – oh yes it does baby!
  • Chapter 13 – Get Social – I would love to get social and now I know how to – (but I am not social and will now go back in my corner and cry)

 

Talk to me like a person – not a machine

You know when you add an ExtLib custom control to your XPage and you see the “All Properties” and 95% of the explanation seems alien speak to you? This book provides the “real person” explanation of the property and what it does for you. Laying all the properties out together in one place also makes is a whole lot easier to understand the control, its purpose and how you use it!

details on client - que?
details on client – que?

Is really IBM speak for….

oooh that's what it means
oooh that’s what it means

 

The Authors

To varying levels I have gotten to know the authors of this book over the last few months and they a genuinely some of the best people you could ever hope to meet. They wrote this book because they are just like you and me – developers – and they want to spread their knowledge and make the whole community better.

Conclusion

This book was written by developers for developers and like I said, you owe it to yourself and your company to check it out. The cost of the book is less than an hour’s worth of your time to your company and unless you are an XPage ÜberGenius already, you cannot help but learn from this book and it will pay for itself the first day you really sit down and read it.

Go Buy it ! No buts, just go buy it.