@Override
public void detach(Component component)
{
AjaxRequestTarget target =
component.getRequestCycle().find(AjaxRequestTarget.class);
if (target != null)
{
stop(target);
}
Just a heads up: less than 24 hours before cutting 6.5.0...
Martijn
On Mon, Jan 14, 2013 at 9:00 AM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
I'll craft a 6.5.0 release on friday.
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
--
Become a Wicket
On Thu, Jan 17, 2013 at 12:17 PM, Sven Meier s...@meiers.net wrote:
@Override
public void detach(Component component)
{
AjaxRequestTarget target = component.getRequestCycle().**
find(AjaxRequestTarget.class);
if (target != null)
Hi,
On Thu, Jan 17, 2013 at 11:17 AM, Sven Meier s...@meiers.net wrote:
@Override
public void detach(Component component)
{
AjaxRequestTarget target = component.getRequestCycle().**
find(AjaxRequestTarget.class);
if (target != null)
I've used component#detach() when the code didn't have a reference to
the model.
Maybe we need another callback method in Behavior
A #removed() callback might be useful ... or overkill ;)
Sven
On 01/17/2013 11:33 AM, Martin Grigorov wrote:
On Thu, Jan 17, 2013 at 12:17 PM, Sven Meier
Yeah, this is what I wrote in my first comment:
Thus the next pending Ajax request comes through, since wicket-ajax's
defaultPrecondition sees the markupId still present in the dom.
Perhaps we have to cancel out all scheduled callbacks for components
which are replaced via Ajax.
Sven
On
Or maybe mark those behaviors as if it fails do not throw exception.
That way when call back comes behavior will be removed form client side and
failing request ignored?
On Thu, Jan 17, 2013 at 11:44 AM, Sven Meier s...@meiers.net wrote:
Yeah, this is what I wrote in my first comment:
Thus
Hi,
I see there is
/**
* Remove any scheduled timers on the removed element.
* This wont remove the timer for elements which are children of the
removed one.
*/
Wicket.Event.subscribe('/dom/node/removing', function(jqEvent, element) {
var id = element.id;
if (Wicket.TimerHandles
On Thu, Jan 17, 2013 at 12:53 PM, Ernesto Reinaldo Barreiro
reier...@gmail.com wrote:
Hi,
I see there is
/**
* Remove any scheduled timers on the removed element.
* This wont remove the timer for elements which are children of the
removed one.
*/
ok. forget this comment. JavaScript doc is very explicit.
On Thu, Jan 17, 2013 at 11:53 AM, Ernesto Reinaldo Barreiro
reier...@gmail.com wrote:
Hi,
I see there is
/**
* Remove any scheduled timers on the removed element.
* This wont remove the timer for elements which are children of
On Thu, Jan 17, 2013 at 12:36 PM, Sven Meier s...@meiers.net wrote:
I've used component#detach() when the code didn't have a reference to the
model.
component.getModel().detach() ?! :-)
Maybe we need another callback method in Behavior
A #removed() callback might be useful ... or
I've attached a patch to WICKET-4959 that introduces
Behavior#onRemove(Component) - a callback that is called when a host
component is removed from its parent.
But there is still a chance for race , much lower than before but still
here .. :-/
On Thu, Jan 17, 2013 at 1:00 PM, Martin Grigorov
Lazy me ;)
On 01/17/2013 12:00 PM, Martin Grigorov wrote:
On Thu, Jan 17, 2013 at 12:36 PM, Sven Meier s...@meiers.net wrote:
I've used component#detach() when the code didn't have a reference to the
model.
component.getModel().detach() ?! :-)
Maybe we need another callback method in
Hi,
it may sound like a crazy idea, but sometimes a good idea started as a
crazy one: I want to remove javax.servlet from wicket-core. Why? Here
are some thoughts:
- run a wicket application on a netty/vert.x/what-ever stack
- make test easier (BaseWicketTester is not as clear as it should
Isolating Servlet dependencies could potentially ease portlet support, too.
It won't be an easy task, though. Some of the main classes of the
framework, like WicketFilter, are deeply coupled to the Servlet API.
But I'm not sure if the benefits out-weight the cost of doing the changes
and
15 matches
Mail list logo
