Leveraging Baseline NetForum Enterprise in Customizations

NetForum Enterprise is a feature-rich association management system (AMS), but most associations will inevitably find themselves needing to customize. That’s fine – NetForum allows customizations. The challenge comes in down the road when you’re looking to upgrade and the customization does not support new functionality available in the new release or worse breaks down completely. Implementing customizations that leverage baseline may reduce your heartburn during future upgrades enhancements. Here are a few customization trade-offs to consider.

User Control vs Design Form with Form Extension

Capturing data in NetForum is critical, and forms are key to any data entry. To create the most simplified NetForum eWeb customer experience, you may need to customize your form’s format and fields. A coded user control overrides default form builder limitations and allows for maximum control. But, everything is written in code, so adding an additional field to the form is not a drag and drop situation. Someone will have to dig into the code.

Alternatively, consider using a design form with a form extension. This allows for a portion of the form to get customized within the form extension, but still have the flexibility to add fields using the Toolkit form designer. If you later decide to add an additional column to the form, simply drag and drop and you’re done!

Baseline Scheduled Task Framework

If you’re building out any customizations that either update data within NetForum or push data out to a third-party system, building out a scheduled task may be needed. This is completely normal. The problem arises when the scheduled task is not built within NetForum’s baseline scheduled task framework. Within the scheduled task framework, any Admin user can go into the admin module and review existing tasks, see when it last ran, and see how often it will run going forward. While not working within the framework may be fine for now, it is likely to cause future problems. Building the task in the baseline framework would allow you and your staff to better troubleshoot the scheduled task should problems arise. Think of it as process documentation: you don’t need to spend the extra effort upfront for the system to work, but three years from now you’ll thank yourself that you did.

Facade Objects to Enforce Business Rules vs Form Extensions/Data Objects/Direct SQL

NetForum provides a layer of facade objects where business rules can be enforced, allowing for a great deal of control and customization. The challenge is the rules around those objects is more specific to NetForum. It may be tempting to simply build logic directly into the SQL database. However, the SQL may not follow other business logic stored in the facade object. In fact, it may directly contradict baseline’s or other custom business logic. Implementing a business rule in Form Extensions causes a similar issue in that the business rule is only enforced on that particular Form. When a second form is used, or the functionality is exposed through the API (xWeb), the rule is ignored. So While direct SQL and Form Extensions can work for basic items, updating the facade object and, following OOP’s inheritance best practices is generally a better approach in the long run.

Static ASPX page vs. baseline ASPX page

As more associations look to better leverage eWeb, there are increasing requests to customize the site. The current baseline eWeb does come with its limitations – forms only have a single column, baseline menu isn’t truly responsive (although this can be fixed). However, the eWeb baseline feature set has continued to grow over time. While building a static ASPX page feels like an easy improvement to eWeb, you may be sacrificing the ability to leverage future functionality at the expense of current convenience. New features that get added to NetForum won’t be available on the static page. Instead, try to leverage the baseline page, along with other customization tools, knowing it will provide more longevity for the site.

“Leveraging” bugs

This sounds strange, but over the years I have seen a few occasions where customizations or “cool tricks” were implemented that leverage either existing “bugs” in NetForum or perhaps an unknown vulnerability. At the moment, the customization works and delivers the functionality your organization needs. Inevitably, after the issue is fixed in a service pack or a new release, these customizations stop working. It might be alright to leverage “unintended features” as a stopgap, but be prepared to re-implement the customization sooner rather than later.

Unfortunately, it’s not always easy to distinguish an “unintended feature” from an unknown system issue – so perhaps the best advice here is to ask “Does this look right?” or “Would there be a reason for this variable to have a different value in a future release?” – when in doubt avoid it.