IBM®
Skip to main content
    Country/region select      Terms of use
 
 
   
     Home      Products      Services & solutions      Support & downloads      My account     

developerWorks  >  Lotus  >  Forums & community  >  Best Practice Makes Perfect

Best Practice Makes Perfect

A collaboration with Domino developers about how to do it and how to get it right in Domino

I've witnessed debates -- sometimes fairly heated -- about the proper way to store the "business logic" relating to a form. I wanted to introduce the subject here because it's always fun to watch a good fight.

"Traditional" development for the Notes client generally entails storing the logic that relates to a specific field, along with the field. I refer to the default (or value) formula, input translation, input validation, Entering, Exiting and Onchange events. Some of these events can be written in JavaScript also, making them applicable to Domino web applications. (Technically, default, translation and validation formulas can also be used for web apps, but the user experience with input translation formulas, at least, is not up to modern standards of web design).

However, those who are versed in software engineering principles, often want to apply the MVC pattern to designing for Notes; and this involves keeping the logic of managing the data and extracting meaning from it, separate from the design of the user experience. The ideal here is that whether the data are accessed through a form, a view, or an agent, the same code handles the transaction, so when there is a change there's only one place that needs to be updated.

The obvious way to apply MVC to a Notes client application is through a script library that represents the data on a form. You might have a class whose constructor accepts a document as argument, and performs manipulations on that document (perhaps another class would handle locating and organizing documents that use that form). Rather than having an input validation formula on a form, you would have methods to update the values of individual fields. This class would perform the input translation and also update related fields (where in the traditional model you might use a computed field formula), and would refuse to perform the update if this would result in invalid data (instead of using a validation formula). So the logic on the form would be reduced to calling methods of these classes.

This has some obvious advantages when you write agents, for instance, because it becomes simpler to make sure your computed fields get updated when you change another field that affects them.

However, it also violates the paradigm of Notes as a rapid application development platform. By adding layers of code, you reduce the flexibility of your application and the ease of copying and modifying applications to suit yourself. With the traditional techniques, if you copy a form, you are also copying the logic associated with that form, so it's quite easy to create a similar form in another database, or to create a slight variant of an existing form, without having to find and copy and customize additional design elements. If you copy a field, you are also getting the formulas and events associated with that field (which you might not always want, but it's easier and less error-prone to remove or modify them by clicking on the field, than to locate the appropriate code in a script library and copy that into a new script library). In addition, of course, you often have to work quite hard to effect the business logic in the Notes client from a script. For instance, there's no way for script code to directly supply values for a keyword list -- obviously the list of valid values is part of the business logic, and you would want to manage that in your model code, not on the form.

Likewise, a view accesses the items of the documents directly via formulas, and may transform those values for display. Under MVC, the code that calculates what appears in the columns should not be part of the same design element that controls the column widths and fonts.

This sort of thing is a little easier to apply if you're designing a web application, where you can just not use a form if you choose, but instead write agents to generate the HTML for whatever web page you wanted to put out, receive and process the post data, etcetera. If you do this it begs the question why you're using Domino in the first place. If you bypass everything Notes does to help you manage the data, you might as well write your application using a development environment that allows you total control at every step of the process. I feel that if you're fighting against the development environment to make it do what you want, or bypassing major parts of the supplied functionality to write your own versions of things that are already supported, something is probably wrong with your approach.

Using MVC in Notes/Domino also violates another key advantage of Notes -- the relatively low barriers to doing Notes development. If you create an application that software engineers will love, the drawback is that only software engineers will be able to maintain and extend it. Many Notes applications were developed by people without formal IT training -- often by taking the supplied templates and adding fields and views. This is both a blessing and a curse. While I'm certainly among those who complain loudly about the boneheaded things novice developers do that wreck performance or result in a less than optimal UI, it's well to remember that an application doesn't have to be perfect to be useful, or to be a lot better than whatever process it replaced.

I think the ability for the department secretary to create an application for the department after reading some book, is far more important to the success of Notes than adhering to a strict software engineering discipline. I think we are better advised to bend our efforts to reducing the amount of trouble novice developers can get into, by providing better education, and better free tools for developers and administrators to apply to applications to discover problems and assist in correcting them.

