Re: ajax form submit, loading gif and swap panels

2011-10-05 Thread Martin Grigorov
On Thu, Oct 6, 2011 at 1:08 AM, Dan Retzlaff  wrote:
> If you override AjaxSubmitLink#getAjaxCallDecorator() you can add JavaScript
> to the link's onclick attribute to show your animated gif. When the AJAX
> request eventually returns, it can replace whatever container has the gif.
Or use the same AjaxCallDecorator and remove the gif in its
onDecorateSuccess()/onDecorateFailure() one of which will be executed
at the end of the Ajax request.
>
> On Wed, Oct 5, 2011 at 2:51 PM, wholalotta  wrote:
>
>> Hi all,
>>
>> I want to remove the form component after hitting submit button and display
>> a loading animated gif.
>> After ajax submit operation finished, i want to display a new panel instead
>> of form component which has a button to generate a new form page..I think I
>> can swap the panels into onSubmit button but how can I check ajax request
>> finished or not and display a animated gif ?
>>
>>                form.add(new AjaxButton("submit") {
>>
>>                        @Override
>>                        protected void onSubmit(AjaxRequestTarget
>> ajaxRequestTarget,Form form) {
>>
>>                                       Processing some data in here..
>>                        }
>>
>>                        @Override
>>                        protected void onError(AjaxRequestTarget target,
>> Form form) {
>>                                super.onError();
>>                                target.addComponent(feedbackPanel);
>>                        }
>>
>>                });
>>
>> Thanks
>>
>>
>> --
>> View this message in context:
>> http://apache-wicket.1842946.n4.nabble.com/ajax-form-submit-loading-gif-and-swap-panels-tp3876326p3876326.html
>> Sent from the Users forum mailing list archive at Nabble.com.
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

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



Re: WicketTester#startComponentInPage and tester#assertModelValue

2011-10-05 Thread Martin Grigorov
Please create a ticket with a quickstart.
Thanks!

