yeah, it can certainly be used as a straightforward replacement.
so the interface adds the ability to decorate some unknown
ajax call implementation.
class AjaxLink { IAjaxCallDecorator getAjaxCallDecorator(); }
but what exactly can you do with that which you cannot do
more simply with classes? i'm trying to understand the use
case that requires these interfaces and i just don't see it. i mean,
instead of getting a call decorator, the ajax link would ask for
exactly what it needs:
class AjaxLink
{
// "Give me some JavaScript based on this AjaxCall script"
// (this permits arbitrary decoration of ajax call script by subclasses)
JavaScript getAjaxCall(AjaxCall call) { return call; }
}
or if ajax call scripts are not specific to components (they are
orthogonal to them), you can simply do this:
class AjaxLink
{
// Ask for JavaScript to do ajax call. Subclass can
// instantiate and/or decorate some appropriate ajax call object
AjaxCall getAjaxCall();
}
but in any case:
class AjaxCall extends JavaScript
{
public JavaScript getScript();
public JavaScript onSuccess();
public JavaScript onFailure();
}
my throttling decorator already decorates /any/ javascript, not just
ajax calls, but you can create decorators that are specific to AjaxCalls
too:
// Decorate any AjaxCall with a success alert box
class SuccessAlertDecorator extends AjaxCall
{
private AjaxCall call;
public SuccessAlertDecorator(AjaxCall call)
{
this.call = call;
}
public JavaScript onSuccess()
{
return call.append(new JavaScript("alert('success')"));
}
...
}
and you can make decoration easier with an adapter:
// Allow easy extension of AjaxCalls
public AjaxCallAdapter extends AjaxCall
{
private AjaxCall call;
public AjaxCallAdapter(AjaxCall call) { this.call = call; }
// Get call being decorated in subclasses
protected AjaxCall getCall() { return call; }
public JavaScript getScript() { return call.getScript(); }
public JavaScript onSuccess() { return call.onSuccess(); }
public JavaScript onFailure() { return call.onFailure(); }
}
then a success decorator is just this in its entirety:
// Decorate any AjaxCall with a success alert box
class SuccessAlertDecorator extends AjaxCallAdapter
{
public SuccessAlertDecorator(AjaxCall call)
{
super(call);
}
public JavaScript onSuccess()
{
return getCall().append(new JavaScript("alert('success')"));
}
}
anyway, i still don't get it. what exactly is it that we cannot accomplish
more simply and powerfully without these interfaces?
addParam? that only solves my specific problem. we need something
more general to allow any kind of URL manipulation, like:
URL getUrl(URL)
igor.vaynberg wrote:
>
> On 4/19/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>> don't forget that a javascript decorator isa JavaScript, so you can nest
>> them arbitrarily:
>
>
> yeah, i think this is exactly what threw me off in the first place. all
> your
> examples were actually extending, but what you needed was an interface so
> you can wrap and return the same thing
>
> IWicketAjaxCall { // whatever initially returns this will be instanceof
> JavaScript as well
> JavaScript getOnSuccessScript();
> JavaScript getOnFailureScript();
> JavaScript getCallScript();
> }
>
> now that a structure like that is defined i think you can start decorating
> things properly. this is exactly what IAjaxCallDecorator does, but all
> your
> examples with inheritance threw me off into thinking in a different
> direction. just have to take JavaScript at face value, a utility to manage
> a
> javascript string, nothing more. i kept thinking there is more to it.
>
> now if we also do:
> IWicketAjaxCall { // whatever initially returns this will be instanceof
> JavaScript as well
> interface ICallbackUrl { void addParam(String,String); }
>
> JavaScript getOnSuccessScript();
> JavaScript getOnFailureScript();
>
> JavaScript getCallScript(ICallbackUrl);
> }
>
> we should also be able to add arbitrary parameters to the callback url
> which
> will nicely link in with decoration.
>
> -igor
>
>
--
View this message in context:
http://www.nabble.com/JavaScript-object-tf3610605.html#a10102373
Sent from the Wicket - Dev mailing list archive at Nabble.com.
