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, Ju
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 act
Just a correction, that t:add is not just unnecessary, but it will be
ignored if you specify the beanModel explicitly:
> A comma-seperated list of property names to be added to the
> org.apache.tapestry5.beaneditor.BeanModel. Cells for added columns will be
> blank unless a cell override is provi
I'm guessing that something in the sorting part attempts to pull out the
value from your passed data source (possibly coerced from a collection).
The thing is that your data source does not contain the property (as it is
synthetic) and you do not really pull the value from the data source ever,
bu
I changed my plan of finding out what causes this difference between 5.3.7 and
5.3.8. Instead I will go with some re-design, using some suggestions I got here.
However I am still very interested in knowing whether my way of defining these
t:add columns (pasted below) in general has something wro
fix.
-Original Message-
From: Chris Poulsen [mailto:mailingl...@nesluop.dk]
Sent: Tuesday, June 28, 2016 16:35
To: Tapestry users
Subject: Re: Null pointer on sort with 5.3.8 that didn't occur with 5.3.7
Hook up a debugger and see what is going on when the NPE is thrown?
On Tue, Jun
nt of that column:
> >>
> >> ${ myColumn3}
> >>
> >> - In the page Java code, there is the method returning the value for
> >> that
> >> column:
> >>
> >> public String getMyColumn3()
> >> {
riginal Message-
From: Chris Poulsen [mailto:mailingl...@nesluop.dk]
Sent: Tuesday, June 28, 2016 15:32
To: Tapestry users
Subject: Re: Null pointer on sort with 5.3.8 that didn't occur with 5.3.7
Also you can control the display blocks using the data-type on the bean model,
if you need somethin
e Java code, there is the method returning the value for that
>> column:
>>
>> public String getMyColumn3()
>> {
>> return aStringThatIsNeverNull;
>> }
>>
>> So I'm trying to find out if this way of defining
; public String getMyColumn3()
> {
> return aStringThatIsNeverNull;
> }
>
> So I'm trying to find out if this way of defining my column is not right
> in 5.3.8 although it was not failing in 5.3.7, in order to rectify it.
>
>
> -
-Original Message-
From: Cezary Biernacki [mailto:cezary...@gmail.com]
Sent: Monday, June 27, 2016 18:10
To: Tapestry users
Subject: Re: Null pointer on sort with 5.3.8 that didn't occur with 5.3.7
Your stack trace seems to indicate that conduit (a mechanism connecting
Tapestry with a c
Your stack trace seems to indicate that conduit (a mechanism connecting
Tapestry with a column) is not available. It can happen if the column is
manually added to the model. Was the column sortable with Tapestry 5.3.7?
How is this column defined?
Best regards,
Cezary
On Mon, Jun 27, 2016 at 4:4
I suspect the culprit is the Java upgrade rather than Tapestry. There are
some internal changes in the sorting algorithm (for example, see
https://bugs.openjdk.java.net/browse/JDK-8062797 although it doesn't
directly match your case). But basically, you have to make sure your grid
data source doesn
Hi everybody
For now I cannot post code to reproduce this problem because it only occurs
with one columns of a specific grid from a big application and so far I wasn't
able to extract the code to reproduce the error into a runnable example. But
after posting this I will keep trying and if I man
14 matches
Mail list logo
