Beyond The Yellow Bubble

I previously had been updating this blog entry about the what was known about plans for new features in future release of Notes/Domino.  This blog was easily the most read of my blogs, so I guess there was a lot of interest in the topic.  Now that most of the information about 8.5.1 is in the public domain I plan on separating out news that leaks out about 8.5.2 & TNMR (The Next Major Release - aka 9.0) into this new blog entry that will be updated as information is put out there.
:
Note 8.5.2

1. Release Timetable
1. Daily builds and internal reviews of 8.5.2 have started within IBM.
2. Look for a big showing at LotusSphere 2010 and a release around May 2010.
   
2. Client Features

1. Will support Windows 7

1. Development Features
1. "Very impressed with the start-up speed": Tweet - tmcerlian
2. Possible - Support for Relational and other datasources in Xpages.
3. Not yet confirmed for specific release - New XPage controls for Outline, Menubar, Toolbar Tag cloud, Popup
4. Database Icon in more than 16 colors -- possible but VOTE

Notes 9.0

1. Timetable
1. Will be talked about in more detail at LotusSphere 2010
2. May not be called Notes 9
2. Client Features
1. Improved Search
2. Group Calendar
3. Adding RSS Feeds to Inbox
4. Contacts and Mail Federation
5. Unified Task Management
6. Improved Workspace

Note: If the features you want are not on the list above hop on over to ideajam and either create your suggestion or vote on an existing suggestion.  IBM does monitor this site and are often influenced by the ideas getting the most votes.

 One of the many cool things about SSJS is that the language can be easily extended (or redefined).  As an example I found that there was not an SSJS version of @getProfileField.  Unlike LotusScript it is possible to create functions with the @ character so adding the following code to a SSJS library provides a quick example of the simple way in which the existing @Language can be extended with your own additions.

function @getProfileField(form, field, key)
{
 if (key == undefined) {var document = database.getProfileDocument(form,"")} else {var document = database.getProfileDocument(form,key)}
 if (document.hasItem(field)) {return document.getItemValue(field)} else {return null}
}

Note: The above also demonstrates yet another feature of SSJS not found in LS.  The ability to support optional parameters in a function.  SSJS (and JS) will accept any number of parameters.  If you provide less than the number specified they are assigned a value of undefined.  If you provide more parameters than specified these can be accessed using arguments

 In XPages kindergarten we started writing our code with crayons.  We were all just starting to learn a complex subject and so our teacher would let us find any place within an XPage  to scrawl out code.  It wasn't pretty, but as long as it worked nobody seemed to mind....

Now in XPage first grade the rules are changing.  The crayons have been taken away and we are being asked to write code that can be easily read (and shared) by others.  This means our teacher is starting to pay more attention to the form of the code and not just what it does.  Having learnt to write LotusScript using OOP I am naturally looking to do the same with SSJS (and even JavaScript).  The following are some of the lessons I have learnt so far.
...
Notes:

1. I am still a long way from university and writing a thesis on the subject but this is a first graders effort at OO-SSJS.  2nd graders please point out my mistakes.
   
2. OOP is almost identical for JavaScript and SSJS so I will simply refer to SSJS but the following also applies when developing client sided Xpage code using traditional JavaScript (aka ECMAscript).
   

Classes:
As a LotusScript/C#/VB.Net developer I always associated OOP with classes.  It turns out that classes are not the only way to implement OOP.  Classes are a structured way of defining objects.  In contrast, the prototypeing model supported by SSJS provides a lot more flexibility.  This is not unlike Notes development itself right!!!  When I first started writing SJS it bothered me that the language was not strongly typed and that it did not have classes.  Now I am beginning to think this could be really cool.  In relational databases we have a regimented structure where every row (document) must have a set number of columns (fields) and each column must contain data of the same datatype.  In the Notes world almost anything goes and it is up to the skill of the Notes developer to exploit this dynamic capability (eg. showing multiple document types in a single view using common field names).  So what if LotusScript & SSJS don't support abstract classes, sealed classes and interfaces like java/c#?  Are those things really needed when the majority of Notes/Domino projects have a single Notes developer?  If a useful way can be found to instantiate a base class or the need to extend a sealed class becomes necessary then why not let this happen.  I don't need a "code-lawyer" creating artificial boundaries for me.  By the time I have finished the debate with the lawyer I could have the entire app written!

In SSJS we represent objects by creating a function and then instantiating the object using the new statement.  The function is referred to as the constructor for the object as it is executed whenever the object is first invoked just like sub new in the LS class.

Example 1: Object with variables defined via the constructor:-

