Re: Best practice sought: Register client change at server
an AjaxEventBehavior, but I don't have a component to attach it to. You have a page, don't you? Otherwise you can request a resource via Ajax too. Regards Sven On 07/11/2014 02:47 AM, Joachim Schrod wrote: Hi, In a Wicket application I have JQuery code that triggers after a certain time of user inactivity. I need to tell server-side about that inactivity. No problem, I thought, just issue an AJAX request. Well, looking around I found several possibilities to do that as a side effect, but no component at first hand that is made up for that task. I thought that's strange, it doesn't sound as a remote demand. So my question is about best practice for this use case. Namely: I have a change on client-side that I want to communicate to server-side. No changes in DOM are associated. Just like triggering an AjaxLink where onClick() does not call any methods on target. I know about the JavaScript function Wicket.Ajax.ajax() and its arguments. My problem is choosing the right component server-side. An AjaxEventBehavior would be the right thing, but I don't have a component to attach it to. The worst solution would be a hidden AjaxLink. IMO I simply need to establish a listener URL that triggers some method, an URL that I can use in a Wicket.Ajax.ajax() call -- but I don't find the Wicket component that supplies me with that functionality. How can I do that? Or is my focus on the Wicket.Ajax.ajax() JS interface blocking my view on another solution that's better? I know my way around Wicket's code and documentation. Thus, a hint like start with class XYZ would be very much appreciated, I don't need a full solution with code. I'm surely missing something obvious and would severely appreciate any help or tips. Cheers, Joachim - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: equals() method for LoadableDetachableModels
Hi, detachable models should never use getObject() in their implementation of equals()? generally this is a good advice: there are several places in Wicket checking for model equality (e.g. ReuseIfModelsEqualStrategy). A detachable model should have enough information to decide equality without loading the model object. Regards Sven On 07/11/2014 01:52 AM, Boris Goldowsky wrote: I’ve started using CheckingObjectOutputStream to test for models of database objects that are not properly detached, and find it very useful. However I just diagnosed (after many hours of frustration) that it can also cause problems rather than solve them. CheckingObjectOutputStream causes the equals() method of models to be called, and in the case of our models the equals() implementation loads the database object (models of the same object being considered equal to each other). Since it’s doing this during serialization and thus after the detach process, the checker actually causes the exact problem that it’s supposed to prevent (and doesn’t generate any warnings in this case). Is it a general rule, that I was just not aware of, that detachable models should never use getObject() in their implementation of equals()? Or should CheckingObjectOutputStream be changed to avoid calling equals() ? Bng - 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: equals() method for LoadableDetachableModels
Hi, On Fri, Jul 11, 2014 at 9:51 AM, Sven Meier s...@meiers.net wrote: Hi, detachable models should never use getObject() in their implementation of equals()? generally this is a good advice: there are several places in Wicket checking for model equality (e.g. ReuseIfModelsEqualStrategy). A detachable model should have enough information to decide equality without loading the model object. Shouldn't the serialize primary key=the bit of info needed to recover data on attach stored on LDM be the criteria for equality? Regards Sven On 07/11/2014 01:52 AM, Boris Goldowsky wrote: I’ve started using CheckingObjectOutputStream to test for models of database objects that are not properly detached, and find it very useful. However I just diagnosed (after many hours of frustration) that it can also cause problems rather than solve them. CheckingObjectOutputStream causes the equals() method of models to be called, and in the case of our models the equals() implementation loads the database object (models of the same object being considered equal to each other). Since it’s doing this during serialization and thus after the detach process, the checker actually causes the exact problem that it’s supposed to prevent (and doesn’t generate any warnings in this case). Is it a general rule, that I was just not aware of, that detachable models should never use getObject() in their implementation of equals()? Or should CheckingObjectOutputStream be changed to avoid calling equals() ? Bng - 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 -- Regards - Ernesto Reinaldo Barreiro
Re: equals() method for LoadableDetachableModels
Hi, I agree that using the primary key should be enough for #equals() but does org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream#check() really need to use #equals() (via Stack#contains()) ? I think checking for identity equality should be OK too. Java Serialization is not the simplest part of Java and I may miss something... On Fri, Jul 11, 2014 at 10:51 AM, Sven Meier s...@meiers.net wrote: Hi, detachable models should never use getObject() in their implementation of equals()? generally this is a good advice: there are several places in Wicket checking for model equality (e.g. ReuseIfModelsEqualStrategy). A detachable model should have enough information to decide equality without loading the model object. Regards Sven On 07/11/2014 01:52 AM, Boris Goldowsky wrote: I’ve started using CheckingObjectOutputStream to test for models of database objects that are not properly detached, and find it very useful. However I just diagnosed (after many hours of frustration) that it can also cause problems rather than solve them. CheckingObjectOutputStream causes the equals() method of models to be called, and in the case of our models the equals() implementation loads the database object (models of the same object being considered equal to each other). Since it’s doing this during serialization and thus after the detach process, the checker actually causes the exact problem that it’s supposed to prevent (and doesn’t generate any warnings in this case). Is it a general rule, that I was just not aware of, that detachable models should never use getObject() in their implementation of equals()? Or should CheckingObjectOutputStream be changed to avoid calling equals() ? Bng - 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: base pages without kludge initialization
I'm 50/50 here.
I agree that it will make it simpler for your use case but in the same time
it will make it possible to expose the parameters+model constructor as
public in YourPage and the problem will become a RuntimeException while at
the moment it is just not possible (i.e. a compile error). Additionally the
runtime exception message will be quite wordy trying to explain why it is
not allowed to have both parameters _and_ a model.
On the other side I am not really sure that it is not allowed to have them
both. As you see in my workaround it is possible to set the model via
setDefaultModel(). So the current protection (if this is really a
protection by design) is insufficient.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Fri, Jul 11, 2014 at 12:05 AM, Garret Wilson gar...@globalmentor.com
wrote:
On 7/10/2014 3:43 AM, Martin Grigorov wrote:
I
think org.apache.wicket.Page#Page(org.apache.wicket.request.
mapper.parameter.PageParameters,
org.apache.wicket.model.IModel?) is private to make it explicit that a
page with PageParameters is bookmarkable and possibly stateless, and a
Page
with IModel is not bookmarkable and stateful.
That makes sense. But that issue can be taken care of easily enough using
a precondition:
protected BasePage(final PageParameters parameters, final IModel?
model)
{
super(parameters);
checkArgument(parameters == null || model == null, Must not provide
both parameters and a model.);
There is a very simple workaround for you:
super(parameters);
setDefaultModel(model);
this.myConstant1 = ...
this.myConstant2 = ...
Ah, thanks! I will use that.
Still, it seems a shame to explicitly set the default model (which goes
through a lot of change-reporting logic), when we could have provided it to
the constructor. I note that even the Page constructor uses the sort of
constructor chaining that I want to do:
protected Page()
{
this(null, null);
}
protected Page(final IModel? model)
{
this(null, model);
}
protected Page(final PageParameters parameters)
{
this(parameters, null);
}
private Page(final PageParameters parameters, IModel? model)
{
But because the ultimate constructor is marked private, even WebPage is
forced to go through the common-initialization drudgery:
protected WebPage(final IModel? model)
{
super(model);
commonInit();
}
etc.
I recommend Wicket modify the Page ultimate constructor to be protected,
and add a simple precondition to keep it from being accidentally misused:
protected Page(final PageParameters parameters, final IModel? model)
{
super(parameters);
checkArgument(parameters == null || model == null, Must not provide
both parameters and a model.);
Cheers,
Garret
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Best practice sought: Register client change at server
page.add(new AjaxEventBehavior(my-special-event) {...});
in JS code: jQuery(document).triggerHandler('my-special-event');
Voila!
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Fri, Jul 11, 2014 at 10:15 AM, Sven Meier s...@meiers.net wrote:
an AjaxEventBehavior, but I don't have a component to attach it to.
You have a page, don't you?
Otherwise you can request a resource via Ajax too.
Regards
Sven
On 07/11/2014 02:47 AM, Joachim Schrod wrote:
Hi,
In a Wicket application I have JQuery code that triggers after a
certain time of user inactivity. I need to tell server-side about
that inactivity. No problem, I thought, just issue an AJAX request.
Well, looking around I found several possibilities to do that as a
side effect, but no component at first hand that is made up for
that task. I thought that's strange, it doesn't sound as a remote
demand. So my question is about best practice for this use case.
Namely: I have a change on client-side that I want to communicate
to server-side. No changes in DOM are associated. Just like
triggering an AjaxLink where onClick() does not call any methods on
target. I know about the JavaScript function Wicket.Ajax.ajax() and
its arguments. My problem is choosing the right component server-side.
An AjaxEventBehavior would be the right thing, but I don't have a
component to attach it to. The worst solution would be a hidden
AjaxLink. IMO I simply need to establish a listener URL that
triggers some method, an URL that I can use in a Wicket.Ajax.ajax()
call -- but I don't find the Wicket component that supplies me with
that functionality.
How can I do that?
Or is my focus on the Wicket.Ajax.ajax() JS interface blocking my
view on another solution that's better?
I know my way around Wicket's code and documentation. Thus, a hint
like start with class XYZ would be very much appreciated, I don't
need a full solution with code. I'm surely missing something
obvious and would severely appreciate any help or tips.
Cheers,
Joachim
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Best practice sought: Register client change at server
On 07/11/14 04:44, Ernesto Reinaldo Barreiro wrote: On Fri, Jul 11, 2014 at 2:47 AM, Joachim Schrod jsch...@acm.org wrote: An AjaxEventBehavior would be the right thing, but I don't have a component to attach it to. The worst solution would be a hidden AjaxLink. IMO I simply need to establish a listener URL that triggers some method, an URL that I can use in a Wicket.Ajax.ajax() call -- but I don't find the Wicket component that supplies me with that functionality. Maybe this can be of some help https://github.com/reiern70/antilia-bits/tree/master/client-sign-out-parent Yes, very illustrating. While I eventually ended up with a different solution, this code showed me an alternative way that I will keep in mind for the future. Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod, Roedermark, Germany Email: jsch...@acm.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Best practice sought: Register client change at server
I didn't know that I can introduce my own event names, I thought I
had to use one of the pre-defined ones.
Thanks for that enlightenment, it works like a charm.
Joachim
On 07/11/14 12:01, Martin Grigorov wrote:
page.add(new AjaxEventBehavior(my-special-event) {...});
in JS code: jQuery(document).triggerHandler('my-special-event');
Voila!
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Fri, Jul 11, 2014 at 10:15 AM, Sven Meier s...@meiers.net wrote:
an AjaxEventBehavior, but I don't have a component to attach it to.
You have a page, don't you?
Otherwise you can request a resource via Ajax too.
Regards
Sven
On 07/11/2014 02:47 AM, Joachim Schrod wrote:
Hi,
In a Wicket application I have JQuery code that triggers after a
certain time of user inactivity. I need to tell server-side about
that inactivity. No problem, I thought, just issue an AJAX request.
Well, looking around I found several possibilities to do that as a
side effect, but no component at first hand that is made up for
that task. I thought that's strange, it doesn't sound as a remote
demand. So my question is about best practice for this use case.
Namely: I have a change on client-side that I want to communicate
to server-side. No changes in DOM are associated. Just like
triggering an AjaxLink where onClick() does not call any methods on
target. I know about the JavaScript function Wicket.Ajax.ajax() and
its arguments. My problem is choosing the right component server-side.
An AjaxEventBehavior would be the right thing, but I don't have a
component to attach it to. The worst solution would be a hidden
AjaxLink. IMO I simply need to establish a listener URL that
triggers some method, an URL that I can use in a Wicket.Ajax.ajax()
call -- but I don't find the Wicket component that supplies me with
that functionality.
How can I do that?
Or is my focus on the Wicket.Ajax.ajax() JS interface blocking my
view on another solution that's better?
I know my way around Wicket's code and documentation. Thus, a hint
like start with class XYZ would be very much appreciated, I don't
need a full solution with code. I'm surely missing something
obvious and would severely appreciate any help or tips.
Cheers,
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod, Roedermark, Germany
Email: jsch...@acm.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: equals() method for LoadableDetachableModels
Thank you all for your replies, very helpful! Sven Meier s...@meiers.netmailto:s...@meiers.net wrote: detachable models should never use getObject() in their implementation of equals()? generally this is a good advice: there are several places in Wicket checking for model equality (e.g. ReuseIfModelsEqualStrategy). A detachable model should have enough information to decide equality without loading the model object. It would be good to note this somewhere in the documentation where model implementers will find it. Ernesto Reinaldo Barreiro reier...@gmail.commailto:reier...@gmail.com wrote: Shouldn't the serialize primary key=the bit of info needed to recover data on attach stored on LDM be the criteria for equality? Yes, and I will look into changing our implementation to do this. However it is more complicated, since our LDM [*] also supports constructing a model based on a query rather than an ID, or storing a not-persisted object directly, so we’d have to do considerably more than just compare IDs. And you could have a query-based model and an ID-based model that resolve to the same object — it’s perhaps a philosophical question whether those ought to compare equal or not. The practical question, of course, is whether changing the definition of equality will break any existing code. [*] we are using a version of the HibernateObjectModel from the no-longer-maintained Databinder (see https://github.com/n8han/Databinder-for-Wicket/ ) updated for wicket 6 and recent Hibernate versions. BTW if anyone is interested in collaborating on maintaining and improving this library that mediates between Wicket Hibernate, please get in touch. Martin Grigorov mgrigo...@apache.orgmailto:mgrigo...@apache.org wrote: does org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream#check() really need to use #equals() (via Stack#contains()) ? I think checking for identity equality should be OK too I was wondering the same thing; using identity would certainly be safer for issues like these. Boris
Re: equals() method for LoadableDetachableModels
Hi, really need to use #equals() ... checking for identity equality should be OK too I've just tried with an IdentityHashMap and all tests passed (except SerializableCheckerTest#runtimeExceptionTolerance() of course). Sven On 07/11/2014 11:39 AM, Martin Grigorov wrote: Hi, I agree that using the primary key should be enough for #equals() but does org.apache.wicket.core.util.objects.checker.CheckingObjectOutputStream#check() really need to use #equals() (via Stack#contains()) ? I think checking for identity equality should be OK too. Java Serialization is not the simplest part of Java and I may miss something... On Fri, Jul 11, 2014 at 10:51 AM, Sven Meier s...@meiers.net wrote: Hi, detachable models should never use getObject() in their implementation of equals()? generally this is a good advice: there are several places in Wicket checking for model equality (e.g. ReuseIfModelsEqualStrategy). A detachable model should have enough information to decide equality without loading the model object. Regards Sven On 07/11/2014 01:52 AM, Boris Goldowsky wrote: I’ve started using CheckingObjectOutputStream to test for models of database objects that are not properly detached, and find it very useful. However I just diagnosed (after many hours of frustration) that it can also cause problems rather than solve them. CheckingObjectOutputStream causes the equals() method of models to be called, and in the case of our models the equals() implementation loads the database object (models of the same object being considered equal to each other). Since it’s doing this during serialization and thus after the detach process, the checker actually causes the exact problem that it’s supposed to prevent (and doesn’t generate any warnings in this case). Is it a general rule, that I was just not aware of, that detachable models should never use getObject() in their implementation of equals()? Or should CheckingObjectOutputStream be changed to avoid calling equals() ? Bng - 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
Validate FormComponent raw input before conversion
Hello! I have textfield backed by Integer Model object in the web app and a number field in the database. The maximum number the database can hold is less than Integer.MAX_VALUE so I have added a validator which checks that and reports the valid range. The problem is that when the user enters a value larger than Integer.MAX_VALUE, the conversion fails and user recieves a generic message. Using BigInteger and BigDecimal everywhere in models seems excessive. And it seems I can't validate the raw input string before conversion? Would you consider adding this feature or is there a better way? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Validate-FormComponent-raw-input-before-conversion-tp4666560.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