Andre Guirard | 29 January 2008 08:00:00 AM ET | Plymouth, MN, USA | Comments (15)


 Comments

1) A maxim I’ve followed for a while...
Nathan T. Freeman | 1/29/2008 8:54:47 AM

...is that Notes should make it hard, but possible, for someone to screwup big time. Most of the barriers-to-success come from trying to overly constrain the user by simply making things too hard to accomplish.

An example of making it hard for a user to screwup big time would be: Defaulting the WindowTitle formula to field value Form. An example of making it possible for a user to screwup big time would be: allowing @DbLookup in a view column.

As you showed with your Developer's Friend application, there are a million small things that are Best Practice habits that we should all get into to make our code complete. And yet we don't -- and probably WON'T unless it becomes easier to do so within the product itself. For instance, there's simply no way I'm going to write an @Trim translation formula for every text field I put on a form. It's too much of a pain in neck. And it's the Designer team's responsibility to make this obvious practice more realistic for developers. (And I know it's on your radar.)

Designer has ignored assisting developers in best practices for FAR too long. So in this case, when you talk about not exploiting the RAD capabilities of the platform, I find myself thinking "physician, heal thyself."

2) Paradigms for their own sake
Tim Tripcony | 1/29/2008 9:30:15 AM

I think this is a good example of needing a business justification for everything we do. If we're using MVC just to use MVC, our users will hate us. If we find that's the best paradigm for delivering quality applications in a timely fashion, they'll love us. While I love the premise of n-tier, the reality is - as you pointed out - there's always going to be some occasional overlap, and jumping through additional hoops in an attempt to be absolutely true to some development paradigm is an investment that is generally unlikely to produce sufficient returns... particularly if it means reinventing a wheel that Notes/Domino happen to handle perfectly well if allowed to do so.

3) Yes and no...
Jim Roysdon | 1/29/2008 9:54:40 AM

I guess I see both sides of that argument. First, Notes/Domino can be great for the department secretary for develop a small, single user or low user application. Then again, she could do this in MS Access just as well (we've all seen it done). However, Notes/Domino is also used to provide enterprise wide, multi-user complex applications. So, something like a MVC approach can be useful.

4) On separating logic from presentation
Kerr | 1/29/2008 10:13:29 AM

"If you create an application that software engineers will love, the drawback is that only software engineers will be able to maintain and extend it." Drawback?

;)

"I feel that if you're fighting against the development environment to make it do what you want, or bypassing major parts of the supplied functionality to write your own versions of things that are already supported, something is probably wrong with your approach."

I tend to find that I'm fighting Domino more often than I should. Am I just doing it for the fun of it, or is it just difficult to get the desired results any other way? Most of the time I feel like Domino is getting in the way and that if it stopped trying to do so much I'd be a lot happier. The basics of what make the core system are great, but sometimes there's a whole lot of cruft that I just don't want. Let me just ignore it rather than have to wrestle with it.

I'm looking forward to having a play with XForms. When's that 8.5 beta coming out? :)

5) mvc makes debugging easier
Joseph LeMay | 1/29/2008 10:47:50 AM

I always try to put as much code as I can in agents and script libraries, not just for organization's sake, but because it's easier to debug things if you don't have to reload the form every time you make a change. That said, I'm still going to take full advantage of the great @ functions that the developers at IBM have taken the time to write for me. @Trim and @Unique are good examples.

6) Depends on how complex the application is
Julian Robichaux | 1/29/2008 12:04:12 PM

For a relatively simple application -- a few forms and views with not too many fields -- putting all the code in at the field/column/whatever level isn't bad at all.

The more complex your application gets, though, the more tedious and fragile it is to have all the code scattered throughout the individual elements of a database. There are plenty of forms "in the wild" that have over 100 fields on them. Trying to manage field translations and validations and whatnot on that many fields is a nightmare. Especially when the business logic changes (yes, on rare occasions a customer will change their mind about something).

I would love to have an easy way to "inject" event code into specific fields on a form. As always, it would be nice to have both -- the way it works now AND MVC. ;-)

