On 4/20/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
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?
you can subclass link and layer existing call decorators, eg
IAjaxCallDecorator getAjaxCallDecorator() {
return new CompoundDecorator().add(new ThrottlingDecorator(
Duration.seconds(5)).add(new IndicatingDecorator("indicator").add(new
ErrorHandler(ErrorPage.class)));
if you do not have a structure of the call defined through some interface
you cannot layer things like above. throttler just decorates the script part
of the call. indicator contributes to the script and to the success/failure
handlers. errorhandler contributes to the failure handler.
class AjaxCall extends JavaScript
that is exactly the same as our iajaxcalldecorator, and is also exactly the
same as my IWicketAjaxCall from above email, so i think you are getting the
picture?
anyway, i still don't get it. what exactly is it that we cannot
accomplish
more simply and powerfully without these interfaces?
see above example
addParam? that only solves my specific problem. we need something
more general to allow any kind of URL manipulation, like:
URL getUrl(URL)
well, i dont think it is _your_ specific problem. i had to do that myself a
couple of times. i just dont see what other url manipulation you would need
to/should be able to do
-igor
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.
