Having this gigantic switch looks not-nice to me. Can't we do something else? Values / handlers at specific keys?

Comments

aspilicious’s picture

aspilicious commented

Well for each "case" you would need a new handler. That means going from 1 handler to 17 or more.

aspilicious’s picture

aspilicious commented
Status: Active » Closed (works as designed)

Ok chx an I talked on irc, he didn't knew how the context caching worked. So I explained him that after the first handler call the value gets saved/cached.

He told me I could close this as "works as designed now :)"

chx’s picture

chx commented
Status: Closed (works as designed) » Active

There actually are more questions, mostly as a parting shot as I am leaving -- if such a switch is ok then why do we have path:raw and path:system handlers instead of path? Especially that path:system call path:raw anyways.

And, if all we had were handlers on the top then we could perhaps significantly simplify findValue. And, who knows, make a different API , like $context->http('query:foo') and $context->path('raw')... perhaps.

Crell’s picture

Crell commented

Originally we had to fold all of the http handlers into a single object to share the request object without duplicating it. There was no way around that. After we switched to the closure-based registration, it is now possible to split the handler up if we wanted to since we can pass the same request object into all of them. Whether or not that's a good trade off (fewer switches vs. more objects) I don't know.

As designed in the current API, however, HOW the handlers are broken up is independent of the API to reach them. So we can refactor HandlerHttp and the path handlers even after code freeze if it made sense to do so.

Crell’s picture

Crell commented
Status: Active » Closed (won't fix)

Deprecated by the new Symfony-based approach.