7) thanks a lot, andre
tom | 1/29/2008 12:05:27 PM

So... I walked into the "Ask the Developers" room and asked a guy (I think his name was Andre) whether I should go to the developers keynote or "Object-Oriented Programming OOP) with LotusScript – Take It To the Next Level."

He told me to go attend the OOP session instead of the keynote. Now I know he was just trying to get rid of me.

8) Practicality over theory
Peter Presnell | 1/29/2008 12:19:45 PM

I was very interesting to read your post. I have struggled with this same dilema for quite a while. Having done some ASP.Net development where models such as MVC are used I have often wondered how that would apply to Note development, especialy for thick (Notes) client development. The conclusion I have reached so far are very similar to your own. Taking all the business logic off a form may be great from a theoretical view but creates a lot of issues from a practical point of view.

1) Productivity

2) @Formulae cannot call LotusScript libraries to innvoke the business logic. So no @Formulae in this model??

3) Productivity

4) A lot of the built in features of Notes such as default values, input validation etc should no longer be used.

5) Productivity

oops

6) I almost forgot... Productivity

But then the same can also be said for the theory of N-tier architecture itself(from which MVC is an extension)... How do you build a Data Access Layer with Notes when the data is deliverd directly from the NSF to the form/view without any code??? Perhaps conventional software architecture models simply do not apply in the Notes world. They have many good ideas which can be adopted in the Notes worl but the entire model (I think) cannot be implemented without paying a HUGE cost.

9) To use MVC or not to use MVC
Thomas Bahn | 1/29/2008 1:55:42 PM

First, as our session got mentioned, you can get the slides and demo db here:

{ Link }

We showed one possible and working solution for implementing an MVC framework for Notes/Domino applications. It's the way, how we do MVC in Notes development: we have developed a framework of some classes in script libraries and we use the form as View (as View in MVC, not NotesView). It's not pure MVC - way not-, but it's a pragmatic approach.

The two main benefits we get from this framework is increased speed in development and a very good maintainability. Reduced time for development translates to reduced costs, as does increased maintainability. And this is, why we do it.

As a consultancy offering the development of custom application leveraging the Notes/Domino platform, we have to compete with products. Customers are very cost sensitive these days, and to sell custom applications, we have to be "near" the price of a product. Therefore we use everything available to reduce the amount of time needed to build that applications - but without reducing their quality: poor quality leads to more work for us or - even worse - to a lost customer.

At isn't that, what slack is about? Working less to get better results? :-)

@Andre:

"However, it also violates the paradigm of Notes as a rapid application development platform."

It depends, how you define a RAD platform, doesn't it? We are now faster then before using our framework.

"By adding layers of code, you reduce the flexibility of your application..."

On the contrary, adding layers (normally and in our case) increases flexibility.

"... you reduce ... the ease of copying and modifying applications to suit yourself. With the traditional techniques, if you copy a form, you are also copying the logic associated with that form, so it's quite easy to create a similar form in another database"

The time needed to find and copy the additional two script libraries is negligible, really. And didn't you forget the shared actions, subforms, shared fields, image resources, etc. which should be copied to the target database as well?

When I create a new form, I start duplicating two script libraries and a form. Then I use a simple search and replace on each script library and rename them (this process could be automated, but isn't so far). Then I rename the form, change the used script library and one line in the QueryOpen event.

"In addition, of course, you often have to work quite hard to effect the business logic in the Notes client from a script."

That's why we chose the pragmatic way, not to implement everything in the model. We still use computed fields, @DbLookups, default and input translation formulas. This is using the tool as it was meant to be used. But we took these functionality, for which it made most sense, and put it into the model class - or the controller.

"Likewise, a view accesses the items of the documents directly via formulas, ..."

We just ignore views in our MVC equtation for the reasons you give. Again, not pure, but pragmatic.

"This sort of thing is a little easier to apply if you're designing a web application, ..."

We still use forms and views and those stuff for web development, but add a WebController class and the same model class as in the Notes client app case.

"Using MVC in Notes/Domino also violates another key advantage of Notes -- the relatively low barriers to doing Notes development."

This is possibly the point, where our points of view differ the most.

First: Even if our applications use the MVC pattern, nobody is hindered to create another application from scratch or as a copy of a in-the-box template.

But if we develop and maintain an application - and this is regardless of the used paradigm, with or without MVC, etc. - we would not want any untrained person to mess it up. At least, as long we are made responsible for the app.

"If you create an application that software engineers will love, the drawback is that only software engineers will be able to maintain and extend it."

This can, but need not to be true. And it depends on how far the modifications go. Adding some fields or validation is nearly as simple as the "normal" approach.

And using a framework is another thing than creating it. If it's well designed with good named methods, if there are plenty of examples, how to use the methods all over the application, even a little-trained Notes developer can use it. But extending the framework should be really left over to "software engineers" or experienced Notes developers. The benefit of having a framework is, there is a quite clear border between framework classes (which shouldn't be touched normally) and app-specific classes, which can be modified as needed.

