|
|
|
|
|
|
|
|
|
|
|
|
|
|
How to reduce your Notes application development time by 15% (continued)
Step 4: Develop the necessary components By this time, our developers had begun champing at the bit (I'm living in Texas now, so I get to use this expression in everyday conversation). [We looked up "champing" and it wasn't in the dictionary. But since Richard's our resident Texan, we'll leave it as he wrote it. Never let it be said that DominoPower doesn't bring you cultural diversity. -- DG] They hadn't been able to write any code throughout any of the preceding steps and were beginning to show signs of keyboard withdrawal. Now we could finally cut them loose.
For each of the components that had been identified in Step 3 of our process, we defined the functions and features that we wanted the component to have. For the rest of this month's article, I'll be describing one component, a standard form header, and go into detail about how it was developed. Using the same process, your organization should be able to develop similar components that can become part of your developer's standard toolkit.
A standard form header In order for a subform to be truly universally applicable, it needs to use abstraction. By abstraction I mean that it needs to be told how to behave depending upon the environment in which it's being asked to operate. We wanted our standard form header to be implemented as a subform so that it could be used on every form within every database of an application.
Because it would be a universally used subform, we couldn't code things like the form name, form description, and comments into the subform itself. This information would be picked up from fields on the base form. See Figure A for an example of the standard form header.
FIGURE A
 
These are some of the fields needed for a reusable header subform. Roll over picture for a larger image.
All of the fields on this subform are Text, Computed for display fields. We made them Computed for display so they didn't get saved into the underlying document and they're all text so they're easier to work with.
What types of information will you need on your global form header? Your project team will determine what makes the most sense in your environment. Table A shows what our team determined we needed for our applications:
| Field Name |
Purpose |
Formula |
| DisplayFormName |
Display what the underlying form is, i.e.: "Employee Master", "KBase Article", "Customer", etc. |
FrmName (field on form) |
| Dtim |
Display the system time when the form was displayed |
@Time( @Now ) |
| Ddat |
Displays the system date when the form was displayed |
@Date( @Now ) |
| DisplayFrmLin2 |
Any additional information about the underlying form which can give it more context. In the example above if the form was an "Employee Master" form, this field might display "Hire Date:"+HiredOn or the Employee's Name |
FrmLin2 (field on form) |
| DfrmUpDate |
Indicate the version of the underlying form |
FrmUpdate (field on form) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
-- Advertisement --
Find unused Lotus Notes groups and clean up your address book
Have you ever wanted to get rid of old Lotus Notes groups that were cluttering up your address book, but you weren't sure if they were used? Find Unused Groups can help.
Find Unused Groups will check your ACL, mail, multi purpose and server groups to help you determine if they are used, and who uses them.
Learn how to easily clean up your address book. |
-- Advertisement --
Teamstudio Edition 25 has shipped
It's finally here! Now that Teamstudio Edition 25 has shipped, listen to our latest Tool Time audio program to find out what's changed. Updates to all your favorite Teamstudio tools will be discussed.
Plus, you'll get an introduction to Teamstudio Undo (formerly known as Teamstudio Snapper).
Tap here to get started! |
|
|
|
|
|
|
|
|
|
|