One of the decisions that you need to make is how will you build your user interface for your search results page. You have two basic options: Use the Out-of-the-Box version or build your own.
Out-of-the-Box User Interface – ODE’s Layout Editor
In one situation, a client decided to enhance the out-of-the-box (OOTB) search functionality by using OmniFind … very late in the implementation process The deal was that we could include it if we used ODE’s layout editor to rapidly prototype and implement a search results page. The trade off is that we would have limited ability to customize the look and feel. The good news is that the OOTB user interface is quite good and ODE’s management console provides a good interface for adding and placing various WebSphere Commerce related widgets. To give the briefest of overviews, the layout editor uses a grid layout. You can add widgets and “sub-grids,” if you will, to the master layout grid. There are a number of widgets that can be included. I especially appreciate the WebSphere Commerce-specific widgets. Overall, pretty nifty.
Custom User Interface: Two Approaches
Another client (with more lead time) wanted a more customized search results page than is available. One thing about the OOTB layout editor is that while there is some room for modification, it is difficult to do wholesale customizations. It’s not that you can’t modify the layout. It’s just not easy. If time is a factor, you are likely to find yourself in a crunch.
If you want a customized interface, you will probably want to build your them using the available JARs:
OneStepRuntimeJspLib
OneStepRuntimeAPI
Obviously, one JAR has a JSP component and one doesn’t. The easiest way to describe the difference between these two JARs is to have a high-level understanding of the basic flow of an ODE application:
- Pre-Query execution
- Query execution
- Post-Query execution
A differentiator between these two JARs occurs in the Query execution step.
JSP API
If you are using the OneStepRuntimeJspLib JAR, query result objects are placed in a JSP’s PageContext and objects can be accessed and manipulate from the JSP. ODE comes with a tabbed navigation sample application that you can study to see how this approach works. The sample uses JSP fragments. Be forewarned. This approach requires considerable JAVA coding on the page. Some WebSphere Commerce developers do not like this (or the Layout Editor’s JSP fragments) because they feel it is inconsistent with the approach used in WebSphere Commerce.
Non-JSP API
If you want a cleaner separation between the search layer and the presentation layer, you will probably want to build a JavaBean using the OneStepRuntimeAPI JAR and encapsulate the data generated by the various result objects. Since there is not a sample application, you’ll need to start from scratch. It’s not hard. It just takes time.
There are times when using the JSP API will work for you and you will never look back. If you plan to or think you are very likely to use ODE to power many different functions within your site, you may want to look seriously at using the non-JSP API. While it requires more effort up front, you are likely to find that you have more flexibility to make changes later. Personally, I prefer having a cleaner separation between the search data layer and the JSP presentation layer.