Beyond The Yellow Bubble

I typically blog about two things.  Books I am reading and my latest gadget :)  No, its my pet  .Domino Framework project on OpenNTF and my interest in the future direction of Notes.  In a way the two are interwined....

Jan Schulz  has posted a very good article questioning the future of LotusScript and the Notes client.  It is was one of a growing number of varied perspectives I have been reading with interest.  I have been asking myself similar questions over the past year since the 8.5 beta was first released.  I have also had the chance to look closely at the 8.5.1 beta, a release I have long said would be a pivotal release in Notes history.  And while I cannot disclose anything specific about 8.5., 1 I still feel this is the case.

I have been doing my bit to create debate within the yellowverse about the direction Notes development might be going .  Not because I believe I have the answers but because I believe it is a very important issue for us ALL to discuss.

1. The organizations for whom we all work must eventually decide about migrating Domino servers and Notes clients to 8.5.0 (and 8.5.1 when it  is released).  The Domino server side is much easier to execute and IBM have created a compelling business case for doing this.  The client side seems to often be driven by support issues and the functionality of the mail client.  Sadly few companies I have worked for are driven to deploy newer Notes clients to allow Notes developers to build better applications (but they should!).  Regardless of where you may sit on the arguments about the use of LS, Java, SSJS, XPages etc. having your companies upgrade their Notes clients to 8.5.1 is only going to increase your options as a developer.  You need to convince yourself that this release is important enought to fight for.
   
2. Whether you are a contractor or employee, your value as a Notes developer depends heavily on the skill set you have and the skills that are now needed.  Almost certainly there will now be some change in the skill sets that are being sought for Notes development.  So each of us needs to make decisions about what skills we want to develop to allow us to continue to be important to our current employer as well as make us attractive o prospective new employers.  This doesn't mean always moving the latest and greatest.  If you had jumped on the Java bandwagon when Java was first added to Notes you would have a skill that is of value but is still largely a niche market for Notes (I have never had a Java Notes developer work on any of my teams).  If you jumped onto the IBM Workplace bandwagon you would have made IBM happy but you would have acquired skills that were largely useless (except perhaps in now helping you with XPages).
   
3. It is no fun working with old code and companies seem to be forever replacing legacy applications.  If Notes code does change significantly as a result of XPages it would be better to stop producing legacy code sooner than later.
4. Notes has defied the odds to remain a vibrant product in part because it acquired a niche market.  It filled a void between low end Excel/Filemaker products and the high end Java/Oracle & .Net/SQL Server platforms.  It is classic marketing scenario, if we chose to leave our present market to compete in another more lucrative market (e.g. Web development) we better make sure we gain more customers than we lose.
   

Every change brings opportunity.  And those that profit the most from change are those that see it coming and position themselves to take advantage of the change.

We are seeing a lot of change in what is now being offered for Notes development but I am not sure the future of Notes is yet written.  That is because we have separate camps each being motivated by different things

1. IBM: I have long argued that Quickr and Lotus Connections could easily have been added as extensions to Lotus Notes giving both products the power of the rich client experience while still allowing a more universal Web client access.  Of course such an approach may not allow IBM to generate additional revenue streams that new products allow.  IBM also invested a lot of money into developing IBM Workplace.  They can only begin to recoup those costs if they find alternative products into which they can inject this technology.  IBM also has a product portfolio in which the common programing language is largely Java/Eclipse, with the exception of Notes and Symphony.  I am sure IBM want to see Notes form part of an integrated product offering and would love to see all us Notes developers programming in Java of SSJS.  I am sure Xpages is largely being added by IBM as a way of meeting some of these goals.
   
2. Notes Gurus: The Notes community has a relatively small number of people who are constantly finding ways to redefine just what Notes is capable of doing.  The best example of this is Lotus911's Bones project.  Most of the Notes gurus tend to be located in software development companies or large companies which invest heavily in technology.  This group are prominent in our community through blogs, presentations at LotusSphere etc, OpenNTF, and the Design Partner program.  Simply put their voice is probably a lot louder than the general Notes community combined.  It is in their interest to see technologies such as XPages come to the fore.  They are better placed than most to deal with the added complexities of technologies being added to Notes like  Xpages, Java, SSJS, Eclipose, Expiditer etc. and motivated by the superior quality of what they can then produce.
3. The Yellow Blob: Most of us are in a position where we must follow rather than lead.  We work with the version of Notes our employer provides.  We build Notes client solutions when asked for, and Web client solutions when called for.  We do have some influence.... We often do have a significant input into how our assigned projects are architectured and designed.   With XPages and Composite Applications we now have additional choices.  XPages adds a lot more capabilities to Notes but there are a lot of Notes things it still can't do.  It was not designed for Notes but adapted to work with Notes.  It also requires a whole new learning, something not all of us are in a position to do.  It will be up to you to decide the extent to which XPages and CA are adopted in your application design.  Customers don't ask for XPages and more than they ask for Java or LS.  They ask for functionality, ease of use, and performance (oh and for a low cost).  You must decide the most cost effective way to deliver those requirements with the toolset now at your disposal.  You do have a say despite what IBM wants -- you didn't follow IBM's lead with Java for Notes, Workplace or DB2 and IBM did listen.
   

