.Domino Framework

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.

The Good: Themes  - When I first started doing Notes development Forms were the only option for editing data and there were only 8 background colors available  There were some Notes developers who felt they needed to use all 8 background colors if they possibly could in their application.  Slowly the choices for styling a Notes application have improved.  But we have never reached the point where CSS and themes are fully supported.  Even now forms provide only a limited support for CSS on the Notes client and views none at all.  For Web applications a lot of pass-thru HTML is often required.  With 8.5.0 we now have a CSS editor that acts a whole lot better than a text editor.  And with XPages we have a design element that fully supports both CSS and themes. 

For the past few years I have moved away from the idea of having each and every application with its own look and feel.  To do so makes each application a little more difficult to learn.  When applications are combined in a composite application (something I believe we will see a LOT more of) they can look terrible when consistent colors have not been used.  I often felt it was better to have a user select the color/theme they prefer than have a developer or key user select their preferred color scheme.  I like that we now have a design element where we can empower users to make these choices.  It allows a Notes developer to provide a personal touch to their applications.

The Bad: Importing Forms - The first time you see someone from IBM demo how easy it is to import a form into a new XPage you go "wow... that's pretty cool, it even finds creates the labels  and all!!!".  The first time.   After that you start to notice that the labels are derived from the field names themselves and not screen scraped off the form.  You also find that not a lot is brought over for each field.  Radio buttons are text, default values don't exist, field validation is not there, and keyword lists are not brought across, no tab orders, and hidden fields are not hidden.  So while it is a start, be prepared for a lot of work migrating an existing form to an XPage.  In the future I expect someone with strong XSLT skills may find a way to translate DXL into the appropriate XP tags (or at least go a lot further than IBM did).

Random Thoughts:  I believe one of the biggest opportunities for software development in general and Notes development in particular is Services Oriented Architecture (SOA).  Now that Notes has Web Service Providers, Web Service Consumers, and Composite Applications it is becoming possible to integrate Notes and non-Notes applications in a way that the underlying platform becomes less relevant.  This should be a boom for Notes development as Notes can be applied for all those components where its RAD style provides cost effective solutions and Java/.Net can be used for heavy lift applications.  With SOA a homogeneous environment is no longer needed.  So just as SOA potentially provides a way for us to integrate Notes and non-Notes applications it seems SOA may also represent a way in which we can seek to integrate XPage and non-XPage applications.  Got lots of code built in LotusScript, well what if we made the XPage consume that code via Web services.  Got an application that has a lot of cool stuff developed with forms, views etc and need to do an enhancement that only an XPage will do, then perhaps a Composite Application can be used to tie the components together.  This is the approach I am now taking with my new xDomino Project.

Note: Observant people may have noticed I skipped a number in this series.  I now have so many thoughts about XPages for Notes I have started to blog into the 8.5.1 beta forum.  As soon as this information goes public I will publish on this blog site....

The Good: Revealing Your Sources - so far we have covered a lot about the design capabilities and programming, but what about the data?  Again XPages is offering a lot when working with data than was never possible before in Notes.  In 8.5.0  XPages gives us the ability to connect to Notes databases using either a form or a view.  This is a lot like NotesSQL and I guess it gives IBM a way to convert the Notes document model into a set of fixed rows and columns that XPages can handle.  What is new to XPages is that we can define multiple data sources allowing a single Xpage to edit multipe documents.  Using the repeater control we can combine characteristics of views and forms together in a manner similar to some of the more sophisticated datagrid controls found in ASP.Net (e.g. Telerik Radcontrols).  To control the many edits Xpages has events for each Form and for the XPages itself.  And yes, there are usually diamonds found next to datasource definitions which means we also have the power to establish the data source to be used at run-time.

For Data Soures we are only seeing the tip of the iceberg in 8.5.0.  The most recent presentations from IBM suggest future release will support connectivity to XML and relational data sources.  When this happens Notes developers are finally goling to be able to fight back.  If you're like me you have often have been on the defensive with Notes as a strategic platform.  Now you will be able to the provide the benefits of Rapid Application Design with the slickness of Xpages running on Web, Notes, and Blackberry clients, AND you will be able to tap into all that data in SQL Server, Oracle, and Sybase databases and bring it together wioth Notes data.  IBM have tried to provide this a couple of times with LEI Virtual Activities and Notes2DB2 but these never delivered on the promise.  Lets hope we get there this time.  Note: There is an article in the Domino Designer Wiki that outlines how JDBC can be used even now to connect to Relational databases.  Sadly its not for people like me still in XPages kindergarten.

