Notes is RAD: keep it that way !
Posted by Theo Heselmans on June 7th, 2008
Don't know if you've been listening to the new podcast in town: Yellowcast. For Notes geeks, by Notes geeks (sorry Adam for stealing your line). Chris Toohey and Tim Tripcony do a great job. In their 2nd episode one of the subjects was about splitting your data from the UI when doing Notes development.
Sorry guys, but I don't agree !
Notes was and still is a RAD tool.
When creating a form, you sort of define your data structure too. This form contains most of your UI: fields, buttons, images, workflow,.... When you use it to enter data, it is stored into a pool of documents (your backend data). Every time you want to see this data, you usually use this form to (re-)present it.
Chris and Tim said that it was far better to use (a series of) dialogboxes to gradually expose data to the user to fill in data, and have a background script do all the work to create data. Now to me, this is certainly an option in some cases, but a form remains the most used way of reading and editing data.
Second thing they talked about was views. Here they compared Notes views to views in a relational database. An RDBMS view is a 'calculated' way of representing structured table data. A Notes view, when visible to the user, is a UI element ! Granted, it contains a select formula to filter data, and (calculated) columns, but it also contains buttons and possibly scripts. What's wrong with this ? You always need a way of showing data in a grid to the user. Views happen to be the way to do this in Notes. Hidden views, used mainly for lookups can be compared to views in a relational db.
What I'm trying to convey here (and I know it sounds poorly) is that you should not try to force Notes into being a split development environment vs data-store like e.g. .Net development.
Notes is both at the same time, hence its inherent power ! There's nothing wrong to keep developing in Notes as you've always done. You don't have to be 'modern' or web 3.0-ish and develop tiny composite applications, that you'll glue together when it suits you. I have nothing against composite apps, mind you, but you should use them when needed, not because its the 'new' way of doing things.
Notes is RAD, so let's keep it that way !
Category: Lotus Notes Domino | 
Technorati: Lotus, Notes, Domino
Comments (5)
Hey Theo:
I appreciate the RAD approach for Lotus Notes client application development, I honestly do - it allows us to quickly both create and modify some very complex and powerful applications.
My issue with it however is that it greatly impacts the extension of the platform - which can ultimately both limit it's utilization and effectivness in the enterprise.
I know that that's a pretty blanket statement, but I've sat through too many strategy meetings where Domino was not even (initialy) considered to address a given problem due to pre-conceived notions about the platform and it's "limitations".
I'm putting together a few articles as well as discussion points for the upcoming 'casts where we'll be talking about more "standards" and "global community" architectures that - when utilized in Lotus Notes and Domino application architecture - can allow you to extend the platform far beyond it's "current limitations".
The first I put out on Friday, called "Domino Development and Data Store Architecture" - I know, I missed my call in marketing ;-)
{ Link }
To speak more specific to your example above...
View Design Elements are also often the initial representation layer and often a secondary entry point into the modification of content - at first via Buttons and Run on Selected Agents, and then eventually via the inclusion of In-View Editing.
Now, take the typical RAD approach to a workflow-heavy application. The majority of Notes Developers store their business logic in a button on a form. If they utilize the "data grid" UI of a Notes View, they'll need to duplicate that business logic in all buttons that modify documents or in the Notes View Design Element's InViewEdit. Okay - something that we'll live with for a few Views, Buttons, and Agents... but forget one in the initial build or revisit your application 6+months later, and your business logic could all be lost due to you forgetting to copy/paste.
Here's a real world example: $$KeepPrivate. You cannot modify this NotesItem on a document that's being viewed by the Memo|Reply|etc. Form Design Elements... but you CAN easily remove this "flag" from your Inbox via a simple SmartIcon. Now, imagine this is your uber-advanced business logic. Someone that knows what they're doing (or something that uses an entry point that hasn't had your logic "duplicated" into it)... you can see where this is heading...
Now, if you dealt with Domino as a true data store, and created your UI to utilize a "message broker" to interact with your UI and your data... well, I'd be able to make sure that you couldn't forward any of my emails ;-)
I agree with Theo. Notes IS different. It's one of its strong points.
Chris, I'm going to come to your house and install a keyboard sniffer on your computer. Every time you type "utilize" it's going to administer an electric shock.
i don't think Notes will ever NOT be "RAD". ibm is too smart to get rid of that stuff. it is too core to the product.
but i do think there are other ways to go about Notes/Domino (esp web) development that could be very successful, where data and UI are more separate. i think a lot of ppl are clamoring for this kind of thing, just look at how much ppl want to use DXL. design elements are themselves in a sense "first class" notes, in other words design elements are data too. i think that many developers are simply wanting more control and flexibility. and the closer you get to that end of the continuum, to my mind, the more agnostic everything is. you've got code and you've got data and you do what you want with it.
hm, hope that makes sense.
It might not have been obvious from my original post, but I don't want to prevent new stuff to appear in Notes.
Opening up Notes to do whatever you want is OK by me.
'Make every developer happy' is my motto.
I just wanted to convey that many developers are happy with the way they can do development right now, and should not be forced into doing things, just because they're fancy or 'à la mode'.