Hi, I have a reusable war overlay project where the omnipresent search bar component is in a layout and search results page is defined in a core library (These are hooked together via @InjectPage in the search bar component so i can set the page's parameters and then send the user there)
The search results page uses a grid to display results. (Actually T5 JQueryDatatables, but let's just say its a plain grid) Each customer implementation wants complete control over the contents of the search results. There were a couple ways I thought of doing this but they all seemed to fight Tapestry's static structure paradigm. The first way would be to let the customer completely define the search results page and tml, and then have a proxy interface that could let my omni-search box redirect the user there. The second way would be to have each customer supply a component that did the templating and grid logic. These first two thoughts allow me to simply define the beanmodel, and handle complex cell values in the customer implementation of the page. I don't see how I could get either of those to work. I was thinking something like making an interface for a page and then binding a certain page implementation to that interface? A third way, which is the most complex but gives us static structure at a cost of customizing, is to pass a list of very flexible object containers that will turn into the right kind of cells. I'd also have to pass the beanmodel and any table options, and have a way of iterating over the contents of complex cells, etc. The problem arises because any of the cells can be complex; for instance a single cell might have a list of contextualized page links back into the search page (allowing the user to pivot his search in the results), or it might be a list of icons or an action button, or an image, links to external urls, etc. I think to do the above I'd have to have display blocks defined in the core library to anticipate how each cell datatype would be handled. All of this starts from needing a similar look and feel for all implementations of our app, and the implementations benefit from new and improved features of the core application. So that's why we provide a standard layout and set of navigation components, including the search bar component that needs to talk to a search results page, somewhere. Any other ideas? Dan