The Bad: All Browsers Are Not The Same: I still have a lot to learn about XPages and also DOJO but I had been kind of hoping that XPages would dramatically reduce the issues with trying to get a Web application looking and behaving the same on all popular browsers.  So far this has not proven to be the case with what I have been doing.  I presenly do 95% of my development for the Notes client so I rarely have to worry about this issue.  But when I do Web client develoipment it always frustrates me the I can get my application toi look fine on one browser and then I can spend almost as much time again getting the application to look/behave the same on all Web browsers.  Thats one reason why I like Notes client development.  I am sure someone will have a comment about this, but I will guess that most solutions will involve doing something additional...  Which is fine, its nice to have a solution but it kills productivity when out of the box a control such as the view control can be so different in IE and FIrefox or even different versions of IE.  I can't wait until we get a new HTML standard and all browsers adhere to it (Microsoft are you listening?)

For now its back to building a few more XPages for the Notes client.  There is a lot I would like to say about XPages in the 8.5.1 context, but I can't.  Those of you in the beta program look out for a few episodes of  The Good, The Bad, and The Ugly that I plan to post in the 8.5.1 beta forum in the next few days.  As soon as I can, I will share this with the yellowverse......

More thoughts as I sat in XPage kindergarten today waiting for the bell to go.....

The Good: Diamonds Are A True Gem - Yesterday I spoke about the VERY VERY large number of components that can go into an Xpage design.  It turns out that many of these attributes have little diamond icons next to them.  In fact I would guess there are probably more diamonds contained in the XPage UI than there are in all the South African diamond mines combined.  The diamond icon is used to denote each place in which a value can be provided either as a literal value or computed.  So what this means is that it is now possible to dynamically set almost ANY attribute on an XPage design at run time.  Ever want to set the width of a column or the column header label dynamically?  Well now you can.  Every want to dynamically disable (or even just disable) an edit control based upon another field value, well now you can.  Ever want to change the color of text based upon the values on a form, well now you can.  Did you ever wish the hide-when formula was a display-when formulae, well now it is.  The formula language use to control these values is SSJS so you can make these formulae as complicated as you wish/need.  If you are like me and you go out of your way to build a design element once in a way that allows it to be consumed by other other applications without the need to change any code then these diamonds are going to be a big help.  Equally, if you like what Notes provides out of the box but just need to change one or two little things then diamonds can also be a big help.

The Bad: What Goes On In XPages Stays In XPages - A lot of the new features found in XPages such as diamonds could be of almost as much value in non-Xpage design elements.  There is no sign at this time that any of these capabilities are likely to be added to existing design elements such as Pages, Forms,  and Views.  These may come at a later stage, but I would not be holding my breathe waiting.  Notes 9.0 should provide a good insight.  Watch to see the extend to which non X-Page design elements get enhanced.  Idea Jam has hundreds of ideas about how.  If they don't make it into this release they may never....

Random Thought:  Does anyone know the history of XPages and where this design element came from? It strikes me that this design element has been developed in too great a level of detail to be a mere 1.0 release.

Slowly but surely this XPage stuff is starting to make sense. A far cry from where I was this time last week...

The Good: This Thing Is BIG I am in total awe in just how much stuff is in this XPage thing (including Custom Controls & Themes).  Its so HUGE that my tiny little brain still has no idea how to even conceptualize much of the stuff that is in there.  Every time I open a door its like it opens into hallway with a whole bunch of more doors (a bit like a scene from The Matrix).  Take for example Custom Controls I spoke about yesterday.  Custom Control properties has ELEVEN tabs each with their own sets of properties and values.  One of these is the Property Definition tab that is used to define the properties.  Once you have properties defined you are then provided with a property tree allowing properties and groups (no idea what they are) in a hierarchical relationship.   For each property there is then another panel with THREE MORE tabs that then allow you to define attributes for the property.  Amongst the things you can define for a property is the data type.  All the basic ones are there such as string, int, boolean, and double.  But then you can pass parameters using a whole swag of complex types (ACL, ACLEntry, Action Listener, DataSource, LinkResource....), Converters, Data Sources, Simple Actions, and Validators.  Dont ask.... I haven't a clue about half this stuff..  So if that is not enough you can also then chose from a large list of editors (think controls) that can be used to edit the property value when it is included in another custom control or XPage.  I imagine I could get lost in just this one little area for weeks.  So if you're the type of developer that likes feature rich design elements I would estimate Xpages alone has more in it than all the other Notes design elements combined.

The Bad: This Thing Is BIG Just as the sheer magnitude of an XPage definition can be seen as a huge plus, it can equally be viewed by others as a minus.  I can see a lot of Notes developers (like me) being intimidated.  At this stage I expect it will take months just to get a basic working knowledge of this beast and perhaps years to truly master (if ever). Notes Developers who come as far as Forms, View & @Formulas are unlikely to make a quick jump into XPages (if at all).  I suspect even a lot of Full-time Note developers who use LotusScript will be intimidated and bawk at taking this on.  Training, documentation, and access to mentors will all be a big help to overcome these hurdles.  It's perhaps a good thing you can still build your apps the same you always have in the past as I suspect there may be more than a few who will.