"Many Notes applications were developed by people without formal IT training -- often by taking the supplied templates and adding fields and views."

As I wrote: don't mess with my apps, until you have a decent understanding of what you do - and this depends on your knowledge and experience, not formal qualifications. Adding fields and views is nearly as easy as in "normal" applications - at least with our framework.

"This is both a blessing and a curse."

Can't agree more. I had to "clean up" some of the ugliest - not (only) in the UI - Notes applications ever made (as far as I believe :-) ) And who benefits of these kind of applications? How are the costs for these kind of applications OVER TIME? Wouldn't it be more cost-effective to train your staff properly before let them create Notes applications? Still, those developers don't have to use an MVC approach for their applications.

"I think the ability for the department secretary to create an application for the department after reading some book, is far more important to the success of Notes than adhering to a strict software engineering discipline."

In my opinion you are true and false here: Those apps build by a secretary (or other untrained developers) are good, but can be a real danger of the success of the Notes/Domino platform, too. People tend to associate the UI of an application to the platform itself. And with some ugly, very basic, perhaps not in all cases working, badly designed Notes apps, the Notes/Domino platform itself is perceived as ugly, very basic, not working and badly designed.

And applying a sound, tested, time-proven best practice approach for interactive applications (you know, I mean the MVC design pattern :-) ) to Notes applications isn't bad for the success of Notes, is it?

"I think we are better advised to bend our efforts to reducing the amount of trouble novice developers can get into, by providing better education, and better free tools for developers and administrators to apply to applications to discover problems and assist in correcting them."

I absolutely agree with you here, but I can't see a contradiction. Providing education and tools AND using a good framework (perhaps MVC based) is better than doing only one or the other.

@2, Tim Tripony:

"I think this is a good example of needing a business justification for everything we do."

You are sooo right. And increased productivity and reduced maintainance cost are a good business justification, aren't they?

@3, Jim Roysdon:

Again, couldn't agree more with you.

@5, Joseph LeMay:

That's what I mean. And may I add: It's easier to understand a form, if all relevant code is in one place instead of scattered around in all different kind of event handlers.

@7, tom:

I'm so sorry to read, you didn't enjoyed the session. Please feel free to email your complains about it, thus I can possibly make up for it.

My email address is: tbahn@assono.de

By the way, have you downloaded and examined the demo database yet? There is a lot more in there, than we had shown and explained. Watch out for the "... utils" script libraries for "non-OO" utility functions.

10) I’d like to see...
Charles Robinson | 1/29/2008 2:39:17 PM

The ability to act on field events from a LS class. That would help separation of business logic from the UI. Since Field isn't a real Notes object class you can't use On Event with it.

11) re: thanks a lot, andre
Andre Guirard | 1/29/2008 2:46:45 PM

Hm. I didn't realize that session would be all about MVC. I'm going to have to look it over myself and see whether I'm persuaded by their approach.

It's frustrating that when I'm working the conference, all my time is spent in the lab, in meetings with my co-workers whom I seldom get to see otherwise, and preparing for my own presentations. I don't get much chance to attend other people's presentations.

I'm sure the session had some good take-aways even for developers who don't mean to use MVC. Good OOP technique is very important, even without MVC. I seldom write anything of any complexity without using OOP.

