One thing that has struck me about the Notes 8.5 beta is that X-Pages implements JavaScript as the only option for both client-sided and server-sided scripting. Neither @Language nor LotusScript appear to be supported directly but the "JavaScript" language has been expanded to provide @Formula emulation. The new server-sided JavaScript now also seems to be able to do some of the things only done in the past using LotusScript... When X-Pages is made available for the Notes client I am expecting to see support for JavaScript only. We already have LotusScript able to run on the Notes client and Domino servers, so why is IBM going to so much trouble to extended JavaScript for server-sided scripting? Could it be that LotusScript is not part of the long term vision IBM has for Notes development? As a devoted LotusScript programmer (biggot) I am hoping I am wrong...
The next version of Notes (post 8.5) promises to be a very interesting one for Notes developers. Consider a scenario in which:-
- X-Pages provides an alternative to Forms, Views, Pages, and Subforms with the added advantages of running on both a Web client and a Notes client, plus the ability to link to non-Notes data sources;
- X-Pages supports "JavaScript" directly but not LotusScript or @Formula
- There is little or no future extension of LotusScript language to make it a more modern OOP language;
- There are few (if any) enhancement made to "old-style "design elements such as Forms, Views, Pages, Subforms, Framesets, Outlines;
- The Eclipse IDE does not provide native support for these older style design elements - although we do get the LotusScript editor almost everyone has been waiting for.
It sounds to me like a completely new Notes II programming environment has been created. An environment in which many of the Notes development paradigms of the past have been replaced, including either the death (or significant downsizing) of the role of LotusScript. Will we have the choice of staying with what we know (e.g. LotusScript & @Formulas) or will we have to move to a new way of doing things (most likely JavaScript based0)? And where does Java fit with this? Hopefully IBM will soon provide a clearer picture to the public of its plans for Notes development post Notes 8.0.
Perhaps those more in the know than I can comment about where I am completely wrong.... "Whenever you have eliminated the impossible, whatever remains, however improbable, must be true".
1
0
0
3
1 Nathan T Freeman Permalink Peter, your Lotusscript skills will transition reasonably to Xpages. And it's not like agents are going away any time soon.
When Xpages are supported in the client, there's no particular
reason to think you're going to get one thing versus another except
that the paradigms will be extremely similar to Xpages for web
clients. Except "server-side Javascript" will really be backend
executed scripts before they're rendered. The "server" in that case
will be the Notes client on the local machine, somewhat similar to
DOLS.
I know you're very embedded in Lotusscript OO, so let me ask you a
question: why aren't you writing all the same code in Java instead?
Is there a reason besides syntax? Because if you're writing LS in
OO, then the syntax differences are trivial.
2 Thomas Bahn Permalink Nathan,
I don't know Peter's reason, but mine is quite simple: There are no
front-end classes for Java!
If they were, I would switch to Java(nearly) immediatly, because
IMHO Java is the superior language:
overloading methods, concurrent programming, infinite number of
libraries/APIs, etc.
Thomas
3 Peter Presnell Permalink My distinct preference would be to program a Notes applications in as few languages as possible. But where is IBM heading? LotusScript, Java, or now JavaScript? If IBM are going to invest in the JavaScript language and make it possible to do everything I can do in LotusScript and Java I am probably going to want to go down that path.
Why not Java? LotusScript came first and has always met my needs.
Plus I have and IDE and debugger that works fairly well and an
object model that allows me to invoke LotusScript from almost any
event. PLUS most of the people I work with also use
LotusScript.
4 Tim Tripcony Permalink Applications written in Notes 1 still run... they just look like applications written in Notes 1. IBM almost never gets rid of anything, but they do allow certain things to stagnate. So, as far as having "the choice of staying with what we know", I'd say that's fairly likely. For example, when LotusScript arrived in R4, they didn't get rid of Formula (and, more than a decade later, still haven't), but there have been far more advancements in LotusScript since then than there have been in Formula... but they still occasionally add useful features to it (i.e. all the new iterative functions added in R6).
So if I had to make a wild guess, it'd be that future versions will
include more noticeable and frequent enhancements to support for
Java and JavaScript than for LotusScript and Formula, but that the
latter will still occasionally get new features. Anything else
would be a departure from the way that they've approached forward
compatibility thus far.
5 Nathan T Freeman Permalink @Thomas - That's an excellent reason to stay with Lotusscript and would be an excellent reason to switch.
@Peter - The Lotusscript IDE in Designer is notably superior to the
Java IDE in Designer. BUT the Java IDE in Eclipse is vastly
superior to the Lotusscript IDE in Designer. This will largely
remain the case even after we get the new LS editor, since the Java
editor and compiler allow for some impressive flexibility in
warning and error control, along with code templating.
Please understand, I have written more Lotusscript in the last 10
years than I care to consider. I *dream* in Lotusscript. But since
I've transitioned out of writing procedural LS almost 100% (I'll
still dash off some straight line code in an Agent now and then,)
Java just ends up being more and more appealing.
If you're wondering about the appeal, I have just two words for
you: optional parameters. :-)
6 Dan Sickles Permalink The functional stuff is what makes javascript rock. I assume that class-based OO is forthcoming as Javascript 2 (ECMAScript 4) is implemented but first class functions, anonymous functions and closures are the powerful stuff. Java will only be getting some of this in the next major version.
Java optional parameters? Lotusscript doesn't have them but python
is the optional/named/default parameter ninja master ;-)
Once the javascript engine is running client side, the
Eclipse/Expeditor APIs should be available, perhaps with a high
level wrapper to handle threading and reduce the cruft. Seems that
that would be a great time for IBM to implement the Notes UI
objects too...I just don't see them doing it for any remaining
native UI in reparented Eclipse windows.
7 Nathan T Freeman Permalink This conversation is starting to chafe my NDA. :-)
Dan, I would encourage you to test first-class functions and
anonymous functions in the server-side Javascript context in 8.5. I
believe the Xpages servlet engine completely contains the
interpreter, which is how they can include all that extra syntax
that's non-standard JS, such as @functions and Lotusscript object
references. Because of this, I'm not entirely sure to what extent
the more advanced Javascript features are available, since
ultimately, whatever you script in there is actually executed by
Java.
So, if you put @DbLookup(@DbName, "View", "key", 3) in the Xpages
script editor, that gets parsed and what ends up actually running
on the server is a View.getAllEntriesByKey() in the Java servlet.
I've seen the source code for this -- Philippe and I sat together
and found a bug in it. (It wouldn't return multiple matches for the
same value in an array result -- effectively performing an @Unique
every time.)
Anyway, so since all the script code you enter is actually parsed
and executed by Java, rather than an actual Javascript package on
the server, we should probably all be cautious about assumptions on
the exact execution of that Javascript, prior to testing it.
8 Peter Presnell Permalink @Tim "IBM almost never gets rid of anything, but they do allow certain things to stagnate".... 100% RIGHT and that's what worries me perhaps more than anything.
@Language - I can do some things really well as these run very
fast. Still many places where this is the only alternative (e.g.
field validation). The language is not really being extended, but
it is often what starts most novices down the Notes development
path.
LotusScript - Grew as a language in Notes 4 & Notes 5 but have
has largely stagnated since. I still can't program half the form
events in LS. Many things remain locked behind the API. And it has
fallen behind other languages for OOP support. This seems to be the
language where most Notes developers gather.
Java - Still does not have the same methods/properties/classses as
LotusScript nor does it have a strong following amongst Notes
developers.
JavaScript - No OOP. The support for DOM and @Languages still very
patch at this stage. Outside of X-Pages native support of
JavaScript (especially for Notes client) is patchy.
DXL - It is still not possible to export and import a some
components of a Notes database as XML.
CSS - There is still only a few aspects of Notes applications which
can be styles via style sheets.
So what are the chances with an increased emphasis on JavaScript
that IBM are ever going to do one thing well (in Notes)? I expect
IBM will try to play catchup with JavaScript during 2008/2009 at
the expense of everything else leaving developers with no single
programming language able to do anything especially well. I would
settle for "best of breed" (or close to it) with one programming
language rather than having to deal with half-baked solutions in
several programming languages/technologies. Without this, it is
very hard to make the case that Notes is a strategic application
development environment.
9 Henning Heinz Permalink Just our of curiosity. You are really writing all your code in the Declarations section?
At least that seems to be the consequence for OO Lotusscript
development. I am not a developer so please excuse me if I get
something wrong here.
10 Dan Sickles Permalink I'm NDA free. No Chafing here. Permission to speak freely ;)
I do get that the javascript is executed on the JVM. It's the same
as Rhino (javascript), Jython, JRuby, Scala etc. They all also have
server side web frameworks. This is common and I'm familiar with
the Rhino and Jython implementations. I Use Jython every day as an
interactive shell for the JVM including the Domino APIs.
The special syntax is there because IBM wrote the javascript engine
so they can add any non standard syntax they like. I hope they
don't plan on extending non standard syntax. The @Functions would
be just fine without the @. : @Functions were in that other product
that shall not be named three years ago...I think just to lure
Domino developers with something familiar. It smells too much of
proprietary. "Just hire javascript programmers". I hope that's the
case...Frankenscript programmers will be harder to find.
Executed by java means executed by the JVM as bytecode, same as any
other JVM language. The script is interpreted or compiled (Rhino
has both options) ultimately as bytecode though the interpreter may
have it's own intermediate code. Since XPages javascript can call
Java classes directly, again like other JVM languages, the
@Functions can just call any Java API like the example you gave.
The javascript language itself is most likely compiled to bytecode.
Implementing language features not supported by java is not a
problem...bytecode is the target language (the assembler if you
will). You are not constrained by the Java language. Unlike the
@Functions, and javascript functions calling JAVA APIS in general,
java source never comes into play. The apparent ability to mix
javascript and java source, not just API calls, is something I'll
have to look into. Is it just tight integration like Groovy or is
it more like javascript as an internal DSL, or did I misread
that?
I'll get an 8.5 server going this weekend and check some specific
features but I expect that all the javascript language features
will be there for the supported version *whatever that may be*. I
know they have some of the proposed JS2 features like optional type
declarations. And what about the cool XPath references, are they
still there? Looks like July 4 is XPages day for me.
11 Garth Thomas Permalink I don't think you need to worry about LS going away if only for the need to keep Notes & Domino backward compatible which IBM have
done a pretty good job of.
Come to think about it, didn't this new functionality come about as
the result of IBM buying out someone? If this is the case, IBM
didn't even choose the language, and there was zero chance it was
going to be in LotusScript initially.
I've been writing LotusScript for about 10 years and when it comes
to anything more than simple pieces of code I prefer to write in
classes. And when that happens I will occasionally get annoyed at
how LS doesn't allow you to write like a proper OO language and
then I usually switch to java. You're right, LS is essential if you
are writing apps for the Notes client and i suspect that will never
change. But only being able to write LS effectively locks you into
always writing Notes client apps which may not be so bad if that's
what you like.
For me, learning java was tough to begin but was so worth it.
Javascript is almost trivially easy and is an essential language
for developers today so is also worth knowing. Also especially with
the use of one of the numerous JS libraries springing up everywhere
you can now write web apps with much richer (and less restrictive)
interfaces than you can easily achieve via the Notes client - and
without needing to be able to write very much JS at all! If you
have all 3 of these languages then you can pretty much choose
whichever language is best for a given situation which is pretty
great.
12 Peter Presnell Permalink @Henning, yes this does mean writing a lot of code in Declarations section of LotusScript library. That is part of the reason for the .Domino Framework - to cut down on the amount of new code that needs to be written in this section. It is also the reason why a lot of Notes developers are desperate for the new eclipse designer to provide a LotusScript editor that allows navigation through classes, methods, and properties.