On Wed, Oct 5, 2011 at 6:14 PM, Andrea Del Bene  wrote:
> Hi,
>
> I agree with you, that's a little ambiguous. Why
> 'getComponentFromLastRenderedPage' uses 'startComponent'? Shouldn't be
> 'path' an absolute path to the component on the page?
>
>> Hi,
>>
>> I have a rather strange behavior, and I don´t know what I´m doing wrong.
>> Before I open a Bug, I would like to hear some opinions, why this works
>> this
>> way.
>>
>> I try the following (in Pseudocode):
>>
>> tester = new WicketTester();
>> tester.startComponentInPage(new Label("test","hello");
>> tester.assertModelValue("test","hello"); -->  throws
>>
>> java.lang.IllegalArgumentException: Component is not a container and so
>> does
>> not contain the path test.
>>
>> Funny as it is, to make this work, you have to do the following assertion:
>>
>> tester.assertModelValue("", "hello");
>>
>> The error lies in
>> public Component getComponentFromLastRenderedPage(String path,
>>                final boolean wantVisibleInHierarchy)
>> in Line: path = startComponent.getId() + ":" + path;
>>
>> Here i think you would need to check whether startComponent is a
>> WebMarkupContainer or not,
>> I would file a Bug and provide a patch, or am I completely wrong?
>>
>> Regards
>>
>> Martin
>>
>>
>> --
>> View this message in context:
>> http://apache-wicket.1842946.n4.nabble.com/WicketTester-startComponentInPage-and-tester-assertModelValue-tp3874269p3874269.html
>> Sent from the Users forum mailing list archive at Nabble.com.
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

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



Re: Wicket.Ajax.all.processEvaluation

2011-10-05 Thread Dawid Dudzinski
It's fixed now. Someone has checked into version control html with
wicket:header section. That section sent to browser incompatible javascript
that caused wicket to fail.

Thanks,
Dave

On Wed, Oct 5, 2011 at 4:23 PM, Dawid Dudzinski  wrote:

> Hello,
>
> I need a help understanding an error I'm receiving.
>
> We have a screen divided into 2 pieces. Left side acts almost independently
> from the right. Everything works until a call is made and entire right side
> swapped out for another content (A call to .replace(Component) is made).
> Expected behavior is that left side of the screen will function properly.
>
> Unfortunately there is an error shown in subject line. Clicking on
> components on the left works properly on the server side but Ajax responses
> are not processing properly on the browser side.
>
> What could be the issue?
>
> Thanks,
> Dave
>


Re: ajax form submit, loading gif and swap panels

2011-10-05 Thread Dan Retzlaff
If you override AjaxSubmitLink#getAjaxCallDecorator() you can add JavaScript
to the link's onclick attribute to show your animated gif. When the AJAX
request eventually returns, it can replace whatever container has the gif.

On Wed, Oct 5, 2011 at 2:51 PM, wholalotta  wrote:

> Hi all,
>
> I want to remove the form component after hitting submit button and display
> a loading animated gif.
> After ajax submit operation finished, i want to display a new panel instead
> of form component which has a button to generate a new form page..I think I
> can swap the panels into onSubmit button but how can I check ajax request
> finished or not and display a animated gif ?
>
>form.add(new AjaxButton("submit") {
>
>@Override
>protected void onSubmit(AjaxRequestTarget
> ajaxRequestTarget,Form form) {
>
>   Processing some data in here..
>}
>
>@Override
>protected void onError(AjaxRequestTarget target,
> Form form) {
>super.onError();
>target.addComponent(feedbackPanel);
>}
>
>});
>
> Thanks
>
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/ajax-form-submit-loading-gif-and-swap-panels-tp3876326p3876326.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


ajax form submit, loading gif and swap panels

2011-10-05 Thread wholalotta
Hi all,

I want to remove the form component after hitting submit button and display
a loading animated gif.
After ajax submit operation finished, i want to display a new panel instead
of form component which has a button to generate a new form page..I think I
can swap the panels into onSubmit button but how can I check ajax request
finished or not and display a animated gif ?

form.add(new AjaxButton("submit") {

@Override
protected void onSubmit(AjaxRequestTarget 
ajaxRequestTarget,Form form) {

   Processing some data in here..
}

@Override
protected void onError(AjaxRequestTarget target, Form 
form) {
super.onError();
target.addComponent(feedbackPanel);
}   

});

Thanks


--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/ajax-form-submit-loading-gif-and-swap-panels-tp3876326p3876326.html
Sent from the Users forum mailing list archive at Nabble.com.

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



Wicket.Ajax.all.processEvaluation

2011-10-05 Thread Dawid Dudzinski
Hello,

I need a help understanding an error I'm receiving.

We have a screen divided into 2 pieces. Left side acts almost independently
from the right. Everything works until a call is made and entire right side
swapped out for another content (A call to .replace(Component) is made).
Expected behavior is that left side of the screen will function properly.

Unfortunately there is an error shown in subject line. Clicking on
components on the left works properly on the server side but Ajax responses
are not processing properly on the browser side.

What could be the issue?

Thanks,
Dave


Re: Is it possible to turn off page serialization in 1.5?

2011-10-05 Thread Nelson Segura
We dont use clustering either. Most of our objects are serializable,
but I am thinking on turning off the page store. What will the effects
of turning off versioning in the IPageManager. I never had conscious
use for the page store. What will I miss?

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



RE: Is it possible to turn off page serialization in 1.5?

2011-10-05 Thread Chris Colman


>-Original Message-
>From: Johan Compagner [mailto:jcompag...@gmail.com]
>Sent: Thursday, 6 October 2011 12:46 AM
>To: users@wicket.apache.org
>Subject: Re: Is it possible to turn off page serialization in 1.5?
>
>no we didn't use the diskpage store and so on
>We still used what wicket did have before that, so with the Change
>recorder and so on.
>
>That works for us. Yes our pages are not serializable but for our
>clustering we have for example Terracotta

Ah Johan, that's a good thought: We were wondering how Terracotta would
work with Wicket. I guess it works well then! I've got some questions
for you that I'll send direct as they aren't wicket related.

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



RE: Is it possible to turn off page serialization in 1.5?

2011-10-05 Thread Chris Colman
>How did you store non-serializable objects in the http session (http
>store) in 1.4 ?
>The session attributes should be serializable if you need clustering
>and/or session persistence.
>I guess you just didn't use any of these features.

We just have a single server (no clustering) with plenty of memory and
with our particular traffic profile it has never been a problem. As
99.9% of traffic is read-only we decided session persistence is not a
problem.

>
>Take a look at https://cwiki.apache.org/confluence/x/qIaoAQ for more
>info about the stores. May be useful.
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
>
>
>--
>Martin Grigorov
>jWeekend
>Training, Consulting, Development
>http://jWeekend.com
>
>-
>To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>For additional commands, e-mail: users-h...@wicket.apache.org


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



Re: ResourceReference and ResponseIOException

2011-10-05 Thread Martin Grigorov
Please create a new ticket and add a working quickstart application.
Thanks!

On Wed, Oct 5, 2011 at 6:38 PM, coincoinfou  wrote:
> Hello,
>
> do you consider reopen  http://
> https://issues.apache.org/jira/browse/WICKET-3869  ?
>
> --
> View this message in context: 
> http://apache-wicket.1842946.n4.nabble.com/ResourceReference-and-ResponseIOException-tp3874906p3874906.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

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



Re: WicketTester#startComponentInPage and tester#assertModelValue

2011-10-05 Thread Andrea Del Bene

Hi,

I agree with you, that's a little ambiguous. Why 
'getComponentFromLastRenderedPage' uses 'startComponent'? Shouldn't be 
'path' an absolute path to the component on the page?



Hi,

I have a rather strange behavior, and I don´t know what I´m doing wrong.
Before I open a Bug, I would like to hear some opinions, why this works this
way.

I try the following (in Pseudocode):

tester = new WicketTester();
tester.startComponentInPage(new Label("test","hello");
tester.assertModelValue("test","hello"); -->  throws

java.lang.IllegalArgumentException: Component is not a container and so does
not contain the path test.

Funny as it is, to make this work, you have to do the following assertion:

tester.assertModelValue("", "hello");

The error lies in
public Component getComponentFromLastRenderedPage(String path,
final boolean wantVisibleInHierarchy)
in Line: path = startComponent.getId() + ":" + path;

Here i think you would need to check whether startComponent is a
WebMarkupContainer or not,
I would file a Bug and provide a patch, or am I completely wrong?

Regards

Martin


--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/WicketTester-startComponentInPage-and-tester-assertModelValue-tp3874269p3874269.html
Sent from the Users forum mailing list archive at Nabble.com.

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






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



Re: Is it possible to turn off page serialization in 1.5?

2011-10-05 Thread Johan Compagner
no we didn't use the diskpage store and so on
We still used what wicket did have before that, so with the Change
recorder and so on.

That works for us. Yes our pages are not serializable but for our
clustering we have for example Terracotta



On Wed, Oct 5, 2011 at 15:41, Martin Grigorov  wrote:
> On Wed, Oct 5, 2011 at 4:33 PM, Johan Compagner  wrote:
>> On Wed, Oct 5, 2011 at 15:21, Martin Grigorov  wrote:
>>> yes. each new page gets its id during construction from the session counter.
>>> if Page#isVersioned() returns 'false' then it will not create new
>>> versions of that page
>>
>> i see that giving a custom IPageManager is also already ok, that has a
>> method supportsVersioning()
>> then it doesn't even matter what the page says.
>>
>> i am also looking into this because we (servoy) has the same problem as Chris
>> our pages are just versionable. And until wicket 1.4 this works fine
>> because of the http store with change recording.
>> But that is now completely gone so or we have to do some major work to
>> get everything serializeable or drop the back button support..
> How did you store non-serializable objects in the http session (http
> store) in 1.4 ?
> The session attributes should be serializable if you need clustering
> and/or session persistence.
> I guess you just didn't use any of these features.
>
> Take a look at https://cwiki.apache.org/confluence/x/qIaoAQ for more
> info about the stores. May be useful.
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

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



Re: Is it possible to turn off page serialization in 1.5?

2011-10-05 Thread Martin Grigorov
On Wed, Oct 5, 2011 at 4:33 PM, Johan Compagner  wrote:
> On Wed, Oct 5, 2011 at 15:21, Martin Grigorov  wrote:
>> yes. each new page gets its id during construction from the session counter.
>> if Page#isVersioned() returns 'false' then it will not create new
>> versions of that page
>
> i see that giving a custom IPageManager is also already ok, that has a
> method supportsVersioning()
> then it doesn't even matter what the page says.
>
> i am also looking into this because we (servoy) has the same problem as Chris
> our pages are just versionable. And until wicket 1.4 this works fine
> because of the http store with change recording.
> But that is now completely gone so or we have to do some major work to
> get everything serializeable or drop the back button support..
How did you store non-serializable objects in the http session (http
store) in 1.4 ?
The session attributes should be serializable if you need clustering
and/or session persistence.
I guess you just didn't use any of these features.

Take a look at https://cwiki.apache.org/confluence/x/qIaoAQ for more
info about the stores. May be useful.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

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



Re: Is it possible to turn off page serialization in 1.5?

2011-10-05 Thread Johan Compagner
On Wed, Oct 5, 2011 at 15:21, Martin Grigorov  wrote:
> yes. each new page gets its id during construction from the session counter.
> if Page#isVersioned() returns 'false' then it will not create new
> versions of that page

i see that giving a custom IPageManager is also already ok, that has a
method supportsVersioning()
then it doesn't even matter what the page says.

i am also looking into this because we (servoy) has the same problem as Chris
our pages are just versionable. And until wicket 1.4 this works fine
because of the http store with change recording.
But that is now completely gone so or we have to do some major work to
get everything serializeable or drop the back button support..

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



Re: Is it possible to turn off page serialization in 1.5?

2011-10-05 Thread Martin Grigorov
On Wed, Oct 5, 2011 at 4:15 PM, Johan Compagner  wrote:
> But that kills the complete back button support right?
right!
>
> Do pages increment their version then?
yes. each new page gets its id during construction from the session counter.
if Page#isVersioned() returns 'false' then it will not create new
versions of that page
>
>
> On Wed, Oct 5, 2011 at 13:47, Martin Grigorov  wrote:
>> On Wed, Oct 5, 2011 at 2:40 PM, Chris Colman
>>  wrote:
>>> Our domain model has about 335 persistent classes so that won't be an 
>>> overnight task ;)
>> I don't remember what exactly #setAutomaticMultiWindowSupport(false)
>> did in 1.4 but its main task for sure wasn't to disabled
>> serialization.
>>
>> In 1.5 there are several approaches to do that.
>> - with IFrameworkSettings#setSerializer() you can setup a ISerializer
>> that is no-op (both directions)
>> - with Application#setPageManagerProvider(IPageManager) you can setup
>> a custom IPageManager that doesn't store pages and returns 'null' when
>> asked for older version
>>>
-Original Message-
From: Robert Dahlström [mailto:robert.dahlst...@ongame.com]
Sent: Wednesday, 5 October 2011 6:24 PM
To: users@wicket.apache.org
Subject: Re: Is it possible to turn off page serialization in 1.5?

Why not simply wrap your objects in a LoadableDetachableModel? That way
you don't need to force serializable objects in your code.

/Rob

On 10/05/2011 08:52 AM, Chris Colman wrote:
> In 1.4 we had used:
>
> getPageSettings().setAutomaticMultiWindowSupport(false);
>
> and everything worked perfectly without making any of our model objects
> serializable.
>
> With 1.5 that method is no longer available and it's causing us to make
> the model object serializable but that's causing a few problems of it's
> own ;)
>
> Is there a way to turn of page serialization in 1.5?
>
> Regards,
> Chris
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Martin Grigorov
>> jWeekend
>> Training, Consulting, Development
>> http://jWeekend.com
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

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



