Re: problems with AjaxFallbackLink on IE

2011-12-06 Thread Nicklas Johnson
I believe target is null when you're in fallback mode with an
AjaxFallbackLink.  You'll need to check for null and handle things
accordingly, as though it were a normal link.


On 12/6/11 10:24 AM, cosmindumy cosmind...@yahoo.com wrote:

 I'm not at office now but most surely this line is Registration.java:787 :
 
 target.addComponent(captchaImage); and I think target is null.
 
 I think I had this problem before in another context, but then target was
 null all the time, on all browsers.
 I changed AjaxFallbackLink with AjaxLink and it worked.
 
 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/problems-with-AjaxFallbackLink-on-I
 E-tp4165457p4165836.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
 

-- 
Nicklas Johnson -=- N6OL
TIBU CTX Software Engineer
Ask is not a noun.  You mean request, requirement, or question.


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



HeaderContributors, Ajax and IE8

2011-05-17 Thread Nicklas Johnson
(posting this as its own thread rather than burying it in a reply like I did
last time)

Has anyone experienced HeaderContributors being ineffective in IE8 when
added via an ajax event?

The scenario is that a component with an attached Ibehavior which in turn
provides several Javascript HeaderContributors is added to an ajax target
(eg, target.addComponent(fooComponent)).

In Firefox the HeaderContributor seems to be added and evaluated correctly,
and the behavior works as expected.  In IE8, however, the contributed
Javascript appears not to be evaluated.

We are able to work around it by pre-adding the HeaderContributors to the
page (thus prior to the ajax event being fired), but that's kind of a messy
solution... Would rather see IE8 doing the right thing.

(Still need to get up to the latest 1.4, so it's possible that this problem
has already been addressed, though I'm curious if it is or was a known
problem with that dreadful browser.)

   Nick
-- 
Nicklas Johnson -=- N6OL
TXBU Software Engineer
Ask is not a noun.  You mean request, requirement, or question.



Re: ModalWindow with Panel - HeaderContributor in Panel not called

2011-05-12 Thread Nicklas Johnson
On a related note, has anyone experienced HeaderContributors being
ineffective in IE8 when added via an ajax event?

The scenario is that a component with an attached Ibehavior which in turn
provides several Javascript HeaderContributors is added to an ajax target
(eg, target.addComponent(fooComponent)).

In Firefox the HeaderContributor seems to be added and evaluated correctly,
and the behavior works as expected.  In IE8, however, the contributed
Javascript appears not to be evaluated.

We are able to work around it by pre-adding the HeaderContributors prior to
the ajax event being fired, but that's kind of a messy solution... Would
rather see IE8 doing the right thing.

(Still need to get up to the latest 1.4, so it's possible that this problem
has already been addressed, though I'm curious if it is or was a known
problem with that dreadful browser.)

   Nick


On 5/12/11 9:51 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote:

 wicket keeps track of header contributions and doesnt contribute the
 same contribution more then once.
 
 -igor
 
 
 On Thu, May 12, 2011 at 1:24 AM, Marieke Vandamme
 marieke.vanda...@tvh.be wrote:
 Igor,
 
 Thanks for the answer, and you're right indeed.
 I forgot that I added code in my HeaderContributor that checked if it was an
 ajax request. Because I found it useless so re-add all the css + js to the
 page just when you're readding your form after validation or something. But
 when using the HeaderContributor with the modalwindow, I can never be
 certain that the css / js is already loaded or not.
 So I just removed my ajax-check, and now it's working. But can I maybe add
 some test to check if my HomeMadeReusabel component is inside a ModalWindow?
 Because now I re-add the js + css every time on an ajax call, and most of
 the time it's not necessary.
 
 Thanks! Marieke Vandamme
 
 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/ModalWindow-with-Panel-HeaderContr
 ibutor-in-Panel-not-called-tp3514628p3516743.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
 

-- 
Nicklas Johnson -=- N6OL
TXBU Software Engineer
Ask is not a noun.  You mean request, requirement, or question.


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



FeedbackPanel's ListView paths missing in WicketTester 1.3.7

2010-03-26 Thread Nicklas Johnson
I¹m trying to drop in 1.3.7 to correct a number of AutoComplete-related
problems, and finding a new problem:

Whereas a FeedbackPanel used to contain paths like this:

feedback:feedbackul:messages:0:message
feedback:feedbackul:messages:1:message

And one could assertLabel on these, now the only path is:

feedback:feedbackul:messages

Which appears to contain the whole ListView.  The individual paths
underneath are no longer reachable/assertable.  They DO, however, render to
the content on the page.

So my questions are: is this intentional and if so, what is the reasoning
behind it... And what¹s the new/right/best way to do these assertions?
(Weirdly assertErrorMessages and assertInfoMessages both fail in this case
(it¹s a warn, not an info or error), which is probably the reason the test
was doing an assertLabel in the first place.)

Suggestions?


1.3.6?

2009-04-23 Thread Nicklas Johnson
I've seen a few posts in the archive over the last few months asking about
1.3.6, but not a definitive answer.

Is 1.3.6 coming?  If so, is there a ballpark about when?

(I've got a project that needs to upgrade, and we're trying to decide
whether to go to 1.3.5 or wait a bit for 1.3.6.)

   Nick

-- 
Courage isn't just a matter of not being frightened, you know. It's being
afraid and doing what you have to do anyway.
  -- Doctor Who - Planet of the Daleks
This message has been brought to you by Nick Johnson 2.3b1 and the number 6.
http://healerNick.com/   http://morons.org/http://spatula.net/