By Nature, WEF is a tool that will generally require a fair amount of overriding. The tool is designed with this consideration in mind. Custom overrides may be as simple as extending base html pages, themes, style sheets, or as complex as writing builders and java code that extend existing behavior. WEF also provides additional override capabilities within their builders as well. These features are more for advanced manipulation of a builder and may not always be evident without a bit of digging around. It always helps to dig around in a builder to better understand its capabilities. The builder documentation also provides additional insight.
The easiest override in most builders is the “overwrite existing” input. This input is usually hanging around in the builder call editor in the form of a checkbox. When enabled, it will overwrite any existing object instance in the WebApp that shares the same name. Sometimes this can be very useful for overriding your own code or common components without having to rewrite things.
Another way to handle overrides is with the Profiling capabilities within the Imported model builder. The Imported model will allow you to override profiled entries within the imported model. If the author of the model to be imported has enough information about how others may use their model ahead of time, they can profile several inputs within the model to allow for flexibility within the portlets that are importing the custom model.
Sometimes we may need to override artifacts created by WEF. This can get tricky as the generated code can change at any time. Sometimes there’s no way around this however, so it’s best to document where and when the override of generated code was made. The easiest way to do this is to look at the WebApp tree, from within the designer, and look at the generated JSP within a page or generated methods. The source code will be included in there.
Usually I will stick the method overrides into a Java method builder with comments and debug notes stating that this is a snapshot of generated code. That way if the generated code updates, you’ll know where it came from and how to fix it.
The Method builder can be used to override existing methods within a model. This is very useful for adding additional functionality into WEF when you’re calling a generated method, or a method provided from an external source. For example, if you want to override a service call builder and inject your own conditional logic, you can use the same name as the existing method, and call the renamed method (The WebApp automatically does this) from within your new method.
When overriding any existing files within a project, it’s best to clone the file and give it a new name. Usually the new file can go in its own folder structure which isolates it from the rest of the WEF artifacts. This practice makes it easier to deal with the content in source control as well.
Within WEF there is a configuration file (override.properties) which contains all override java property settings within the project. If you need to change configuration settings in any of the other properties files, the property should be copied to this file instead and edited in override.properties. This ensures that your changes are saved and localized to a single file. Note if the file does not exist in WEB-INF/config, then you may need to create it.
WEF contains may modifier builders which will override existing settings within the web-app. A good deal of these builders are used to modify the internal schema or base RDD within a given model. A good deal of these modifier/override builders can be found within the “Formatting and Visibility” category of the Builder Picker dialog.
Lastly, There are some overrides that may not always be evident. A decent amount of builder overrides can be found in the Theme builder. By Default each model pulls in a specific theme file that is specified by the “bowstreet.themefile” property found in WEB-INF/config/override.properties. If you navigate to the Application Tree view, and expand the Theme node, you’ll see all of the theme definitions in the right designer panel. These definitions will override default builder settings within WEF. A lot of these are involved with Page Automation (DataPage). By utilizing the theme builder (and associated base theme file), you can override a lot of default settings within WEF.
- Don’t extrapolate too much generated code from WEF. Instead, try to find a builder or another way to accomplish your task. Code is always changing and it may break without much indication. If you do override, try to comment / debug as appropriate to indicate so and where the code was obtained from
- The WEF Best practices guide always recommends cloning editable files and referencing the clone rather than editing the default factory files in place. This is mostly due to the fact that a WEF upgrade (fix, feature or otherwise) can and will override any changes you made previously.
- Locate the default theme object within the Application Tree. Click on the default theme and look at the properties provided in the right UI panel. This will show you a lot of the default override settings for the current theme. By adding your own theme file (or builder) you can change these default values.
- If you have specific behavior stored in an imported model, consider profiling some of the inputs that you may think need to change in the future. The person importing your model will be able to override these profiled inputs (as needed) to customize your model to meet their needs.
About the author: Adam Kewley has been working with Web Experience Factory (WEF) for 12 years. He began his career working with the WEF development team itself. Over time he moved from software QA to Development, L3 support lead (assisting the IBM customer support team), and finally on to consulting. He is a resident of southern New Hampshire.
This article is from our monthly resource e-Newsletter. Did you miss it in your inbox? Visit our eNewsletter archives for past editions or if you want to receive our monthly newsletter automatically, simply write to Ruth O’Keefe and request to be added to our E-Newsletter list. You can also view the Master Series Archives.