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.

Reply via email to