Of course, it could be better to have semantic routes/method names pointing to their related controller methods:
unite GET / unite.:sf_format indexAction unite_new GET /unite/ new.:sf_format newAction unite_create POST / unite.:sf_format createAction unite_edit GET /unite/:id/ edit.:sf_format ... and so on... unite_update PUT /unite/:id.:sf_format unite_delete DELETE /unite/:id.:sf_format unite_show GET /unite/:id.:sf_format unite_object GET /unite/:id/:action.:sf_format unite_collection POST /unite/:action/action.:sf_format On 22 sep, 19:56, "Nicolas A. Bérard-Nault" <[email protected]> wrote: > Hi Florian, > > On 37-01--10 02:59 PM, Florian wrote:> Hi, > > > To my mind, this can be done with the routing framework. > > For the moment ( I think to sf1 RouteCollections ) it has to be > > described explicitly. > > > Take a look at the quick tour: > >http://docs.symfony-reloaded.org/quick_tour/the_controller.html > > > there is no explicit example of the _method parameter however, but you > > can take _format as an example. > > Thank you for your reply, this is exactly what I need. It certainly > would be nice to mention _method in the documentation. > > > > > With the example you gave, it could be done like this: ( look the > > _method parameter ) > > > dummy_xyz_get: > > pattern: /dummy/:a/:b/:c.:_format > > defaults: { _controller: DummyBundle:Dummy:xyzGet, _format: > > html } > > requirements: { _format: (html|xml|json), _method: GET } > > > dummy_xyz_post: > > pattern: /dummy/:a/:b/:c.:_format > > defaults: { _controller: DummyBundle:Dummy:xyzPost, _format: > > html } > > requirements: { _format: (html|xml|json), _method: POST } > > > and so on... > > > Hope it helps! > > > Florian. > > > On 22 sep, 17:16, Nicolas A. B rard-Nault<[email protected]> > > wrote: > > >> Hi, > > >> First of all, forgive me for my lack of clue as my only experience > >> with Symfony has been accumulated by poking around the SF2 sandbox out > >> of curiosity and attraction to such a wonderful way of doing things. > > >> I have REST services and the classic controller seems rather > >> inappropriate for them. I end up with code such as: > > >> class DummyController extends Controller > >> { > >> public function xyzAction($a, $b, $c) > >> { > >> switch ($this->container['request']->getMethod()) > >> { > >> case 'GET': > >> ... > >> break; > >> case 'POST': > >> ... > >> break; > >> case 'PUT': > >> ... > >> break; > >> case 'DELETE': > >> ... > >> break; > >> } > >> } > > >> } > > >> Which seems rather odd. My question is: is there a plan to provide an > >> extended controller to facilitate REST services ? I know it is easily > >> feasible and I would surely volunteer to write that piece of code. My > >> idea is to provide something along the lines of: > > >> class DummyController extends RestController > >> { > >> public function xyzActionGet($a, $b, $c) > >> { > >> } > > >> public function xyzActionPost($a, $b, $c) > >> { > >> } > > >> public function xyzActionPut($a, $b, $c) > >> { > >> } > > >> public function xyzActionDelete($a, $b, $c) > >> { > >> } > > >> } > > >> Does that seem reasonable ? Maybe I am missing something. > > >> Thank you, > >> NABN. -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