Re: Is it possible to turn off page serialization in 1.5?

2011-10-05 Thread Johan Compagner
But that kills the complete back button support right?

Do pages increment their version then?


On Wed, Oct 5, 2011 at 13:47, Martin Grigorov  wrote:
> On Wed, Oct 5, 2011 at 2:40 PM, Chris Colman
>  wrote:
>> Our domain model has about 335 persistent classes so that won't be an 
>> overnight task ;)
> I don't remember what exactly #setAutomaticMultiWindowSupport(false)
> did in 1.4 but its main task for sure wasn't to disabled
> serialization.
>
> In 1.5 there are several approaches to do that.
> - with IFrameworkSettings#setSerializer() you can setup a ISerializer
> that is no-op (both directions)
> - with Application#setPageManagerProvider(IPageManager) you can setup
> a custom IPageManager that doesn't store pages and returns 'null' when
> asked for older version
>>
>>>-Original Message-
>>>From: Robert Dahlström [mailto:robert.dahlst...@ongame.com]
>>>Sent: Wednesday, 5 October 2011 6:24 PM
>>>To: users@wicket.apache.org
>>>Subject: Re: Is it possible to turn off page serialization in 1.5?
>>>
>>>Why not simply wrap your objects in a LoadableDetachableModel? That way
>>>you don't need to force serializable objects in your code.
>>>
>>>/Rob
>>>
>>>On 10/05/2011 08:52 AM, Chris Colman wrote:
 In 1.4 we had used:

 getPageSettings().setAutomaticMultiWindowSupport(false);

 and everything worked perfectly without making any of our model objects
 serializable.

 With 1.5 that method is no longer available and it's causing us to make
 the model object serializable but that's causing a few problems of it's
 own ;)

 Is there a way to turn of page serialization in 1.5?

 Regards,
 Chris

>>>
>>>-
>>>To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

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



WicketTester#startComponentInPage and tester#assertModelValue

2011-10-05 Thread splitshade
Hi, 

I have a rather strange behavior, and I don´t know what I´m doing wrong.
Before I open a Bug, I would like to hear some opinions, why this works this
way.

I try the following (in Pseudocode):

