It is still early days in my Xpages learning but one thing has already become very clear. Xpages development is crying out for a framework even more so than LotusScript. It is not yet clear to me how much of my time moving forward is going to be spent doing Xpages development, but the extend to which I do I just know a lot of my time is going to be consumed collecting code from all over the place and consolidating it and combining it with my own code in a way that will allow me to continue to do Rapid Application Development.
It is now clear to me that I need two separate framework. The existing one that is OOP LS based and will support all non XPage development and a separate one that will focus almost exclusively on Xpages and SSJS (and possbly Java and even LS at a later stage). My goal is to at least have a beta posted on OpenNTF sometime soo after 8.5.1 is released.
The current .Domino Framework proect is likely to be extended but will focus on non-XPages development. How much will depend on how much non-Xpages development gets done in the future.
I have now created a community on bleedyellow.com. Anyone who would like to get involved in any way is encourage to join this community (it is moderated but I have super low standards on membership -- If you drink beer or even if you write some form of Notes code your are a shoe in to be accepted). Contributions can include ideas, enhancement requests, code contributions, rolling up your sleeves and building the code, or just telling us what we are doing wrong.
|
New OpenNTF Project - xDomino Framework
|
.Domino Framework 1.0 has been released on OpenNTF under the Apache License (which basically means anyone can use the code for whatever they want). This project was thirteen years in the making. It contains a collection of tools, code, and information to assist Lotus Notes developers build Notes applications.
Resources:
.Domino Framework Project (Download)
.Domino Framework Wiki
.Domino Framewrok Web Site
.Domino Framework Blog
.Domino Framework Community
Points of Note:
- The framework is not an application template. It is a component library. Copy/paste the needed components from the template based upon your own application's needs. A separate application template will be release soon with core components likely to be used in building a new application.
- Application code is separated into a presentation layer and a business logic layer.
- The presentation layer is targeted at Notes 6.0+ and contains forms, views etc. to support generic functionality common to many Notes applications.
- The business logic layer consists of a collections of LotusScript libraries containing 100+ classes that can be used directly or extended by your own applications.
- The framework is specifically designed for Object Oriented Programmers but much of the code be adapted/used by procedural programmers.
- The framework has been designed to allow you or your organization to customize and/or extend.
- The focus of the framework has been Notes client development. There is some stuff there for Web development but not a whole lot.
- The framework is the basis for EVERY notes application I have created or significantly enhanced over the past two years. I estimate its use makes me almost twice as fast developing Notes applications.
What is the significance of a 1.0 release?
- A number of beta releases were made available as a way of testing the water as well as allow other Notes developers to make use of the code sooner.
- Like many 1.0 releases it is going to have issues. Much of the code has been tested in production applications. There are still parts that were started but never finished and/or fully tested. I have left this code there because it may still be of value to others. Over time I would like to think I will get the chance to finish these parts off in later releases.
- I no longer have the need to focus on Notes 6 development. All my Domino Designer clients are now either 8.5.0 or 8.5.1 (beta). I wanted to publish this initial release with code that would run on every version of Notes from 6.0+. I may never get a chance to go back and finish it.
Brief History
I started collecting code for .Domino Framework in 1996 when I first started doing LotusScript programming. Before that I had kept to forms, views, agents and @formulas (yeah I was one of those Notes developers!). I had a research and knowledge management background and quickly collected and stored lots of stuff to help me while I was learning. I soon had so many code samples, samples databases, and bookmarks to Web sites etc. it was getting hard to find specific code as I needed it. This was slowing me down. So I started to build a Notes database I called "Code Central" to hold all this stuff.
During the Dark days of Notes 7 and IBM Workplace I thought it was a smart career choice to move away from Notes. I was presented with a great chance managing a team of C# and .Net developers. This is where I learnt to understand and appreciate the power of OOP. I was particularly impressed with Microsoft's .Net Framework and how it took VB.Net (a language very much like LotusScipt) and took it a whole new level.
Two years ago I found myself back doing Notes development. IBM seemed to be interested in Notes again (yeah). Only now I was convinced OOP represented the future and I needed a framework to elevate LotusScript and my productivity. IBM didn't seem to be doing much with LotusScript (boo) So, for the past two years I have rewritten Code Central from the ground up as an OOP framework.
Contributions
My many inspirations for the .Domino Framework come from hundreds of people in the yellowverse that published code or ideas into the public domain. Unfortunately due to the way the code was developed I lost details about the original sources for a lot of the stuff I had collected. Sorry, I never intended to share this... I have since written almost every line of code in the framework myself to suit an OOP style and to ensure the general style and my own best practices are implemented. Where I can I have tried to identify sources of the original code or ideas upon which it was based. Please,please, please... if you see anything in the framework that you feel you may have played a role in at some time please let me know. It is not my intention to lay claim to anyone else's ideas and I will happily acknowledge your contribution. Even if I never saw your code I don't mind acknowledging your work.. As I have said, I believe I have painfully written each line of the code eventually implemented., but just in case, let me know.
I do want to acknowledge several people who did not participate directly in this project but have provided signifcant indirect contributions (in alphabetical order).
Ben Poole: Ben was kind enough to provide me with an early 1.2 beta of his OpenNTF DominiWki project. I have modified some of Ben's code to suit my own needs but the credit for all the code in the .Domino Framewok Wiki belongs to Ben and his great project. (Note to self: I need to share with Ben some of the changes I made).
Chris Blatnik is one of the Notes UI gurus. I have tried to follow his many ideas. Its not great but the .Domino Framework is distinctly less ugly than the original Code Store.
Damian Katz
did much of the early pioneering work on accessing design elements from
LotusScript. I studied this code carefully before building my own
solution.
Jake Howlett:
has been one of the largest contributors of code to the Notes community
via has codestore.net site. I have followed this site and blogs closely for
ideas and information on how to solve common Notes problems.
Julian Robichaux: I decided to replaced my own error logging solution with Julian's OpenNTF OpenLog project. In my early days I used Julains nsftools site a lot for examples of LotusScript code I could use. I have also incorporated Julian's LS2HTML applet as a developer tool within the .Domino Framework.
Nathan Freeman and the entire Lotus911 team have consistently developed pioneering work in the Notes arena and I have tried where I can to incorporate some of their ideas in the framework. Nathan, Tim, Kevin et al have read my stuff and frequently comment on my work and crazy ideas. Lotus911 also provide the bleedyellow blog site and Lotus Connections community I have been using for this project. Much appreciated guys.
Finally to all those I have not mentioned I would like to thank the entire yellowverse and your willingness to share code and provide comments and feedback to my own blog. These have all been a big help in improving my own limited understanding of Notes development. Even you Java guys!!. I still have a long way to go but I am hoping by publishing this framework I can provide something back to the community as a small thanks for the help I have received these past 13 years in making me a better Notes developer. There has been a lot of yellow blood spilt over this project... Please enjoy.
|
Domino Framework 1.0 Released
|
I don't normally plug my own ideas on ideajam, but this is one I would like to encourage notes developers in the yellowverse to cast a vote. As many of you know from reading my blog I am in the process of learning how to develop xpages. It is still early stages for 8.5, xpages ,and server sided Javascript but I am interested in getting and early indicator based upon your own experiences and insight as to whether or not xpages is likely to change Notes developer programming habits away from LotusScript towards Javascript. Away from forms, views, pages and outlines to xPages. IBM may or may not care but I am certainly interested. It will help me decide what I do next with my OpenNTF project .Domino Framework. Do I continue to focus on LotusScript, do I turn my attention exclusively to xPages and Javascript, or do I focus on both?
|
LotusScript v JavaScript
|
Mary Beth Raven recently posted an interesting article in which she provided some insight into the Release process for 8.5.1and the steps such as string freeze and pixel freeze needed to control quality of the released code. I thought I should take a leaf from IBM's book and introduce similar controls for my own OpenNTF project....
I am therefore pleased to announce that as of last night .Domino Framework 1.0 has entered string freeze.... Those of you have that have seen the betas up close will know this project is largely held together using mirrors and bits of string. We believe that freezing the string will lessen the chance the code will break prior to delivery.
Tomorrow evening the software will enter pixie freeze... I will be sending a team of pixies up to the north pole to gather pixie dust. The hope is that sprinkling frozen pixie dust on the code will make all those remaining bugs disappear prior to release.
The gold code will be posted on OpenNTF over the weekend. I would like to than the millions of .Domino Framework design partners who particpated in our extensive early release program. This project has been 10+ years in the making and I hope that it will assist at least one other Notes developer out there in the yellowverse.
|
.Domino Framework enters string freeze
|
I have chosen to document the .Domino Framework project using a wiki. The wiki is based upon DominoWiki, one of the really cool OpenNTF projects chaired by Ben Poole. If you need a wiki that runs on Notes and support all versions of Notes check this project out... I have extended DominoWIki with some additional features I wanted to make it fit in better with .Domino Framework.
The URL for the wiki is http://www.dominoframework.com/A55C93/DominoWiki.nsf. It forms part of a new Web site I am slowly putting into place for the .Domino Framework. The wiki contains a lot of material about the .Domino Framework as well as a large collection of General Notes development stuff I have acquired over the years. Hopefully it will fill in some of the gaps about the framework and how to make effective use of it.
Note: The wiki still needs a lot of work (both technically and in terms of content) so don't be surprised if a lot of the wiki features break. I will be working hard to fill in the major gaps in the documentation as well as getting the wiki itself the way I want it to. And yes, I do need to work on documenting the source of some of the material contained in the wiki. This was originally just a dump of useful information I had collected for my own use. By placing it in the public domain I now need to ensure that the original sources for some of this stuff is appropriately attributed to the original authors. It would be safe to assume all the non-framework stuff represents the larger yellow universe rather than being my own material (I'll take credit for all the "crap" in there)..
|
.Domino Framework Wiki Available
|
Of all the terms in programming I think polymorphism is one of the coolest. While I cannnot include eclipse plug-in developer on my resume, I think being able to feature a cool term like polymorphism on my resume must be worth an extra $10 for my hourly rate!!!
Polymorphism is a common feature available in most object oriented programming languages such as java, c#, and VB.Net. Search the Domino designer help and you will not find any mentions of this term. In the limited coverage given to classes there are no hints as to polymorphism being available. And yet, it does seem that LotusScript can perform a limited amount of polymorphism.
If you are a LotusScript developer you may not have had the need to ever understand polymorphism (even if it did add $10 to your hourly rate). Consider a simple HR database such as the following:-
Class Person
' ...
End Class
Class Associate As Person
' ...
End Class
Class Contractor As Person
' ...
End Class
Class Manager As Associate
' ...
End Class
I could read a document from a Notes HR-related database and then assign it to a variable that is any one of the above classes. But what if I then wanted to start treating that variable like it belonged to one of the related classes? In C# this can be achieved using casting. It turns out that with LotusScript that the following code is possible:-
Dim Employee As Person
Set Employee = New Person(Doc)
Call Employee.Update()
Set Employee = New Manager(Doc)
Call Employee.Update()
In the above... The first time the Update method is invoked it will call the method defined in the Person class. The second time the update method is called it invokes the method defined in the Manager class (assuming it exists). There are some limitations with this approach. In particular, the properties/methods must all be defined in the base class.
The .Domino Framework provides 100+ custom classes defined so the need for polymorphism does arise periodically and will now be implemented using the above technique (for no other reason than to add polymorphism to my resume).
|
Polymorphism with LotusScript
|
The traditional way to approach formal application development is to create a project, draw up a list of requirements to be included, estimate the effort, commit resources, prepare a project plan, get approval, and then try as hard as possible to deliver the requested changes within the agreed time frame. This approach I call " fixed content" development and forms the basis of most waterfall SDLC's.
The approach works well in many situations but does have its problems:-
- Scope Creep: Whenever someone decides to change the requirements this usually has an impact on the project causing delays in delivery and cost overruns. Participants in the project often have conflicting priorities when trying to resolve these changes.
- Delays: If the project stops going to plan for any reason (including scope creep) there can be a ripple effect across this project and onto other projects that are interrelated because the applications interact in some way or because resources are shared across multiple projects. This often results in changes being required to project plans for one or more projects and can lead to issues with resource availability. The most like change is to make the project late which then can lead to other projects being delayed.
In many organizations Lotus Notes tends to be implemented as a solution for small-medium sized applications. Notes application development is often way faster than other development platforms. As a result, the typical Notes developer is often working on a much larger number of projects in a given timeframe than say a Java or C# developer. Notes developers are therefore more likely to have to deal with the issues that arise whenever one or more of they projects fall behind schedule. Many SDLCs simply do not apply well to Notes development.
In order to address these issues I have been slowly trying to adapt my approach to demand/project management by focusing more on what I call "fixed time" development. This is an adaptation of some of the newer agile methodologies, in particular SCRUM. The following is a brief outline of how this works:-
- Projects are now broken down into fixed time cycles/units (aka Sprint). In my case I find a week is a workable unit for the Notes applications I develop/support. In a given week I can typically spend 60-80% of my time on "new development". The remainder goes in to administrative tasks, addressing QA defects, and performing releases etc. So a weekly cycle roughly equates to 25-30 hours per week. (It is charged as 40 hours to cover those other costs).
- When a project is assigned we allocate a fixed number of cycles and we provide an assessment of how many requests can be completed in that cycle. Note: For any one application there is often more requested features than can be delivered so these are added to a backlog queue.
- Now when development starts we either add or subtract requests based upon the developers burn rate during the course of the week. No matter what development for that cycle is completed at the end of the cycle (week).
- If we are falling behind schedule we also have the option of adding additional resources and/or increase the hours worked for that cycle. This is not required but an option that can suit some circumstances.
- If a project consumes more than one cycle then QA can start with the output from the first cycle so that QA issues can be addressed as part of the next cycle. If is suits the project then the output from each cycle can be released into production so that users of the application can take advantage of the added features without having to wait for them all to be completed. Note: This is not a requirement, but an option where it makes sense.
- For really really small projects, two (or more) could be scheduled in a single cycle.
The advantages of the above approach include:-- Because we always hit our delivery time the organization does not consume significant amounts of time changing project plans and working out how to juggle projects/resources that are downstream from this project.
- Projects almost always come in on time and on budget! Sometime we may not have all the features we had originally hoped, but sometime we have more.
- If a customer/analyst chooses to make late changes to requirements they do so knowing that it will probably come at the cost of something else getting bumped. Its surprising how this seems to moderate the number of changes requested and sets more balanced expectations!
- Life is so much easier to plan in advance when every project is running in fixed units. e.g. Meetings etc can be booked well in advance because we have a greater degree of certainty of exactly when things will happen. A meeting room can be reserved for the same day of every week.
- My future availability is so much easier to represent as I have weekly cycles into which sprints are allocated. Rescheduling involves juggling my weeks, not reworking milestones for each and every project I am involved.
- Applications are typically enhanced by smaller more frequent releases. Users are more likely to be more flexible with what they require because they know if it is not done now it will be in the next release in the not too distant future. Feedback from smaller releases can be applied before we develop the functionality of the next release. With organizations constantly in change we are less likely to deliver features that are no longer relevant.
The above is not suited to all projects or even all developers. For this Notes developer it does seem to work, making me more productive and reducing stress from trying to constantly juggle the many conflicting demands from various stakeholders in the large number of projects I am assigned.
Note: I presently have a new OpenNTF project called .SCRUM that aims to provide a Notes application capable of assisting in the management of projects using a modified form of SCRUM such as the one above. It will be a Notes 8.5.1 application and based upon the .Domino Framework 2.0 project I am kicking off July 1. For now I am working on refining the business process before I write too much of the code. Anyone who wishes to share there own experiences please do as I am sure there are a great many tricks/techniques that can be accommodated within .SCRUM as it is built.
|
Fixed Time v Fixed Content Development
|
From time to time I get requests to create a view in a Notes applications that shows the first or first x documents (only) for each category in the view. Out of the box there does not appear to be a simple way to do this as the selection formula for Notes views is executed against the document data and not against the view data itself. It would be kind of nice if one day it became possible in Notes to add view filtering that ran against the view results allowing us Notes developers to do such things as only show those categories where the document count is greater than 1, only show categories where the average is within a certain range, or only show the first x for each category. With SQL this is a breeze.
Last week I presented the concept of a building datasets (Part 1, Part 2, Part 3) and how this can be used to create a runtime version of a view that can get rid of some of the limitations commonly encountered with standard views. The components to build this are being included in the .Domino Framework. I have now extended this concept in the .Domino Framework to allow for the creation of a dataset in which it is possible to specify that the dataset only contain the top x documents for each category. The resulting dataset can then be saved in a folder allowing the results to be displayed as part of the application. With one application I have the data in the folder can refreshed on a daily basis using an agent. With another I have set the QueryOpen event of the folder to refresh each time the folder is opened. I am working on one final tweak to be included with the 1.0 release of the .Domino Framework. This provides the ability to nominate if you wish to display the top x per lop level category or top x per subcategory.
|
Show Top X Per Category
|
In Part 1 and Part 2 I presented the opportunity to add functionality to applications by generating a collection of data (dataset) at run-time and presenting this data within a Notes application as a datagrid. Using this technique it becomes possible to do such things as embed multiple category views, display the top 5 x by category, or generate dynamic columns based upon logic built into a form. The components to implement this in the .Domino Framework are based upon Notes 6.0 (Form, View, Folder, LS Class).
In July I will be starting work on .Domino Framewok 2.0. This new version of the framework will be targeted specifically at Notes 8.5.1. (I previously blogged about bypassing 8.5.0 and whilst a year has now passsed my views havent changed about this). One of the first things I want to do with 2.0 is extend the concept of datasets/datagrids even further....
In .Domino Framework 2.0 the process for building a dataset will be converted to a Web service. The Web service will then return a Notes URL that correspons to either an existing view/folder that can be used to view this dataset or a folder that has been dynamically generated by the Web service. This takes the task of (potentially) building a document collection away from the Notes client and places it on the Domino server. What it also means is that I now have a simple way to build a dataset in one Notes database and pass it to another Notes application where it can potentially be embedded in a frame, form, page, or XPage. This may not always be the most efficient way to achieve the end result, but in implementing an SOA approach, it eliminates the need to customize views in application A to meet the needs of Application B.
|
Adding Datasets & Datagrids to Notes Applications ...
|
In part 1I discussed the concept of a dataset and how it can be applied to Notes application. While Notes views are a representation of a dataset I wanted to focus on the opportunities of generating the dataset at run time. e.g. it becomes possible to take input from the application/user to build the data collection.
Internally, the easiest way to represent a dataset is a NotesDocumentCollection. One of the issues with this class is there is presently no easy way to store such a dataset, even for the duration of a session. Nor is there an easy way to display its contents within an application. Notes provides views/folders as the only effective way of displaying a collection of documents.
- Views have a number of issues.. The contents of a view are based upon a specified selection formula. Once created a large amount of server resources are devoted to manitaining the contents of views each and every time the contents of database change. For this reason the number of views in an application (especially large applications) should always be kept to a practical minimum.
- Folders seems a much better match for a dynamic run-time dataset as they provide the same basic look/feel but do not carry an overhead to maintan their content. The process of taking a document collection and adding it toi a view is a very simple one.
The .Domino Framework's DominoDataset class provides a Rebuild method which takes a dataset and gives it a phyiscal form using folders. We tare then able to mimic the functionality of a datagrid control using the Notes folder control which can be displayed directly or embedded on a form or page. To maximize flexibility options exist to:-
- Recognize a dataset that already exists as a view
- Allow a specific (existing) folder design element to be used.
- Allow an existing view/folder to be used as a template for a new folder
- Build a new folder from scratch based upon the field defined in the dataset
'/**
' * Place the dataset into a folder so that is able to be displayed
' */
Function Rebuild() As NotesView
Dim Collection As NotesDocumentCollection
Dim Column As NotesViewColumn
Dim Entries As NotesViewEntryCollection
Dim FieldIndex As Integer
Dim Dataset As NotesView
' Locate exisging view/folder
Set Dataset = iDocument.ParentDatabase.GetView(Me.Foldername$)
' For folders, empty the content
If (Not Dataset Is Nothing) Then
If (Dataset.IsFolder) Then
Set Entries = Dataset.AllEntries
Call Entries.RemoveAllFromFolder(Me.Foldername$)
End If
End If
' Add documents to folder
If (Dataset.IsFolder) Then
Set Collection = Me.AllDocuments
Call Collection.PutAllInFolder(Me.FolderName$)
Set Dataset = iDocument.ParentDatabase.GetView(Me.Foldername$)
' Set folder name and alias
If (Dataset.Aliases(0) <> Me.FolderName$) Then Dataset.Aliases = Me.FolderName$
If (Dataset.Name <> Me.Title) Then Dataset.Name = Me.Title$
' For dynamic folders, refresh design of folder.
' If a template view is provided, refersh from that else build the folder design based upon the dataset definition.
If (Me.StoreData$ = ENUM_STORE_DATA__DYNAMIC_FOLDER) Then
If (Me.TemplateView$ = "") Then
If (Not Isempty(Dataset.Columns)) Then
Forall ExistingColumn In Dataset.Columns
Call Dataset.RemoveColumn(ExistingColumn)
End Forall
End If
Forall NewColumn In Me.Fields
Set Column = Dataset.CreateColumn(Dataset.ColumnCount%+1,Cstr(NewColumn),
|
2
34
0
|
Title
|
Most Recommendations
|
Most Comments
|
Most Visits