function employee ()
{
    var privatevariable;
    this.publicvariable;
}
var emp = new employee()

Properties:
Strictly speaking SJS does not have properties.  Rather, what SSJS supports is both private and public variables.  These can be defined in one of two ways:-

1. Constructor: The easiest way is to create private/global variables inside the constructor as demonstrated above.  This has the advantage that the definition of the property cannot be over-ridden.  Variables are made public using this.variablename whereas private variables are defined using a var statement.
   
2. Prototype: The format of OOP implemented by SSJS is known as protype-based programming and uses the prototype statement.  This technique provides better support when it comes to extending a base class (inheretance is a  key principal in OOP).  It also allows properties/methods to be added dynamically, a really powerful capability not available in java or C#.

Example 2:  Object with variable defined via prototype

functionemployee()
{
    this.Document=source;
}
employee.prototype.publicvariable;

The difference between a variable and a property is that a property allows additional logic to be executed each time a property's value is accessed.  In the case of SSJS we are most likely to create objects to represent the content of Notes documents.  The properties corresponds to fields, so when we attempt to get a property value we need to extract the value from the Notes document.  And when we set a property value we need to ensure that value is store back in the Notes document.   Not all properties behave this need, but a great many will.  Variables do not allow us to do this...

The solution I have developed for this is to pass the XSPDocument as a parameter to the object's constructor.  This is saved in a public variable (Document).  For each property I then add a public variable to the object (using prototype).  This can be made private if you have a compelling reason, but why bother?  Who are you really protecting by doing this?   I then add two public functions to the object for the get and set (using prototype).  If you only need a get (or set) then just one function will suffice.  The get function contain the logic for extracting the data from the XSPDocument along with any other preprocessing that may be required before it is used.  The set function contains the logic needed to process the value before it is saved back in the XSPDocument.  This may include validation logic to prevent invalid values being stored.  This is the concept of encapsulation (another key principal in OOP).  I can then use the get function much like I would use the LS get property and the set function the same as a LS set property.  I also have the option of using the public variable directly.  This would be done for the purposes of efficiency where I need to refer to a property many times and I do not wish to pull the data from the XSPDocument each and every time.

Example 3: Notes Field Represented as a Property

Employee.EmployeeID;
Employee.prototype.getEmployeeID=function()
{
    if ( this.Document.hasItem("Emp_No")) {this.EmployeeID = this.Document.getItemValueString("Emp_No")}
    return this.EmployeeID;
}
Employee.prototype.setEmployeeID= function(value)
{
    this.EmployeeID = value;
    this.Document.replaceItemValue("Emp_No",value);
}

Note: At  this time SSJS is only supported within Xpages.  Back-end processing would be supported via Agents or Web Services which must be written using either LotusScript or Java.  It therefore seems to make more sense to develop SSJS classes to interact with the XSPDocument class than it does the NotesDocument class.  If at a later time IBM provides a clearer strategy for SSJS this decision may need to be revisited.

To simplify the task of creating these property statements I have added a tool to the .Domino Framework as outlined in my previous blog.

 Release 1.1 of the .Domino Framework will contain an enhanced version of the Property Generator tool that will allow Object Oriented Programmers to generate SSJS property statements.  A sample of the SSJS code generated is as follows:-

Employee.prototype.EmployeeID;
Employee.prototype.getEmployeeID= function()
{
    if ( this.Document.hasItem("Emp_No")) {this.EmployeeID = this.Document.getItemValueString("Emp_No")}
    return this.EmployeeID;
}
Employee.prototype.setEmployeeID= function(value)
{
    this.EmployeeID = value;
    this.Document.replaceItemValue("Emp_No",value);
}

There are times (like today) when I feel like everything possible has been implemented to ensure that learning Server Sided JavaScript(SSJS) is as difficult as it can be.

