Some Notes on Xpages (or What I Did Over My Summer Holiday)
With props to John Mackey and Andrew Pollack for publishing tips that I leaned on in my work today. And a deep, ingratiating bow to Thomas Gumz for taking the time to talk to me about some tricky pieces on Thursday afternoon!
You must use Session-based authentication for Xpages.
applicationScope and sessionScope variables totally kick ass.
Finding all the detail controls for things like "what to iterate over in a repeat control" is some deep voodoo. But it's very satisfying once you find it.
When in doubt, Project - Clean is your friend.
Speaking of the Project menu, make sure "Build Automatically" is turned on. Unless you don't want it on -- in which case make sure you remember to Build before testing.
It's helped a lot to have a second machine on my desk, with 8.0.1, where I can do things like create new libraries, since that's broken in 8.5 Beta 1.
Screen real estate is VITAL when working with Eclipse. I already kinda knew this working with Component design, but now that we have visual editors for xpages and HUGE property sets for various controls, dual monitors is going to be a minimum requirement.
The Outline control is one of the most useful aspects of DDE (Domino Designer in Eclipse).
Debugging is a major challenge. Sometimes the engine throws a global error page. Sometimes it doesn't. Sometimes you have to just use the print () command in your server-side script to trace what's going on.
You MUST just open your mind and explore things. There's no way it's all going to get documented, and it's going to be years before there's a broad base of design patterns and tools to make things obvious. But you can learn a lot just by going to All Properties and reading the hover help on the properties labels.
The visual editor really only scratches the surface. Try this: create an Xpage. Go to the All Properties tab. Go down to the "data" section. Click on the property value and you'll see a little plus icon. Click it. Read the list of options. You won't be disappointed.
All the editors controls -- every place you type in text -- still need a LOT of work in DDE. The script editor is really rough, and you particularly don't want to try to use the mouse to select content in the script edit pane. But even some of the edit boxes in regular properties try to deal with type-ahead, and can drag on like a Friday afternoon in the summertime. (oh... wait... it IS Friday afternoon in the summertime!)
Okay... it's late.... probably no one will read this until Monday, but today is Independence Day, and that's exactly what I feel like I'm getting as I start trying to do some serious projects with Xpages!
Comments
As for screen real estate, keyboard navigation is critical. Ctrl+M is your friend when editing. Multiple screens are good too.
There's no context menu for Editor tabs: Close, Close all Others etc. It's all really is a strange brew of Eclipse and Domino Designer and lwpd. My background track today was "It's beta..maybe leta..It's just beta..so maybe leta"
The javascript is standard ECMAScript 3. The parser was implemented with JavaCC. The ~EBNF file is in there. The JSDT allows adding in additional syntax libraries that are supported in the tooling. I think this gives enough IDE extensibility but I'd really still like to see some modern javascript features (E4X, for each, generators, array comprehension, __iterator__, split etc..). ECMAScript 3 is circa 1999.
Hey, there's no line numbers in the javascript editor popup, dialog thing.
Speaking of the javascipt editor popup dialog thing, why can't all the javascript editors just be standard Eclipse editors? And everything else too. So much UI, so many contexts...Alan Cooper's not gonna like this.
Posted by Dan Sickles At 01:01:12 AM On 07/05/2008 |
Can you fill us in on how you see XPages and Comp. Apps coming together at some point?
Posted by Bruce Elgort At 12:09:27 PM On 07/05/2008 |
Seriously ... the end goal has to be for Xpages to be the non-java composite app component tool in the near future. But we need client support first, don't we Bruce ...
Posted by john head At 12:13:45 PM On 07/05/2008 |
@1 - Dan, it can't be the standard Eclipse editors because they check syntax, and this syntax is not Javascript. It's not at all. And people need to disabuse themselves of this notion. It's not server-side Javascript. It's server-side XpagesScript.
Posted by Nathan T. Freeman At 02:37:10 PM On 07/05/2008 |
Language features are another discussion.
Posted by Dan Sickles At 03:52:48 PM On 07/05/2008 |
@revenue = 200;
function @sqr(@v) {
return @v * @v;
}
@plan = @sqr(@revenue);
I doubt that I'll use it but there it is. You could build script libraries of '@functions' and import them into your XPages. Or not. @Functions...Just like any other function but with an '@'.
F(oo)B(ar)Script? F(an)B(oy)Script? Who knows what the 'FB' in FBScript(2) stands for? Is the 'B' for B(ill)?
Posted by Dan Sickles At 02:54:54 AM On 07/07/2008 |
Posted by Nathan T. Freeman At 07:11:27 AM On 07/07/2008 |
I don't know how document context is established yet. You could pass the doc in explicitly but that would not be idiomatic @Formula (@Formulaic? ).
Well designed script libraries using this naming convention would be guaranteed not to clash with names imported from standard libraries, thoguh any standard libraries worth using should have their own 'namespace' anyway.
Posted by Dan Sickles At 09:50:54 AM On 07/07/2008 |