Cannot get Ajax Window Debug to trace responses
Hi, I'm starting a new project so made the jump to wicket 1.5. However when using ajax, I cannot see the responses being returned from the server - this is a form thats submitted via ajax. However if I use an ajx link then I get the response. I'm sure this was not the case with 1.4.x Am I missing something? thanks - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: AjaxSubmitLink 1.4.18 issue/not working
The thing is I'm not doing anything special here, just straight wicket
form stuff AFAIK.
Here is what is generated from wicket for the form and the link:
form id=userForm4e
action=../../?wicket:interface=:2:users:addPersonContainer:addPersonPanel:userForm::IFormSubmitListener::
method=post
...
a onclick=if (document.getElementById('spinnerContainer23'))
(document.getElementById('spinnerContainer23')).style.display =
'inline';if (document.getElementById('submitLink22'))
(document.getElementById('submitLink22')).disabled = true;var
wcall=wicketSubmitFormById('userForm1f',
'../../?wicket:interface=:1:users:addPersonContainer:addPersonPanel:userForm:submitLink::IActivePageBehaviorListener:0:2amp;wicket:ignoreIfNotActive=true',
'submitLink' ,function() { if
(document.getElementById('spinnerContainer23')) {
(document.getElementById('spinnerContainer23')).style.display =
'none';}if (document.getElementById('submitLink22'))
(document.getElementById('submitLink22')).disabled =
false;}.bind(this),function() { alert('There was a communication
problem. Please try refreshing your browser');if
(document.getElementById('spinnerContainer23')) {
(document.getElementById('spinnerContainer23')).style.display =
'none';}if (document.getElementById('submitLink22'))
(document.getElementById('submitLink22')).disabled =
false;}.bind(this), function() {return
Wicket.$$(this)amp;amp;Wicket.$$('userForm1f')}.bind(this));;;
return false; href=# id=submitLink22
spanAdd this person or
group/span
span class=left/span
span class=right/span
span id=spinnerContainer23
style=display:nonenbsp;img
src=../../images/icons/spinnerflat.gif/span
/a
As you may see we have an ajax call decorator as well.
On Sat, Sep 17, 2011 at 3:59 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
no. i thikn it should be
if (typeof(retVal)==undefined) retVal=true;
-igor
On Fri, Sep 16, 2011 at 10:58 AM, Martin Grigorov mgrigo...@apache.org
wrote:
return (typeOf retVal === undefined || retVal === true)
in all other cases stop the submit
looks OK ?
On Fri, Sep 16, 2011 at 8:57 PM, Martin Grigorov mgrigo...@apache.org
wrote:
Yes, sounds like a good idea.
What if the user code returns an object ?
On Fri, Sep 16, 2011 at 6:11 PM, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
i think in this case we should define the undefined to be true...
-igor
On Fri, Sep 16, 2011 at 5:56 AM, Martin Grigorov mgrigo...@apache.org
wrote:
it seems in your code you have form onsubmit=something(); without
returning anything. Since 'if (undefined)' is 'false' the call stops
there.
On Fri, Sep 16, 2011 at 3:25 PM, Wayne W waynemailingli...@gmail.com
wrote:
and in what case does it not return anything?
On Fri, Sep 16, 2011 at 5:04 PM, Martin Grigorov mgrigo...@apache.org
wrote:
It should return true or false.
False if there is some reason to not submit the form, for example
client side validation failed.
True if everything is OK and the submit can proceed.
On Fri, Sep 16, 2011 at 6:21 AM, Wayne W waynemailingli...@gmail.com
wrote:
Hi,
I'm trying to upgrade from 1.4.8 to 1.4.18 and I'm finding that
AjaxSubmitLink is not working (at least with one form).
The form doesn't get submitted - the problem in wicket-ajax.js is
(~line 1120):
// Submits a form using ajax.
// This method serializes a form and sends it as POST body.
submitForm: function(form, submitButton) {
var submittingAttribute = 'data-wicket-submitting';
if (form.onsubmit
!form.getAttribute(submittingAttribute)) {
form.setAttribute(submittingAttribute,
submittingAttribute);
var retValue = form.onsubmit();
form.removeAttribute(submittingAttribute);
if (!retValue) return;
}
The problem is var retValue = form.onsubmit(); does not return any
value (retValue remains undefined) and hence it returns and doesn't do
the submit. I don't know enough about javascript to really understand
whats happening here. The form is fairly unremarkable.
For now I've patch the wicket-ajax.js code and comment out the return,
and it works fine again. I notice this code here was not in 1.4.8. But
obviously this is not the solution.
So I imagine it something to do with the form, but I don't know where
to start and look - what is normally returned by form.onsubmit();?
what can I look for?
many thanks
-
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: AjaxSubmitLink 1.4.18 issue/not working
and in what case does it not return anything?
On Fri, Sep 16, 2011 at 5:04 PM, Martin Grigorov mgrigo...@apache.org wrote:
It should return true or false.
False if there is some reason to not submit the form, for example
client side validation failed.
True if everything is OK and the submit can proceed.
On Fri, Sep 16, 2011 at 6:21 AM, Wayne W waynemailingli...@gmail.com wrote:
Hi,
I'm trying to upgrade from 1.4.8 to 1.4.18 and I'm finding that
AjaxSubmitLink is not working (at least with one form).
The form doesn't get submitted - the problem in wicket-ajax.js is (~line
1120):
// Submits a form using ajax.
// This method serializes a form and sends it as POST body.
submitForm: function(form, submitButton) {
var submittingAttribute = 'data-wicket-submitting';
if (form.onsubmit !form.getAttribute(submittingAttribute))
{
form.setAttribute(submittingAttribute,
submittingAttribute);
var retValue = form.onsubmit();
form.removeAttribute(submittingAttribute);
if (!retValue) return;
}
The problem is var retValue = form.onsubmit(); does not return any
value (retValue remains undefined) and hence it returns and doesn't do
the submit. I don't know enough about javascript to really understand
whats happening here. The form is fairly unremarkable.
For now I've patch the wicket-ajax.js code and comment out the return,
and it works fine again. I notice this code here was not in 1.4.8. But
obviously this is not the solution.
So I imagine it something to do with the form, but I don't know where
to start and look - what is normally returned by form.onsubmit();?
what can I look for?
many thanks
-
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
AjaxSubmitLink 1.4.18 issue/not working
Hi,
I'm trying to upgrade from 1.4.8 to 1.4.18 and I'm finding that
AjaxSubmitLink is not working (at least with one form).
The form doesn't get submitted - the problem in wicket-ajax.js is (~line 1120):
// Submits a form using ajax.
// This method serializes a form and sends it as POST body.
submitForm: function(form, submitButton) {
var submittingAttribute = 'data-wicket-submitting';
if (form.onsubmit !form.getAttribute(submittingAttribute)) {
form.setAttribute(submittingAttribute,
submittingAttribute);
var retValue = form.onsubmit();
form.removeAttribute(submittingAttribute);
if (!retValue) return;
}
The problem is var retValue = form.onsubmit(); does not return any
value (retValue remains undefined) and hence it returns and doesn't do
the submit. I don't know enough about javascript to really understand
whats happening here. The form is fairly unremarkable.
For now I've patch the wicket-ajax.js code and comment out the return,
and it works fine again. I notice this code here was not in 1.4.8. But
obviously this is not the solution.
So I imagine it something to do with the form, but I don't know where
to start and look - what is normally returned by form.onsubmit();?
what can I look for?
many thanks
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Ajax Response xml showing in browser
Hi Jeremy, did you find a solution as we've had the problem for a long time now and more and more people are reporting it as they move over to FF and Chrome? On Tue, Jan 25, 2011 at 3:39 AM, Jeremy Thomerson jer...@wickettraining.com wrote: Perhaps this thread will help: http://apache-wicket.1842946.n4.nabble.com/Ajax-response-render-as-source-in-the-browser-tt3028722.html -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org* On Mon, Jan 24, 2011 at 9:48 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote: please attach a quickstart that reproduce it to a jira issue. -igor On Sun, Jan 23, 2011 at 10:40 PM, Jeffrey Schneller jeffrey.schnel...@envisa.com wrote: Got an odd issue occurring where the Ajax Response xml is showing in the browser rather than modifying the DOM of the page as it usually does. The scenario is the following: My Login page is abstract and has an abstract method called onLoginSuccess. When the login is successful we call onLoginSuccess. Abstract Class called LoginLink which extends AjaxLink LoginLink has an abstract method called onSuccess() and onAlreadyLoggedIn() The Login page is constructed and has it's abstract method onLoginSuccess defined to call onSuccess() The onClick method of LoginLink does a setResponsePage to my Login page if not already logged in and calls onAlreadyLoggedIn() if the user is already logged into the site. I have a page called Page1 which contains a LoginLink. The onSuccess() method is defined to setResponsePage() to the page I ultimately need to go to say Page2. The onAlreadyLoggedIn() method is defined to setResponsePage() to the page I ultimately need to go to say Page2. On Page2, there are AjaxButtons to submit forms. If any button is clicked I get the AjaxResponse xml showing in the browser window. Any ideas on how to solve this? Is there another way of doing this interaction with built in wicket components. Thanks. Jeff - 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: Ajax response render as source in the browser
just to say we still have this issue and its getting more and more
worse as people are moving to FF and Chrome.
We have no idea how to solve as we cannot reproduce it consistently.
On Mon, Dec 13, 2010 at 8:41 PM, Wayne W waynemailingli...@gmail.com wrote:
Hello everyone,
I thought you might be interested. At the weekend I experienced this
problem myself on my local machine, so I had the chance to debug and
figure what was happening.
The short version is 99.9% sure its a javascript engine bug on Firefox
(and we've had a couple of users say they had it on Chome). The only
way to 'fix' the issue was to clear all cached data from the browser.
Restarting the browser or the server made no difference. I will report
this to Mozilla today.
Luckily I could consistently make it fail and succeed so I could debug
and trace exactly what was happening. I don't know if thus is
something to do with the URL format of the request (I very much doubt
it) but its odd that this has never been reported before, but clearly
it wasn't working for use and for some of our users.
We observed the following:
GOOD REQUEST
We could set break points in the wicket-ajax.js and step though it
until the Request.doGet line 841 where transport.send(null) is called.
The headers where:
Response Headers
Content-Type text/xml; charset=utf-8
Pragma no-cache
Cache-Control no-cache, must-revalidate
Expires Mon, 26 Jul 1997 05:00:00 GMT
Content-Length 3346
Server Jetty(6.1.4)
Request Headers
Host foo7.glasscubesdev.com:8080
User-Agent Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB;
rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729;
.NET4.0C)
Accept text/xml
Accept-Language
en-gb,en-us;q=0.9,de;q=0.8,es;q=0.7,pl;q=0.6,hu;q=0.4,nl;q=0.3,sv-se;q=0.2,en;q=0.1
Accept-Encoding gzip,deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive 115
Connection keep-alive
Wicket-Ajax true
Wicket-FocusedElementId changeBillingAddress177
Referer http://foo7.glasscubesdev.com:8080/?wicket:interface=:20
Cookie JSESSIONID=1vsuz0qz6v33o
Now for the BAD REQUEST
At first none of the break points in the javascript would hit at all ,
we'd click on the ajaxlink and immediately we would see the ajax
response from the server in the browser window and the URL in the
address bar as:
http://foo7.glasscubesdev.com:8080/?wicket:interface=:44:changeBillingAddress::IBehaviorListener:0:random=0.7035102055608244
So we knew the javascript must of been running as the random parameter
was different each time it failed.
I then realised that I needed to 're-set' the break points in the
wicket-ajax.js again. It seems that firefug was treating the js file
as a different file when on the failing request versus the good
request. Anyhow once I realised that I could step through it again to
the same line in the Request::doGet(). At this point we got the
behaviour as described before with the URL in the browser and the ajax
response in the page. Looking at the headers we can see:
Response Headers
Content-Type text/xml; charset=utf-8
Expires Mon, 26 Jul 1997 05:00:00 GMT
Cache-Control no-cache, must-revalidate
Pragma no-cache
Content-Length 3346
Server Jetty(6.1.4)
Request Headers
Host foo7.glasscubesdev.com:8080
User-Agent Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB;
rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729;
.NET4.0C)
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language
en-gb,en-us;q=0.9,de;q=0.8,es;q=0.7,pl;q=0.6,hu;q=0.4,nl;q=0.3,sv-se;q=0.2,en;q=0.1
Accept-Encoding gzip,deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive 115
Connection keep-alive
Cookie JSESSIONID=1vsuz0qz6v33o
The wicket specific headers and content type are not there, even
though the code was explicitly setting them just before the call to
transport send.
Our only conclusion is that is must be a javascript engine bug, we
just surprised this has never reported before as its not a wicket bug
.
On Tue, Nov 16, 2010 at 5:29 PM, Wayne W waynemailingli...@gmail.com wrote:
Hello,
we've upgraded the apache to 2.2.15 in production and this made no
difference.
However today we got a screen shot from one client who has been having
the issue see:
https://home.glasscubes.com/share/code/8a8c7ecf37fe9d95cefaf787529b0828
(you'll need to download to see the details of the URL)
What's really odd about this is that it looks like the browser is
doing a HTTP GET rather than using the xml request object - you can
plainly see in the browser the URL. Looking at the code for the
onclick event it looks (to me normal) (see below).
Anyone got any further ideas on this? Its like the wicketAjaxGet is
literally doing a GET!
a onclick=if (document.getElementById('spinnerContainere'))
(document.getElementById('spinnerContainere')).style.display =
'inline
Forms marked as multipart do not work with ajax and IE9
Hi, We have a form that you can make comments in against something. This is submitted normally via a AjaxSubmitLink, however if you attach a file to the form then then form is submitted in a normal non-ajax request. The problem I'm seeing is if a form is marked as multipart/form-data then is submited via ajax IE9 fails with : Wicket.Ajax.Call.failure: Error while parsing response: Could not find root ajax-response IE8 and 7 work fine. Doing some debugging in IE9 versus FF I see that in handleMultipartComplete() that the envelope is of type DispHTMLDocument instead of XMLDocument I'm now trying to work around the problem by removing the enctype attribute if doing an ajax request. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Is there anyway to get a bookmarkable url from calling setResponsePage?
Hi, I love using wicket (1.4) its by far the best web framework for java I have used. However the one thing that really is hard work is the url handling for me. Our users all the time want to copy and paste the url of a given page in to an email or use in a comment to link to something in the app. We've tried making as many links bookmarkable as possible but this only works until they click on another link/action and then the url is lost. I have 2 questions: 1 - is there a way to have a bookmarkable url from using a setResponsePage? Basically we have a tree view, and when one of the nodes is click via ajax I want to redirect them to a given page. However I want that page's URL in the browser to be bookmarkable so they can copy and paste the url. Is there any way of doing this? I've mounted the page using MixedParamUrlCodingStrategy but this doesn't work. 2- is there a better strategy to having all url's bookmarkable (providing the page supports pageparamters)? Are there any changes in wicket 1.5 to make life more easy? thanks - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Is there anyway to get a bookmarkable url from calling setResponsePage?
thanks Martijn, I was looking at someone's else code and it was : params.add(PROJECTID, info.getId().toString()); setResponsePage(new =ProjectPage(params)); rather than: params.add(PROJECTID, info.getId().toString()); setResponsePage(ProjectPage.class, params); Need coffee. Sorry about that. Thanks for the pointer to wicket-annot - looks interesting Another question if you don't mind? Quite often we have a bookmarkable page with a form or link on it. This form/link will update the model and redisplay the current page. When this happens we loose the bookmarkable url. At the end of the onSubmit, or onClick we don't call setResponsePage. Should be call setResponsePage to get the bookmarkable url? On Wed, Feb 9, 2011 at 10:10 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: On Wed, Feb 9, 2011 at 9:37 AM, Wayne W waynemailingli...@gmail.com wrote: 2- is there a better strategy to having all url's bookmarkable (providing the page supports pageparamters)? Are there any changes in wicket 1.5 to make life more easy? Default constructor or constructor with pageparameters: you can take a look at wicket-annot from wicketstuff core Martijn - 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: Ajax response render as source in the browser
Hello everyone,
I thought you might be interested. At the weekend I experienced this
problem myself on my local machine, so I had the chance to debug and
figure what was happening.
The short version is 99.9% sure its a javascript engine bug on Firefox
(and we've had a couple of users say they had it on Chome). The only
way to 'fix' the issue was to clear all cached data from the browser.
Restarting the browser or the server made no difference. I will report
this to Mozilla today.
Luckily I could consistently make it fail and succeed so I could debug
and trace exactly what was happening. I don't know if thus is
something to do with the URL format of the request (I very much doubt
it) but its odd that this has never been reported before, but clearly
it wasn't working for use and for some of our users.
We observed the following:
GOOD REQUEST
We could set break points in the wicket-ajax.js and step though it
until the Request.doGet line 841 where transport.send(null) is called.
The headers where:
Response Headers
Content-Typetext/xml; charset=utf-8
Pragma no-cache
Cache-Control no-cache, must-revalidate
Expires Mon, 26 Jul 1997 05:00:00 GMT
Content-Length 3346
Server Jetty(6.1.4)
Request Headers
Hostfoo7.glasscubesdev.com:8080
User-Agent Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB;
rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729;
.NET4.0C)
Accept text/xml
Accept-Language
en-gb,en-us;q=0.9,de;q=0.8,es;q=0.7,pl;q=0.6,hu;q=0.4,nl;q=0.3,sv-se;q=0.2,en;q=0.1
Accept-Encoding gzip,deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive 115
Connection keep-alive
Wicket-Ajax true
Wicket-FocusedElementId changeBillingAddress177
Referer http://foo7.glasscubesdev.com:8080/?wicket:interface=:20
Cookie JSESSIONID=1vsuz0qz6v33o
Now for the BAD REQUEST
At first none of the break points in the javascript would hit at all ,
we'd click on the ajaxlink and immediately we would see the ajax
response from the server in the browser window and the URL in the
address bar as:
http://foo7.glasscubesdev.com:8080/?wicket:interface=:44:changeBillingAddress::IBehaviorListener:0:random=0.7035102055608244
So we knew the javascript must of been running as the random parameter
was different each time it failed.
I then realised that I needed to 're-set' the break points in the
wicket-ajax.js again. It seems that firefug was treating the js file
as a different file when on the failing request versus the good
request. Anyhow once I realised that I could step through it again to
the same line in the Request::doGet(). At this point we got the
behaviour as described before with the URL in the browser and the ajax
response in the page. Looking at the headers we can see:
Response Headers
Content-Typetext/xml; charset=utf-8
Expires Mon, 26 Jul 1997 05:00:00 GMT
Cache-Control no-cache, must-revalidate
Pragma no-cache
Content-Length 3346
Server Jetty(6.1.4)
Request Headers
Hostfoo7.glasscubesdev.com:8080
User-Agent Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB;
rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729;
.NET4.0C)
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language
en-gb,en-us;q=0.9,de;q=0.8,es;q=0.7,pl;q=0.6,hu;q=0.4,nl;q=0.3,sv-se;q=0.2,en;q=0.1
Accept-Encoding gzip,deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive 115
Connection keep-alive
Cookie JSESSIONID=1vsuz0qz6v33o
The wicket specific headers and content type are not there, even
though the code was explicitly setting them just before the call to
transport send.
Our only conclusion is that is must be a javascript engine bug, we
just surprised this has never reported before as its not a wicket bug
.
On Tue, Nov 16, 2010 at 5:29 PM, Wayne W waynemailingli...@gmail.com wrote:
Hello,
we've upgraded the apache to 2.2.15 in production and this made no difference.
However today we got a screen shot from one client who has been having
the issue see:
https://home.glasscubes.com/share/code/8a8c7ecf37fe9d95cefaf787529b0828
(you'll need to download to see the details of the URL)
What's really odd about this is that it looks like the browser is
doing a HTTP GET rather than using the xml request object - you can
plainly see in the browser the URL. Looking at the code for the
onclick event it looks (to me normal) (see below).
Anyone got any further ideas on this? Its like the wicketAjaxGet is
literally doing a GET!
a onclick=if (document.getElementById('spinnerContainere'))
(document.getElementById('spinnerContainere')).style.display =
'inline';if (document.getElementById('filterEverythingc'))
(document.getElementById('filterEverythingc')).disabled = true;var
wcall=wicketAjaxGet('../?wicket:interface=:1:mainPanel:filterContainer:filterEverything::IBehaviorListener:0:1',function()
{ if (document.getElementById('spinnerContainere')) {
(document.getElementById('spinnerContainere')).style.display
UploadProgressBar alternative that supports Chrome and Safari?
Hi, I just want to check that there isn't an alternative out there already that someone has done that supports webkit browsers? We're finding nearly 20% of our users now are on these browsers so we must support them better, hence why we're looking at alternatives. If not we'll have to write something ourselves - I looked at the current code, but cannot figure out a way of patching that. thanks! - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: UploadProgressBar alternative that supports Chrome and Safari?
Wow thanks Zilvnas - that looks great. How on earth does it calculate the progress? very clever. On Wed, Dec 8, 2010 at 4:08 PM, Zilvinas Vilutis cika...@gmail.com wrote: I use this AJAX uploader: http://valums.com/ajax-upload/ Žilvinas Vilutis Mobile: (+370) 652 38353 E-mail: cika...@gmail.com On Wed, Dec 8, 2010 at 7:46 AM, Martin Grigorov mgrigo...@apache.org wrote: On Wed, Dec 8, 2010 at 3:18 PM, Wayne W waynemailingli...@gmail.com wrote: Hi, I just want to check that there isn't an alternative out there already that someone has done that supports webkit browsers? We're finding nearly 20% of our users now are on these browsers so we must support them better, hence why we're looking at alternatives. If not we'll have to write something ourselves - I looked at the current code, but cannot figure out a way of patching that. Download Wicket source = patch it locally = test it against any browser = attach the patch in Jira ticket and it will be incorporated for the next versions of Wicket ;-) thanks! - 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Tree - component nodeLink not found on page
Hi, we recently introduced a extensions.markup.html.tree.Tree component in our product. However we're seeing some errors in production where the nodeLink in the component cannot be found in the page. In our onNodeLinkClicked we just perform a setResponsePage with a bookmarkable page. I've done a lot of searching around this issue and it seems the main culprits are invalid html or the browser caching something. However we - alas - cannot reproduce this in any way. How does this work? - is it basically telling me that that link (nodeLink) has activity been removed from the page by are code somewhere, however the url has code our of sync with our state on the server? is that right? thanks - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: mobile Apllication via Wicket
We use the excellent wurfl open source project to help us out with devices. On Wed, Nov 10, 2010 at 3:49 PM, jcgarciam jcgarc...@gmail.com wrote: In server side, just check the User-Agent header from your HttpRequest. On Wed, Nov 10, 2010 at 11:41 AM, Madlip89 [via Apache Wicket] ml-node+3036192-1884488973-65...@n4.nabble.comml-node%2b3036192-1884488973-65...@n4.nabble.com wrote: Hey everyone, i must started a apllication with wicket. This is a Web-Application. A must find out, Who send the Request? (SmartPhones or Desctop PC) I started this with a Javascript that's call by browserdetect. Now I'm searching a way to realise that's in wicket. Can u help me, from what object or variable i get this information? please. thank u Madlip -- View message @ http://apache-wicket.1842946.n4.nabble.com/mobile-Apllication-via-Wicket-tp3036192p3036192.html To start a new topic under Apache Wicket, email ml-node+1842946-398011874-65...@n4.nabble.comml-node%2b1842946-398011874-65...@n4.nabble.com To unsubscribe from Apache Wicket, click herehttp://apache-wicket.1842946.n4.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_codenode=1842946code=amNnYXJjaWFtQGdtYWlsLmNvbXwxODQyOTQ2fDEyNTYxMzc3ODY=. -- Sincerely, JC (http://www.linkedin.com/in/jcgarciam) Work smarter, not harder!. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/mobile-Apllication-via-Wicket-tp3036192p3036212.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: Ajax response render as source in the browser
the browser. do you have a proxy between the servlet container and the
outside? maybe something is injecting a redirect or something weird.
I did wonder if there was weird redirect issue, but after doing a lot
of reading yesterday it seems the xmlrequest object *should* handle
redirects fine. However either way we're not doing anything like that.
We've got a couple of tomcat instances load balanced through apache,
routed via a hardware firewall and out of the datacenter, so no
proxies or anything at least I'm aware of.
Its very frustrating.
On Sun, Nov 7, 2010 at 9:41 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
the only way i can see that happenning if the url is no longer
processed by wicket's ajax support and so the response just ends up in
the browser. do you have a proxy between the servlet container and the
outside? maybe something is injecting a redirect or something weird.
-igor
On Sun, Nov 7, 2010 at 8:26 AM, Wayne W waynemailingli...@gmail.com wrote:
thanks Igor,
I've just spent a few hours stepping though the code and I cannot see
anyway the content type could be set wrong - I see the content type is
set in the final respond(requestCycle) method, so I'm now thinking
this is not a content type issue.
However we just got another user email with a screen shot showing the
wicket ajax-response in the browser so something is up.
My javascript knowledge is weak at best so I've not been able to tell
much from the js .
Any ideas on how we can resolve this or at least get more info?
many thanks
On Sat, Nov 6, 2010 at 6:40 PM, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
see AjaxRequestTarget class, this is where the response is generated
on the serverside
wicket-ajax.js is where it is processed on the client side.
-igor
On Sat, Nov 6, 2010 at 2:49 AM, Wayne W waynemailingli...@gmail.com wrote:
Hi Igor,
Whats odd is that one guy was getting it on his iPad consistently and
when we asked him to try his desktop he's got the same problem on
Firefox on Mac. We initially though it might have been a browser
issue. We then got another user who got it only once on Chrome on
windows - all in the space of 1 day. We're worried that's it happening
more often but users are not reporting the issue.
Of course we cannot reproduce the issue, but its definitely happening.
So you don;t think the shared resource could effect the threads in any way?
Where can I start looking in the wicket code to understand where ajax
requests are serviced etc? Is there any where/docs I can find to get
started at looking at this? - at least to complete more my
understanding of how it all works.
thanks
Wayne
On Fri, Nov 5, 2010 at 10:05 PM, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
it may be a content type issue, but it is still weird because the
response is received by the xml http request object, not the browser
directly. strange indeed.
-igor
On Fri, Nov 5, 2010 at 7:51 AM, Wayne W waynemailingli...@gmail.com
wrote:
Hi,
has anyone had this issue? We're getting emails from our users that
sometime when clicking on an ajax link the raw wicket ajax response is
being rendered on the browser - ie the just see all the html source
code on the page. Its not any particular page.
Anyone seen this or has any ideas?
The only thing we have changed recently was adding a non blocking file
download using a link and a shared resource which could be related due
to the Content Type.
In the configureResponse of the shared resource that we set the
Content Type for that request. Is there any chance that this is
somehow polluting the other threads requests?
public class DownloadFileResourceReference extends ResourceReference {
public DownloadFileResourceReference() {
super(DownloadLink.class, );
}
private static final long serialVersionUID = 1L;
public Resource newResource() {
Resource r = new Resource() {
private static final long serialVersionUID = 1L;
public IResourceStream getResourceStream() {
Long id =
getParameters().getLong(DownloadLink.DOCID);
// get file
return new FileResourceStream(new
File(file.getAbsolutePath()));
}
protected void configureResponse(Response
response) {
Long id =
getParameters().getLong(DownloadLink.DOCID);
// get file
((WebResponse)
response).setAttachmentHeader(df.getFileName());
String mimeType =
ResourceHelper.getContentType(df.getFileName());
if (!StringUtils.isEmpty(mimeType)) {
((WebResponse)
response).setContentType(mimeType
Re: Ajax response render as source in the browser
thanks Igor,
I've just spent a few hours stepping though the code and I cannot see
anyway the content type could be set wrong - I see the content type is
set in the final respond(requestCycle) method, so I'm now thinking
this is not a content type issue.
However we just got another user email with a screen shot showing the
wicket ajax-response in the browser so something is up.
My javascript knowledge is weak at best so I've not been able to tell
much from the js .
Any ideas on how we can resolve this or at least get more info?
many thanks
On Sat, Nov 6, 2010 at 6:40 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
see AjaxRequestTarget class, this is where the response is generated
on the serverside
wicket-ajax.js is where it is processed on the client side.
-igor
On Sat, Nov 6, 2010 at 2:49 AM, Wayne W waynemailingli...@gmail.com wrote:
Hi Igor,
Whats odd is that one guy was getting it on his iPad consistently and
when we asked him to try his desktop he's got the same problem on
Firefox on Mac. We initially though it might have been a browser
issue. We then got another user who got it only once on Chrome on
windows - all in the space of 1 day. We're worried that's it happening
more often but users are not reporting the issue.
Of course we cannot reproduce the issue, but its definitely happening.
So you don;t think the shared resource could effect the threads in any way?
Where can I start looking in the wicket code to understand where ajax
requests are serviced etc? Is there any where/docs I can find to get
started at looking at this? - at least to complete more my
understanding of how it all works.
thanks
Wayne
On Fri, Nov 5, 2010 at 10:05 PM, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
it may be a content type issue, but it is still weird because the
response is received by the xml http request object, not the browser
directly. strange indeed.
-igor
On Fri, Nov 5, 2010 at 7:51 AM, Wayne W waynemailingli...@gmail.com wrote:
Hi,
has anyone had this issue? We're getting emails from our users that
sometime when clicking on an ajax link the raw wicket ajax response is
being rendered on the browser - ie the just see all the html source
code on the page. Its not any particular page.
Anyone seen this or has any ideas?
The only thing we have changed recently was adding a non blocking file
download using a link and a shared resource which could be related due
to the Content Type.
In the configureResponse of the shared resource that we set the
Content Type for that request. Is there any chance that this is
somehow polluting the other threads requests?
public class DownloadFileResourceReference extends ResourceReference {
public DownloadFileResourceReference() {
super(DownloadLink.class, );
}
private static final long serialVersionUID = 1L;
public Resource newResource() {
Resource r = new Resource() {
private static final long serialVersionUID = 1L;
public IResourceStream getResourceStream() {
Long id =
getParameters().getLong(DownloadLink.DOCID);
// get file
return new FileResourceStream(new
File(file.getAbsolutePath()));
}
protected void configureResponse(Response response)
{
Long id =
getParameters().getLong(DownloadLink.DOCID);
// get file
((WebResponse)
response).setAttachmentHeader(df.getFileName());
String mimeType =
ResourceHelper.getContentType(df.getFileName());
if (!StringUtils.isEmpty(mimeType)) {
((WebResponse)
response).setContentType(mimeType);
}
}
};
r.setCacheable(false);
return r;
}
}
-
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
-
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: Ajax response render as source in the browser
Hi Igor,
Whats odd is that one guy was getting it on his iPad consistently and
when we asked him to try his desktop he's got the same problem on
Firefox on Mac. We initially though it might have been a browser
issue. We then got another user who got it only once on Chrome on
windows - all in the space of 1 day. We're worried that's it happening
more often but users are not reporting the issue.
Of course we cannot reproduce the issue, but its definitely happening.
So you don;t think the shared resource could effect the threads in any way?
Where can I start looking in the wicket code to understand where ajax
requests are serviced etc? Is there any where/docs I can find to get
started at looking at this? - at least to complete more my
understanding of how it all works.
thanks
Wayne
On Fri, Nov 5, 2010 at 10:05 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
it may be a content type issue, but it is still weird because the
response is received by the xml http request object, not the browser
directly. strange indeed.
-igor
On Fri, Nov 5, 2010 at 7:51 AM, Wayne W waynemailingli...@gmail.com wrote:
Hi,
has anyone had this issue? We're getting emails from our users that
sometime when clicking on an ajax link the raw wicket ajax response is
being rendered on the browser - ie the just see all the html source
code on the page. Its not any particular page.
Anyone seen this or has any ideas?
The only thing we have changed recently was adding a non blocking file
download using a link and a shared resource which could be related due
to the Content Type.
In the configureResponse of the shared resource that we set the
Content Type for that request. Is there any chance that this is
somehow polluting the other threads requests?
public class DownloadFileResourceReference extends ResourceReference {
public DownloadFileResourceReference() {
super(DownloadLink.class, );
}
private static final long serialVersionUID = 1L;
public Resource newResource() {
Resource r = new Resource() {
private static final long serialVersionUID = 1L;
public IResourceStream getResourceStream() {
Long id =
getParameters().getLong(DownloadLink.DOCID);
// get file
return new FileResourceStream(new
File(file.getAbsolutePath()));
}
protected void configureResponse(Response response) {
Long id =
getParameters().getLong(DownloadLink.DOCID);
// get file
((WebResponse)
response).setAttachmentHeader(df.getFileName());
String mimeType =
ResourceHelper.getContentType(df.getFileName());
if (!StringUtils.isEmpty(mimeType)) {
((WebResponse)
response).setContentType(mimeType);
}
}
};
r.setCacheable(false);
return r;
}
}
-
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
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Ajax response render as source in the browser
Hi,
has anyone had this issue? We're getting emails from our users that
sometime when clicking on an ajax link the raw wicket ajax response is
being rendered on the browser - ie the just see all the html source
code on the page. Its not any particular page.
Anyone seen this or has any ideas?
The only thing we have changed recently was adding a non blocking file
download using a link and a shared resource which could be related due
to the Content Type.
In the configureResponse of the shared resource that we set the
Content Type for that request. Is there any chance that this is
somehow polluting the other threads requests?
public class DownloadFileResourceReference extends ResourceReference {
public DownloadFileResourceReference() {
super(DownloadLink.class, );
}
private static final long serialVersionUID = 1L;
public Resource newResource() {
Resource r = new Resource() {
private static final long serialVersionUID = 1L;
public IResourceStream getResourceStream() {
Long id =
getParameters().getLong(DownloadLink.DOCID);
// get file
return new FileResourceStream(new
File(file.getAbsolutePath()));
}
protected void configureResponse(Response response) {
Long id =
getParameters().getLong(DownloadLink.DOCID);
// get file
((WebResponse)
response).setAttachmentHeader(df.getFileName());
String mimeType =
ResourceHelper.getContentType(df.getFileName());
if (!StringUtils.isEmpty(mimeType)) {
((WebResponse)
response).setContentType(mimeType);
}
}
};
r.setCacheable(false);
return r;
}
}
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: FileUpload in ModalWindow
We're on 1.4.7 currently and when I tried 1.4.11 we had a few issues with ajax - unfortunality we've not had time to really try and understand the issue. I'll be interested if anyone else is having a problem. I know there was some work done in the ajax area, but I'm not sure where to start looking. On Tue, Nov 2, 2010 at 10:45 AM, Stefan Lindner lind...@visionet.de wrote: To make it more clear: FileUpload with ProgressBar does not work at all for me. Not in FF not in IE. Without ProgressBar everything works well. This is a Problem since 1.4.11. In 1.4.10 it works well. Stefan - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Firefox : ServletRequest does not contain multipart content
Hi, we see this error time to time in production, and one of use here got the problem ourselves. We have a Form set to multipart true and a FileUploadField and SubmitLink amongst some other fields, however there is no ajax submit. This works 99% of the time it seems. Now this happened using Firefox, Nick here selected the file on his computer and hit submit, he said the browser took about 10 secs or so then he got the error page (with the below stack) trace, and then when back to the Form and tried again - this time is uploaded the image file and refresh the page correctly in about 2 seconds. Does anyone have a clue what could cause this? We're seeing them in production. Caused by: java.lang.IllegalStateException: ServletRequest does not contain multipart content. One possible solution is to explicitly call Form.setMultipart(true), Wicket tries its best to auto-detect multipart forms but there are certain situation where it cannot. at org.apache.wicket.protocol.http.servlet.MultipartServletWebRequest.init(MultipartServletWebRequest.java:113) at org.apache.wicket.protocol.http.servlet.MultipartServletWebRequest.init(MultipartServletWebRequest.java:83) at org.apache.wicket.extensions.ajax.markup.html.form.upload.MultipartRequest.init(MultipartRequest.java:41) at org.apache.wicket.extensions.ajax.markup.html.form.upload.UploadWebRequest.newMultipartWebRequest(UploadWebRequest.java:66) at org.apache.wicket.markup.html.form.Form.handleMultiPart(Form.java:1668) at org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:862) ... 32 more 2010-11-04 15:07:32,053 ERROR - hub.app.wicket.app.HubWebRequestCycle.onRuntimeException(HubWebRequestCycle.java:67) 67 HubWebRequestCycle - Runtime Exception! org.apache.wicket.WicketRuntimeException: Method onFormSubmitted of interface org.apache.wicket.markup.html.form.IFormSubmitListener targeted at component [MarkupContainer [Component id = form]] threw an exception at org.apache.wicket.RequestListenerInterface.invoke(RequestListenerInterface.java:193) at org.apache.wicket.request.target.component.listener.ListenerInterfaceRequestTarget.processEvents(ListenerInterfaceRequestTarget.java:73) at org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:92) at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1250) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1428) at org.apache.wicket.RequestCycle.request(RequestCycle.java:545) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:479) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:312) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.wideplay.warp.persist.PersistenceFilter$3.run(PersistenceFilter.java:141) at com.wideplay.warp.persist.internal.Lifecycles.failEarlyAndLeaveNoOneBehind(Lifecycles.java:29) at com.wideplay.warp.persist.PersistenceFilter.doFilter(PersistenceFilter.java:155) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) 308166,2-999% at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:769) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:698) at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:891) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690) at java.lang.Thread.run(Thread.java:619)
Re: _extend48 - ring any bells?
Here's the code for the CompanyPage (the first panel)
public class CompanyPage extends DashboardMenuPage {
public CompanyPage() {
super(CompanySelected.dashboard);
if (ContextUtil.get().getUser() instanceof ExternalUser) {
TeamProject[] projs =
ContextUtil.get().getUser().getProjects().toArray(new TeamProject[0]);
if (projs.length == 0) {
User admin =
ServiceLocator.getUserService().getFirstAdmin(ContextUtil.get().getCompany());
String body =
getString(noworkspace.message.body);
body = body.replace({0}, admin.getEmail());
setResponsePage(new
MessagePage(getString(noworkspace.message.title), body));
} else {
setResponsePage(new ProjectPage(new
HibernateEntityModelTeamProject(projs[0])));
}
return;
}
// perhaps they have configured their look and feel not to have
the dashboard
// if not redirect to the All workspace page
if
(!ContextUtil.get().getCompany().getGeneralSettings().isShowMyDashboard())
{
throw new RestartResponseException(new
WorkspacesPage());
}
add(new CompanyDashboardPanel(mainPanel));
}
public CompanyPage(PageParameters params) {
super(CompanySelected.dashboard);
if (params.get(PostingLinkBuildingStrategy.POSTINGID) != null) {
IModelPosting postingModel = new
HibernateEntityModelPosting(Posting.class,
params.getLong(PostingLinkBuildingStrategy.POSTINGID));
add(new PostingDetailPanel(mainPanel, postingModel));
} else {
add(new CompanyDashboardPanel(mainPanel));
}
}
}
The second depends on the context, so thats a lot fo code to copy and
paste . Something that looks wrong here is calling setResponsePage
directly in the constructor rather than using
RestartResponseException. However calling setResponsePage does seem to
work fine - could it cause this issue?
What could I look for here?
many thanks
On Wed, Oct 20, 2010 at 4:58 PM, Jeremy Thomerson
jer...@wickettraining.com wrote:
On Wed, Oct 20, 2010 at 5:12 AM, Wayne W waynemailingli...@gmail.comwrote:
Hi Jeremy,
That is the id for the wicket extend tag in your markup
This might be a stupid question - but can I tell where in the page
this might be causing the problem from the _extend38? Is that the 38th
extend for example?
Any hints on how I can track this down?
Show us the java code for the two panels that you sent HTML for.
--
Jeremy Thomerson
http://wickettraining.com
*Need a CMS for Wicket? Use Brix! http://brixcms.org*
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: _extend48 - ring any bells?
Hi Jeremy, That is the id for the wicket extend tag in your markup This might be a stupid question - but can I tell where in the page this might be causing the problem from the _extend38? Is that the 38th extend for example? Any hints on how I can track this down? thanks On Tue, Oct 19, 2010 at 7:47 PM, Jeremy Thomerson jer...@wickettraining.com wrote: That is the id for the wicket extend tag in your markup Jeremy Thomerson http://wickettraining.com -- sent from my smart phone, so please excuse spelling, formatting, or compiler errors On Oct 19, 2010 12:46 PM, Wayne W waynemailingli...@gmail.com wrote: Hi, I've got a problem in production whereby our application home page throws a :Unable to find component with id 'mainPanel' in [MarkupContainer [Component id = _extend48]] This only happens once or twice a week. We don't have any components named '_extend48' or similar anywhere in the code. Whats odd is that this page renders 99% of the time fine, but for the life of me I cannot understand how this can happen. Is the component id given a red herring? Any ideas on how I can find out what causes this? thanks - 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
_extend48 - ring any bells?
Hi, I've got a problem in production whereby our application home page throws a :Unable to find component with id 'mainPanel' in [MarkupContainer [Component id = _extend48]] This only happens once or twice a week. We don't have any components named '_extend48' or similar anywhere in the code. Whats odd is that this page renders 99% of the time fine, but for the life of me I cannot understand how this can happen. Is the component id given a red herring? Any ideas on how I can find out what causes this? thanks - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: _extend48 - ring any bells?
/li 73 li class=userDefinedBg 74 a class=add_link announcements wicket:id=switchAnnoncementsLinkspan wicket:id=switchLabelsiwtch new/old announcements/span/a 75 /li 76 wicket:enclosure 77 li class=userDefinedBg 78 a class=add_link newcube wicket:id=addCubeswicket:message key=company.newCubeCreate a new Cube/wicket:message/a 79 /li 80 /wicket:enclosure 81 li class=expandable userDefinedBg 82 div class=subscribe wicket:id=subscribe/div 83 /li 84 85 /ul 86 div class=spacer/div 87 /div 88 div class=contentBlock_bottomspan class=right_endspan/span/span/div 89 90 91 92 93 h2 class=userDefinedBgspan class=right_endspan class=startwicket:message key=company.hotstuffHot Stuff/wicket:message/span/span/h2 94 div class=contentBox_body 95 div class=contentBlock 96 div wicket:id=hotStuff/div 97 div class=spacer/div 98 /div 99 div class=contentBlock_bottomspan class=right_endspan/span/span/div 100 /div 101 102 103 104 105 106 h2 class=userDefinedBg filter wicket:id=workspaceFilterContainer 107 spanwicket:container wicket:id=cubesTitleAll Cubes/wicket:container/span 108 div class=filter 109 a href= wicket:id=filterCubes wicket:container wicket:id=filterTextMe as member/wicket:container/a 110 span class=loading spinner wicket:id=workspaceSpinnerContainer style=display:nonenbsp;img src=images/icons/throbber.gif //span 111 /div 112 /h2 113 div class=contentBox_body 114 div class=contentBlock wicket:id=allProjectsContainer 115 div wicket:id=allProjects/div 116 div class=spacer/div 117 /div 118 div class=contentBlock_bottomspan class=right_endspan/span/span/div 119 /div 120 121 /div 122 /div 123 /wicket:panel 124 /body 125 /html On Tue, Oct 19, 2010 at 7:50 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: Would you show the html of this mainpanel and also its super panel? ** Martin 2010/10/19 Wayne W waynemailingli...@gmail.com: Hi, I've got a problem in production whereby our application home page throws a :Unable to find component with id 'mainPanel' in [MarkupContainer [Component id = _extend48]] This only happens once or twice a week. We don't have any components named '_extend48' or similar anywhere in the code. Whats odd is that this page renders 99% of the time fine, but for the life of me I cannot understand how this can happen. Is the component id given a red herring? Any ideas on how I can find out what causes this? thanks - 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 - To unsubscribe, e-mail
