Re: Custom complex grid / search results page

[Thiago H de Paula Figueiredo]

On Mon, 09 Mar 2015 20:45:30 -0300, Daniel Jue  wrote:


Hi,


Hi!


There were a couple ways I thought of doing this but they all seemed to
fight Tapestry's static structure paradigm.


Let's see. :)


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.


This isn't against the Tapestry static structure paradigm at all. You're  
just direting the browser to the page that will handle the results.



The second way would be to have each customer supply a component that did
the templating and grid logic.


I think you can solve the whole problem by defining different Tapestry  
types (by contributing DataTypeAnalyzer implementations to the  
DataTypeAnalyzer service) for different visualizations and contributing  
viewing and edition blocks for these types and just let Grid and  
BeanEditor/BeanEditForm do their job. As the distributed configuration of  
DataTypeAnalyzer is ordered, you can very easily override the base logic  
for it.


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.


This is handled easily by the approach above.

In addition, Tapestry 5.4 has the ComponentOverrides service, which allows  
you to override a page, component or mixin completely. For example, if you  
want every  or  replaced by your  
own DanielDataField component, you can do it:


public static void contributeComponentOverrides(MappedConfigurationClass>) {

configuration.add(DateField.class, DanielDateField.class);
}

--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Custom complex grid / search results page

[Chris Poulsen]

Perhaps you could use display blocks like the beaneditor/grid etc. does.

-- 
Chris

On Tue, Mar 10, 2015 at 12:45 AM, Daniel Jue  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
>

Custom complex grid / search results page

[Daniel Jue]

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