You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@click.apache.org by Ingie <in...@mail.ru> on 2011/03/18 19:23:32 UTC
@Bindable
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
Re: @Bindable
Posted by Bob Schellink <sa...@gmail.com>.
On 2011/03/20 01:19 AM, Михаил Пересыпкин wrote:
> My fault, forget to remove it.
>
> It's a Spring issue. I forgot to change scope of my page beans to "prototype" value.
> It's well documented in javadocs on SpringClickServlet.
Ah, that makes sense. Thanks for clarifying. I forgot that Spring can also create stateful pages.
> "Please Note ensure the page beans scope is set to "prototype" so a new page instance will be created with every HTTP request. Otherwise Spring will default to using singletons and your code will not be thread safe."
>
> Sorry for inconvenience, It was stupid question.
There are no stupid questions. Glad you got it working.
Kind regards
Bob
Re[2]: @Bindable
Posted by Михаил Пересыпкин <in...@mail.ru>.
My fault, forget to remove it.
It's a Spring issue. I forgot to change scope of my page beans to "prototype" value.
It's well documented in javadocs on SpringClickServlet. Shame on me.
"Please Note ensure the page beans scope is set to "prototype" so a new page instance will be created with every HTTP request. Otherwise Spring will default to using singletons and your code will not be thread safe."
Sorry for inconvenience, It was stupid question.
Kind regards,
Mikhail
Sat, 19 Mar 2011 23:16:53 +0200 письмо от Bob Schellink <sa...@gmail.com>:
> On 2011/03/19 22:43 PM, wrote:
> > I see...
> >
> > Ok. I made SSCCE. Please find attached bindable.zip. What's wrong with it?
>
> It doesn't compile for me. I don't know anything bout maven but I think your
> hibernate dependency is
> wrong.
>
> [INFO] Unable to find resource 'org.hibernate:hibernate-core:pom:3.6.2.Final'
> in
> repository central (http://repo1.maven.org/maven2)
> Downloading:
> http://repo1.maven.org/maven2/org/hibernate/hibernate-core/3.6.2.Fi
>
> Why not test with Click on its own?
>
> Bob
Re: @Bindable
Posted by Bob Schellink <sa...@gmail.com>.
On 2011/03/19 22:43 PM, Михаил Пересыпкин wrote:
> I see...
>
> Ok. I made SSCCE. Please find attached bindable.zip. What's wrong with it?
It doesn't compile for me. I don't know anything bout maven but I think your hibernate dependency is
wrong.
[INFO] Unable to find resource 'org.hibernate:hibernate-core:pom:3.6.2.Final' in
repository central (http://repo1.maven.org/maven2)
Downloading: http://repo1.maven.org/maven2/org/hibernate/hibernate-core/3.6.2.Fi
Why not test with Click on its own?
Bob
Re[2]: @Bindable
Posted by Михаил Пересыпкин <in...@mail.ru>.
I see...
Ok. I made SSCCE. Please find attached bindable.zip. What's wrong with it?
mvn jetty:run
http://localhost:8080/test/test-page.htm -> null
http://localhost:8080/test/test-page.htm?id=5 -> 5
http://localhost:8080/test/test-page.htm -> 5
PerfomanceFilter?
Spring?
Smth else?
Sat, 19 Mar 2011 20:34:02 +0200 письмо от Bob Schellink <sa...@gmail.com>:
> Hi,
>
> Doing your test on my machine I'm getting the expected behavior. The id is
> null again if no param is
> provided.
>
> If you look at the examples you'll see same behavior:
>
> http://click.avoka.com/click-examples/edit-customer.htm?id=16038
>
> remove the id and no customer is selected.
>
> Click always creates a new page unless you set it to stateful. Are you setting
> the page to stateful
> in your BorderPage?
>
> regards
>
> Bob
>
>
> On 2011/03/19 19:54 PM, Михаил Пересыпкин wrote:
> > 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 <sa...@gmail.com>:
> >
> >> 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
> >>>
> >
> >
Re: @Bindable
Posted by Bob Schellink <sa...@gmail.com>.
Hi,
Doing your test on my machine I'm getting the expected behavior. The id is null again if no param is
provided.
If you look at the examples you'll see same behavior:
http://click.avoka.com/click-examples/edit-customer.htm?id=16038
remove the id and no customer is selected.
Click always creates a new page unless you set it to stateful. Are you setting the page to stateful
in your BorderPage?
regards
Bob
On 2011/03/19 19:54 PM, Михаил Пересыпкин wrote:
> 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 <sa...@gmail.com>:
>
>> 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
>>>
>
>
Re[2]: @Bindable
Posted by Михаил Пересыпкин <in...@mail.ru>.
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 <sa...@gmail.com>:
> 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
> >
Re: @Bindable
Posted by Bob Schellink <sa...@gmail.com>.
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
>
Re: @Bindable
Posted by Bob Schellink <sa...@gmail.com>.
You can also plug in your own request converter in web.xml and change how it converts values.
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
>