1. Me: Lets start by assuming I could well be at least part of the problem. i.e. you can't teach and old dog new tricks and I have been doing Classic Notes development for so long I have a tendency to try and do things the way I have "always" done them.
2. XPages Is Complex: Xpages are a very powerful, but also complex, design element requiring a lot of learning.
3. On-Line Help: I have vented my frustrations many times about the lack of quality and depth of On-Line documentation.  Yes it's 1.0.0 for Xpages and SSJS but right now is when I need it the most!
4. No Text Book: Whenever learning any new IT technology I have usually found a good reference book on the topic to supplement my other learning.  It is a shame IBM did not sponsor somebody to write a reference book on Xpages and/or SSJS.  Blogs and wikis help in the wired world we now live in but they are often difficult to mine for information.
5. SSJS 1.0: After being in Xpage school for a while I am starting to realize its not always me that is doing something stupid.  This is 1.0.0 of Xpages and SSJS and there are a few things actually wrong/missing in the desgn element and code execution.
6. No Debugger: Given all the above the chances are high that a "few" bug will creep into the code I am writing.  So finding and fixing those logic errors becomes a major challenge when I cannot use a modern debugger to step through my code and inspect variables.  I am forced to use the same debugging techniques I used when I wrote my first BASIC program back in 1977! (see what I mean about an 'Old' dog!!)
7. SSJS Editor 1.0:  Just as SSJS is 1.0.0, so too is the editor used to edit the code.  It would be nice if the editor was able to compile the code and tell me about errors such as referencing a propertry that is not defined before the code is executed.  And then telling me I have an error on line 456 col 34 is a bit of a tease when the SSJSS editor does not display line numbers.
8. Objects is SSJS:  My shinny new LotusScript editor coming with 8.5.1 is about to allow me to navigate through the properties/methods of classes so it is a shame the new SSJS editor in 8.5.0 does not already do the same for the properties/methods of objects.  Or is IBM starting a push to discourage everyone from using Object Oriented Programming?

The bottom line is that right now with Notes 8.5.0 you have to want to learn Xpages and SSJS a LOT to navigate the many barriers that can get in the way of building some of those slick applications we have seen.  I have nothing but admiration for those that have blazed trails across the new frontier.  They are at least providing something of a path for others like me to try and follow.  I can't wait until IBM steps in and provides a mulkti-lane freeway so that more of us can travel a little faster than we are right now.

Building on previous blogs, I am providing an updated dictionary of terms spoken within the Lotus Notes Community - and perhaps only mastered by an estimated 1,500 people know to inhabit the yellow bubble.

Beeps
Blueverse

I am presently spending a lot of my time back in Xpage school developing real-life Xpage functionaility.  So I can again share with you some of my thoughts based upon my latest experiences learning this new technology.
.
The Good: Validation - Yet another of the really cool capabilities Xpages bring to NSF development is a range of new options for validating fields.  Most controls have a validation section which allows you to set a property to mark that a field is required.  As with most properties of an Xpage, this can be enabled via a formula to conditionally determine when it is required.  Depending on the display type of the data (text, date/time, number) it is also possible to specify additional validation checks.  For strings this includes minimum and maximum lengths.  For dates, that the date lies within a specified range.   For attachments you can specify MIME types allowed (or not allowed).  Underlying this are a series nine different alidators that can be coded directly to do all of this plus a whole lot more.  In short there seems to be a a way to perform every form of validation possible.  Tied with the validtors are two error controls you can add to your Xpage.  This can be a single control that displays all validation errors, one control for each field being validated, or almost anywhere in between.
.

I have added a new video outlining some of the advanced features that are being considered for implementation as part of the OpenNTF Discussion Nextgen project


Note: If you missed my previous video covering the basic feature set, please watch this first as it contains much of the background for this latest video.  Niklas has also posted several videos on the OpenNTF blog that cover other aspects under development.

Peter Presnell - Notes Classic - Basic Feature Set
Niklas Heidloff - Can a Composite Application look as good
Niklas Heidloff - New/better Prototype for Discussion Template Rich Client UI

and PLEASE, PLEASE, PLEASE...

visit our Ideajam to create your own ideas and vote on existing ideas for this project.  We really need (and appreciate) your input. 
Lotus Knows The Lotus Community has great ideas on how to make the discussion template a first class product.

And one from the vaults - a missing blog that was posted into the 8.5.1 beta forum due to non-disclosure...

The Good - Finally  Some Control - One of the definite advantages of Xpages is that is raises the bar on the user experience for "out-of-the box" Web applications.  As an independent contractor I have worked for many clients around the globe.  For the clients I have worked a majority of Notes applications  (~70%) have been Notes client applications, 20% Dual client (Notes/Web) and perhaps 10% Web applications.  I am sure there are some companies where the mix is the other way round but I would be surprised if my experience is not typical.  Most of the developers I therefore work with tend to have much stronger Notes client development skills (Including LotusScript) than they do Web skills.  So anything IBM can do to help me render an application out of the box for Web clients without me needing to add my own copious amounts of HTML, JavaScript, x etc is certainly most welcome. I would rather just add a moderate amount to round out the application.  From what I have seen so far Xpages are a giant leap forward in meeting that need.  I no longer need that ugly view applet and I am hoping soon I will not need the Outline and action bar applets.  I now have a handy set of controls that render fairly nicely onto the Web browser.  The pager control is especially a great addition.

