XPages... the Biggest Barrier
UPDATE: Here's a link to this idea on IdeaJam.
So XPages are cool. VERY cool. And since they can be bolted onto an existing Notes app you should be really, REALLY tempted to upgrade your existing Domino web apps with screen-by-screen updates.
Simply rewrite a form/view/etc. as an XPage and leverage all of the CSS and JSF goodness, give your users a better experience, give your app better performance, etc. And you can finally code stuff where it's supposed to be, without having to use all of the hack-tastic legacy Domino web techniques.
But there's one big hurdle here: XPages don't work with LotusScript. At all. So those legacy apps, if they use WebQueryOpen or WebQuerySave agents, are looking for a forklift-style upgrade where you get to rewrite your agents and script libraries in Javascript and/or Java.
So a cool new technology requires a massive rewrite? Hmm.... sounds kinda like Microsoft.
But wait, it gets worse. The Notes client doesn't support XPages (yet). Oh, I'm sorry - did you need to use that app on the web AND in the Notes client? Well now you get to maintain your Lotusscript libraries for the Notes client, all while maintaining new Javascript/Java libraries for XPages on the web, right? Certainly you're ready to double your dev and testing efforts.
I know, I know - Notes 8.5.1 will get XPage support in the Notes client. This may mean we finally have a single dev road where we can simply write an app in XPages and it Just Works(tm) in browser or client. And that would be really, really fantastic. But (as far as I know) Xpages still aren't going to support LotusScript. So, again, any legacy apps will need major rewrites to take advantage of the new front-end.
I'm sure Lotus development saw this coming a mile away as a shortcoming of XPages. It was asked about in forums for the Notes/Domino 8.5 Beta, and also the Gold release. There's even a Wiki article that tells you how you can have an XPage run an agent (which could be an LS agent) as a pseudo-band-aid to try to help on some things. Unfortunately that approach is riddled with shortcomings, such as requiring that you save your doc(s) prior to calling the agent (even if you're not certain you want to do so yet) and foregoing all XPage error encapsulation. All your XPage can do is say "Hey man, I kicked off the agent, ok?" And recreating the functionality of a WebQueryOpen agent? That's even more fun.
Naturally, I opened a PMR for this, asking to be added to the enhancement request to have XPages consume Lotusscript. But you know what? THERE WASN'T ONE. Not a single SPR relating to this.
Now, certainly Lotus development has talked about this. Certainly Design Partners have mentioned this on conference calls. Certainly there was feedback about this in the private Betas. I'm sure Nathan's shouted loudly that this is a huge barrier for legacy applications. But for general customers this is the only formal means at our disposal to ask for this type of thing.
So if you too would like to see Lotusscript support in XPages, open a PMR and ask to be added to SPR# PALT7SVH29 .
|
 Ratings
0
|
Comments (9)
You can use Lotusscript (but requires a doc save first) http://www.stevecastledine.com/sc.nsf/dx/07112008092834AMSCAD5L.htm
There is further work in progress here but I'm unable to provide
detail on when this will be available.
"...sounds kinda like Microsoft."
Not really, Microsoft would have removed lotuscript altogether and
force you to upgrade. You do have a choice.
@1 - Yeah, the Wiki article explains that too. But there's many, many cases under which that approach isn't desirable (or even feasible).
I'm glad to hear there's work underway in this area. Obviously
there are mountains of pre-existing LotusScript code out there that
are currently left out in the cold.
"Well now you get to maintain your Lotusscript libraries for the Notes client, all while maintaining new Javascript/Java libraries for XPages on the web, right? Certainly you're ready to double your dev and testing efforts."
So, what you're saying is that before 8.5 you would use your
WebQuerySave agents in the Notes client too and you didn't have to
maintain two sets of code, is that it?
@2 - Hence the "kinda". It's nice that IBM/Lotus kept the old stuff around, but there's obviously a massive disconnect on migrating legacy apps to the wonderful new technology. For an app dev platform that is frequently being regarded as "outdated", the conversion of existing apps to a modern look-and-feel and current programming/development standards should be a big priority.
@4 - Close, but no. Before 8.5 you would use your WQS agents to
call classes and functions in LotusScript libraries. Notes client
code would call the same libraries. How did you do it?
Unless you're nothing whatsoever like me, once you start actually developing XPages, you'll never want to write LotusScript again. I know that must sound crazy coming from me... until October I was a LotusScript fanatic. But trust me, SSJS is every bit as easy to write as LS (in my opinion, even easier, for several reasons), but WAY more powerful.
I admit, thus far I've had the luxury of developing XPages for
audiences primarily interested in a web interface. Additionally,
nearly all of the XPage-based apps I've been building have been
brand new applications. But on one recent project the client was
rewriting an entire public-facing website from a LS-heavy version
to an XPage version; much of the LS code that was still needed
could be rewritten at a pace of 5-10 minutes per agent because the
method syntax is so similar... but the majority of the code wasn't
even needed anymore because it was reams of script just for
rendering interface components that are now bundled controls in
XPages.
There are ways to save yourself time now:
1. Use lower-camel-case. For example:
Set docSomething = vwSomething.getDocumentByKey("key", True)
When it comes time to rewrite that line of code in SSJS, all you
have to do is delete "Set" and change "True" to "true" (and -
optionally, but recommended - tack a ; onto the end of the line).
LS won't let you change the case of a Boolean constant, but it
doesn't care about case in method calls. So make your code more
portable by using lower-camel.
2. Avoid extended class syntax for accessing item values. For
example:
subject = docSomething.subject(0) 'original LotusScript
...becomes:
subject = docSomething.getItemValueString("Subject"); // SSJS
equivalent
If you code is already:
subject = docSomething.getItemValue("Subject")(0)
...your code is more portable, because (like the previous example)
there's simply less changes required.
In short, when there's something optional in one language that's
required in another, it's generally a good idea to adopt that as a
convention, because sooner or later you'll have a reason for using
the other language... at which point either you're completely
rewriting your code in a syntax that seems utterly foreign... or
you're just tweaking code in a new but already familiar context.
@Tim - Trust me, I've got no problem writing SSJS. And my coding styles mesh well, similar to the examples you provided. It's getting *to* that point with legacy apps that is the challenge. If only XPages had a way to execute LS code similar to WQO/WQS it would be much easier to incrementally update/migrate pieces as you go.
The biggest huddle will be the apps only work with 8.5.x. So until the costumer has upgrade the servers and clients (8.5.1), it's unusable. For a lot of my customers this means 2010.
Also it means that customers train their developers, now I can get
an web developer and notes developer together to build web pages
that are nice. Not with xpages.
It's not compatible with another code. you can't intermix an xpage
and normal webpage or normal notes form.
I think it has it's place but it's going to be a long time for it
to be the Notes development standard.
It's nice technology
Hi Erik. I am very in interested in this topic too and have posted an idea on ideajam to allow developers to vote on LS v SSJS.