You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Peter Ertl (JIRA)" <ji...@apache.org> on 2007/12/08 12:35:43 UTC
[jira] Created: (WICKET-1213) enable subclassing of
AjaxRequestTarget
enable subclassing of AjaxRequestTarget
---------------------------------------
Key: WICKET-1213
URL: https://issues.apache.org/jira/browse/WICKET-1213
Project: Wicket
Issue Type: Wish
Components: wicket
Reporter: Peter Ertl
Attachments: AjaxRequestTarget_with_subclassing.patch
In my wicket programming experience so far I always didn't feel quite comfortable with the ajax part.
I had some issues in particular with these as an example:
- "Always include a common feedback panel from my template page"
--> add 'target.addComponent(feedbackPanel)' just _everywhere_ (very cumbersome and not elegant at all)
- add a listener using AjaxRequestTarget#addListener
--> not possible without subclassing the request cycle (which is *yuk* if you ask me) to catch the short moment in between AjaxRequestTarget is instantiated and AjaxRequestTarget#onRespond() is called
- automatically set focus on the first form component with errors
--> add bulky code into all onSubmit() and onError() to check for errrors and call AjaxRequestTarget#setFocus
- add some common function like AjaxRequestTarget#yellowFade(FormComponent)
--> have some utility method and call it like this: AjaxUtil.yellowFade(target) -- not nice as functionality like this should really belong to the request target
I found that all these issues can be solved very elegantly if you could just catch the moment where AjaxRequestTarget is instantiated.
I attached a very little patch (!) which solves all that issues and makes ajax just a lot more powerful inside wicket *imho*
also, it will not break current code but is just an enhancement you will not notice unless you need it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1213) enable subclassing of
AjaxRequestTarget
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550669 ]
Igor Vaynberg commented on WICKET-1213:
---------------------------------------
@Johan
and that is fine per page, but what if you want it per session or per application? you will basically force the user to use a basepages if they want to handle this in a consistent manner. feel free to refactor it, i really dont care that much for it. i just implemented it the way that is more consistent with the current state of how we handle these things...
> enable subclassing of AjaxRequestTarget
> ---------------------------------------
>
> Key: WICKET-1213
> URL: https://issues.apache.org/jira/browse/WICKET-1213
> Project: Wicket
> Issue Type: Wish
> Components: wicket
> Affects Versions: 1.3.0-rc1
> Reporter: Peter Ertl
> Assignee: Igor Vaynberg
> Fix For: 1.3.0-rc3
>
> Attachments: AjaxRequestTarget_using_callback_interface.patch, AjaxRequestTarget_with_subclassing.patch
>
>
> In my wicket programming experience so far I always didn't feel quite comfortable with the ajax part.
> I had some issues in particular with these as an example:
> - "Always include a common feedback panel from my template page"
> --> add 'target.addComponent(feedbackPanel)' just _everywhere_ (very cumbersome and not elegant at all)
> - add a listener using AjaxRequestTarget#addListener
> --> not possible without subclassing the request cycle (which is *yuk* if you ask me) to catch the short moment in between AjaxRequestTarget is instantiated and AjaxRequestTarget#onRespond() is called
> - automatically set focus on the first form component with errors
> --> add bulky code into all onSubmit() and onError() to check for errrors and call AjaxRequestTarget#setFocus
> - add some common function like AjaxRequestTarget#yellowFade(FormComponent)
> --> have some utility method and call it like this: AjaxUtil.yellowFade(target) -- not nice as functionality like this should really belong to the request target
> I found that all these issues can be solved very elegantly if you could just catch the moment where AjaxRequestTarget is instantiated.
> I attached a very little patch (!) which solves all that issues and makes ajax just a lot more powerful inside wicket *imho*
> also, it will not break current code but is just an enhancement you will not notice unless you need it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1213) enable subclassing of
AjaxRequestTarget
Posted by "Johan Compagner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549760 ]
Johan Compagner commented on WICKET-1213:
-----------------------------------------
as i said the Page will also not make the PageRequestTarget (that also just has a page constructor) should it also do that??
Besides that Page is the base component that is Web/Html less... So Page itself is a big no go.
If we did it in a component structure then it has to be WebPage anyway because there shouldn't be references to Ajax/Web stuff in the base Page.
That said then even RequestCycle is also not the right place. Because you should be able to move teh *.ajax packages outside of the wicket jar and everything should pretty much still compile. There shouldn't be any spill to the real default none web stuff.
> enable subclassing of AjaxRequestTarget
> ---------------------------------------
>
> Key: WICKET-1213
> URL: https://issues.apache.org/jira/browse/WICKET-1213
> Project: Wicket
> Issue Type: Wish
> Components: wicket
> Affects Versions: 1.3.0-rc1
> Reporter: Peter Ertl
> Assignee: Matej Knopp
> Fix For: 1.4.0-alpha
>
> Attachments: AjaxRequestTarget_with_subclassing.patch
>
>
> In my wicket programming experience so far I always didn't feel quite comfortable with the ajax part.
> I had some issues in particular with these as an example:
> - "Always include a common feedback panel from my template page"
> --> add 'target.addComponent(feedbackPanel)' just _everywhere_ (very cumbersome and not elegant at all)
> - add a listener using AjaxRequestTarget#addListener
> --> not possible without subclassing the request cycle (which is *yuk* if you ask me) to catch the short moment in between AjaxRequestTarget is instantiated and AjaxRequestTarget#onRespond() is called
> - automatically set focus on the first form component with errors
> --> add bulky code into all onSubmit() and onError() to check for errrors and call AjaxRequestTarget#setFocus
> - add some common function like AjaxRequestTarget#yellowFade(FormComponent)
> --> have some utility method and call it like this: AjaxUtil.yellowFade(target) -- not nice as functionality like this should really belong to the request target
> I found that all these issues can be solved very elegantly if you could just catch the moment where AjaxRequestTarget is instantiated.
> I attached a very little patch (!) which solves all that issues and makes ajax just a lot more powerful inside wicket *imho*
> also, it will not break current code but is just an enhancement you will not notice unless you need it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1213) enable subclassing of
AjaxRequestTarget
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550302 ]
Igor Vaynberg commented on WICKET-1213:
---------------------------------------
johan, martijn thoughts?
> enable subclassing of AjaxRequestTarget
> ---------------------------------------
>
> Key: WICKET-1213
> URL: https://issues.apache.org/jira/browse/WICKET-1213
> Project: Wicket
> Issue Type: Wish
> Components: wicket
> Affects Versions: 1.3.0-rc1
> Reporter: Peter Ertl
> Assignee: Igor Vaynberg
> Fix For: 1.3.0-rc3
>
> Attachments: AjaxRequestTarget_using_callback_interface.patch, AjaxRequestTarget_with_subclassing.patch
>
>
> In my wicket programming experience so far I always didn't feel quite comfortable with the ajax part.
> I had some issues in particular with these as an example:
> - "Always include a common feedback panel from my template page"
> --> add 'target.addComponent(feedbackPanel)' just _everywhere_ (very cumbersome and not elegant at all)
> - add a listener using AjaxRequestTarget#addListener
> --> not possible without subclassing the request cycle (which is *yuk* if you ask me) to catch the short moment in between AjaxRequestTarget is instantiated and AjaxRequestTarget#onRespond() is called
> - automatically set focus on the first form component with errors
> --> add bulky code into all onSubmit() and onError() to check for errrors and call AjaxRequestTarget#setFocus
> - add some common function like AjaxRequestTarget#yellowFade(FormComponent)
> --> have some utility method and call it like this: AjaxUtil.yellowFade(target) -- not nice as functionality like this should really belong to the request target
> I found that all these issues can be solved very elegantly if you could just catch the moment where AjaxRequestTarget is instantiated.
> I attached a very little patch (!) which solves all that issues and makes ajax just a lot more powerful inside wicket *imho*
> also, it will not break current code but is just an enhancement you will not notice unless you need it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1213) enable subclassing of
AjaxRequestTarget
Posted by "Frank Bille Jensen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Frank Bille Jensen updated WICKET-1213:
---------------------------------------
Fix Version/s: (was: 1.3.0-rc3)
1.3.0-final
> enable subclassing of AjaxRequestTarget
> ---------------------------------------
>
> Key: WICKET-1213
> URL: https://issues.apache.org/jira/browse/WICKET-1213
> Project: Wicket
> Issue Type: Wish
> Components: wicket
> Affects Versions: 1.3.0-rc1
> Reporter: Peter Ertl
> Assignee: Igor Vaynberg
> Fix For: 1.3.0-final
>
> Attachments: AjaxRequestTarget_using_callback_interface.patch, AjaxRequestTarget_with_subclassing.patch
>
>
> In my wicket programming experience so far I always didn't feel quite comfortable with the ajax part.
> I had some issues in particular with these as an example:
> - "Always include a common feedback panel from my template page"
> --> add 'target.addComponent(feedbackPanel)' just _everywhere_ (very cumbersome and not elegant at all)
> - add a listener using AjaxRequestTarget#addListener
> --> not possible without subclassing the request cycle (which is *yuk* if you ask me) to catch the short moment in between AjaxRequestTarget is instantiated and AjaxRequestTarget#onRespond() is called
> - automatically set focus on the first form component with errors
> --> add bulky code into all onSubmit() and onError() to check for errrors and call AjaxRequestTarget#setFocus
> - add some common function like AjaxRequestTarget#yellowFade(FormComponent)
> --> have some utility method and call it like this: AjaxUtil.yellowFade(target) -- not nice as functionality like this should really belong to the request target
> I found that all these issues can be solved very elegantly if you could just catch the moment where AjaxRequestTarget is instantiated.
> I attached a very little patch (!) which solves all that issues and makes ajax just a lot more powerful inside wicket *imho*
> also, it will not break current code but is just an enhancement you will not notice unless you need it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1213) enable subclassing of
AjaxRequestTarget
Posted by "Johan Compagner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550357 ]
Johan Compagner commented on WICKET-1213:
-----------------------------------------
The current impl is also fine but i think i liked the interface that resides in the .ajax.* package a bit better
(its nicer i think on some levels)
So an interface besides AbstractDefaultAjaxBehavior that is IAjaxRequestTargetFactory
and then an page can implement that if he wants to control the ajax request target creation.so we only test this in AbstractDefaultAjaxBehavior
we take the page if page implements the interface call it else doe default.
that way the whole of ajax is still nicely packages in the ajax.* package.
> enable subclassing of AjaxRequestTarget
> ---------------------------------------
>
> Key: WICKET-1213
> URL: https://issues.apache.org/jira/browse/WICKET-1213
> Project: Wicket
> Issue Type: Wish
> Components: wicket
> Affects Versions: 1.3.0-rc1
> Reporter: Peter Ertl
> Assignee: Igor Vaynberg
> Fix For: 1.3.0-rc3
>
> Attachments: AjaxRequestTarget_using_callback_interface.patch, AjaxRequestTarget_with_subclassing.patch
>
>
> In my wicket programming experience so far I always didn't feel quite comfortable with the ajax part.
> I had some issues in particular with these as an example:
> - "Always include a common feedback panel from my template page"
> --> add 'target.addComponent(feedbackPanel)' just _everywhere_ (very cumbersome and not elegant at all)
> - add a listener using AjaxRequestTarget#addListener
> --> not possible without subclassing the request cycle (which is *yuk* if you ask me) to catch the short moment in between AjaxRequestTarget is instantiated and AjaxRequestTarget#onRespond() is called
> - automatically set focus on the first form component with errors
> --> add bulky code into all onSubmit() and onError() to check for errrors and call AjaxRequestTarget#setFocus
> - add some common function like AjaxRequestTarget#yellowFade(FormComponent)
> --> have some utility method and call it like this: AjaxUtil.yellowFade(target) -- not nice as functionality like this should really belong to the request target
> I found that all these issues can be solved very elegantly if you could just catch the moment where AjaxRequestTarget is instantiated.
> I attached a very little patch (!) which solves all that issues and makes ajax just a lot more powerful inside wicket *imho*
> also, it will not break current code but is just an enhancement you will not notice unless you need it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1213) enable subclassing of
AjaxRequestTarget
Posted by "Peter Ertl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549710 ]
Peter Ertl commented on WICKET-1213:
------------------------------------
Johan,
I don't think there is such a thing as a 'global ajax request target' as it is always(!) bound to a page. think about it, how else should the response be processed if there wasn't a call from within the corresponding page first? so I think it's even more logical that way.
> what does page has to do with request processing.. Page is just a component.
the ajax request is sent asynchronously from the page, and the response will be processed by that same page.
What would be the meaning of having new AjaxRequestTarget(null) ?
When scanning throught the 'wicket' and 'wicket-extensions' project I found there's no other place except the 'onRequest()' where AjaxRequestTarget is instantiated (except BaseWicketTester). so there are no place where AjaxRequestTarget is used in a 'global' context so far, also there should be no side effects when applying this patch.
> enable subclassing of AjaxRequestTarget
> ---------------------------------------
>
> Key: WICKET-1213
> URL: https://issues.apache.org/jira/browse/WICKET-1213
> Project: Wicket
> Issue Type: Wish
> Components: wicket
> Affects Versions: 1.3.0-rc1
> Reporter: Peter Ertl
> Assignee: Matej Knopp
> Fix For: 1.4.0-alpha
>
> Attachments: AjaxRequestTarget_with_subclassing.patch
>
>
> In my wicket programming experience so far I always didn't feel quite comfortable with the ajax part.
> I had some issues in particular with these as an example:
> - "Always include a common feedback panel from my template page"
> --> add 'target.addComponent(feedbackPanel)' just _everywhere_ (very cumbersome and not elegant at all)
> - add a listener using AjaxRequestTarget#addListener
> --> not possible without subclassing the request cycle (which is *yuk* if you ask me) to catch the short moment in between AjaxRequestTarget is instantiated and AjaxRequestTarget#onRespond() is called
> - automatically set focus on the first form component with errors
> --> add bulky code into all onSubmit() and onError() to check for errrors and call AjaxRequestTarget#setFocus
> - add some common function like AjaxRequestTarget#yellowFade(FormComponent)
> --> have some utility method and call it like this: AjaxUtil.yellowFade(target) -- not nice as functionality like this should really belong to the request target
> I found that all these issues can be solved very elegantly if you could just catch the moment where AjaxRequestTarget is instantiated.
> I attached a very little patch (!) which solves all that issues and makes ajax just a lot more powerful inside wicket *imho*
> also, it will not break current code but is just an enhancement you will not notice unless you need it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1213) enable subclassing of
AjaxRequestTarget
Posted by "Peter Ertl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550427 ]
Peter Ertl commented on WICKET-1213:
------------------------------------
Yippie, it's just great to have this new feature which will simplify some facets of ajax programming a lot...
Thanks to all of you very much! :-)
> enable subclassing of AjaxRequestTarget
> ---------------------------------------
>
> Key: WICKET-1213
> URL: https://issues.apache.org/jira/browse/WICKET-1213
> Project: Wicket
> Issue Type: Wish
> Components: wicket
> Affects Versions: 1.3.0-rc1
> Reporter: Peter Ertl
> Assignee: Igor Vaynberg
> Fix For: 1.3.0-rc3
>
> Attachments: AjaxRequestTarget_using_callback_interface.patch, AjaxRequestTarget_with_subclassing.patch
>
>
> In my wicket programming experience so far I always didn't feel quite comfortable with the ajax part.
> I had some issues in particular with these as an example:
> - "Always include a common feedback panel from my template page"
> --> add 'target.addComponent(feedbackPanel)' just _everywhere_ (very cumbersome and not elegant at all)
> - add a listener using AjaxRequestTarget#addListener
> --> not possible without subclassing the request cycle (which is *yuk* if you ask me) to catch the short moment in between AjaxRequestTarget is instantiated and AjaxRequestTarget#onRespond() is called
> - automatically set focus on the first form component with errors
> --> add bulky code into all onSubmit() and onError() to check for errrors and call AjaxRequestTarget#setFocus
> - add some common function like AjaxRequestTarget#yellowFade(FormComponent)
> --> have some utility method and call it like this: AjaxUtil.yellowFade(target) -- not nice as functionality like this should really belong to the request target
> I found that all these issues can be solved very elegantly if you could just catch the moment where AjaxRequestTarget is instantiated.
> I attached a very little patch (!) which solves all that issues and makes ajax just a lot more powerful inside wicket *imho*
> also, it will not break current code but is just an enhancement you will not notice unless you need it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (WICKET-1213) enable subclassing of
AjaxRequestTarget
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Igor Vaynberg reassigned WICKET-1213:
-------------------------------------
Assignee: Igor Vaynberg (was: Matej Knopp)
> enable subclassing of AjaxRequestTarget
> ---------------------------------------
>
> Key: WICKET-1213
> URL: https://issues.apache.org/jira/browse/WICKET-1213
> Project: Wicket
> Issue Type: Wish
> Components: wicket
> Affects Versions: 1.3.0-rc1
> Reporter: Peter Ertl
> Assignee: Igor Vaynberg
> Fix For: 1.4.0-alpha
>
> Attachments: AjaxRequestTarget_using_callback_interface.patch, AjaxRequestTarget_with_subclassing.patch
>
>
> In my wicket programming experience so far I always didn't feel quite comfortable with the ajax part.
> I had some issues in particular with these as an example:
> - "Always include a common feedback panel from my template page"
> --> add 'target.addComponent(feedbackPanel)' just _everywhere_ (very cumbersome and not elegant at all)
> - add a listener using AjaxRequestTarget#addListener
> --> not possible without subclassing the request cycle (which is *yuk* if you ask me) to catch the short moment in between AjaxRequestTarget is instantiated and AjaxRequestTarget#onRespond() is called
> - automatically set focus on the first form component with errors
> --> add bulky code into all onSubmit() and onError() to check for errrors and call AjaxRequestTarget#setFocus
> - add some common function like AjaxRequestTarget#yellowFade(FormComponent)
> --> have some utility method and call it like this: AjaxUtil.yellowFade(target) -- not nice as functionality like this should really belong to the request target
> I found that all these issues can be solved very elegantly if you could just catch the moment where AjaxRequestTarget is instantiated.
> I attached a very little patch (!) which solves all that issues and makes ajax just a lot more powerful inside wicket *imho*
> also, it will not break current code but is just an enhancement you will not notice unless you need it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1213) enable subclassing of
AjaxRequestTarget
Posted by "Peter Ertl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Ertl updated WICKET-1213:
-------------------------------
Attachment: AjaxRequestTarget_using_callback_interface.patch
> enable subclassing of AjaxRequestTarget
> ---------------------------------------
>
> Key: WICKET-1213
> URL: https://issues.apache.org/jira/browse/WICKET-1213
> Project: Wicket
> Issue Type: Wish
> Components: wicket
> Affects Versions: 1.3.0-rc1
> Reporter: Peter Ertl
> Assignee: Matej Knopp
> Fix For: 1.4.0-alpha
>
> Attachments: AjaxRequestTarget_using_callback_interface.patch, AjaxRequestTarget_with_subclassing.patch
>
>
> In my wicket programming experience so far I always didn't feel quite comfortable with the ajax part.
> I had some issues in particular with these as an example:
> - "Always include a common feedback panel from my template page"
> --> add 'target.addComponent(feedbackPanel)' just _everywhere_ (very cumbersome and not elegant at all)
> - add a listener using AjaxRequestTarget#addListener
> --> not possible without subclassing the request cycle (which is *yuk* if you ask me) to catch the short moment in between AjaxRequestTarget is instantiated and AjaxRequestTarget#onRespond() is called
> - automatically set focus on the first form component with errors
> --> add bulky code into all onSubmit() and onError() to check for errrors and call AjaxRequestTarget#setFocus
> - add some common function like AjaxRequestTarget#yellowFade(FormComponent)
> --> have some utility method and call it like this: AjaxUtil.yellowFade(target) -- not nice as functionality like this should really belong to the request target
> I found that all these issues can be solved very elegantly if you could just catch the moment where AjaxRequestTarget is instantiated.
> I attached a very little patch (!) which solves all that issues and makes ajax just a lot more powerful inside wicket *imho*
> also, it will not break current code but is just an enhancement you will not notice unless you need it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (WICKET-1213) enable subclassing of
AjaxRequestTarget
Posted by "Peter Ertl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549696 ]
pete edited comment on WICKET-1213 at 12/8/07 4:42 AM:
-------------------------------------------------------------
here's an example of how this could be used -- you might get an better idea of what I want to achieve with this patch...
this is some code inside my template page:
@Override
public AjaxRequestTarget newAjaxRequestTarget()
{
final AjaxRequestTarget target = super.newAjaxRequestTarget();
target.addListener(new AjaxRequestTarget.IListener()
{
@SuppressWarnings({"RawUseOfParameterizedType"})
public void onBeforeRespond(final Map map, final AjaxRequestTarget target)
{
// always render the feedback component that belongs to this template
// no need to include it in all pages that use this template
target.addComponent(feedbackPanel);
}
@SuppressWarnings({"RawUseOfParameterizedType"})
public void onAfterRespond(final Map map, final AjaxRequestTarget.IJavascriptResponse response)
{
//
// set the focus on the first form component that has errors
// this is very convenient for the user as he doesn't have to click on the erroneous field first
//
// this has to be rendered in onAfterRespond to be sure the dom component for setting focus on has
// already been rendered in the dom structure of the browser
//
final FormComponent focus = (FormComponent) visitChildren(FormComponent.class, new IVisitor()
{
public Object component(final Component component)
{
final FormComponent formComponent = (FormComponent) component;
if (formComponent.hasErrorMessage() && formComponent.getOutputMarkupId())
return formComponent;
return CONTINUE_TRAVERSAL;
}
});
if (focus != null)
target.focusComponent(focus);
}
});
return target;
}
another possible example (using common functionality specific to your application this time)
@Override
public AjaxRequestTarget newAjaxRequestTarget()
{
return new CustomAjaxRequestTarget(); // extends AjaxRequestTarget
}
so inside your pages you could for example do this:
public void onClick(final AjaxRequestTarget target)
{
final CustomAjaxRequestTarget customTarget = (CustomAjaxRequestTarget)target;
// change some setting on the page
// ..
// let the user take notice of the change (the heavily-used effect from Ruby on Rails we probably all know)
customTarget.applyYellowFadeEffect(component);
// make it even more obvious (some freaky javascript :-)
customTarget.letScreenShakeUpAndDown();
// even half-blind people should see that (another crazy js)
customTarget.zoomInAndOutAgain(component);
}
was (Author: pete):
here's an example of how this could be used -- you might get an better idea of what I want to achieve with this patch...
this is some code inside my template page:
@Override
public AjaxRequestTarget newAjaxRequestTarget()
{
final AjaxRequestTarget target = super.newAjaxRequestTarget();
target.addListener(new AjaxRequestTarget.IListener()
{
@SuppressWarnings({"RawUseOfParameterizedType"})
public void onBeforeRespond(final Map map, final AjaxRequestTarget target)
{
// always render the feedback component that belongs to this template
// no need to include it in all pages that use this template
target.addComponent(feedbackPanel);
}
@SuppressWarnings({"RawUseOfParameterizedType"})
public void onAfterRespond(final Map map, final AjaxRequestTarget.IJavascriptResponse response)
{
//
// set the focus on the first form component that has errors
// this is very convenient for the user as he doesn't have to click on the erroneous field first
//
// this has to be rendered in onAfterRespond to be sure the dom component for setting focus on has
// already been rendered in the dom structure of the browser
//
final FormComponent focus = (FormComponent) visitChildren(FormComponent.class, new IVisitor()
{
public Object component(final Component component)
{
final FormComponent formComponent = (FormComponent) component;
if (formComponent.hasErrorMessage() && formComponent.getOutputMarkupId())
return formComponent;
return CONTINUE_TRAVERSAL;
}
});
if (focus != null)
target.focusComponent(focus);
}
});
return target;
}
another possible example (using common functionality specific to your application this time)
@Override
public AjaxRequestTarget newAjaxRequestTarget()
{
return new CustomAjaxRequestTarget(); // extends AjaxRequestTarget
}
so inside your pages you could for example do this:
public void onClick(final AjaxRequestTarget target)
{
final CustomAjaxRequestTarget customTarget = (CustomAjaxRequestTarget)target;
// change some setting on the page
// ..
// let the user take notice of the change (the heavily-used effect from Ruby on Rails we probably all know)
customTarget.applyYellowFadeEffect(component);
// make it even more obvious (some freaky javascript :-)
customTarget.letScreenShakeUpAndDown();
// even half-blind people should see that (another crazy js)
customTarget.zoomInAndOutAgain(component);
}
this way you could provide some common ajax functionality to your application which is easy to use and implementation details are perfectly hidden
> enable subclassing of AjaxRequestTarget
> ---------------------------------------
>
> Key: WICKET-1213
> URL: https://issues.apache.org/jira/browse/WICKET-1213
> Project: Wicket
> Issue Type: Wish
> Components: wicket
> Affects Versions: 1.3.0-rc1
> Reporter: Peter Ertl
> Assignee: Matej Knopp
> Fix For: 1.4.0-alpha
>
> Attachments: AjaxRequestTarget_with_subclassing.patch
>
>
> In my wicket programming experience so far I always didn't feel quite comfortable with the ajax part.
> I had some issues in particular with these as an example:
> - "Always include a common feedback panel from my template page"
> --> add 'target.addComponent(feedbackPanel)' just _everywhere_ (very cumbersome and not elegant at all)
> - add a listener using AjaxRequestTarget#addListener
> --> not possible without subclassing the request cycle (which is *yuk* if you ask me) to catch the short moment in between AjaxRequestTarget is instantiated and AjaxRequestTarget#onRespond() is called
> - automatically set focus on the first form component with errors
> --> add bulky code into all onSubmit() and onError() to check for errrors and call AjaxRequestTarget#setFocus
> - add some common function like AjaxRequestTarget#yellowFade(FormComponent)
> --> have some utility method and call it like this: AjaxUtil.yellowFade(target) -- not nice as functionality like this should really belong to the request target
> I found that all these issues can be solved very elegantly if you could just catch the moment where AjaxRequestTarget is instantiated.
> I attached a very little patch (!) which solves all that issues and makes ajax just a lot more powerful inside wicket *imho*
> also, it will not break current code but is just an enhancement you will not notice unless you need it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1213) enable subclassing of
AjaxRequestTarget
Posted by "Peter Ertl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Ertl updated WICKET-1213:
-------------------------------
Attachment: AjaxRequestTarget_with_subclassing.patch
> enable subclassing of AjaxRequestTarget
> ---------------------------------------
>
> Key: WICKET-1213
> URL: https://issues.apache.org/jira/browse/WICKET-1213
> Project: Wicket
> Issue Type: Wish
> Components: wicket
> Reporter: Peter Ertl
> Attachments: AjaxRequestTarget_with_subclassing.patch
>
>
> In my wicket programming experience so far I always didn't feel quite comfortable with the ajax part.
> I had some issues in particular with these as an example:
> - "Always include a common feedback panel from my template page"
> --> add 'target.addComponent(feedbackPanel)' just _everywhere_ (very cumbersome and not elegant at all)
> - add a listener using AjaxRequestTarget#addListener
> --> not possible without subclassing the request cycle (which is *yuk* if you ask me) to catch the short moment in between AjaxRequestTarget is instantiated and AjaxRequestTarget#onRespond() is called
> - automatically set focus on the first form component with errors
> --> add bulky code into all onSubmit() and onError() to check for errrors and call AjaxRequestTarget#setFocus
> - add some common function like AjaxRequestTarget#yellowFade(FormComponent)
> --> have some utility method and call it like this: AjaxUtil.yellowFade(target) -- not nice as functionality like this should really belong to the request target
> I found that all these issues can be solved very elegantly if you could just catch the moment where AjaxRequestTarget is instantiated.
> I attached a very little patch (!) which solves all that issues and makes ajax just a lot more powerful inside wicket *imho*
> also, it will not break current code but is just an enhancement you will not notice unless you need it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (WICKET-1213) enable subclassing of
AjaxRequestTarget
Posted by "Peter Ertl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549696 ]
pete edited comment on WICKET-1213 at 12/8/07 4:41 AM:
-------------------------------------------------------------
here's an example of how this could be used -- you might get an better idea of what I want to achieve with this patch...
this is some code inside my template page:
@Override
public AjaxRequestTarget newAjaxRequestTarget()
{
final AjaxRequestTarget target = super.newAjaxRequestTarget();
target.addListener(new AjaxRequestTarget.IListener()
{
@SuppressWarnings({"RawUseOfParameterizedType"})
public void onBeforeRespond(final Map map, final AjaxRequestTarget target)
{
// always render the feedback component that belongs to this template
// no need to include it in all pages that use this template
target.addComponent(feedbackPanel);
}
@SuppressWarnings({"RawUseOfParameterizedType"})
public void onAfterRespond(final Map map, final AjaxRequestTarget.IJavascriptResponse response)
{
//
// set the focus on the first form component that has errors
// this is very convenient for the user as he doesn't have to click on the erroneous field first
//
// this has to be rendered in onAfterRespond to be sure the dom component for setting focus on has
// already been rendered in the dom structure of the browser
//
final FormComponent focus = (FormComponent) visitChildren(FormComponent.class, new IVisitor()
{
public Object component(final Component component)
{
final FormComponent formComponent = (FormComponent) component;
if (formComponent.hasErrorMessage() && formComponent.getOutputMarkupId())
return formComponent;
return CONTINUE_TRAVERSAL;
}
});
if (focus != null)
target.focusComponent(focus);
}
});
return target;
}
another possible example (using common functionality specific to your application this time)
@Override
public AjaxRequestTarget newAjaxRequestTarget()
{
return new CustomAjaxRequestTarget(); // extends AjaxRequestTarget
}
so inside your pages you could for example do this:
public void onClick(final AjaxRequestTarget target)
{
final CustomAjaxRequestTarget customTarget = (CustomAjaxRequestTarget)target;
// change some setting on the page
// ..
// let the user take notice of the change (the heavily-used effect from Ruby on Rails we probably all know)
customTarget.applyYellowFadeEffect(component);
// make it even more obvious (some freaky javascript :-)
customTarget.letScreenShakeUpAndDown();
// even half-blind people should see that (another crazy js)
customTarget.zoomInAndOutAgain(component);
}
this way you could provide some common ajax functionality to your application which is easy to use and implementation details are perfectly hidden
was (Author: pete):
here's an example of how this could be used -- you might get an better idea of what I want to achieve with this patch...
this is some code inside my template page:
@Override
public AjaxRequestTarget newAjaxRequestTarget()
{
final AjaxRequestTarget target = super.newAjaxRequestTarget();
target.addListener(new AjaxRequestTarget.IListener()
{
@SuppressWarnings({"RawUseOfParameterizedType"})
public void onBeforeRespond(final Map map, final AjaxRequestTarget target)
{
// always render the feedback component that belongs to this template
// no need to include it in all pages that use this template
target.addComponent(feedbackPanel);
}
@SuppressWarnings({"RawUseOfParameterizedType"})
public void onAfterRespond(final Map map, final AjaxRequestTarget.IJavascriptResponse response)
{
//
// set the focus on the first form component that has errors
// this is very convenient for the user as he doesn't have to click on the erroneous field first
//
// this has to be rendered in onAfterRespond to be sure the dom component for setting focus on has
// already been rendered in the dom structure of the browser
//
final FormComponent focus = (FormComponent) visitChildren(FormComponent.class, new IVisitor()
{
public Object component(final Component component)
{
final FormComponent formComponent = (FormComponent) component;
if (formComponent.hasErrorMessage() && formComponent.getOutputMarkupId())
return formComponent;
return CONTINUE_TRAVERSAL;
}
});
if (focus != null)
target.focusComponent(focus);
}
});
return target;
}
another possible example (using common functionality specific to your application this time)
@Override
public AjaxRequestTarget newAjaxRequestTarget()
{
return new CustomAjaxRequestTarget();
}
so inside your pages you could for example do this:
public void onClick(final AjaxRequestTarget target)
{
final CustomAjaxRequestTarget customTarget = (CustomAjaxRequestTarget)target;
// change some setting on the page
// ..
// let the user take notice of the change (the heavily-used effect from Ruby on Rails we probably all know)
customTarget.applyYellowFadeEffect(component);
// make it even more obvious (some freaky javascript :-)
customTarget.letScreenShakeUpAndDown();
// even half-blind people should see that (another crazy js)
customTarget.zoomInAndOutAgain(component);
}
this way you could provide some common ajax functionality to your application which is easy to use and implementation details are perfectly hidden
> enable subclassing of AjaxRequestTarget
> ---------------------------------------
>
> Key: WICKET-1213
> URL: https://issues.apache.org/jira/browse/WICKET-1213
> Project: Wicket
> Issue Type: Wish
> Components: wicket
> Affects Versions: 1.3.0-rc1
> Reporter: Peter Ertl
> Fix For: 1.4.0-alpha
>
> Attachments: AjaxRequestTarget_with_subclassing.patch
>
>
> In my wicket programming life I always had some trouble with the ajax part when wanting stuff like this:
> - "Always update a common feedback panel from my template page"
> --> add 'target.addComponent(feedbackPanel)' just _everywhere_ (very cumbersome and not elegant at all)
> - add a listener using AjaxRequestTarget#addListener
> --> not quite possible without subclassing the request cycle (which is *yuk* if you ask me) to catch the short moment in between AjaxRequestTarget is instantiated and IRequestTarget#onRespond() is called
> - automatically set focus on the first form component with errors
> --> add bulky code into all onError() to check for the proper component and call AjaxRequestTarget#setFocus
> - add some common function like AjaxRequestTarget#yellowFadeEffect(FormComponent)
> --> have some utility method and call it like this: AjaxUtil.yellowFade(target) -- not nice as functionality like this should really belong to the ajax target which represents the ajax request / response.
> I found that all these issues can be solved very elegantly if you could just catch the moment where AjaxRequestTarget is instantiated.
> I attached a very little patch (!) which enables you to
> - subclass
> - add listeners to
> the AjaxRequestTarget
> In AbstractDefaultAjaxBehavior:281
> public final void onRequest()
> {
> AjaxRequestTarget target = new AjaxRequestTarget(getComponent().getPage()); // *******
> RequestCycle.get().setRequestTarget(target);
> respond(target)
> }
> is changed to
> public final void onRequest()
> {
> AjaxRequestTarget target = getComponent().getPage().newAjaxRequestTarget(); // *******
> RequestCycle.get().setRequestTarget(target);
> respond(target);
> }
> org.apache.wicket.Page will have an additional method:
> public AjaxRequestTarget newAjaxRequestTarget()
> {
> return new AjaxRequestTarget(this);
> }
> }
> so by overriding newAjaxRequestTarget in your page you could customize or subclass the ajax response very easily
> also, this will not break current code but is just an enhancement you will not notice unless you need it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1213) enable subclassing of
AjaxRequestTarget
Posted by "Peter Ertl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550134 ]
Peter Ertl commented on WICKET-1213:
------------------------------------
I would like to express my suggestion again in different words in the hope that I could possibly convince you of the benefit.
Everything in this jira issue comes down to three lines:
org.apache.wicket.ajax.AbstractDefaultAjaxBehavior#onRequest()
public final void onRequest()
{
(1) AjaxRequestTarget target = new AjaxRequestTarget(getComponent().getPage());
(2) RequestCycle.get().setRequestTarget(target);
(3) respond(target);
}
I want to provide a way to not only create AjaxRequestTarget but also subclasses of it. This has to happen before (3) because implementors of AbstractDefaultAjaxBehavior should be able to use that enhanced/enriched subclasses of AjaxRequestTarget. These could contain for example additional ajax effects. Also, it would be possible to call AjaxRequestTarget#addListener() to decorate the ajax request with some base functionality (like e.g. auto-focus on error fields or update some basic components like feedback panels).
Possible approaches would *imho* be:
make (1) call some kind of callback / factory method to create a specific instance of an ajax target which contains additional methods. Also, listeners could be bound to the ajax requests in that moment.
make (2) RequestCycle#setRequestTarget() non-final.
> enable subclassing of AjaxRequestTarget
> ---------------------------------------
>
> Key: WICKET-1213
> URL: https://issues.apache.org/jira/browse/WICKET-1213
> Project: Wicket
> Issue Type: Wish
> Components: wicket
> Affects Versions: 1.3.0-rc1
> Reporter: Peter Ertl
> Assignee: Matej Knopp
> Fix For: 1.4.0-alpha
>
> Attachments: AjaxRequestTarget_using_callback_interface.patch, AjaxRequestTarget_with_subclassing.patch
>
>
> In my wicket programming experience so far I always didn't feel quite comfortable with the ajax part.
> I had some issues in particular with these as an example:
> - "Always include a common feedback panel from my template page"
> --> add 'target.addComponent(feedbackPanel)' just _everywhere_ (very cumbersome and not elegant at all)
> - add a listener using AjaxRequestTarget#addListener
> --> not possible without subclassing the request cycle (which is *yuk* if you ask me) to catch the short moment in between AjaxRequestTarget is instantiated and AjaxRequestTarget#onRespond() is called
> - automatically set focus on the first form component with errors
> --> add bulky code into all onSubmit() and onError() to check for errrors and call AjaxRequestTarget#setFocus
> - add some common function like AjaxRequestTarget#yellowFade(FormComponent)
> --> have some utility method and call it like this: AjaxUtil.yellowFade(target) -- not nice as functionality like this should really belong to the request target
> I found that all these issues can be solved very elegantly if you could just catch the moment where AjaxRequestTarget is instantiated.
> I attached a very little patch (!) which solves all that issues and makes ajax just a lot more powerful inside wicket *imho*
> also, it will not break current code but is just an enhancement you will not notice unless you need it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (WICKET-1213) enable subclassing of
AjaxRequestTarget
Posted by "Peter Ertl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Ertl closed WICKET-1213.
------------------------------
> enable subclassing of AjaxRequestTarget
> ---------------------------------------
>
> Key: WICKET-1213
> URL: https://issues.apache.org/jira/browse/WICKET-1213
> Project: Wicket
> Issue Type: Wish
> Components: wicket
> Affects Versions: 1.3.0-rc1
> Reporter: Peter Ertl
> Assignee: Igor Vaynberg
> Fix For: 1.3.0-final
>
> Attachments: AjaxRequestTarget_using_callback_interface.patch, AjaxRequestTarget_with_subclassing.patch
>
>
> In my wicket programming experience so far I always didn't feel quite comfortable with the ajax part.
> I had some issues in particular with these as an example:
> - "Always include a common feedback panel from my template page"
> --> add 'target.addComponent(feedbackPanel)' just _everywhere_ (very cumbersome and not elegant at all)
> - add a listener using AjaxRequestTarget#addListener
> --> not possible without subclassing the request cycle (which is *yuk* if you ask me) to catch the short moment in between AjaxRequestTarget is instantiated and AjaxRequestTarget#onRespond() is called
> - automatically set focus on the first form component with errors
> --> add bulky code into all onSubmit() and onError() to check for errrors and call AjaxRequestTarget#setFocus
> - add some common function like AjaxRequestTarget#yellowFade(FormComponent)
> --> have some utility method and call it like this: AjaxUtil.yellowFade(target) -- not nice as functionality like this should really belong to the request target
> I found that all these issues can be solved very elegantly if you could just catch the moment where AjaxRequestTarget is instantiated.
> I attached a very little patch (!) which solves all that issues and makes ajax just a lot more powerful inside wicket *imho*
> also, it will not break current code but is just an enhancement you will not notice unless you need it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1213) enable subclassing of
AjaxRequestTarget
Posted by "Peter Ertl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Ertl updated WICKET-1213:
-------------------------------
Description:
In my wicket programming life I always had some trouble with the ajax part when wanting stuff like this:
- "Always update a common feedback panel from my template page"
--> add 'target.addComponent(feedbackPanel)' just _everywhere_ (very cumbersome and not elegant at all)
- add a listener using AjaxRequestTarget#addListener
--> not quite possible without subclassing the request cycle (which is *yuk* if you ask me) to catch the short moment in between AjaxRequestTarget is instantiated and IRequestTarget#onRespond() is called
- automatically set focus on the first form component with errors
--> add bulky code into all onError() to check for the proper component and call AjaxRequestTarget#setFocus
- add some common function like AjaxRequestTarget#yellowFadeEffect(FormComponent)
--> have some utility method and call it like this: AjaxUtil.yellowFade(target) -- not nice as functionality like this should really belong to the ajax target which represents the ajax request / response.
I found that all these issues can be solved very elegantly if you could just catch the moment where AjaxRequestTarget is instantiated.
I attached a very little patch (!) which enables you to
- subclass
- add listeners to
the AjaxRequestTarget
In AbstractDefaultAjaxBehavior:281
public final void onRequest()
{
AjaxRequestTarget target = new AjaxRequestTarget(getComponent().getPage()); // *******
RequestCycle.get().setRequestTarget(target);
respond(target)
}
is changed to
public final void onRequest()
{
AjaxRequestTarget target = getComponent().getPage().newAjaxRequestTarget(); // *******
RequestCycle.get().setRequestTarget(target);
respond(target);
}
org.apache.wicket.Page will have an additional method:
public AjaxRequestTarget newAjaxRequestTarget()
{
return new AjaxRequestTarget(this);
}
}
so by overriding newAjaxRequestTarget in your page you could customize or subclass the ajax response very easily
also, this will not break current code but is just an enhancement you will not notice unless you need it.
was:
In my wicket programming life I always had some trouble with the ajax part when wanting stuff like this:
- "Always update a common feedback panel from my template page"
--> add 'target.addComponent(feedbackPanel)' just _everywhere_ (very cumbersome and not elegant at all)
- add a listener using AjaxRequestTarget#addListener
--> not quite possible without subclassing the request cycle (which is *yuk* if you ask me) to catch the short moment in between AjaxRequestTarget is instantiated and IRequestTarget#onRespond() is called
- automatically set focus on the first form component with errors
--> add bulky code into all onError() to check for the proper component and call AjaxRequestTarget#setFocus
- add some common function like AjaxRequestTarget#yellowFadeEffect(FormComponent)
--> have some utility method and call it like this: AjaxUtil.yellowFade(target) -- not nice as functionality like this should really belong to the ajax target which represents the ajax request / response.
I found that all these issues can be solved very elegantly if you could just catch the moment where AjaxRequestTarget is instantiated.
I attached a very little patch (!) which enables you to
- subclass
- add listeners to
the AjaxRequestTarget
In AbstractDefaultAjaxBehavior:281
public final void onRequest()
{
AjaxRequestTarget target = new AjaxRequestTarget(getComponent().getPage()); // *******
RequestCycle.get().setRequestTarget(target);
respond(target);
}
is changed to
public final void onRequest()
{
AjaxRequestTarget target = getComponent().getPage().newAjaxRequestTarget(); // *******
RequestCycle.get().setRequestTarget(target);
respond(target);
}
org.apache.wicket.Page will have an additional method:
public AjaxRequestTarget newAjaxRequestTarget()
{
return new AjaxRequestTarget(this);
}
}
so by overriding newAjaxRequestTarget in your page you could customize or subclass the ajax response very easily
also, this will not break current code but is just an enhancement you will not notice unless you need it.
> enable subclassing of AjaxRequestTarget
> ---------------------------------------
>
> Key: WICKET-1213
> URL: https://issues.apache.org/jira/browse/WICKET-1213
> Project: Wicket
> Issue Type: Wish
> Components: wicket
> Reporter: Peter Ertl
> Attachments: AjaxRequestTarget_with_subclassing.patch
>
>
> In my wicket programming life I always had some trouble with the ajax part when wanting stuff like this:
> - "Always update a common feedback panel from my template page"
> --> add 'target.addComponent(feedbackPanel)' just _everywhere_ (very cumbersome and not elegant at all)
> - add a listener using AjaxRequestTarget#addListener
> --> not quite possible without subclassing the request cycle (which is *yuk* if you ask me) to catch the short moment in between AjaxRequestTarget is instantiated and IRequestTarget#onRespond() is called
> - automatically set focus on the first form component with errors
> --> add bulky code into all onError() to check for the proper component and call AjaxRequestTarget#setFocus
> - add some common function like AjaxRequestTarget#yellowFadeEffect(FormComponent)
> --> have some utility method and call it like this: AjaxUtil.yellowFade(target) -- not nice as functionality like this should really belong to the ajax target which represents the ajax request / response.
> I found that all these issues can be solved very elegantly if you could just catch the moment where AjaxRequestTarget is instantiated.
> I attached a very little patch (!) which enables you to
> - subclass
> - add listeners to
> the AjaxRequestTarget
> In AbstractDefaultAjaxBehavior:281
> public final void onRequest()
> {
> AjaxRequestTarget target = new AjaxRequestTarget(getComponent().getPage()); // *******
> RequestCycle.get().setRequestTarget(target);
> respond(target)
> }
> is changed to
> public final void onRequest()
> {
> AjaxRequestTarget target = getComponent().getPage().newAjaxRequestTarget(); // *******
> RequestCycle.get().setRequestTarget(target);
> respond(target);
> }
> org.apache.wicket.Page will have an additional method:
> public AjaxRequestTarget newAjaxRequestTarget()
> {
> return new AjaxRequestTarget(this);
> }
> }
> so by overriding newAjaxRequestTarget in your page you could customize or subclass the ajax response very easily
> also, this will not break current code but is just an enhancement you will not notice unless you need it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1213) enable subclassing of
AjaxRequestTarget
Posted by "Peter Ertl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550039 ]
Peter Ertl commented on WICKET-1213:
------------------------------------
Ok, seems like nobody wants a compiler dependency between Page and AjaxRequestTarget.
So how you think about that:
Similar to org.apache.wicket.html.IHeaderContributor there will be a callback interface IAjaxRequestTargetCreator that (optionally) lets the page control the creation of the ajax request target.
The code would look like this:
public final void onRequest()
{
Page page = getComponent().getPage();
AjaxRequestTarget target = null;
if(page != null && page instanceof IAjaxRequestTargetCreator)
target = ((IAjaxRequestTargetCreator)page).createAjaxRequestTarget();
if(target == null)
target = new AjaxRequestTarget(page);
RequestCycle.get().setRequestTarget(target);
respond(target);
}
I attached another patch based on that suggestion. Would be great if you like it :-)
> enable subclassing of AjaxRequestTarget
> ---------------------------------------
>
> Key: WICKET-1213
> URL: https://issues.apache.org/jira/browse/WICKET-1213
> Project: Wicket
> Issue Type: Wish
> Components: wicket
> Affects Versions: 1.3.0-rc1
> Reporter: Peter Ertl
> Assignee: Matej Knopp
> Fix For: 1.4.0-alpha
>
> Attachments: AjaxRequestTarget_with_subclassing.patch
>
>
> In my wicket programming experience so far I always didn't feel quite comfortable with the ajax part.
> I had some issues in particular with these as an example:
> - "Always include a common feedback panel from my template page"
> --> add 'target.addComponent(feedbackPanel)' just _everywhere_ (very cumbersome and not elegant at all)
> - add a listener using AjaxRequestTarget#addListener
> --> not possible without subclassing the request cycle (which is *yuk* if you ask me) to catch the short moment in between AjaxRequestTarget is instantiated and AjaxRequestTarget#onRespond() is called
> - automatically set focus on the first form component with errors
> --> add bulky code into all onSubmit() and onError() to check for errrors and call AjaxRequestTarget#setFocus
> - add some common function like AjaxRequestTarget#yellowFade(FormComponent)
> --> have some utility method and call it like this: AjaxUtil.yellowFade(target) -- not nice as functionality like this should really belong to the request target
> I found that all these issues can be solved very elegantly if you could just catch the moment where AjaxRequestTarget is instantiated.
> I attached a very little patch (!) which solves all that issues and makes ajax just a lot more powerful inside wicket *imho*
> also, it will not break current code but is just an enhancement you will not notice unless you need it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1213) enable subclassing of
AjaxRequestTarget
Posted by "Peter Ertl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549696 ]
Peter Ertl commented on WICKET-1213:
------------------------------------
here's an example of how this could be used -- you might get an better idea of what I want to achieve with this patch...
this is some code inside my template page:
@Override
public AjaxRequestTarget newAjaxRequestTarget()
{
final AjaxRequestTarget target = super.newAjaxRequestTarget();
target.addListener(new AjaxRequestTarget.IListener()
{
@SuppressWarnings({"RawUseOfParameterizedType"})
public void onBeforeRespond(final Map map, final AjaxRequestTarget target)
{
// always render the feedback component that belongs to this template
// no need to include it in all pages that use this template
target.addComponent(feedbackPanel);
}
@SuppressWarnings({"RawUseOfParameterizedType"})
public void onAfterRespond(final Map map, final AjaxRequestTarget.IJavascriptResponse response)
{
//
// set the focus on the first form component that has errors
// this is very convenient for the user as he doesn't have to click on the erroneous field first
//
// this has to be rendered in onAfterRespond to be sure the dom component for setting focus on has
// already been rendered in the dom structure of the browser
//
final FormComponent focus = (FormComponent) visitChildren(FormComponent.class, new IVisitor()
{
public Object component(final Component component)
{
final FormComponent formComponent = (FormComponent) component;
if (formComponent.hasErrorMessage() && formComponent.getOutputMarkupId())
return formComponent;
return CONTINUE_TRAVERSAL;
}
});
if (focus != null)
target.focusComponent(focus);
}
});
return target;
}
another possible example (using common functionality specific to your application this time)
@Override
public AjaxRequestTarget newAjaxRequestTarget()
{
return new CustomAjaxRequestTarget();
}
so inside your pages you could for example do this:
public void onClick(final AjaxRequestTarget target)
{
final CustomAjaxRequestTarget customTarget = (CustomAjaxRequestTarget)target;
// change some setting on the page
// ..
// let the user take notice of the change (the heavily-used effect from Ruby on Rails we probably all know)
customTarget.applyYellowFadeEffect(component);
// make it even more obvious (some freaky javascript :-)
customTarget.letScreenShakeUpAndDown();
// even half-blind people should see that (another crazy js)
customTarget.zoomInAndOutAgain(component);
}
this way you could provide some common ajax functionality to your application which is easy to use and implementation details are perfectly hidden
> enable subclassing of AjaxRequestTarget
> ---------------------------------------
>
> Key: WICKET-1213
> URL: https://issues.apache.org/jira/browse/WICKET-1213
> Project: Wicket
> Issue Type: Wish
> Components: wicket
> Reporter: Peter Ertl
> Attachments: AjaxRequestTarget_with_subclassing.patch
>
>
> In my wicket programming experience so far I always didn't feel quite comfortable with the ajax part.
> I had some issues in particular with these as an example:
> - "Always include a common feedback panel from my template page"
> --> add 'target.addComponent(feedbackPanel)' just _everywhere_ (very cumbersome and not elegant at all)
> - add a listener using AjaxRequestTarget#addListener
> --> not possible without subclassing the request cycle (which is *yuk* if you ask me) to catch the short moment in between AjaxRequestTarget is instantiated and AjaxRequestTarget#onRespond() is called
> - automatically set focus on the first form component with errors
> --> add bulky code into all onSubmit() and onError() to check for errrors and call AjaxRequestTarget#setFocus
> - add some common function like AjaxRequestTarget#yellowFade(FormComponent)
> --> have some utility method and call it like this: AjaxUtil.yellowFade(target) -- not nice as functionality like this should really belong to the request target
> I found that all these issues can be solved very elegantly if you could just catch the moment where AjaxRequestTarget is instantiated.
> I attached a very little patch (!) which solves all that issues and makes ajax just a lot more powerful inside wicket *imho*
> also, it will not break current code but is just an enhancement you will not notice unless you need it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1213) enable subclassing of
AjaxRequestTarget
Posted by "Peter Ertl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549861 ]
Peter Ertl commented on WICKET-1213:
------------------------------------
I see no logical reason to be able to compile base wicket without the *.ajax part. What the benefit except from being able to do it? do you really want to ship ajax-less wicket jars?
>From my point of view an ajax response is even something that logically belongs to a page. Having an ajax response without a corresponding page is pointless (please correct me if I am wrong). Where should the ajax request come from if not from an XmlHttpRequest being launched by the page? What should happen to the response if not processed by some javascript inside that same page? The whole goal of asynchronous ajax requests was to avoid refreshing the whole page by a full page reload.
In OOP speak I would state: AjaxRequestTarget is an aggregate of page as it could not 'life alone'.
So based on that close relationship I see no reason to not instantiate the ajax request by an instance of page.
One reason for doing that is to be able to subclass AjaxRequestTarget and enrich it with additional functionality that belongs to the ajax part of the application.
For example we have AjaxRequestTarget#focusComponent(Component). Why shouldn't be there something like AjaxRequestTarget#fadeOut(Component), AjaxRequestTarget#moveTo(Component), AjaxRequestTarget#explode(Component :-) or other nifty effects? However, it not possible to add new methods to an existing instance of a class (like in ruby for example by mix-ins) so subclassing should be the best solution in that case.
Another reason is to decorate the request. For example a template page could add 'automatically focus first component with errors' or 'automatically update feedback panel'. This could simplify complex ajax interfaces a lot.
Just my 2ct :-)
> enable subclassing of AjaxRequestTarget
> ---------------------------------------
>
> Key: WICKET-1213
> URL: https://issues.apache.org/jira/browse/WICKET-1213
> Project: Wicket
> Issue Type: Wish
> Components: wicket
> Affects Versions: 1.3.0-rc1
> Reporter: Peter Ertl
> Assignee: Matej Knopp
> Fix For: 1.4.0-alpha
>
> Attachments: AjaxRequestTarget_with_subclassing.patch
>
>
> In my wicket programming experience so far I always didn't feel quite comfortable with the ajax part.
> I had some issues in particular with these as an example:
> - "Always include a common feedback panel from my template page"
> --> add 'target.addComponent(feedbackPanel)' just _everywhere_ (very cumbersome and not elegant at all)
> - add a listener using AjaxRequestTarget#addListener
> --> not possible without subclassing the request cycle (which is *yuk* if you ask me) to catch the short moment in between AjaxRequestTarget is instantiated and AjaxRequestTarget#onRespond() is called
> - automatically set focus on the first form component with errors
> --> add bulky code into all onSubmit() and onError() to check for errrors and call AjaxRequestTarget#setFocus
> - add some common function like AjaxRequestTarget#yellowFade(FormComponent)
> --> have some utility method and call it like this: AjaxUtil.yellowFade(target) -- not nice as functionality like this should really belong to the request target
> I found that all these issues can be solved very elegantly if you could just catch the moment where AjaxRequestTarget is instantiated.
> I attached a very little patch (!) which solves all that issues and makes ajax just a lot more powerful inside wicket *imho*
> also, it will not break current code but is just an enhancement you will not notice unless you need it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1213) enable subclassing of
AjaxRequestTarget
Posted by "Peter Ertl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Ertl updated WICKET-1213:
-------------------------------
Description:
In my wicket programming life I always had some trouble with the ajax part when wanting stuff like this:
- "Always update a common feedback panel from my template page"
--> add 'target.addComponent(feedbackPanel)' just _everywhere_ (very cumbersome and not elegant at all)
- add a listener using AjaxRequestTarget#addListener
--> not quite possible without subclassing the request cycle (which is *yuk* if you ask me) to catch the short moment in between AjaxRequestTarget is instantiated and IRequestTarget#onRespond() is called
- automatically set focus on the first form component with errors
--> add bulky code into all onError() to check for the proper component and call AjaxRequestTarget#setFocus
- add some common function like AjaxRequestTarget#yellowFadeEffect(FormComponent)
--> have some utility method and call it like this: AjaxUtil.yellowFade(target) -- not nice as functionality like this should really belong to the ajax target which represents the ajax request / response.
I found that all these issues can be solved very elegantly if you could just catch the moment where AjaxRequestTarget is instantiated.
I attached a very little patch (!) which enables you to
- subclass
- add listeners to
the AjaxRequestTarget
In AbstractDefaultAjaxBehavior:281
public final void onRequest()
{
AjaxRequestTarget target = new AjaxRequestTarget(getComponent().getPage()); // *******
RequestCycle.get().setRequestTarget(target);
respond(target);
}
is changed to
public final void onRequest()
{
AjaxRequestTarget target = getComponent().getPage().newAjaxRequestTarget(); // *******
RequestCycle.get().setRequestTarget(target);
respond(target);
}
org.apache.wicket.Page will have an additional method:
public AjaxRequestTarget newAjaxRequestTarget()
{
return new AjaxRequestTarget(this);
}
}
so by overriding newAjaxRequestTarget in your page you could customize or subclass the ajax response very easily
also, this will not break current code but is just an enhancement you will not notice unless you need it.
was:
In my wicket programming experience so far I always didn't feel quite comfortable with the ajax part.
I had some issues in particular with these as an example:
- "Always include a common feedback panel from my template page"
--> add 'target.addComponent(feedbackPanel)' just _everywhere_ (very cumbersome and not elegant at all)
- add a listener using AjaxRequestTarget#addListener
--> not possible without subclassing the request cycle (which is *yuk* if you ask me) to catch the short moment in between AjaxRequestTarget is instantiated and AjaxRequestTarget#onRespond() is called
- automatically set focus on the first form component with errors
--> add bulky code into all onSubmit() and onError() to check for errrors and call AjaxRequestTarget#setFocus
- add some common function like AjaxRequestTarget#yellowFade(FormComponent)
--> have some utility method and call it like this: AjaxUtil.yellowFade(target) -- not nice as functionality like this should really belong to the request target
I found that all these issues can be solved very elegantly if you could just catch the moment where AjaxRequestTarget is instantiated.
I attached a very little patch (!) which solves all that issues and makes ajax just a lot more powerful inside wicket *imho*
also, it will not break current code but is just an enhancement you will not notice unless you need it.
> enable subclassing of AjaxRequestTarget
> ---------------------------------------
>
> Key: WICKET-1213
> URL: https://issues.apache.org/jira/browse/WICKET-1213
> Project: Wicket
> Issue Type: Wish
> Components: wicket
> Reporter: Peter Ertl
> Attachments: AjaxRequestTarget_with_subclassing.patch
>
>
> In my wicket programming life I always had some trouble with the ajax part when wanting stuff like this:
> - "Always update a common feedback panel from my template page"
> --> add 'target.addComponent(feedbackPanel)' just _everywhere_ (very cumbersome and not elegant at all)
> - add a listener using AjaxRequestTarget#addListener
> --> not quite possible without subclassing the request cycle (which is *yuk* if you ask me) to catch the short moment in between AjaxRequestTarget is instantiated and IRequestTarget#onRespond() is called
> - automatically set focus on the first form component with errors
> --> add bulky code into all onError() to check for the proper component and call AjaxRequestTarget#setFocus
> - add some common function like AjaxRequestTarget#yellowFadeEffect(FormComponent)
> --> have some utility method and call it like this: AjaxUtil.yellowFade(target) -- not nice as functionality like this should really belong to the ajax target which represents the ajax request / response.
> I found that all these issues can be solved very elegantly if you could just catch the moment where AjaxRequestTarget is instantiated.
> I attached a very little patch (!) which enables you to
> - subclass
> - add listeners to
> the AjaxRequestTarget
> In AbstractDefaultAjaxBehavior:281
> public final void onRequest()
> {
> AjaxRequestTarget target = new AjaxRequestTarget(getComponent().getPage()); // *******
> RequestCycle.get().setRequestTarget(target);
> respond(target);
> }
> is changed to
> public final void onRequest()
> {
> AjaxRequestTarget target = getComponent().getPage().newAjaxRequestTarget(); // *******
> RequestCycle.get().setRequestTarget(target);
> respond(target);
> }
> org.apache.wicket.Page will have an additional method:
> public AjaxRequestTarget newAjaxRequestTarget()
> {
> return new AjaxRequestTarget(this);
> }
> }
> so by overriding newAjaxRequestTarget in your page you could customize or subclass the ajax response very easily
> also, this will not break current code but is just an enhancement you will not notice unless you need it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1213) enable subclassing of
AjaxRequestTarget
Posted by "Martijn Dashorst (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549862 ]
Martijn Dashorst commented on WICKET-1213:
------------------------------------------
-1 on binding the AjaxRequestTarget to a page. RequestTargets are a separate, orthogonal concept: they are not part of a component.
Ajax requests could be something we may implement in a totally different way in the future, for instance to be able to use comet where ajax is used, or to automatically add any component that was changed, or ...
In OOP speak: an AjaxRequestTarget can easily live on its own. There is no tie what so ever to any page. It is a completely separate and orthogonal concept.
> enable subclassing of AjaxRequestTarget
> ---------------------------------------
>
> Key: WICKET-1213
> URL: https://issues.apache.org/jira/browse/WICKET-1213
> Project: Wicket
> Issue Type: Wish
> Components: wicket
> Affects Versions: 1.3.0-rc1
> Reporter: Peter Ertl
> Assignee: Matej Knopp
> Fix For: 1.4.0-alpha
>
> Attachments: AjaxRequestTarget_with_subclassing.patch
>
>
> In my wicket programming experience so far I always didn't feel quite comfortable with the ajax part.
> I had some issues in particular with these as an example:
> - "Always include a common feedback panel from my template page"
> --> add 'target.addComponent(feedbackPanel)' just _everywhere_ (very cumbersome and not elegant at all)
> - add a listener using AjaxRequestTarget#addListener
> --> not possible without subclassing the request cycle (which is *yuk* if you ask me) to catch the short moment in between AjaxRequestTarget is instantiated and AjaxRequestTarget#onRespond() is called
> - automatically set focus on the first form component with errors
> --> add bulky code into all onSubmit() and onError() to check for errrors and call AjaxRequestTarget#setFocus
> - add some common function like AjaxRequestTarget#yellowFade(FormComponent)
> --> have some utility method and call it like this: AjaxUtil.yellowFade(target) -- not nice as functionality like this should really belong to the request target
> I found that all these issues can be solved very elegantly if you could just catch the moment where AjaxRequestTarget is instantiated.
> I attached a very little patch (!) which solves all that issues and makes ajax just a lot more powerful inside wicket *imho*
> also, it will not break current code but is just an enhancement you will not notice unless you need it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1213) enable subclassing of
AjaxRequestTarget
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Igor Vaynberg resolved WICKET-1213.
-----------------------------------
Resolution: Fixed
Fix Version/s: (was: 1.4.0-alpha)
1.3.0-rc3
we cannot have this on page because it will be possible to have jars depending on things that will not exist in applications they are used in.
so what i did was create the factory on WebApplication. that way it is nice and global and it is explicit that it is the application-level that controls this, not component level.
if you want to implement your per-page thing then simply make the factory check if the passed in page is instance of that targetcreator and delegate the creation back to page.
thoughts?
> enable subclassing of AjaxRequestTarget
> ---------------------------------------
>
> Key: WICKET-1213
> URL: https://issues.apache.org/jira/browse/WICKET-1213
> Project: Wicket
> Issue Type: Wish
> Components: wicket
> Affects Versions: 1.3.0-rc1
> Reporter: Peter Ertl
> Assignee: Igor Vaynberg
> Fix For: 1.3.0-rc3
>
> Attachments: AjaxRequestTarget_using_callback_interface.patch, AjaxRequestTarget_with_subclassing.patch
>
>
> In my wicket programming experience so far I always didn't feel quite comfortable with the ajax part.
> I had some issues in particular with these as an example:
> - "Always include a common feedback panel from my template page"
> --> add 'target.addComponent(feedbackPanel)' just _everywhere_ (very cumbersome and not elegant at all)
> - add a listener using AjaxRequestTarget#addListener
> --> not possible without subclassing the request cycle (which is *yuk* if you ask me) to catch the short moment in between AjaxRequestTarget is instantiated and AjaxRequestTarget#onRespond() is called
> - automatically set focus on the first form component with errors
> --> add bulky code into all onSubmit() and onError() to check for errrors and call AjaxRequestTarget#setFocus
> - add some common function like AjaxRequestTarget#yellowFade(FormComponent)
> --> have some utility method and call it like this: AjaxUtil.yellowFade(target) -- not nice as functionality like this should really belong to the request target
> I found that all these issues can be solved very elegantly if you could just catch the moment where AjaxRequestTarget is instantiated.
> I attached a very little patch (!) which solves all that issues and makes ajax just a lot more powerful inside wicket *imho*
> also, it will not break current code but is just an enhancement you will not notice unless you need it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1213) enable subclassing of
AjaxRequestTarget
Posted by "Johan Compagner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Johan Compagner updated WICKET-1213:
------------------------------------
Description:
In my wicket programming experience so far I always didn't feel quite comfortable with the ajax part.
I had some issues in particular with these as an example:
- "Always include a common feedback panel from my template page"
--> add 'target.addComponent(feedbackPanel)' just _everywhere_ (very cumbersome and not elegant at all)
- add a listener using AjaxRequestTarget#addListener
--> not possible without subclassing the request cycle (which is *yuk* if you ask me) to catch the short moment in between AjaxRequestTarget is instantiated and AjaxRequestTarget#onRespond() is called
- automatically set focus on the first form component with errors
--> add bulky code into all onSubmit() and onError() to check for errrors and call AjaxRequestTarget#setFocus
- add some common function like AjaxRequestTarget#yellowFade(FormComponent)
--> have some utility method and call it like this: AjaxUtil.yellowFade(target) -- not nice as functionality like this should really belong to the request target
I found that all these issues can be solved very elegantly if you could just catch the moment where AjaxRequestTarget is instantiated.
I attached a very little patch (!) which solves all that issues and makes ajax just a lot more powerful inside wicket *imho*
also, it will not break current code but is just an enhancement you will not notice unless you need it.
was:
In my wicket programming life I always had some trouble with the ajax part when wanting stuff like this:
- "Always update a common feedback panel from my template page"
--> add 'target.addComponent(feedbackPanel)' just _everywhere_ (very cumbersome and not elegant at all)
- add a listener using AjaxRequestTarget#addListener
--> not quite possible without subclassing the request cycle (which is *yuk* if you ask me) to catch the short moment in between AjaxRequestTarget is instantiated and IRequestTarget#onRespond() is called
- automatically set focus on the first form component with errors
--> add bulky code into all onError() to check for the proper component and call AjaxRequestTarget#setFocus
- add some common function like AjaxRequestTarget#yellowFadeEffect(FormComponent)
--> have some utility method and call it like this: AjaxUtil.yellowFade(target) -- not nice as functionality like this should really belong to the ajax target which represents the ajax request / response.
I found that all these issues can be solved very elegantly if you could just catch the moment where AjaxRequestTarget is instantiated.
I attached a very little patch (!) which enables you to
- subclass
- add listeners to
the AjaxRequestTarget
In AbstractDefaultAjaxBehavior:281
public final void onRequest()
{
AjaxRequestTarget target = new AjaxRequestTarget(getComponent().getPage()); // *******
RequestCycle.get().setRequestTarget(target);
respond(target)
}
is changed to
public final void onRequest()
{
AjaxRequestTarget target = getComponent().getPage().newAjaxRequestTarget(); // *******
RequestCycle.get().setRequestTarget(target);
respond(target);
}
org.apache.wicket.Page will have an additional method:
public AjaxRequestTarget newAjaxRequestTarget()
{
return new AjaxRequestTarget(this);
}
}
so by overriding newAjaxRequestTarget in your page you could customize or subclass the ajax response very easily
also, this will not break current code but is just an enhancement you will not notice unless you need it.
Affects Version/s: 1.3.0-rc1
Fix Version/s: 1.4.0-alpha
Assignee: Matej Knopp
please clean up your patch if possible, its a bit messy with the javadoc changes (but maybe this is because of our own formatter and the page isn't formatted right)
But i am against this method on page. That is really the wrong place. Page.newAjaxRequestTarget()
what does page has to do with request processing.. Page is just a component.
Or do you really want to have all kinds of different AjaxRequestTargets for all kinds of differnent pages?
But still i don't like it to have it on that place for example the PageRequestTarget is also not made inside the page.
When quickly looking at it i think the best way to do it is instead of this
public final void onRequest()
{
AjaxRequestTarget target = new AjaxRequestTarget(getComponent().getPage());
RequestCycle.get().setRequestTarget(target);
respond(target);
}
this
public final void onRequest()
{
RequestCycle rc = RequestCycle.get();
AjaxRequestTarget target = rc.newAjaxRequestTarget(getComponent().getPage());
RequestCycle.get().setRequestTarget(target);
respond(target);
}
and then you can do anything you want, You can ask the page for its ajax request target if you want or create a default one (call super) or create a none standaard global one.
> enable subclassing of AjaxRequestTarget
> ---------------------------------------
>
> Key: WICKET-1213
> URL: https://issues.apache.org/jira/browse/WICKET-1213
> Project: Wicket
> Issue Type: Wish
> Components: wicket
> Affects Versions: 1.3.0-rc1
> Reporter: Peter Ertl
> Assignee: Matej Knopp
> Fix For: 1.4.0-alpha
>
> Attachments: AjaxRequestTarget_with_subclassing.patch
>
>
> In my wicket programming experience so far I always didn't feel quite comfortable with the ajax part.
> I had some issues in particular with these as an example:
> - "Always include a common feedback panel from my template page"
> --> add 'target.addComponent(feedbackPanel)' just _everywhere_ (very cumbersome and not elegant at all)
> - add a listener using AjaxRequestTarget#addListener
> --> not possible without subclassing the request cycle (which is *yuk* if you ask me) to catch the short moment in between AjaxRequestTarget is instantiated and AjaxRequestTarget#onRespond() is called
> - automatically set focus on the first form component with errors
> --> add bulky code into all onSubmit() and onError() to check for errrors and call AjaxRequestTarget#setFocus
> - add some common function like AjaxRequestTarget#yellowFade(FormComponent)
> --> have some utility method and call it like this: AjaxUtil.yellowFade(target) -- not nice as functionality like this should really belong to the request target
> I found that all these issues can be solved very elegantly if you could just catch the moment where AjaxRequestTarget is instantiated.
> I attached a very little patch (!) which solves all that issues and makes ajax just a lot more powerful inside wicket *imho*
> also, it will not break current code but is just an enhancement you will not notice unless you need it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.