The Bad - Still Out Of Controls -  Good start IBM but you are still not letting me be an absolute star.  I want to make my applications dazzle in the same way that Lotus0911 did with Bones.  Only I don't want to go to all that trouble.  I am lazy.  I want IBM to give me a signifcantly expanded set of controls out of the box that will have my customers demanding that both I and Lotus Notes get to stay for a long time.  A while ago I had the pleasure oif managing a team of ASP.Net developers and one of the first decisions I made was that I didnt want my developers consuming large amounts building user controls.  I wanted to bring in best of breed controls and focus on building applications.  I found a company called telerik (www.telerik.com) that does some pretty amazing stuff with ASP.Net controls.  If you want some absolutely great ideas for the types of controls that other Web developers are using now do yourself a favor and take a long look at the site and all the demos they run.  They also show how the same control can be rendered differently on different platforms to exploit each one's capabilities. I went back to teheir site a few days ago and was amazed how much further they have gone in the two years since I returned to Notes.  I am positively drooling at the opportunities controls like this would create.  After all these are controls that competing products are already able to use.  We need to be setting the bar at least at this height.  The Notes client must the the biggest and most powerful client out there so we should be capable of delivering the best user experience possible without going  through all the trick Lotus 911 went to.

Well it looks like Steve McDonagh has let the cat out of the bag.  Being on the beta program I can probably help fill in some of the gaps left in Steve's report...

Disclaimer: IBM Lotus Notes/Domino and Lotus Notes Traveler 8.5.1 is prerelease code and there are no guarantees from IBM that the functionality presented or discussed will be in the final shipping product.  (Steve you forgot this!!!!)
"Domino 8.5.1 is very radio-active. It will probably be on CNN and as part of LotusKnows it will contain a dilithium crystals which not only vibrates at 1200Hz and can be used to irradiate kettles.  It can also be used for thermo-nuclear war and bringing world peace (such is its flexibility) but that is really only useful if you are able to walk on water with a penchent for doing healing to leapers (aka Exchange users)

The new LotusScript Editor with added support for a vastly expanded LotusScript syntax is really very useful and has been well received by all testers.  DXL now works as expected but can cause database corruptions (still) which may lead to emotional outbursts and tears before bed. A series of Lotus videos will describe how to reincarnate Domino.Doc in glorious detail and technicolor dreams but looks remarkably like Lotus Quickr with a weasel in up his Eclipse kilt an effect that detracts from the overall production.

Changes to the Basic Client have removed all performance advantages from the client which is a great relief to anyone who has EclipseClientUpgradeitis and uses curly side-bar plug-ins on a regular basis.

My contact was also keen to pass on the fact that xpages now come with usable on-line help which now allow you to actually find things and even learn at the same time! MaryBeth does warn that this can lead to understanding and XPage mastery and if left in place may cause your user's eyes to water. I for one look forward to this!

Performance issues have also been addressed with a vastly improved hyperdrive and new random error generator leading to the status quo being preserved but this is sort of like dancing with a Java programmer warts and all !!

I for one am moist with and my fellow yellowbleeders are tingling with excitement"

Another one from the vaults - a missing blog that was posted into the 8.5.1 beta forum due to non-disclosure...

The Good: Page Lifecycle - Prior to XPages, the page lifecycle for Domino Web applications was nice and simple.  WebQueryOpen and WebQuerySave. This limited greatly what could be achieved with a Domino application.  The most notable was the inability to send a page back to the web client after WebQuerySave.  XPages now introduces a full page lifecycle comparable to that found in most modern Web development platforms.  We have been initially provided with 5 events - beforePageLoad, afterpageload, afterRestoreView, beforeRenderResponse, and afterRenderResponse.  These five events plus page round-tripping, AJAX, and state management combine to allow powerful dynalic Web applications to be built inside the NSF container for the first time.  We are already seeing many great examples of what can now be created.

The Bad: Page Lifecycle - While the extended page lifecycle is a major step forward for Domino Web applications, I am less convinced this is the case when design Notes client applications.  In implementing Xpages for Notes the way it has, we seem to have essentially turned the Notes client into a glorified Web browser.  Yes, it is GREAT that the same XPage code written for a Web application will also run on the Notes client.  But in doing so I wonder if we have locked ourselves into following the Web application model.  There is where I get confused and would value greatly IBM outlining its development strategy moving forward.  Why deploy a 250MB client onto everyones desk only to have the applications run in browser mode?  Why did we do all the work to improve the Notes client with Notes 8.0 to then move to a thin client programming model?  Adding Notes client controls to Xpages is not all that different to the option of using Winform controls in .Net development - which require a much much smaller .Net framework client to be installed.  The biggest asset Notes application development has had up until now has been the Notes client itself.  I tried .Net development.  Even with the more powerful Visual Studio editor and sophisticated controls from telerik I was still unable to come close to developing applications as fast as I could with Notes.  That was largely because Notes gave me a thick client application model.

