Monday, November 18, 2013

Really Strange Behavior with the REST Service Control in Xpages

Today I encountered some really strange behavior when trying to add a new column to a view that is used by a REST service.  I couldn't find anything out there on this, so I decided to write a short blog post detailing what happened and how I fixed it.

I was wanting to add a new column to the underlining view that the REST service uses.   The column is going to store raw HTML that I am going to use in an ExtJs RowExpander plugin.   I create the new column and add it my ExtJs and nothing happens.  After figuring out it wasn't my code, I checked the REST service and the column was not there.

I verified everything and even restarted Notes.  To prove that the view was being read, I tried deleting a column and refreshing my browser page and sure enough the column disappeared.  To test the REST service I used the URL to see the raw JSON data.  (This is done by adding '/restData' after the Xpage URL, or whatever you entered for pathInfo).

You can see here that I am reading all columns
Here is where it gets weird.  If I enter any quotes string in the column value then nothing shows up.   If the string is the result of most any formula it works.   Note:  @Text("test123") did not work.  For clarity, the value "$91" is the programmatic name of the column "confirm91".

This doesn't work

Column value contains only text

This works

The column result is the same, but the column is now read.

Obviously the formula is fake, but for whatever reason the REST service now sees it.   Now that the REST service is pulling the column, I can use it in a grid of my choosing.  

Labels:

5 comments:

  1. Marky RodenNovember 18, 2013 at 4:45 PM

    Something to note. The column will always send a field name if that is what you calm it.

    So for example if shippers is a field name in the document it will send the field value regardless of the view column value. A bug in the service j think.

    No idea if that is the issue but worth knowing.

    Thanks for sharing :)

    ReplyDelete
  2. Brad BalassaitisNovember 18, 2013 at 8:07 PM

    I wonder if it's being ignored because it's a hard-coded column. Like in the way that you don't count hard-coded columns when determining the column number for an @DBLookup. Notes just seems to treat them differently. Adding a formula made it treat it as a dynamically-determined value at runtime.

    ReplyDelete
  3. Karsten LehmannNovember 19, 2013 at 12:53 AM

    @Brad: I am pretty sure that's the reason. If a hard coded value like "test123" is used, ViewEntry.getColumnValues() does not contain that value, so it could even worse, because there are more ViewColumn's than column values, which messes up the columns to the right of the hard coded one.
    A fake formula like @If(fielddoesnotexist="";"test123";"") should help, because then Notes does not recognize that the column is hard coded.

    ReplyDelete
  4. The Zavocki'sNovember 19, 2013 at 10:10 AM

    Thanks all for the feedback. Hope this all save someone the two hours I spent trying to figure this out.

    ReplyDelete
  5. şükrüAugust 1, 2023 at 8:25 PM

    trabzon
    edirne
    van
    bingöl
    yalova
    X3V

    ReplyDelete

Subscribe to: Post Comments (Atom)