When I was assigned to rebuild company’s web site for the second time in 7 or 8 years, I have decided that it is probably the time to implement some modularity to the database. First in line were sidebars. Why? Well, despite “awesome” notes rich text to HTML rendering, web content was always contained in rich text field on a document, making it very customizable. On the other hand, sidebars were always subforms that were then connected to the document via a field (user specified subforms name). This was customizable, but regular content editors did not have designer access to the database. Thus, all modifications were relayed to us, developers. And there were quite a bit of modifications. I will pitch you my idea of solution to this problem.

First step

In order to ensure that content editors could alter sidebars by itself, they had to be moved from design elements to documents. All fine and well. However, if you look at typical sidebar, it is assembled from multiple parts called widgets. This widgets can be e.g. adverts, link boxes, etc. Now, I wanted to achieve as much modularity as I could and there used to be quite a lot of sidebars, containing same widgets (not all, but some). So why force a user to create same thing multiple times? Thus, widgets came to be.

Widgets

Widget (in this case) is the smallest single component that can be displayed in a sidebar. This can be a simple image, or a complex linkbox. Widget in Notes database is a simple document containing descriptive name, short web name and a rich text field. This rich text field contains content for the widget. It can be pure notes content or it can be HTML, that CSS will change into something “edible”.

Simple, and easy. However, what you now don’t want, is for users to link multiple widgets into web content documents. For one, content of sidebars is usually content related, meaning that web pages on same topic will probably have same widgets. And it has to be user friendly if you want users to use it. So, you can’t expect users to be comfortable with a feature that gives them more work if they decide to change something. And here is where Sidebar documents come in handy.

Sidebar documents

Sidebar document is nothing else but a container of widgets. What I did was enabled user to choose widgets he wants in this sidebar and he/she can sort them however he/she sees it fit. Sidebar document also contains a rich text field that will contain content of specified widgets rich text fields.

Subform

Now, that I had sidebar documents created, there is one thing I could not avoid. I had to create a subform, which I can include on each web form there is. This subform includes a rich text item and some HTML. On the plus side, you now only need one subform for all sidebars.

What does this bring me?

Well, besides the fact that users will now be able to do their own sidebars and have an easy way to change it’s contents (which means less work for you), this organization also gives you one powerful feature. All computed values and hide formulas that you will specify in widgets will be recalculated once they are displayed as part of the document and displayed on web. Thus, you can i.e. add a computed value that computes from a field on web page form and will compute correctly when displayed on web page.