tester = new WicketTester();
tester.startComponentInPage(new Label("test","hello");
tester.assertModelValue("test","hello"); --> throws 

java.lang.IllegalArgumentException: Component is not a container and so does
not contain the path test.

Funny as it is, to make this work, you have to do the following assertion:

tester.assertModelValue("", "hello");

The error lies in 
public Component getComponentFromLastRenderedPage(String path,
final boolean wantVisibleInHierarchy)
in Line: path = startComponent.getId() + ":" + path;

Here i think you would need to check whether startComponent is a
WebMarkupContainer or not, 
I would file a Bug and provide a patch, or am I completely wrong?

Regards

Martin


--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/WicketTester-startComponentInPage-and-tester-assertModelValue-tp3874269p3874269.html
Sent from the Users forum mailing list archive at Nabble.com.

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



Re: Upgrade 1.5 - PageParameters#toRequestParameters

2011-10-05 Thread splitshade
Hi,

sure I can, I just wanted to make sure, that I haven´t overseen 
an already implemented solution.
Thank you Martin.

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Upgrade-1-5-PageParameters-toRequestParameters-tp3871781p3874199.html
Sent from the Users forum mailing list archive at Nabble.com.

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



Re: Is it possible to turn off page serialization in 1.5?

2011-10-05 Thread Martin Grigorov
On Wed, Oct 5, 2011 at 2:40 PM, Chris Colman
 wrote:
> Our domain model has about 335 persistent classes so that won't be an 
> overnight task ;)
I don't remember what exactly #setAutomaticMultiWindowSupport(false)
did in 1.4 but its main task for sure wasn't to disabled
serialization.

In 1.5 there are several approaches to do that.
- with IFrameworkSettings#setSerializer() you can setup a ISerializer
that is no-op (both directions)
- with Application#setPageManagerProvider(IPageManager) you can setup
a custom IPageManager that doesn't store pages and returns 'null' when
asked for older version
>
>>-Original Message-
>>From: Robert Dahlström [mailto:robert.dahlst...@ongame.com]
>>Sent: Wednesday, 5 October 2011 6:24 PM
>>To: users@wicket.apache.org
>>Subject: Re: Is it possible to turn off page serialization in 1.5?
>>
>>Why not simply wrap your objects in a LoadableDetachableModel? That way
>>you don't need to force serializable objects in your code.
>>
>>/Rob
>>
>>On 10/05/2011 08:52 AM, Chris Colman wrote:
>>> In 1.4 we had used:
>>>
>>> getPageSettings().setAutomaticMultiWindowSupport(false);
>>>
>>> and everything worked perfectly without making any of our model objects
>>> serializable.
>>>
>>> With 1.5 that method is no longer available and it's causing us to make
>>> the model object serializable but that's causing a few problems of it's
>>> own ;)
>>>
>>> Is there a way to turn of page serialization in 1.5?
>>>
>>> Regards,
>>> Chris
>>>
>>
>>-
>>To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>For additional commands, e-mail: users-h...@wicket.apache.org
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

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



RE: Is it possible to turn off page serialization in 1.5?

2011-10-05 Thread Chris Colman
Our domain model has about 335 persistent classes so that won't be an overnight 
task ;)

>-Original Message-
>From: Robert Dahlström [mailto:robert.dahlst...@ongame.com]
>Sent: Wednesday, 5 October 2011 6:24 PM
>To: users@wicket.apache.org
>Subject: Re: Is it possible to turn off page serialization in 1.5?
>
>Why not simply wrap your objects in a LoadableDetachableModel? That way
>you don't need to force serializable objects in your code.
>
>/Rob
>
>On 10/05/2011 08:52 AM, Chris Colman wrote:
>> In 1.4 we had used:
>>
>> getPageSettings().setAutomaticMultiWindowSupport(false);
>>
>> and everything worked perfectly without making any of our model objects
>> serializable.
>>
>> With 1.5 that method is no longer available and it's causing us to make
>> the model object serializable but that's causing a few problems of it's
>> own ;)
>>
>> Is there a way to turn of page serialization in 1.5?
>>
>> Regards,
>> Chris
>>
>
>-
>To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>For additional commands, e-mail: users-h...@wicket.apache.org


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



Re: Messages to FeedBackPanel from AbstractAjaxBehavior onRequest

2011-10-05 Thread Martin Grigorov
On Wed, Oct 5, 2011 at 2:11 PM, Tate Jones  wrote:
> No filters.
>
> response() method did have this at the end.
>
>                IRequestTarget t = new StringRequestTarget("application/json", 
> "UTF-8", jsonAck);
>                getRequestCycle().setRequestTarget(t);
As I said you need JSONP-like approach for having both features
AjaxRequestTarget should be executed last to update the feedback
component, and use target.appendJavascript("myHandler("+jsonAck+")")
where 'myHandler' is a function which will be executed with the
generated JSON as parameter.
>
> Once I removed this the warning message disappeared, however the feedback 
> panel still didn't show the required message.
>
> On 05/10/2011, at 8:07 PM, Martin Grigorov wrote:
>
>> On Wed, Oct 5, 2011 at 1:02 PM, Tate Jones  wrote:
>>> Thanks Martin,
>>>
>>> I am still learning so AbstractAjaxBehavior was my first choice.  No 
>>> reason...
>>>
>>> I have changed it to AbstractDefaultAjaxBehavior and added the following 
>>> code to the respond method.
>>>
>>>                       target.addComponent(feedback);
>>>                       error(errorMessage);
>>>
>>> However I still receiving the same WARNING message.
>> This looks OK.
>> I guess your FeedbackPanel has no explicit filter.
>>>
>>> Layout
>>>
>>> Page
>>>        - feedback
>>>        - form
>>>                - TextFields
>>>                - AbstractDefaultAjaxBehavior has been added here.
>>>
>>> I must missing something very basic.
>>>
>>> On 05/10/2011, at 5:57 PM, Martin Grigorov wrote:
>>>
 Hi,

 Why do you use AbstractAjaxBehavior instead of AbstractDefaultAjaxBehavior?

 AbstractDefaultAjaxBehavior passes you an instance of
 AjaxRequestTarget which you can use to add the feedback panel and show
 the feedback message. It writes a special XML back to the browser
 which wicket-ajax.js (e.g. wicketAjaxPost()) knows how to read and
 uses it to update the components.

 AbstractAjaxBehavior is a bit more general Ajax behavior with which
 you can write back to the response any kind of response (e.g. JSON).

 If you need both kind of responses then I suggest you to use
 AbstractDefaultAjaxBehavior to update components (target.add()) and
 target.appendJavaScript(someJSONP)

 On Wed, Oct 5, 2011 at 10:38 AM, Tate Jones  wrote:
