search

coduo / TuTu

Flexible HTTP server mocking tool in PHP. TuTu can work with built-in php server so everything that you need to use is php.
MIT License
58 stars 10 forks source link

Replaced routing with matching policy service #7

Closed norberttech closed 10 years ago

norberttech commented 10 years ago

I know that this code removes almost everything from #6, sorry for that. It was not my intention to waste your work @defrag. I have a strange feeling that Routing component (which is great) does not fit here. Its because we have only one action that build request so ewerything thing that we need is to match Request to ResponseConfig. Right now matching is done in MatchingPolicy chain that holds smaller matching policies. This gives us possibility to add new matching policies via extensions. I'm open to any suggestions about this PR.

defrag commented 10 years ago

Umm, tbh i dont like this solution. I think its reinventing the wheel. The chain matching policy makes not too much sense for me. It has too loop through every response and return true at the end. TuTu is and app, which has routes. I dont see why cant we use RoutingCollection. Routing collection is routing and serving the ResponseConfig. Maybe the idea of response config is not that good as initially thought.

norberttech commented 10 years ago

Actually looping through every single route is what UrlMatcher internal does (but UrlMatcher use compiled routes collection. It also need to compile every single route) so I dont know how looping through each ResponseConfig (it's not a response yet, its just a configuration) can be a problem? In my opinion simple, separated, testable request matching rules are good here. Its just like with DI, we could use symfony di component but it would be a overkill for our needs. All we need atm is to check if ResponseConfiguration fits specific Request and pass this configuration into ResponseBuilder. If there is third part lib that can do it we can use it but symfony routing seems to be too big for me. But maybe somebody else have something to say in this case? @l3l0, @jakzal I would love to read your opinions about this PR.

norberttech commented 10 years ago

Jus too explain why do I think that matching policy is better that current solution:

Why do I think that symfony/routing is too much here? Becase routing in my opinion is responsible for routing requestes into controllers/actions that can generate responses from request. This project does not have controllers instead of that there is a builder that build Response from ResponseConfiguration and everything that we rly need is to check if there is a Response configuration for specific request.

If there is something more that can be done here or if there is a better way to handle our use case I would love to read about it.

defrag commented 10 years ago

I can see that this implementation is good if we dont want to tied ourself to routing component. I think the routing is responsible for matching requests and poining them to somewhere. So tbh, both solutions are ok for me. I just though if we will need for example requirements for path placeholders, we will be reinventing the wheel again. It might happen that its gonna be needed at some point. But i can see that the route compiling might be too heave for simple app that just stub api responses.