Hmmm....
Sorry, I don't know that is OGNL, I think it's insignificant.
My question is not about null to 0/0 to null conversion.
I should provide better example. That's it:
Page:
$id
Java:
public class TestPage extends BorderPage {
@Bindable public Long id;
@Override
public void onInit() {
super.onInit();
addModel("id", String.valueOf(id));
}
}
order does matter:
REQ: /test-page.html
RES: null
REQ: /test-page.html?id=4
RES: 4
REQ: /test-page.html
RES: 4
REQ: /test-page.html (from another comp)
RES: 4
Looks like I misunderstand general concept of "stateless page". I thought we
have one object per request in Click.
According to User Guide: "Stepping through this GET request sequence, a new
Page instance is created and the attributes for the Page are set..."
But my test shows that actually page have state.
Should I place "id = null" in onDestroy() method? Is it good practice?
BTW, what kind of problems with Bindable? Except this one.
Fri, 18 Mar 2011 21:08:20 +0200 Bob Schellink <[email protected]>:
> Hi Mikhail,
>
> Click uses OGNL to bind the field's value which coerces the value to 0.
>
> Do note that in my exp Bindable has proven very problematic in practice. One
> of those things
> implicit behaviors which looks great at face value but hinders maintenance. I
> suggest you don't use
> it. In click.xml you can switch it off with autobinding="none".
>
> kind regards
>
> Bob
>
> On 2011/03/18 20:23 PM, Ingie wrote:
> > Hi all,
> >
> > First of all i like Click, thank you for great work guys.
> >
> > Can't understand @Bindable behavior:
> >
> > class MyPage extends BorderPage {
> >
> > @Bindable protected Long id;
> >
> > public void onInit() {
> > sout(id);
> > }
> >
> > }
> >
> > Output:
> >
> > for my-page.htm?id=0 -> 0 (it's ok)
> > for my-page.htm -> 0 (why?)
> >
> > Is it bug or feature?
> >
> > I run 2.3.0-RC1
> >
> > Kind regards,
> > Mikhail
> >