As many of you many know I have been lucky enough to have the chance to participate in the OpenNTF project to extend the Discussion template.  The team includes Niklas Heidloff and Steve Castledine, two of IBM's great application developers.  These guys are constantly coming up with great ideas for this project.  One of Niklas's contributions was the idea of using video as a medium to communicate some of the ideas we have for the template.  Thanks to Niklas it is now occurring to me that video may be one of the missing pieces for one of my other OpenNTF projects, the .Domino Framework.

Here is my first video which explains one of the framework's developer tools, the Property Generator and how it can be used in conjunction with the new Eclipse LotusScript Editor to quikcly generate LotusScript classes.  So if you haven't yet had a chance to see the new LotusScript editor up close, here's your chance.

From the vaults - a missing blog that was posted into the 8.5.1 beta forum due to non-disclosure...

Disclaimer: IBM Lotus Notes/Domino and Lotus Notes Traveler 8.5.1 is prerelease code and there are no guarantees from IBM that the functionality presented or discussed will be in the final shipping product.  
The Good: Multi-Client Fidelity - Ever since Notes 4.5 Lotus/IBM have striven to make to provide the ability to deliver a single application for both thick (Notes) and thin (web) clients.  Up until now the results have never achieved those goals.  Some would say they never really got close (not me of course!!!).  Now with XPages we have for the first time a design element that renders almost identically on both the Notes and Web clients.  And then there is also the promise of Xpages soon being supported on Blackberry devices too.  I have found a few minor issues but so far I am satisfied that Xpages for Notes looks almost the same as XPages for Web.   OK, so its not a complete surprise given that it seems underneath this is achieved by using a Mozilla engine to render the page but this is a HUGE help in developing multi-client applications.
 
The Bad: Multi-Client Fidelity - There is a saying "be careful what you ask for as you just might get it".  That certainly applies here.  In providing fiedelity between the Notes and Web client for Xpages we have essentially delivered a very powerful design element for the Notes client that is limited in its capabilities by what a Web browser can do.  There are a few exceptions here - Composite Application support and integrated Notes security.  The Notes client has a number of very powerful rich client controls such as its rich text editor, outlines (including drag/drop), views, name fields, and action bars.  I am hoping that longer term plans are to allow the rich client version of XPages to support more functional controls in the Notes client via rcp tags.  If we don't then we have largely turned the Notes client into a browser as far as Xpages is concerned.  Why install a 300 MB client just to run it like a browser (not all apps will be CA)??  I am sure there are going to be times when I will be torn between the superior UI of existing Notes design elements versus the power and flexibility provided by XPages.
 
Note: IBM are starting to publicly state there intentions of developing Rich Client capabilities for Xpages.  So I am hopeful over time that Xpages for the Notes client may prvode most (if not all) of the functionality of forms, views, pages, outlines, framesets etc.

I have been spending a lot of my "free" time over the past month working on an OpenNTF project to develop the next version of the Discussion Template.  All going well this will be available around the time 8.5.2 is released.  My initial focus has been on developing a new Notes Classic interface for the discussion template.  Please take a look at the video posted on You Tube and share with me any thoughts.  The entire project team is looking for as many ideas as possible about how we can improve the look and feel, ease of use, and functionality of the Discussion template.  There is an IdeaSpace on the OpeNNTF web site for the Discussion NextGen project that can be used to add and vote on ideas.  And if there is anyone else out there with some spare time that could lend a hand all the better!

My Xpages Summer vacation has ended and I am now back working on Xpages projects.  Here is a quick tip for those like me still in the early stages of learning...

SSJS provides a cool emulation of many of the popular @Functions written using much the same syntax as the original language.  But there are a few gotchas:

1. They are ALL case sensative... So when they say" @UserName" use @UserName and not @Username or @USERNAME etc
2. These are functions so if you what the value use @UserName() .  @UserName returns a delagate to the function itself.
3. If you don't want your entire Xpage to crash if something goes wrong with an @Function wrap your code in a try/catch statement  e.g. using catch(e) { return e } will return the error message should an error occur, catch(e){} will return nothing when an error occurs but the page will still display.

I regularly find myself forgetting all of the above on a regular basis!!