[
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.