Random Thoughts:  A lot of my thinking is still stuck on this programming language thing.  I promise I will move on eventually but I think it important to think through before heading off in a particular direction.  Ready... Fire.... Aim....  I posted an idea on idea jam that so far has received almost as many comments as it has votes.  There are some great comments in there too.  The views vary considerably, which is what I expected.  It is early days but I am very curious about how Xpages will pan out.  I have said for a long time that 8.5.1 could very well be one of the most pivotal releases of Notes yet.  And this may well still prove to be the case (even more so than 9.0).

I don't understand the technology behind how XPages is implemented but, it seems IBM may have had the choice to use LotusScript as its server sided programming language for XPages.  Instead it chose to use a programing language not found in Notes development before (SSJS).  Me thinks they have a plan.   It could be that this is being done to allow IBM to better integrate its entire product line.  Yes it may be that IBM unofficially retired LS after Notes 6.  But then I think IBM tried to retire NSF for DB2 and even the entire Notes product for IBM Workplace around this time too.  But we didn't all get the memo, proving it is not always about what IBM wants but also about what market forces allow.  I can see a lot of smart people doing some really cool stuff with Xpages.  But how many will stay behind, that is the question?  The people who read this and other Notes blogs, use Idea Jam etc are probably the ones most likely to make the jump.  Perhaps two forms of  application development  will evolve both within the same NSF container.  If that is the case it will be a shame if there are not migration tools available to migrate forms, views, agents etc into XPages. There is a huge opportunity there for someone....

As for me....  I'm inclined to think I will be  making the jump and hopfeully fully emersing myself in this new XPage technology.  Assuming I am allowed -- I doubt I could stay in the old world, especially if IBM was doing little to enhance it.   If only those Lotus911 guys would slow down so I can catch up.

Week 2 of xpages kindergarten has started on a much sounder footing than week 1.  Still finding heaps of cool things and a few not so cool things....

The Good - Custom Controls:  The coolest thing I have found so far about xpages is in 8.5.1 so we will have to wait.  The 2nd coolest thing I have found so far is custom controls.  These things are absolutely awesome.  Think of the like subforms on steroids.  They are way cooler than subforms for the following key reasons:-

1. An xpage can provide the functionality of a form, view, and page.  So in some ways a custom control is also like hiving a "subview" or "subpage.", a way to define a common set of visual elements that can be included on a group or all design elements in your application.  Do you have a set of actions you would like to make available on all (or some) of your views then think custom control.
2. Unlike subforms, it is possible to include the same custom control more than once inside the one xpage or custom control.  This is a characteristic that is especially useful when using the repeater control (another day).
3. The really cool thing  about custom controls is that you can define parameters that are passed from the parent object (xpage or custom control ).  This allows the custom control to modify its behavior based upon information passed in from above.  Think now about having a super-control in place of a number of less powerful controls.  Just like widgets, plug-ins etc, xpage developers are going to be building and sharing all manner of custom controls that will allow generic functionality to implemented with a simple drag/drop.

I expoect the use of custom controls will very greatly.  Just like LotusScript and subforms today we will have unstructured developers who do not use them at all and we will have structured developers (e.g. OOP) that will create xpages that consist almost entirely of custom controls whose behavior is controlled via parameters.

The Bad: Screen Hog: Xpages are a real screen hog when they are loaded in the new DDE.  There is so much information contained on an Xpage that IBM gives us a total of nine panels that we can use to manage their design.  On the left we have the traditional bookmarks for databases and design elements.  Below that is a new outline panel.  In the middle we have the xpage code itself which is shown in design and source format.  below this are three panels showing Properties, Events, and Problems (another day).  To the right we have our controls toolbox and a Data Source panel.  Even then the properties box often tries to display more information than will fit in the space allocated so I find myself wanting to resize the window to avoid the need to scroll.  This makes my xpage even smaller.

On a typical SXGA monitor (1280x1024) the amount of space left to show the xpage is probably less than 50% of the total space.  On an XGA monitor (1024x768) it is even less.  If you find yourself doing a lot of xpage design and you don't yet have a high resolution monitor I expect you will soon be demanding one.  I went all the way and purchased a 30" wide-screen monitor at home.  I can justify it to myself (and my wife) because it is a huge productivity aid when developing xpages in particular,

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.

.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:

1. 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.
2. Application code is separated into a presentation layer and a business logic layer.
1. The presentation layer is targeted at Notes 6.0+ and contains forms, views etc. to support generic functionality common to many Notes applications.
2. 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.
3. The framework is specifically designed for Object Oriented Programmers but much of the code be adapted/used by procedural programmers.
4. The framework has been designed to allow you or your organization to customize and/or extend.
5. The focus of the framework has been Notes client development.  There is some stuff there for Web development but not a whole lot.
6. 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?

1. 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.
2. 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.
3. 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.

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?