Matej Knopp wrote:
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.On Sun, Oct 4, 2009 at 3:03 PM, Erik van Oosten <e.vanoos...@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).
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?* 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).
* 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/