My series of blogs on XPages are entitle "The Good, The Bad, and the Ugly": for a reason.  There is both a good side and a bad side to XPages.  And 8.5.1 probably provides more questions than answers.  There is some really powerful stuff there in 8.5.1 that we should all be pushing to get access to when it is released later this year.  What I can say about 8.5.1 is I do not see either the Notes client or traditional Notes client development going away any time soon.  Lets be clear, 8.5.0 was for Web developers, 8.5.1 is for Notes client developers.  It is public knowledge that 8.5.1 brings XPages to the Notes client.  But what exactly does it bring to the Notes client?  To what extent does IBM plan to bring the many great features already available to Notes application development into XPages.  The NSF container, replication, security, design templates, Rich Text editor, view control, outlines (including drag/drop), shared actions, shared fields, shared columns, personal folders, profile documents, name fields, Sametime awareness, and yes LOTUSSCRIPT.  Having seen 8.5.I have thought a lot these past two weeks about what it means for me.  I do about 95% of my development for the Notes client.  The XPages project I am working on at the moment is to enhance a dual client application in which the existing Web component was a little hokey.  XPages can fix that.  I am not walking away from the Notes client.  I believe strongly in the power of a rich client over a Web browser.  I believe given the chance to deploy and use 8.5.1 not only will I be continuing to do mainly Notes client development but  with the power it gives me I will be pushing to have Notes client applications displace Web-based applications being developed in non-Notes platforms.  Notes 8.5.1 is simply that good.  But it is not (yet) perfect.  In my next blog I would outline my view on what my ideal Notes development platform would looks like.

I am presently working on a project that requires coordination between separate components contained within a frameset.  In Notes 8 this would be considered a composite application but I need to implement this solution in Notes 6.0.  Fortuantely there has been some excellent articles recently posted by Tim Tripcony, Jan Shulz , and Nathan T Freeman on the subject of remote event binding - an important part for creating composite applications.

I have now extended the .Domino Framework by adding a new DominoListener class.  This class is designed to listen for events that occur in a nominated Notes UI class.

Class DominoListener As DominoBaseClass 
 Private iParent  As Variant  ' The object requesting a listener
 Private iTarget  As Variant  ' The UI object being monitored for one or more events
 Sub New(Parent As Variant,Target As Variant), DominoBaseClass(ENUM_CLASS__ABSTRACT  + "DOMINOLISTENER")
 End Sub
 Property Get Parent As Variant
  Set Parent = iParent
 End Property
 Property Set Parent As Variant
  Set iParent = Parent
 End Property
 Property Get Target As Variant
  Set Target = iTarget
 End Property
 Property Set Target As Variant
  Set iTarget = Target
 End Property
End Class

The DominoLIstener class is extended by DominoDocumentListener and DominoViewListener  classes designed to specifically listen for events in NotesUIDocument and NotuesUIView classes.  ( a DominoDatabaseListener may be added later).

Class DominoViewListener As DominoListener
 Sub New(Parent As Variant,Target As Variant)
  Call DominoBaseClass..ValidateClass(ENUM_CLASS__ABSTRACT,"DOMINOVIEWLISTENER")
  If (Not Typename(Target) = "NOTESUIVIEW") Then End
  Set iTarget = Target
 End Sub
End Class

Class DominoDocumentListener As DominoListener
 Sub New(Parent As Variant,Target As Variant)
  If (Not Typename(Target) = "NOTESUIDOCUMENT") Then End
  Set iTarget = Target
 End Sub
End Class

The above classes are all abstract classes and demonstrate the use of a DominoBaseClass covered in a previous blog to implement/enforce class abstraction.

To wire two objects together I need to create a Listener class that defines the events to be monitored and the action to take when the event occurs.  The following demonstrates a single event, but I could just as easily monitor multiple events by adding additional delegates/methods to the code.

Class OpenFeatureListener As DominoDocumentListener 
 Sub New(Parent As Variant,Target As Variant)
  If Not Parent Isa "DominoFeature" Then End
  Set iParent = Parent
  On Event PostOpen From Target Call DelegatePostOpen
 End Sub
 Sub DelegatePostOpen(Source As NotesUIDocument)
  Dim DesignListUIDoc As NotesUIDocument
  Dim DesignListDoc  As NotesDocument
  Dim DesignList   As DominoDesignList
  Set DesignListDoc = New NotesDocument(Source.Document.ParentDatabase)
  Call UIW.SetTargetFrame(ENUM_FRAME_DESIGN_LIST)
  Set DesignListUIDoc = UIW.ComposeDocument("","",ENUM_FORM_DESIGN_LIST)
  Set DesignList = New DominoDesignList(DesignListUIDoc)
  DesignList.Title$ = iParent.Title$
  Call DesignListUIDoc.Refresh()
 End Sub
End Class

The listener is invoked in the parent object with a simple statement

Set Handler = New OpenFeatureListener(Me,Source)

Within a composite application an object may have the need to observe multiple objects.  I have therefore created a DominoBroker class as a container for Listeners.

Class DominoBroker
 Private iListeners As Variant
 Sub Register(Listener As Variant)  
  If Not Listener Isa "DominoListener" Then End
  If Not Isarray(iListeners) Then Redim iListeners(0) Else Redim Preserve iListeners(Ubound(iListeners)+1)
  Set iListeners(Ubound(iListeners)) = Listener
 End Sub
End Class

This is not unlike Nathan's totally cool concept of a unicache.  Ideally I would like to have a single Broker for an entire Notes session, but presently I seem to be constrained by LotusScript to only being able to get a handle on UI objects that are currently active (one NotesUIDocument, one NotesUIView) or when LotusScript code launches a UI object (e.g. UIW.EditDocument).  So far I have only been able to share the love (broker) around between UI objects that have been loaded by a common UI object (class). Documents opened in preview mode from a view, embedded views etc. are a Remote event black hole.

Combining the above with framesets (to contruct the presentation layer) allows me to implement design patterns in Notes 6 very similar to Notes 8 composite applications.  The down side(?) is that I am restricted to only wiring Notes components and only for some very specific scenarios.  On the plus side this is all Notes code with no Eclipse required.

Note: The above is designed for Notes 6/7 only.  Notes 8 provides additional classes to support composite applications as well as a composite application editor.