Martin,
ok, I will think about going to one of the ideas Thomas suggested. I still like
the
idea that I have my javascript only in the markup file and nothing in the Java
class,
though...
Thanks again,
J.
On 04.06.2012 21:25, Martin Grigorov wrote:
On Mon, Jun 4, 2012 at 10:22 PM, Jürgen L
On Mon, Jun 4, 2012 at 10:22 PM, Jürgen Lind wrote:
> Thanks Martin,
>
> maybe I should have asked before trying to invent my own stuff... Anyway,
> developing
> a new wicket tag was some kind of fun as well...
I'm glad you have fun but I highly recommend staying away from
IComponentResolver if y
… or you could put your Javascript code into a template, e.g. like that:
MyComponent.js.tmpl:
$('#${markupId} .ttr').tipTip({defaultPosition: 'right'});
// ... some long Javascript block ….
and in MyComponent.java you'd have:
---
public
Thanks Martin,
maybe I should have asked before trying to invent my own stuff... Anyway,
developing
a new wicket tag was some kind of fun as well...
J.
On 04.06.2012 21:10, Martin Grigorov wrote:
On Mon, Jun 4, 2012 at 10:01 PM, Jürgen Lind wrote:
Thomas,
thanks for this hint, didn't know
On Mon, Jun 4, 2012 at 10:01 PM, Jürgen Lind wrote:
> Thomas,
>
> thanks for this hint, didn't know about that... So the script is executed
> every time the
> component is updated in an ajax call, correct? If so, it would surely solve
For every rerender of the component. That includes non-Ajax (w
Thomas,
thanks for this hint, didn't know about that... So the script is executed every
time the
component is updated in an ajax call, correct? If so, it would surely solve
some of my
issues. For longer scripts, I would still prefer to have them in the markup
file (might be
different if we had
What about this?
public class MyComponent extends Panel {
public MyComponent(String id) {
super(id);
setOutputMarkupId(true);
}
@Override
public void renderHead(IHeaderResponse response) {
response.renderOnDomReadyJavaScript(
"$('#" + getM
That's right, I just checked the sources... Anyways, although migration the
project
now does not make sense, it is a good idea for the next project...
Thanks everybody,
J.
On 20.02.2012 08:31, Wilhelmsen Tor Iver wrote:
Thanks a lot. One last stupid question: is this supposed to work for Wick
> Thanks a lot. One last stupid question: is this supposed to work for Wicket
> 1.4?
Doubful, the event system was added in 1.5
- Tor Iver
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e
Thanks a lot. One last stupid question: is this supposed to work for Wicket 1.4?
J.
On 19.02.2012 15:28, Christoph Leiter wrote:
$(document).ready(function() {
Wicket.Event.subscribe('/dom/node/added', function(element) {
$(element).css('border', '1px solid red');
});
});
Sure:
$(document).ready(function() {
Wicket.Event.subscribe('/dom/node/added', function(element) {
$(element).css('border', '1px solid red');
});
});
On 19.02.2012 13:39, Jürgen Lind wrote:
I'm not sure if I get you right on this one: the first argument of which
event
handler is
I'm not sure if I get you right on this one: the first argument of which event
handler is the added element? Could you probably add some code to illustrate
this?
J.
On 19.02.2012 13:28, Christoph Leiter wrote:
Hi Juergen,
there's actually no need to scan the full DOM with this method. :) The
Hi Juergen,
there's actually no need to scan the full DOM with this method. :) The
first argument of the event handler is the added element. You can simply
use it as is or pass it to $() to do jQuery magic just for the relevant
part.
Christoph
On 19.02.2012 13:18, Jürgen Lind wrote:
Chri
Christoph,
I have use yout approach (jQuery + css-class) for some time now as well.
However, I
have found that if the DOM tree grows rather large, a full scan puts
significant load
on the browser. That's why I want to be more specific and limit the scanning +
updating
to the relevant parts of
On 18.02.2012 17:46, Jürgen Lind wrote:
thank you for your reply, I did not know that such a method exists (does
it for 1.4
or is this already Wicket 1.5). An secondly: are these handlers fired on
a ajax
update of an existing DOM Element or only when it is added?
This is also available in 1.4.
s@wicket.apache.org"
> Sent: Sunday, 19 February 2012, 12:08
> Subject: Re: Component specific JavaScript
>
> Hi Jorge,
>
> thanks for the hint, unfortunately, this method is only available in Wicket
> 1.5 -
> in this projekt, I am still using Wicket 1.4. Maybe I should stop
(IHeaderResponse)
IHeaderResponse#renderOnDomReadyJavascript() methods are available in 1.4.x.
What exactly you think is not available there ?
From: Jürgen Lind
To: "users@wicket.apache.org"
Sent: Sunday, 19 February 2012, 12:08
Subject: Re: Component specific
9 February 2012, 12:08
Subject: Re: Component specific JavaScript
Hi Jorge,
thanks for the hint, unfortunately, this method is only available in Wicket 1.5
-
in this projekt, I am still using Wicket 1.4. Maybe I should stop looking for
a general solution for this project and in the future use the so
Hi Jorge,
thanks for the hint, unfortunately, this method is only available in Wicket 1.5
-
in this projekt, I am still using Wicket 1.4. Maybe I should stop looking for
a general solution for this project and in the future use the solution you
suggested...
J.
On 19.02.2012 10:30, Jorge Rodr
Hi,
I think you just need:
class MyComponent extends SomeWicketComponent {
@Override public void renderHead(IHeaderResponse response) {
response.renderOnDomReadyJavascript("someJSToExecute()");
}
}
someJSToExecute() will be executed every time an instance of MyComponent is
rendered. Bot
Hi Christoph,
thank you for your reply, I did not know that such a method exists (does it for
1.4
or is this already Wicket 1.5). An secondly: are these handlers fired on a ajax
update of an existing DOM Element or only when it is added?
And where would I put the Javascript that registers the h
Hello Juergen,
you can register a function that gets called when wicket creates a new
element in the DOM:
Wicket.Event.subscribe('/dom/node/added', function(element) {
// do stuff
});
You can also use the '/dom/node/removing' channel.
Hope this helps.
Christoph
Jürgen Lind (2012-02
Hi,
I was wondering if there is any kind of best practice to add specific javascript
to a component. I often have the case, where a piece of javascript needs to run
when the component is rendered as part of full-page request, and then
subsequently
as part of a self-triggered Ajax-Request or as p
23 matches
Mail list logo
