Perhaps you could use display blocks like the beaneditor/grid etc. does. -- Chris
On Tue, Mar 10, 2015 at 12:45 AM, Daniel Jue <[email protected]> wrote: > 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 >
