wissel.net

wissel.net

Usability - Productivity - Business - The web - Singapore & Twins

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.
ExtensibleClassArchitecture.png

Posted by on 25 March 2009 | Comments (3) | categories: Show-N-Tell Thursday

Comments

  1. posted by David Leedy on Wednesday 25 March 2009 AD:
    Stephan,

    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.
  2. posted by Stephan H. Wissel on Thursday 26 March 2009 AD:
    @David:
    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.
  3. posted by David Leedy on Thursday 26 March 2009 AD:
    Well that filled in some missing pieces. Can't wait to play with this! Thanks a lot!