wicket-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik van Oosten <e.vanoos...@grons.nl>
Subject Re: [wicket 1.5] url handling refactor preview
Date Sun, 04 Oct 2009 18:06:44 GMT
Matej Knopp wrote:
> On Sun, Oct 4, 2009 at 3:03 PM, Erik van Oosten <e.vanoosten@grons.nl> wrote:
>   
>> * I am a bit confused about the RequestHandler interface. It contains
>> nothing to get the request's parameters. How is method
>> RequestMapper#map(RequestHandler) supposed to work then? I guess it will
>> always need to know about the types of RequestHandlers it supports. This
>> introduces a tight coupling I did not expect. (I am not saying it is wrong,
>> it just confused me.)
>>     
> RequestHandler should not care about request parameters at all. That's
> what RequestMapper does. It takes request and produces RequestHandler.
> It must of course know which handlers to produce and which it can
> accept (to generate URLs). On the other hand RequestHandler doesn't
> know about RequestMapper nor should it. It's not tight coupling, just
> a chain of responsibility.
>
> RequestMapper knows how to parse urls and create request handlers, it
> also knows how to produce URLs for those request handlers. The
> responsibility of RequestHandler is to produce response (which can
> sometimes include other activities, such as invoking listener
> interface on components).
>   
I think I get your point: each RequestMapper is responsible for both Url 
<-> ReqeustHandler conversions and therefore should always know what its 
doing. Still, there is a tight coupling (I now understand, a good 
uni-directional one) between each RequestMapper instance to the 
RequestHandlers it supports.

>> * I guess BufferedResponseMapper#getCompatibilityScore should return
>> Integer.MIN_VALUE (instead of 0) when it can not process the request. Or is
>> 0 a kind of magic value?
>>     
> Well, if being the smallest positive number counts as magical then
> yes. If java had unsigned numbers the result type would be unsigned
> int. Look at RequestMapper#getCompatibilityScore javadoc. There is a
> suggestion how the algorithm should work (matching number of
> segments).
>   
Right, I saw that. I guess some kind of documentation is needed that 
will vaguely describe what numbers are expected. I was also thinking 
about the name. The score is my thinking more about precedence then 
about compatibility (though after some more thinking I understand the 
term). What do you think about PrecedenceScore?

>> * When I look at ThreadsafeCompoundRequestMapper I am a (little) bit worried
>> about performance. The main worry is that methods are called multiple times
>> for the same request. For example method getCompatibilityScore of the nested
>> RequestMappers is called in both map(Request) as in getCompatibilityScore. A
>> request mapper can not simultaneously calculate a map and a compatibility
>> score precluding some optimizations.
>>     
> Premature optimizations most probably. Unless you have thousands of
> mount points. Also, implementation wise compatibility score
> can be completely independent to request decoding.
> Nevertheless should this become a bottleneck (which i think is highly
> unlikely)  we can cache
> the compatibility score during request in RequestCycle metadata.
>   
Yes, very true.

Regards,
     Erik.

-- 
Erik van Oosten
http://www.day-to-day-stuff.blogspot.com/


Mime
View raw message