Building extensible applications
One challenge that all Notes developers, including the IBM template team, face is the customer's need or desire to customize given applications. Warren started to ask if that is a good thing. With a little planning you can design your applications so they can be easily customized without creating an upgrade nightmare (it still might be a bad dream). A very interesting example for such a "upgrade-save" extension is actually the Domino Directory (a.k.a the Name and Address book). It contains for people, groups etc. subforms that are empty. IBM will *never* touch these subforms. They are designed for schema extensions. So when you change these forms to contain additional fields, code or actions a system upgrade never will overwrite them (you need to follow some instructions to be save). In your own applications you would have these additional subforms so your customers can add functionality as needed (OK it doesn't help when you want to change the main forms).When you want to make your behavior extensible you need to take a few extra steps:
- Move your event code from the forms and the views into a custom class.
- Ideally that custom class would inherit from a base class, that determines general behavior (e.g. validation based on a system configuration)
- Buttons, Links or Field Events can call methods of the class
- You might have the class, which obviously needs front-end methods (otherwise the On Event doesn't work) contain a class that does back-end only, so you can have the same function in your web application too.
- Now create a second/third class that inherits from the class that does all the work but leave it empty. Never touch that one, it is for your customers. That class would live in its own script library and can be overwritten by customizers without impacting your general design. Remember Interfaces live forever
- Link that class using "On event" to the form or view so the form/view events are handed down the class hierarchy until executed, see the diagram below. And no: it is not time expensive.
| Permalink | 
Comments
Great post. I get the high level concepts, but it'll take me a little bit to digest the meat of it I think. I love Custom Classes, but haven't done a lot with sub-classing yet.
The really interesting thing that you touch on, which I'd love to get more details/examples on (hint hint) is putting the form/view event code inside custom classes. I've seen that discussed before in the "YellowVerse" but I don't remember seeing best practices on how to do just that. How do you link these events to the class methods? There's more to it then just calling a method from inside an event isn't there?
Seperating the Backend from Front end is also a neat idea. Anything to make code more re-usable is a good thing!
Thanks again for the post. I'll be pondering this one for a while.
Posted by David Leedy At 22:02:55 On 03/25/2009 | - Website - |
It is the "On Event" statement. In your form you would have code in Globals:
Dim formlogic as formSampleAimp
In your Query or PostOpen:
Set formlogic = new formSampleAimp(source)
and in the class
Public Class formSampleAimp as formSampleAction
Private uiDoc as NotesUIDocument
Sub new(uDoc as NotesUIDocument)
Set Me.uiDoc = uDoc
On Event QuerySave From uiDoc Call Me.QuerySave
End sub
Sub QuerySave(Source as NotesUIDocument, Continue as Variant)
Msgbox("Attached event fires")
End Sub
...
End Class
So you need a little code in your form, but only in one event.
Posted by Stephan H. Wissel At 18:01:15 On 03/26/2009 | - Website - |
Posted by David Leedy At 21:58:42 On 03/26/2009 | - Website - |