More observations on Xpages from my first few days in XPages kindergarten.
The Good: Source View. This is up there as one of my favorite additions to Domino Designer. It is also something I can easily relate to having used a similar feature in MS Visual Studio for ASP.Net development. I am a developer and so I like to look at code. Being an OOP developer I am used to seeing all my LS code in one place (LS library). So being able to see visual elements such as XPages represented as a single block of XML code is really cool. It provides options for me to do things I haven't been able to do with other visual design elements. I can now see what I have done with my Xpage without the need to click on an endless number of controls and review all the tabs with various radio buttoms, check boxes and keywords. I can use the source view to edit visual elements too small to see. I can copy/paste the xml and do search/replace much as I can with LotusScript code. I havent tried this yet, but I can probably now use TeamStudio code snippets as a way of creating a library of common xPage components (over an above custom controls). I am hoping IBM plan to extend this capability to all other Visual design elements, especially forms and views. If I do I might then be able to copy/paste codes between these design elements (see legacy code yesterday).
The Bad: Programming Language Support I was tempted to classify this as just plain UGLY, but that might be a little unfair. I am sure a few people out there such as Nathan T Freeman and Andrew Pollack will disagree with me. That's OK, I respect their opinions, even when they are wrong :)... Without doubt my single biggest disappointnment with xPages so far is the decision to support server sided scripting for XPages with a new variation of JavaScript. Sorry, but I just don't accept that JavaScript is a programming language. Most other development platforms employ JavaScript for client events only. If they could get Java or C# to run in a browser I am sure they wouldn't even be using JavaScript. Most server sided programming outside of the Notes world is now done using OOP languages like Java or one of the .Net languages - C# or VB.Net. Outside the yellowverse it is also pretty much accepted that OOP is the programming style of choice. Within Notes Java is OOP and LotusScript can be (sort of, kind of). JavaScript does not support classes (outside of hacks such as prototype), it doesn't even support strong typing, everything is a variant. There are some cool things with this version of JavaScript such as implementations of @functions, but it is still a procedural scripting language. It seems with this current version of XPages OOP is sadly not an option (agent hacks aside).
I have seen suggestions that JavaScript was chosen as a way of getting Xpages implemented and out there quickly using JFaces. I am not sure if that is true. If it is, I am not sure if that then means in the future support will be added for both Java and LotusScript for Server events and LotusScript for client events. I hope that is the case as it creates a real dilema for me as to whether or not I would want to rewrite my applications from being OOP to procedural. For me that is a giant step backwards from a software engineering perspective. Xpages need engineering as they can be very complicated. I am not sure if IBM have ever publicly commented on its choice of JavaScript for XPages and where this is leading.... It is is still my hope that one day soon IBM will publish a road map for Notes Development programming languages that clarifies the future for both LotusScript and Java. In every Notes shop I have worked for in the past 10 years LotusScript has been the dominant programming language (95%+) . Convincing people to move away from LotusScript may prove to be just as hard as convincing these same people to move away from Notes to Workplace.
Ratings
0
Comments (3)
I'll disagree with you, but just because you can use Java classes in SSJS. That's how Squawk works. All the heavy lifting is done by a highly specialized JAR behind the scenes. There's really not much to the SSJS. It just instantiates a couple of scoped Java objects and calls some methods on them.
That being said, JavaScript sucks. Big time. I detest it. We're in
complete agreement about that.
I'm bound by NDA not to discuss Lotuscript in Xpages. I have
proposed an approach to it that I believe Andrew Pollack called
"ridiculous." :-)
I'm gonna have to disagree with both of you. JavaScript doesn't need classes because of closures... if you don't know what closures are, now would be an excellent time to find out.
Nathan's spot on about Squawk: there's maybe a dozen lines of SSJS;
and in every case it's just instantiating a Java object and calling
a couple of its methods. But to be honest, all the apps I'm writing
now include less and less custom Java classes because I'm
sprinkling in calls to standard Java classes where I need them
(same goes for @Functions, though that too is decreasing), and
everything else is being handled in typical JS syntax.
It's a very misunderstood language... far more powerful than its
reputation (which is primarily the fault of lazy developers).
Expect a followup post on my blog about what a JS "class" looks
like. :)
I agree with Nathan and Tim too. Sometimes this Peter Presnell character is full of crap. Does he put scotch on his cornflakes or something? I think Peter is mixing up these two completely different languages. IBM have gone out of there way to make it clear these are different languages. One is called JavaScript and the other one is called... um.. er... JavaScript.
Anyway. I suggest we find out where this guy lives and pay him a
visit. We should dip him in green paint, superglue an iPhone to his
hand, lock it on Twitter and put him on a plane to Iran. They'll
know how to deal with him.
Anon.