> Hi Group,
>
> I have added a AbstractAjaxBehavior  to WebPage to recieve a 'post' 
> request from JavaScript (.ajax post).  During the onRequest method an 
> error could occur and I want to display this in the FeedbackPanel.  When 
> I attempt to use the error(..) or info(..) method the following WARNING 
> appears in the console.
>
> WARNING: Component-targetted feedback message was left unrendered. This 
> could be because you are missing a FeedbackPanel on the page.  Message: 
> [FeedbackMessage message = "to be display in feedback panel", reporter = 
> 2, level = ERROR]
>
> I already have a working Feedback panel on the page for a basic button 
> submit method.
>
> code fragment.
>
> @AuthorizeInstantiation(Roles.ADMIN)
> public class AdminPage extends WebPage {
>
>    private static final long serialVersionUID = 1L;
>    private static final Logger log = 
> LoggerFactory.getLogger(WebPage.class);
>
>    public AdminPage() {
>
>        add(new FeedbackPanel("feedback"));
>
>
>        Form form = new Form("adminForm", new 
> CompoundPropertyModel(tuneChip));
>        add(form);
>
>        form.add(new RequiredTextField("description"));
>
>           AbstractAjaxBehavior ajaxPostBehaviour = new 
> AbstractAjaxBehavior() {
>            private static final long serialVersionUID = 1L;
>
>            @SuppressWarnings("unchecked")
>            public void onRequest() {
>                /**…..
>                some logic. The something goes wrong...
>                …..**/
>
>                error("Report Error Message");
>            }
>        };
>        add(ajaxPostBehaviour);
>
> What is the best way to bind AbstractAjaxBehavior to the FeedbackPanel or 
> should I used another approach?   As mentioned I am using 
> AbstractAjaxBehavior to received a 'post' request.
>
> eg.
>         "$.ajax({ " +
>                        "url: '" + callBackURL + "'," +
>                        "type: 'post'," +
>        …etc..
>
> Tate
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>



 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com

 -

Re: Messages to FeedBackPanel from AbstractAjaxBehavior onRequest

2011-10-05 Thread Tate Jones
No filters.

response() method did have this at the end.

IRequestTarget t = new StringRequestTarget("application/json", 
"UTF-8", jsonAck);
getRequestCycle().setRequestTarget(t);

Once I removed this the warning message disappeared, however the feedback panel 
still didn't show the required message. 

On 05/10/2011, at 8:07 PM, Martin Grigorov wrote:

> On Wed, Oct 5, 2011 at 1:02 PM, Tate Jones  wrote:
>> Thanks Martin,
>> 
>> I am still learning so AbstractAjaxBehavior was my first choice.  No 
>> reason...
>> 
>> I have changed it to AbstractDefaultAjaxBehavior and added the following 
>> code to the respond method.
>> 
>>   target.addComponent(feedback);
>>   error(errorMessage);
>> 
>> However I still receiving the same WARNING message.
> This looks OK.
> I guess your FeedbackPanel has no explicit filter.
>> 
>> Layout
>> 
>> Page
>>- feedback
>>- form
>>- TextFields
>>- AbstractDefaultAjaxBehavior has been added here.
>> 
>> I must missing something very basic.
>> 
>> On 05/10/2011, at 5:57 PM, Martin Grigorov wrote:
>> 
>>> Hi,
>>> 
>>> Why do you use AbstractAjaxBehavior instead of AbstractDefaultAjaxBehavior?
>>> 
>>> AbstractDefaultAjaxBehavior passes you an instance of
>>> AjaxRequestTarget which you can use to add the feedback panel and show
>>> the feedback message. It writes a special XML back to the browser
>>> which wicket-ajax.js (e.g. wicketAjaxPost()) knows how to read and
>>> uses it to update the components.
>>> 
>>> AbstractAjaxBehavior is a bit more general Ajax behavior with which
>>> you can write back to the response any kind of response (e.g. JSON).
>>> 
>>> If you need both kind of responses then I suggest you to use
>>> AbstractDefaultAjaxBehavior to update components (target.add()) and
>>> target.appendJavaScript(someJSONP)
>>> 
>>> On Wed, Oct 5, 2011 at 10:38 AM, Tate Jones  wrote:
 Hi Group,
 
 I have added a AbstractAjaxBehavior  to WebPage to recieve a 'post' 
 request from JavaScript (.ajax post).  During the onRequest method an 
 error could occur and I want to display this in the FeedbackPanel.  When I 
 attempt to use the error(..) or info(..) method the following WARNING 
 appears in the console.
 
 WARNING: Component-targetted feedback message was left unrendered. This 
 could be because you are missing a FeedbackPanel on the page.  Message: 
 [FeedbackMessage message = "to be display in feedback panel", reporter = 
 2, level = ERROR]
 
 I already have a working Feedback panel on the page for a basic button 
 submit method.
 
 code fragment.
 
 @AuthorizeInstantiation(Roles.ADMIN)
 public class AdminPage extends WebPage {
 
private static final long serialVersionUID = 1L;
private static final Logger log = 
 LoggerFactory.getLogger(WebPage.class);
 
public AdminPage() {
 
add(new FeedbackPanel("feedback"));
 
 
Form form = new Form("adminForm", new 
 CompoundPropertyModel(tuneChip));
add(form);
 
form.add(new RequiredTextField("description"));
 
   AbstractAjaxBehavior ajaxPostBehaviour = new 
 AbstractAjaxBehavior() {
private static final long serialVersionUID = 1L;
 
@SuppressWarnings("unchecked")
public void onRequest() {
/**…..
some logic. The something goes wrong...
…..**/
 
error("Report Error Message");
}
};
add(ajaxPostBehaviour);
 
 What is the best way to bind AbstractAjaxBehavior to the FeedbackPanel or 
 should I used another approach?   As mentioned I am using 
 AbstractAjaxBehavior to received a 'post' request.
 
 eg.
 "$.ajax({ " +
"url: '" + callBackURL + "'," +
"type: 'post'," +
…etc..
 
 Tate
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 
>>> 
>>> 
>>> 
>>> --
>>> Martin Grigorov
>>> jWeekend
>>> Training, Consulting, Development
>>> http://jWeekend.com
>>> 
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>> 
>> 
> 
> 
> 
> -- 
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWee

Re: Messages to FeedBackPanel from AbstractAjaxBehavior onRequest

2011-10-05 Thread Martin Grigorov
On Wed, Oct 5, 2011 at 1:02 PM, Tate Jones  wrote:
> Thanks Martin,
>
> I am still learning so AbstractAjaxBehavior was my first choice.  No reason...
>
> I have changed it to AbstractDefaultAjaxBehavior and added the following code 
> to the respond method.
>
>                       target.addComponent(feedback);
>                       error(errorMessage);
>
> However I still receiving the same WARNING message.
This looks OK.
I guess your FeedbackPanel has no explicit filter.
>
> Layout
>
> Page
>        - feedback
>        - form
>                - TextFields
>                - AbstractDefaultAjaxBehavior has been added here.
>
> I must missing something very basic.
>
> On 05/10/2011, at 5:57 PM, Martin Grigorov wrote:
>
>> Hi,
>>
>> Why do you use AbstractAjaxBehavior instead of AbstractDefaultAjaxBehavior?
>>
>> AbstractDefaultAjaxBehavior passes you an instance of
>> AjaxRequestTarget which you can use to add the feedback panel and show
>> the feedback message. It writes a special XML back to the browser
>> which wicket-ajax.js (e.g. wicketAjaxPost()) knows how to read and
>> uses it to update the components.
>>
>> AbstractAjaxBehavior is a bit more general Ajax behavior with which
>> you can write back to the response any kind of response (e.g. JSON).
>>
>> If you need both kind of responses then I suggest you to use
>> AbstractDefaultAjaxBehavior to update components (target.add()) and
>> target.appendJavaScript(someJSONP)
>>
>> On Wed, Oct 5, 2011 at 10:38 AM, Tate Jones  wrote:
>>> Hi Group,
>>>
>>> I have added a AbstractAjaxBehavior  to WebPage to recieve a 'post' request 
>>> from JavaScript (.ajax post).  During the onRequest method an error could 
>>> occur and I want to display this in the FeedbackPanel.  When I attempt to 
>>> use the error(..) or info(..) method the following WARNING appears in the 
>>> console.
>>>
>>> WARNING: Component-targetted feedback message was left unrendered. This 
>>> could be because you are missing a FeedbackPanel on the page.  Message: 
>>> [FeedbackMessage message = "to be display in feedback panel", reporter = 2, 
>>> level = ERROR]
>>>
>>> I already have a working Feedback panel on the page for a basic button 
>>> submit method.
>>>
>>> code fragment.
>>>
>>> @AuthorizeInstantiation(Roles.ADMIN)
>>> public class AdminPage extends WebPage {
>>>
>>>    private static final long serialVersionUID = 1L;
>>>    private static final Logger log = LoggerFactory.getLogger(WebPage.class);
>>>
>>>    public AdminPage() {
>>>
>>>        add(new FeedbackPanel("feedback"));
>>>
>>>
>>>        Form form = new Form("adminForm", new 
>>> CompoundPropertyModel(tuneChip));
>>>        add(form);
>>>
>>>        form.add(new RequiredTextField("description"));
>>>
>>>           AbstractAjaxBehavior ajaxPostBehaviour = new 
>>> AbstractAjaxBehavior() {
>>>            private static final long serialVersionUID = 1L;
>>>
>>>            @SuppressWarnings("unchecked")
>>>            public void onRequest() {
>>>                /**…..
>>>                some logic. The something goes wrong...
>>>                …..**/
>>>
>>>                error("Report Error Message");
>>>            }
>>>        };
>>>        add(ajaxPostBehaviour);
>>>
>>> What is the best way to bind AbstractAjaxBehavior to the FeedbackPanel or 
>>> should I used another approach?   As mentioned I am using 
>>> AbstractAjaxBehavior to received a 'post' request.
>>>
>>> eg.
>>>         "$.ajax({ " +
>>>                        "url: '" + callBackURL + "'," +
>>>                        "type: 'post'," +
>>>        …etc..
>>>
>>> Tate
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Martin Grigorov
>> jWeekend
>> Training, Consulting, Development
>> http://jWeekend.com
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

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



Re: Messages to FeedBackPanel from AbstractAjaxBehavior onRequest

2011-10-05 Thread Tate Jones
Thanks Martin,

I am still learning so AbstractAjaxBehavior was my first choice.  No reason...

I have changed it to AbstractDefaultAjaxBehavior and added the following code 
to the respond method.

   target.addComponent(feedback);
   error(errorMessage);

However I still receiving the same WARNING message.

Layout

Page
- feedback
- form
- TextFields
- AbstractDefaultAjaxBehavior has been added here.

I must missing something very basic.

On 05/10/2011, at 5:57 PM, Martin Grigorov wrote:

> Hi,
> 
> Why do you use AbstractAjaxBehavior instead of AbstractDefaultAjaxBehavior?
> 
> AbstractDefaultAjaxBehavior passes you an instance of
> AjaxRequestTarget which you can use to add the feedback panel and show
> the feedback message. It writes a special XML back to the browser
> which wicket-ajax.js (e.g. wicketAjaxPost()) knows how to read and
> uses it to update the components.
> 
> AbstractAjaxBehavior is a bit more general Ajax behavior with which
> you can write back to the response any kind of response (e.g. JSON).
> 
> If you need both kind of responses then I suggest you to use
> AbstractDefaultAjaxBehavior to update components (target.add()) and
> target.appendJavaScript(someJSONP)
> 
> On Wed, Oct 5, 2011 at 10:38 AM, Tate Jones  wrote:
>> Hi Group,
>> 
>> I have added a AbstractAjaxBehavior  to WebPage to recieve a 'post' request 
>> from JavaScript (.ajax post).  During the onRequest method an error could 
>> occur and I want to display this in the FeedbackPanel.  When I attempt to 
>> use the error(..) or info(..) method the following WARNING appears in the 
>> console.
>> 
>> WARNING: Component-targetted feedback message was left unrendered. This 
>> could be because you are missing a FeedbackPanel on the page.  Message: 
>> [FeedbackMessage message = "to be display in feedback panel", reporter = 2, 
>> level = ERROR]
>> 
>> I already have a working Feedback panel on the page for a basic button 
>> submit method.
>> 
>> code fragment.
>> 
>> @AuthorizeInstantiation(Roles.ADMIN)
>> public class AdminPage extends WebPage {
>> 
>>private static final long serialVersionUID = 1L;
>>private static final Logger log = LoggerFactory.getLogger(WebPage.class);
>> 
>>public AdminPage() {
>> 
>>add(new FeedbackPanel("feedback"));
>> 
>> 
>>Form form = new Form("adminForm", new 
>> CompoundPropertyModel(tuneChip));
>>add(form);
>> 
>>form.add(new RequiredTextField("description"));
>> 
>>   AbstractAjaxBehavior ajaxPostBehaviour = new 
>> AbstractAjaxBehavior() {
>>private static final long serialVersionUID = 1L;
>> 
>>@SuppressWarnings("unchecked")
>>public void onRequest() {
>>/**…..
>>some logic. The something goes wrong...
>>…..**/
>> 
>>error("Report Error Message");
>>}
>>};
>>add(ajaxPostBehaviour);
>> 
>> What is the best way to bind AbstractAjaxBehavior to the FeedbackPanel or 
>> should I used another approach?   As mentioned I am using 
>> AbstractAjaxBehavior to received a 'post' request.
>> 
>> eg.
>> "$.ajax({ " +
>>"url: '" + callBackURL + "'," +
>>"type: 'post'," +
>>…etc..
>> 
>> Tate
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>> 
>> 
> 
> 
> 
> -- 
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 


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



Re: Upgrade 1.5 - PageParameters#toRequestParameters

2011-10-05 Thread Martin Grigorov
The closest is 
org.apache.wicket.request.mapper.parameter.PageParameters.getAllNamed()
You can write a helper function to convert it to Map wrote:
> Hi,
>
> in 1.5 the Method toRequestParameters in class PageParameters, which returns
> all Parameters as Map is gone, what to use instead?
>
> Thanks
>
> Marti
>
> --
> View this message in context: 
> http://apache-wicket.1842946.n4.nabble.com/Upgrade-1-5-PageParameters-toRequestParameters-tp3871781p3871781.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

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



Re: CouldNotLockPageException using localized RequestMapper URLs

2011-10-05 Thread Martin Grigorov
Hi,

Page ids are session relative. I.e. different users may have the same
page id. The actual key is (sessionId, pageId).
Better dump the stacktraces and see why the thread that acquired the
lock needs more than a minute for it to do its job.

On Tue, Oct 4, 2011 at 8:37 PM, Jim Pinkham  wrote:
> Maybe I'm doing something out of the ordinary - I have several independant
> 'clients' using their own versions of my site, and it's been working OK till
> recent increase in my site's use by several clients at once using the 'same'
> pages.
>
> I have a ClientFirstRootRequestMapper extends AbstractComponentMapper that
> pulls the client prefix from my URL and then chains the call to
> super.mapRequest() with the prefix removed from the url - this has been
> working fine since early 1.5.
>
> But now I have these lockups in production recently.  My theory is that they
> are somehow sharing ids in the page map(s) such that locking behavior is not
> correct.   I'm working on a quickstart, but I thought I'd first throw out
> some details and see if anyone has a better theory?   Obviously, this is a
> pretty major issue for me, since it brings my whole site down, with a bunch
> of http-80-xx threads showing entries like this:
>
> WARN  - PageAccessSynchronizer     - http-80-65 failed to acquire lock to
> page 7, attempted for 1 minute out of allowed 1 minute
> ERROR - PageAccessSynchronizer     - failed to acquire lockheld by
> http-80-70. Would have thrown:
> org.apache.wicket.page.CouldNotLockPageException: Could not lock page 7.
> Attempt lasted 1 minute
>    at
> org.apache.wicket.page.PageAccessSynchronizer.lockPage(PageAccessSynchronizer.java:155)
>    at
> org.apache.wicket.page.PageAccessSynchronizer$2.touchPage(PageAccessSynchronizer.java:214)
> ...
>    at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
>    at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
>    at
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
>    at java.lang.Thread.run(Thread.java:662)
> Oct 3, 2011 5:57:55 PM org.apache.tomcat.util.net.JIoEndpoint
> createWorkerThread
> INFO: Maximum number of threads (200) created for connector with address
> null and port 80
> INFO  - AuctionApplication         - Bye
>
> I already tried this attempted fix to bypass throwing this exception and
> just let it get the lock anyway (I'm desparate here).
>            String info=" held by: ";
>            Iterator locks = this.locks.get().values().iterator();
>            while (locks.hasNext()) {
>                PageLock culprit = locks.next();
>                info += culprit.getThread().getName() + ", ";
>            }
>            if (info.endsWith(", "))
>                info = info.substring(0, info.length()-2);
>
>            logger.error("failed to acquire lock"+info+". Would have thrown:
> ",
>                /*throw*/ new CouldNotLockPageException(pageId,
> thread.getName(), timeout));
>
> In my app, I have mounted a CatalogPage like this:
>
>        getRootRequestMapperAsCompound().add(new MountedMapper("/catalog",
> CatalogPage.class, e));
>
> Running this locally with debug turned on for PageAccessSynchronizer, I open
> two windows and load this page with different prefixes - it appears they use
> the same page id 0 (which might be OK but I'm suspicious..?)
>
> loading http://localhost:8080/clientOne/catalog
>
> 13532 [qtp10217370-20] DEBUG - PageAccessSynchronizer     - 'qtp10217370-20'
> attempting to acquire lock to page with id '0'
> 13532 [qtp10217370-20] DEBUG - PageAccessSynchronizer     - qtp10217370-20
> acquired lock to page 0
> 13532 [qtp10217370-15] DEBUG - PageAccessSynchronizer     - 'qtp10217370-15'
> attempting to acquire lock to page with id '0'
> 13532 [qtp10217370-15] DEBUG - PageAccessSynchronizer     - qtp10217370-15
> acquired lock to page 0
> 13532 [qtp10217370-18] DEBUG - PageAccessSynchronizer     - 'qtp10217370-18'
> attempting to acquire lock to page with id '0'
> 13532 [qtp10217370-18] DEBUG - PageAccessSynchronizer     - qtp10217370-18
> acquired lock to page 0
> 13532 [qtp10217370-15] DEBUG - PageAccessSynchronizer     - qtp10217370-15
> released lock to page 0
> 13532 [qtp10217370-15] DEBUG - PageAccessSynchronizer     - qtp10217370-15
> notifying blocked threads
> 13532 [qtp10217370-20] DEBUG - PageAccessSynchronizer     - qtp10217370-20
> released lock to page 0
> 13532 [qtp10217370-20] DEBUG - PageAccessSynchronizer     - qtp10217370-20
> notifying blocked threads
> 13532 [qtp10217370-18] DEBUG - PageAccessSynchronizer     - qtp10217370-18
> released lock to page 0
> 13532 [qtp10217370-18] DEBUG - PageAccessSynchronizer     - qtp10217370-18
> notifying blocked threads
>
> then http://localhost:8080/clientTwo/catalog
>
> 40953 [qtp10217370-19] DEBUG - PageAccessSynchronizer     - 'qtp10217370-19'
> attempting to acquire lock to page with id '0'
> 40953 [qtp10217370-19] DEBUG - PageAccessSynchronizer     - 

Re: Messages to FeedBackPanel from AbstractAjaxBehavior onRequest

2011-10-05 Thread Martin Grigorov
Hi,

Why do you use AbstractAjaxBehavior instead of AbstractDefaultAjaxBehavior?

AbstractDefaultAjaxBehavior passes you an instance of
AjaxRequestTarget which you can use to add the feedback panel and show
the feedback message. It writes a special XML back to the browser
which wicket-ajax.js (e.g. wicketAjaxPost()) knows how to read and
uses it to update the components.

AbstractAjaxBehavior is a bit more general Ajax behavior with which
you can write back to the response any kind of response (e.g. JSON).

If you need both kind of responses then I suggest you to use
AbstractDefaultAjaxBehavior to update components (target.add()) and
target.appendJavaScript(someJSONP)

On Wed, Oct 5, 2011 at 10:38 AM, Tate Jones  wrote:
> Hi Group,
>
> I have added a AbstractAjaxBehavior  to WebPage to recieve a 'post' request 
> from JavaScript (.ajax post).  During the onRequest method an error could 
> occur and I want to display this in the FeedbackPanel.  When I attempt to use 
> the error(..) or info(..) method the following WARNING appears in the console.
>
> WARNING: Component-targetted feedback message was left unrendered. This could 
> be because you are missing a FeedbackPanel on the page.  Message: 
> [FeedbackMessage message = "to be display in feedback panel", reporter = 2, 
> level = ERROR]
>
> I already have a working Feedback panel on the page for a basic button submit 
> method.
>
> code fragment.
>
> @AuthorizeInstantiation(Roles.ADMIN)
> public class AdminPage extends WebPage {
>
>    private static final long serialVersionUID = 1L;
>    private static final Logger log = LoggerFactory.getLogger(WebPage.class);
>
>    public AdminPage() {
>
>        add(new FeedbackPanel("feedback"));
>
>
>        Form form = new Form("adminForm", new CompoundPropertyModel(tuneChip));
>        add(form);
>
>        form.add(new RequiredTextField("description"));
>
>           AbstractAjaxBehavior ajaxPostBehaviour = new AbstractAjaxBehavior() 
> {
>            private static final long serialVersionUID = 1L;
>
>            @SuppressWarnings("unchecked")
>            public void onRequest() {
>                /**…..
>                some logic. The something goes wrong...
>                …..**/
>
>                error("Report Error Message");
>            }
>        };
>        add(ajaxPostBehaviour);
>
> What is the best way to bind AbstractAjaxBehavior to the FeedbackPanel or 
> should I used another approach?   As mentioned I am using 
> AbstractAjaxBehavior to received a 'post' request.
>
> eg.
>         "$.ajax({ " +
>                        "url: '" + callBackURL + "'," +
>                        "type: 'post'," +
>        …etc..
>
> Tate
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

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



Messages to FeedBackPanel from AbstractAjaxBehavior onRequest

2011-10-05 Thread Tate Jones
Hi Group,

I have added a AbstractAjaxBehavior  to WebPage to recieve a 'post' request 
from JavaScript (.ajax post).  During the onRequest method an error could occur 
and I want to display this in the FeedbackPanel.  When I attempt to use the 
error(..) or info(..) method the following WARNING appears in the console.

WARNING: Component-targetted feedback message was left unrendered. This could 
be because you are missing a FeedbackPanel on the page.  Message: 
[FeedbackMessage message = "to be display in feedback panel", reporter = 2, 
level = ERROR]

I already have a working Feedback panel on the page for a basic button submit 
method.

code fragment.

@AuthorizeInstantiation(Roles.ADMIN)
public class AdminPage extends WebPage {

private static final long serialVersionUID = 1L;
private static final Logger log = LoggerFactory.getLogger(WebPage.class);

public AdminPage() {

add(new FeedbackPanel("feedback"));


Form form = new Form("adminForm", new CompoundPropertyModel(tuneChip));
add(form);

form.add(new RequiredTextField("description"));

   AbstractAjaxBehavior ajaxPostBehaviour = new AbstractAjaxBehavior() {
private static final long serialVersionUID = 1L;

@SuppressWarnings("unchecked")
public void onRequest() {
/**…..
some logic. The something goes wrong...
…..**/

error("Report Error Message");
}
};
add(ajaxPostBehaviour);

What is the best way to bind AbstractAjaxBehavior to the FeedbackPanel or 
should I used another approach?   As mentioned I am using AbstractAjaxBehavior 
to received a 'post' request.

eg.
 "$.ajax({ " +
"url: '" + callBackURL + "'," +
"type: 'post'," +
…etc..

Tate


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



Re: Is it possible to turn off page serialization in 1.5?

2011-10-05 Thread Robert Dahlström
Why not simply wrap your objects in a LoadableDetachableModel? That way 
you don't need to force serializable objects in your code.


/Rob

On 10/05/2011 08:52 AM, Chris Colman wrote:

In 1.4 we had used:

getPageSettings().setAutomaticMultiWindowSupport(false);

and everything worked perfectly without making any of our model objects
serializable.

With 1.5 that method is no longer available and it's causing us to make
the model object serializable but that's causing a few problems of it's
own ;)

Is there a way to turn of page serialization in 1.5?

Regards,
Chris



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