On Tue, Jan 10, 2012 at 12:21 PM, Emond Papegaaij
emond.papega...@topicus.nl wrote:
I'm +0 for the rename. I understand that IAjaxRequestHandler is a better name
than AjaxRequestTarget, but it also involves quite a lot of work from our
users to fix their apps. You have to remember that they
im all for removing the I anyways, so +1 from me
-igor
On Wed, Jan 11, 2012 at 12:27 AM, Martin Grigorov mgrigo...@apache.org wrote:
On Tue, Jan 10, 2012 at 12:21 PM, Emond Papegaaij
emond.papega...@topicus.nl wrote:
I'm +0 for the rename. I understand that IAjaxRequestHandler is a better
No, please not another breaking change just for the sake of it.
It's cheap to rename things that exist in your codebase and you hit
'Ctrl+Shift+R', and Eclipse does it all for you. It's not that cheap
to fix safely (which 'find|grep|wc' is not!) thousands of compiler
errors spread across hundreds
Oh, or just remove the 'final' from the methods! (I can suggest a
number of other cases it could also be done)
On Wed, Jan 11, 2012 at 8:32 PM, tetsuo ronald.tet...@gmail.com wrote:
No, please not another breaking change just for the sake of it.
It's cheap to rename things that exist in your
-1
There is no reason other than esthetics for renaming
AjaxRequestTarget. It is probably after Label and Link the most used
API in our framework. This breaks all existing applications about a
million times.
This is similar to renaming Form to something else, or Label to
TextRenderingComponent.
On Tue, Jan 10, 2012 at 11:22 AM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
-1
There is no reason other than esthetics for renaming
AjaxRequestTarget. It is probably after Label and Link the most used
API in our framework. This breaks all existing applications about a
million times.
I'm +0 for the rename. I understand that IAjaxRequestHandler is a better name
than AjaxRequestTarget, but it also involves quite a lot of work from our
users to fix their apps. You have to remember that they have to cope with all
renames at once, where you have the priviledge to deal with them
Hi,
In https://issues.apache.org/jira/browse/WICKET-4326 I suggest to
introduce IAjaxRequestHander which is an interface for
AjaxRequestTarget.
It gives the possibility to be able to provide customized ART or
completely new one. This way it is much easier to use a mock for
testing too.
Until now
On Mon, Jan 9, 2012 at 6:14 AM, Martin Grigorov mgrigo...@apache.org wrote:
Hi,
In https://issues.apache.org/jira/browse/WICKET-4326 I suggest to
introduce IAjaxRequestHander which is an interface for
AjaxRequestTarget.
It gives the possibility to be able to provide customized ART or
At first sight I would choose to introduce IAjaxRequestHander. IMHO
migrating from 1.4 to 1.5, you must tackle problems bigger than
renaming AjaxRequestTarget to IAjaxRequestHander.
Just my two cents.
Hi,
In https://issues.apache.org/jira/browse/WICKET-4326 I suggest to
introduce
On Mon, Jan 9, 2012 at 6:59 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
On Mon, Jan 9, 2012 at 6:14 AM, Martin Grigorov mgrigo...@apache.org wrote:
Hi,
In https://issues.apache.org/jira/browse/WICKET-4326 I suggest to
introduce IAjaxRequestHander which is an interface for
One more thing:
currently we have : AjaxRequestTarget.get() which extracts the ART
from the scheduled IRequestTargets
I think we should move this code somewhere out.
Either:
class IAjaxRequestHandler {
public static class Current {
public static IAjaxRequestHandler get() { // the
There are a few places where the active or next requestHandler is looked
up by type. This could be:
T extends IRequestHandler T RequestCycle#resolveHandler(ClassT)
This would result in a little more typing though, e.g. for Ajax:
RequestCycle.get().resolveHandler(IAjaxRequestHandler.class)
findHandler()
-igor
On Mon, Jan 9, 2012 at 9:57 AM, Sven Meier s...@meiers.net wrote:
There are a few places where the active or next requestHandler is looked up
by type. This could be:
T extends IRequestHandler T RequestCycle#resolveHandler(ClassT)
This would result in a little more
Just to make the picture complete, I think one more reason we have an ART
provider was that we could basically have something like
MyAjaxRequestTarget
and add additional methods to itt, e.g.:
- MyAjaxRequestTarget#focus(FormComponent)
-
No objections so far...
I'll apply the patch with the improvements mentioned in this thread.
On Tue, Jan 10, 2012 at 12:55 AM, Peter Ertl pe...@gmx.org wrote:
Just to make the picture complete, I think one more reason we have an ART
provider was that we could basically have something like
16 matches
Mail list logo