12) Hitting the square nail on the head into the round hole
Kevin Pettitt | 1/29/2008 4:26:27 PM

@Andre: Well put! Considering the spaghetti-code I've inherited occasionally from "real" programmers, I've basically concluded that applying ideas like MVC to a project is often just an excuse to code for job security.

@Thomas: First, let me say love your work and but for time constraints would have included your framework db in our "Templates Templates" presentation...

You wrote: "The time needed to find and copy the additional two script libraries is negligible, really. And didn't you forget the shared actions, subforms, shared fields, image resources, etc. which should be copied to the target database as well?"

Since you acknowledge Andre's point about Notes development being approachable by non-programmers, I almost thought the above statement was meant as a joke. Assuming not, I would just make the point that novice developers would generally NOT consider the need to track down multiple dependencies of this sort "negligible". I know - I started out as one 12 years ago. The fact is many of them never receive training, formal or otherwise, so keeping the logic as self-contained as possible is highly desired *if* the goal is to make your code usable by these folks.

This indeed is one of the guiding principles of the SuperNTF framework, which is specifically designed to be given to a novice (not to be confused with "idiot" mind you ;-) ) with minimal risk of "breakage".

13) refactoring tools needed
tom | 1/29/2008 5:33:54 PM

@Thomas Bahn

I was kidding (kind of). Andre did send my to your OOP session but in reality I found it pretty cool.

I would probably be more willing to code that way if the Domino Designer had better refactoring tools.

14) Untitled
Thomas Bahn | 1/31/2008 11:01:02 AM

@9, Charles Robinson

THAT would be cool. By the way, I don't see any reason, WHY Field is such a crippled class.

@11, Kevin Pettitt

We have different goals, I think. SuperNTF is a great collection of very useful ideas and their implementation. one can use as basis for own developments or as a resource to pick from.

We did our framework to lighten and accelerate OUR development work. And since we thought (and think), that the pragmatic MVC approach we took could be beneficial for others, we applied for a LS session to tell about it. It was never intended to be something like SuperNTF - although it has certainly some potential.

"I've basically concluded that applying ideas like MVC to a project is often just an excuse to code for job security."

Interesting conclusion: Applying a best-practice approach only for job security. ;-) Okay, I understand, what you mean, but I doubt the "often". At least in our case, it's absolutely not the case.

"..., I almost thought the above statement was meant as a joke."

What I meant, not all Notes applications need to be based on the MVC framework template. The non-programmer can still create new apps from scratch or from the templates "in the box". But not all advanced and complex applications need to be open to be edited by non-programmers, neither. You wouldn't let someone repair or modify your car, just after reading some books, would you? Nowadays even changing the back lights of my Audi A4 should only be done by pros (according to the manual).

And teaching someone, who already knows LotusScript, to USE a framework isn't to hard nor time-consuming. It's even simpler, when the framework is consistent and a good documentation exists. In our case, each form depends on two LotusScript libraries: "Class <FormName>Controller" and "Class <FormName>Model". And we create a documentation using ls.doc automatically, thus the classes of the framework and their (public) methods and attributes are well documented and the documentation is easily accessible.

@12, tom

Refactoring - what a dream - THAT would be cool. But with inheritance of design elements to other applications, refactoring would be probably limited to the current database, limiting its usefulness.

For easy and fast access to classes and their members in the Domino Designer we propose using the Class Navigator from the NotesHound tool set.

Not so fast, with another focus (all LotusScript from a database) and free is the LotusScript Browser from TeamStudio.

15) Replies
Thomas Bahn | 1/31/2008 11:01:36 AM

@9, Charles Robinson

THAT would be cool. By the way, I don't see any reason, WHY Field is such a crippled class.

@11, Kevin Pettitt

We have different goals, I think. SuperNTF is a great collection of very useful ideas and their implementation. one can use as basis for own developments or as a resource to pick from.

We did our framework to lighten and accelerate OUR development work. And since we thought (and think), that the pragmatic MVC approach we took could be beneficial for others, we applied for a LS session to tell about it. It was never intended to be something like SuperNTF - although it has certainly some potential.

