I guess using t:add is OK as long as the grid is not performing operations
where it needs to access the property in the data source (for operations
like sorting/filtering).
Generally speaking we (@work) almost always end up using bean models,
except in the most simple cases.
--
Chris
On Thu, Jun 30, 2016 at 11:04 AM, Davide Vecchi <d...@amc.dk> wrote:
> Thanks for the pointers, creating a BeanModel and adding my extra columns
> to it sounds like the right way to go. As an emergency solution for now I'm
> just going through all grids and adding the t:add columns into
> t:excludeSort in order to avoid the crashes on sorting. Then I will work on
> the actual solution with the BeanModel.
>
> In the meantime, regardless of these crashes and of whether it's 5.3.7 or
> 5.3.8, I'm still wondering if my way of defining these t:add columns
> (pasted below for convenience) has something wrong in general. Any opinion
> about that would be very useful.
>
> The column is defined like this:
>
> - In the page template, one param of the grid tag is
>
> t:add="prop:gridAdd"
>
> - In the page Java code, there is the corresponding
>
> public String getGridAdd() {
> return " myColumn1, myColumn2, myColumn3, myColumn4";
> }
>
> where let's say that "myColumn3" is the column whose sorting fails.
>
> - In the page template, within the t:grid tag there is the definition of
> the customized content of that column:
>
> <p: myColumn3Cell>${ myColumn3}</p: myColumn3Cell>
>
> - In the page Java code, there is the method returning the value for that
> column:
>
> public String getMyColumn3()
> {
> return aStringThatIsNeverNull;
> }
>
> ----------------------------------------------------
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
