YellowDay: Partnering with IBM on Xpages Extensions
The crazy few that attended our IamLUG
presentation in St. Louis already heard this, but because the live streaming
didn't work, it turns out that I get to make this announcement twice.
A few weeks ago, the mighty Philippe Riand and I were discussing some of the missing ingredients from Xpages. While Xpages gives Domino developers unprecedented power and flexibility, many people (including we here at GROUP) were struggling with some of the constructs that are part of the basic nature of the Notes client. @Picklist, .DialogBox, Mail Address Fields, computed subforms, and even just keyword aliasing were turning out to prove quite a challenge to implement over and over in every XSP project that we engaged in.
Tim and I had been working feverishly on designing and building a collection of reusable controls that would behave as closely as possible to the traditional UI elements of the Notes client. And as it turned out, we were not alone. IBM had too been facing the same challenge, and members of the Xpages team all over the world had been working on similar concepts, in between fixing bugs to get 8.5.2 to ship quality.
Philippe and I agreed: "this seems like a lot of redundant work for us to be doing. Surely there's a better way to get this done." IBM was already planning on releasing their toolkit on OpenNTF, so we had the option of waiting until they did all the work, and then just reusing it like everyone else. But we're in a very big hurry, and I wanted to get access to some of these controls just as soon as possible. We also had a slightly different objective with many of them that required 100% consistency with the Notes client behavior, so while IBM's design for a dialog box required that you put the dialog contents into the container at compile time, we needed to be able to determine the contents dynamically at runtime. (Note: they knew exactly how to do this, of course. It just wasn't a requirement for them where it was for us.)
So I asked my boss if we could join forces with the Xpages team on this effort. We'd have to do something unusual for GROUP, because we would explicitly be tasking full-time resources during regular hours to the production of an open source result. But in the end, we agreed that being able to work with the components that much sooner was worth sharing the results, and thus we moved forward with IBM with all speed.
The official beginning to this project was Monday. And I am thrilled to tell you just SOME of what it includes, as components that are both drag & drop in DDE, and declaratively through SSJS...
1) InputBoxes and @Prompt
2) Aliased keyword lists
3) View-driven Custom Picklists
4) Address selection fields & buttons (using the full Directory API, no less)
5) @DialogBox
6) Computed Subforms
7) Draggable "framesets" with computed contents
8) Multiple styles of Outlines that actually read from Outline design elements
9) Dramatically simpler OneUI implementation
10) Scrolling Dojo Grids driven from back-end data sets like a Notes view
11) Tag Cloud
12) Simple User Bean for Directory Info
13) Sametime Presence Awareness
14) Dojo Layouts and Events
15) Calendar Views (yes, calendar views. I said it.)
I'm not going to tempt fate by announcing a delivery date on my blog, but I can tell you that you'll need Notes/Domino 8.5.2 to work with all these features, and that our objective is "very soon after 8.5.2 is available." We're as excited as ever to be working on this stuff, and we think that when you see it in action, you'll be excited to.
Thanks for stopping by on YellowDay!
A few weeks ago, the mighty Philippe Riand and I were discussing some of the missing ingredients from Xpages. While Xpages gives Domino developers unprecedented power and flexibility, many people (including we here at GROUP) were struggling with some of the constructs that are part of the basic nature of the Notes client. @Picklist, .DialogBox, Mail Address Fields, computed subforms, and even just keyword aliasing were turning out to prove quite a challenge to implement over and over in every XSP project that we engaged in.
Tim and I had been working feverishly on designing and building a collection of reusable controls that would behave as closely as possible to the traditional UI elements of the Notes client. And as it turned out, we were not alone. IBM had too been facing the same challenge, and members of the Xpages team all over the world had been working on similar concepts, in between fixing bugs to get 8.5.2 to ship quality.
Philippe and I agreed: "this seems like a lot of redundant work for us to be doing. Surely there's a better way to get this done." IBM was already planning on releasing their toolkit on OpenNTF, so we had the option of waiting until they did all the work, and then just reusing it like everyone else. But we're in a very big hurry, and I wanted to get access to some of these controls just as soon as possible. We also had a slightly different objective with many of them that required 100% consistency with the Notes client behavior, so while IBM's design for a dialog box required that you put the dialog contents into the container at compile time, we needed to be able to determine the contents dynamically at runtime. (Note: they knew exactly how to do this, of course. It just wasn't a requirement for them where it was for us.)
So I asked my boss if we could join forces with the Xpages team on this effort. We'd have to do something unusual for GROUP, because we would explicitly be tasking full-time resources during regular hours to the production of an open source result. But in the end, we agreed that being able to work with the components that much sooner was worth sharing the results, and thus we moved forward with IBM with all speed.
The official beginning to this project was Monday. And I am thrilled to tell you just SOME of what it includes, as components that are both drag & drop in DDE, and declaratively through SSJS...
1) InputBoxes and @Prompt
2) Aliased keyword lists
3) View-driven Custom Picklists
4) Address selection fields & buttons (using the full Directory API, no less)
5) @DialogBox
6) Computed Subforms
7) Draggable "framesets" with computed contents
8) Multiple styles of Outlines that actually read from Outline design elements
9) Dramatically simpler OneUI implementation
10) Scrolling Dojo Grids driven from back-end data sets like a Notes view
11) Tag Cloud
12) Simple User Bean for Directory Info
13) Sametime Presence Awareness
14) Dojo Layouts and Events
15) Calendar Views (yes, calendar views. I said it.)
I'm not going to tempt fate by announcing a delivery date on my blog, but I can tell you that you'll need Notes/Domino 8.5.2 to work with all these features, and that our objective is "very soon after 8.5.2 is available." We're as excited as ever to be working on this stuff, and we think that when you see it in action, you'll be excited to.
Thanks for stopping by on YellowDay!
Comments
FUCKING AWESOME!
Posted by John Head At 01:34:13 PM On 08/11/2010 |
Thanks in advanced for your effort.
Posted by Steve Smillie At 01:46:03 PM On 08/11/2010 |
Thank you Nate, Tim and the team at GROUP!
Posted by Dan Soares At 01:54:33 PM On 08/11/2010 |
This should move some of the fence sitters to action (myself included).
Many thanks...
Posted by Wayne Sobers At 02:33:13 PM On 08/11/2010 |
Posted by Mark Hughes At 02:46:49 PM On 08/11/2010 |
Posted by Rob McDonagh At 02:55:30 PM On 08/11/2010 |
Posted by Nathan T. Freeman At 03:03:49 PM On 08/11/2010 |
Since this library uses the Extensibility API, the library takes the form of an Eclipse plugin, so installation is straightforward: install the plugin into Designer via an update site, then copy the plugin JAR(s) to a specific directory on the Domino server. That's it.
Once that's done, all the controls the library defines will be instantly available for use in any NSF without having to copy custom control definitions around to every database. In fact, one of the fun things about this approach is that you can bundle client/server-side JavaScript, CSS, and even images as part of a plugin, so if any of the controls in this library need to use those types of resources, you won't have to add those to the server separately or maintain them in each NSF... once the plugin itself is where it needs to be, everything else is managed automatically for you. It's really quite slick to see it in action...
Posted by Tim Tripcony At 03:06:19 PM On 08/11/2010 |
Posted by Sean Cull At 03:09:04 PM On 08/11/2010 |
Posted by IamLUG Information At 03:33:02 PM On 08/11/2010 |
Posted by Fredrik Sjöström At 04:03:50 PM On 08/11/2010 |
Posted by Stephan Wissel At 04:45:17 PM On 08/11/2010 |
Posted by Paul Withers At 04:55:04 PM On 08/19/2010 |
Posted by null At 06:26:53 AM On 11/16/2011 |
Posted by null At 06:26:54 AM On 11/16/2011 |