On several occasions, Domino Designer falls short when it comes to developing XPages. On those occasions I try to dive into the XPages API. I used to create a computed field with the value of typeof getComponent( 'component-id' ). This gave me the class name of the object. Then I declared a variable with the type of the class. This gave me the methods available for the component type. E.g.
var field:com.ibm.xsp.component.xp.XspInputText = new com.ibm.xsp..It started with a simple field that you put a class name into. This gave you the properties and methods of the class.
Then I added the functionality to type the name of a global object (e.g. facesContext), and it printed the properties/methods of that object.
Then, while writing/preparing this blog post, I remembered my client side getClientId/getComponent. After a little bit of copy/paste/modify, I ended up with a custom control that lets you select any control (including event handlers/etc) on the page from a combobox (just add the custom control to the XPage you're developing), and get the methods and properties of the corresponding class in the XPages API.
A couple of screen captures (animated gif):
>> Download Demoapp with custom control (28K zip)
In theory, the custom control lets you post commands to the server, so remember to modify the ACL after you download!
Share and enjoy!
20 comments:
I love you, man.
Do you love me enough to make me an Eclipse plugin that lets me debug XPages live? :P
AWESOME. Thanks for taking the time to share.
No problem..
I make applications to make money (and I love to code).
I share code/ideas to hopefully help in the evolution of Notes/Domino technology/techniques.
If someone use this to make a kick ass app/technique, and share it, this helps increase my knowledge. I can use this knowledge to make another useful technique/app, and so on..
The circle of sharing knowledge. Share and enjoy.. :)
This is pure awsomesauce. Thanks Tommy. Tweeted about it!
Great utility. Pure love! thanks
Has anyone had problems using a Domino Document data source in 8.5.1 Designer? It worked in 8.5, but is broken in 8.5.1.
I've installed 8.5.1 on several different machines with different ids, and none of them display the data source for Domino Document correctly (although Domino View works fine).
Strange!
I use 64bit Windows 7 at home, and 32bit Windows XP at work. I have no problem with Document Data Sources in Domino Designer 8.5.1.
Have you tried a clean install of Notes and/or created an application from scratch (new form, new XPage)?
If possible, try to boot up in safe mode, and see if there's any difference.
Hi Tommy,
Thanks for confirming that this does work for someone!
Yeah, I tried several machines, ids, etc. I have tried several clean installs as well as creating a new application from scratch.
I even setup a new laptop and installed 8.5.1 in a stand-alone environment (no Internet, no Domino server, no id). Same result.
I have also reproduced this on several of my co-workers machines as well including Win7-64Bit and WinXp-32Bit. I have not found a single instance where this works in 8.5.1 (the bug is consistently reproducible).
I have tried starting with 8.5.0 and upgrading to 8.5.1. I have also tried applying 8.5.1 FP1. Nothing helps.
So, yeah, this is really frustrating.
If I install 8.5.0, everything works as expected, but I loose xpage support in the client. Right now, I'm developing in 8.5.0 and testing in 8.5.1. It works, but is a hassle.
I have not tried safemode yet, so I can try that next, but I'm not very hopeful.
FYI: Here's the exact indication:
After adding a 'Domino Document' data source to an xpage, no fields display in the Data tab. The selector is still there, but no fields and no message stating 'No data available', just a blank tab. At first, I thought it was a display issue, so I tried dragging and dropping the 'invisible' elements on the tab, but there's nothing to click on. Strangely, 'Domino View' data sources appear and function normally.
Very strange.
I assume you're using the US version of Notes/Domino? Have you tried downloading 8.5.1 more than once, in case the installer is slightly corrupted?
Strange indeed!
Yes, I'm using the US English version that I downloaded from the BP software catalog.
I thought about re-downloading, but one of my tests was to install 8.5.0 (clean install), followed by the 8.5 to 8.5.1 update. This also failed and used different installers.
I have since left the office to test this at home... Same result!
I'm going to download the public version from here (http://www.ibm.com/developerworks/downloads/ls/dominodesigner) to see if that makes a difference.
BTW, What version are you using?
I'm using the US version, at home and at work.
worth a million! this will make my designer life a lot easier =)
Guess what? I'm not crazy after all!
Well, at least I'm not the only one with this issue, and I have a solution, and I can duplicate it on any machine! That's close enough for me!
Here's the skinny:
The bug only happens when the first line of a source form is hidden.
It only happens for legacy forms. If you create a form using 8.5.1 and hide the first line, no bug.
Sometimes, all you have to do is save the source form once in 8.5.1 to get rid of the bug, but not always.
Here's how you can see this bug on your own machine. I'd be interested to hear your experience.
1) Create a simple xpage for testing this bug.
2) Add a document data source that points to the Group form in your address book.
3) You should not see any fields in the data palette. This is the bug.
4) To fix it, open the Group form in designer, make a trivial change and save the form.
5) Switch back to your test xpage, and presto! The fields are there!
Thank you to Mr. Reith, who pointed this workaround to me in the 8.5 Forum.
And thank you, Tommy, for your valuable info (I realize that your blog was not the right place for this, but I was desperate).
So far, I have not seen anything about this bug in the 8.5.1 FP2 or 8.5.2 fix notes yet. I don't have support, so I can't even report it.
BTW: I just got a chance to try out this control of yours. Wow... nice job! I'm sure I'll use this.
Just tested on my work computer (32bit Windows XP), and got the same results as you. Empty data palette.
This is an awesome resource, thanks!
I was trying to figure out the hit count on a view control using the search parameter and the "getRowCount()" method did the trick. Sadly, such information is nowhere to be found in the designer help files.
I'm glad you found it useful :)
One thing to be aware of when using com.ibm.xsp.component.xp.XspViewPanel.getRowCount(), is that it doesn't work correctly for views with empty search-parameters.
If you have a view that the user can filter/view all entries, use getEntryCount() on the view Data Source.
Example code:
var entryCount = viewData.getEntryCount();
var viewControl = getComponent( 'viewControlId' );
var rowCount = viewControl.getRowCount();
// Search is active -> rowcount, else entrycount
var count = ( viewControl.getDataSource().getSearch() ) ? rowCount : entryCount;
return 'Number of entries: ' + count;
What I mean by that it doesn't work correctly for unfiltered views is that the the getRowCount() result increases as you paginate (click next page).
@Bill: Thanks for the tip! Was about to get insane because of this bug...!
Post a Comment