to make a long story short, this does that now:
new WindowClosedBehavior() {
@Override
protected JavaScript callbackScript() {
return new ThrottlingDecorator("throttleId", Duration
.seconds(5), new ResultIndicatorDecorator(new
AjaxCall() {
@Override
public JavaScript onFailure() {
return new FailureHandlerScript();
}
}));
}
};
igor.vaynberg wrote:
>
> thats not quiet there
>
> indicatingdecorator also contributes to success and failure listeners, how
> does it do that in your example?
>
> -igor
>
>
> On 4/20/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>> yeah, but you're doing all this so you can make compound decorator
>> generic,
>> which i don't really agree is a good goal because it obscures the way the
>> decorators
>> are combined when it would be better to compose more explicitly anyway.
>> anyway,
>> in the case below, i would write something more like this:
>>
>> JavaScript getAjaxCall(AjaxCall call)
>> {
>> return new ThrottlingDecorator(Duration.seconds(5), new AjaxCall()
>> {
>> AjaxCall onError() { return new ErrorHandler(ErrorPage.class); }
>> AjaxCall getScript() { return new
>> IndicatingDecorator("indicator",
>> call.getScript()); }
>> };
>> }
>>
>> actually since i'm not coding in eclipse, i may be losing a few details,
>> but
>> this is the gist of it.
>>
>>
>> igor.vaynberg wrote:
>> >
>> > 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.
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/JavaScript-object-tf3610605.html#a10111023
>> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/JavaScript-object-tf3610605.html#a10127715
Sent from the Wicket - Dev mailing list archive at Nabble.com.