"I've basically concluded that applying ideas like MVC to a project is often just an excuse to code for job security."

Interesting conclusion: Applying a best-practice approach only for job security. ;-) Okay, I understand, what you mean, but I doubt the "often". At least in our case, it's absolutely not the case.

"..., I almost thought the above statement was meant as a joke."

What I meant, not all Notes applications need to be based on the MVC framework template. The non-programmer can still create new apps from scratch or from the templates "in the box". But not all advanced and complex applications need to be open to be edited by non-programmers, neither. You wouldn't let someone repair or modify your car, just after reading some books, would you? Nowadays even changing the back lights of my Audi A4 should only be done by pros (according to the manual).

And teaching someone, who already knows LotusScript, to USE a framework isn't to hard nor time-consuming. It's even simpler, when the framework is consistent and a good documentation exists. In our case, each form depends on two LotusScript libraries: "Class <FormName>Controller" and "Class <FormName>Model". And we create a documentation using ls.doc automatically, thus the classes of the framework and their (public) methods and attributes are well documented and the documentation is easily accessible.

@12, tom

Refactoring - what a dream - THAT would be cool. But with inheritance of design elements to other applications, refactoring would be probably limited to the current database, limiting its usefulness.

For easy and fast access to classes and their members in the Domino Designer we propose using the Class Navigator from the NotesHound tool set.

Not so fast, with another focus (all LotusScript from a database) and free is the LotusScript Browser from TeamStudio.

16) Not everyone codes for job security
Kevin Pettitt | 1/31/2008 2:18:55 PM

@Thomas - of course it sounded like I was lumping you into that bucket but for the record I was not. There are certainly very valid reasons to sometimes adopt more advanced approaches to development, particularly to deal with highly complex applications. I have done this myself and it is a great way to keep a larger development team working smoothly. It sounds like you have taken the notion much further.

Unfortunately, I have often found myself following behind developers who embraced complexity for its own sake and not because requirements demanded it. Not to single out MVC, but there typically was some attempt in these cases to use smoke and mirror buzzwords to justify why that complexity was necessary. Someday I'll do a session on "Forensic Notes Development" that would be all about techniques for dealing with inherited spaghetti code :-).

17) About frameworks ...
harkpabst_meliantrop | 2/5/2008 8:04:08 AM

I sometimes feel like we're living in a constant state of framework-mania. Everyone who's been asked to write a Java program today, seems to feel the rush to implement a new framework, first. That's for one. Also, I'd like to remind anybody of a classic keyboard shortcut: Got a new problem? Press Ctrl+N.

But (and this but is my main point): There is plain nothing wrong with adopting the technique advocated by Assonos (or maybe even just parts of it) for any non-trivial application.

Spaghetti code? Just not so, if you adhere to OO principals. Have a look at the (admittedly ages old) registration database sample in the sandbox, if you want to see unmanageable spaghetti code and all the ugliness of global variables.

Developers not being able to spot dependencies of two (always about the same) script libraries? Those shouldn't code in LS anyway. And as Thomas already pointed out: How do they cope with (computed) subforms, shared fields, shared actions, images resources or inheritance on a per-design note basis?

If you want to see a framework, that /really/ went way over the top, have a look at the (old?) IT Factory stuff. (Apparently, they are still in business, but I have no idea, if there current stuff is still based on Notes). Dog slow, only maintainable through their own tools (if at all) and incredibly complicated to even configure.

I'm also pretty sure, that the fact that Andre posted this so shortly after Lotusphere was by pure coincidence. I'm confident that once he finds the time to have a look at the presentation and demo db, he will agree, that this approach - while probably not required for everything - is very usable and pragmatic and indeed a proof, that MVC in Notes not necessarily is a bad idea.

To sum it up in one sentence: The published work of Bernd and Thomas has sort of redefined my concept of good application development in Notes.

 Add a Comment
Subject:
   
Name:
Comment:  (No HTML - Links will be converted if prefixed http://)
 
Remember Me?     Cancel

Search this blog 

Disclaimer 

    About IBM Privacy Contact