Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrate routing to Symfony #465

Closed
20 tasks done
Guite opened this issue Jan 15, 2014 · 6 comments
Closed
20 tasks done

Migrate routing to Symfony #465

Guite opened this issue Jan 15, 2014 · 6 comments
Assignees
Milestone

Comments

@Guite
Copy link
Owner

Guite commented Jan 15, 2014

Currently the generator uses a custom Routing class. This should be changed in order to support routing by Symfony2.
Also the handling of different output formats should be updated to use the mechanism Symfony offers for this.

  • Move old short urls to legacy classes
  • Generate routing configuration file
  • Update changelog and user manual
  • Rearrange controller organisation to avoid ambigious routes (see below)

Structural problems in the generator which should be cleaned up in the same step:

  • currently there are three routes for display methods because it is generic for all object types. specifically there are routes for 1. id without slug, 2. non-unique slug combined with id and 3. a unique slug.
  • the default controller actions (view, display, edit, delete) are generically designed for multiple object types. To get cleaner and non-ambigious routes this should be changed.

Approach for reorganisation:

  • One controller for each entity → PersonController, AddressController etc.
  • Also for 1.3.x to keep the gap as small as possible
  • Update legacy routes

Advantages:

  • Controller actions become smaller, since several code parts are not relevant for all entities.
  • One can override stuff more precisely.
  • @paramconverter is possible.

Cleanup:

  • Check usermenu
  • Admin and user controller: redirect to controller for corresponding object type
  • Admin area of an object: with lct=admin (legacy controller type) in the query string
  • The theme parameter is not being added to any routes, but assigned as additional parameter so that it becomes part of the query string instead of the route itself
  • Unify templates; check for lct inside the templates (pathes like: Resources/views/Post/display.tpl)
  • Customise form handler structure accordingly
  • Bugfixing 1.3.x

Add new routing support:

  • Generate the actual route annotations
  • Outsource configurable parts into container parameters (for example: plural names used as "url folders", supported formats)
  • Update handling of different output formats (based on the _format parameter, remove helper plugin for setting the content type)
  • Remove unrequired code in entity-related controller actions
    Examples for cleaned signatures:
  • PostController#displayAction($id)
  • PostController#displayAction($slug)
  • PostController#displayAction($id, $slug = '')
  • Update url generation in code to Symfony style
  • Bugfixing 1.4.x
@ghost ghost assigned Guite Jan 15, 2014
@cmfcmf
Copy link
Contributor

cmfcmf commented Jan 16, 2014

As you already labelled it, this should wait until routing in the core is more finalised. Currently routing is in a state where it could all change from day to day.

@Guite
Copy link
Owner Author

Guite commented Mar 15, 2014

@cmfcmf @craigh Is this still blocked? I've seen several modules using the route annotation already.

@craigh
Copy link

craigh commented Mar 15, 2014

I've used it in two modules, but I'm not sure about it's finalization yet. I'm just hoping that if @cmfcmf changes it, that it won't be too hard to adjust what I have.

@cmfcmf
Copy link
Contributor

cmfcmf commented Mar 17, 2014

@cmfcmf @craigh Is this still blocked? I've seen several modules using the route annotation already.

It's true what @craigh says. It might be necessary to adjust the implementation later on. But I think you can give it a try @Guite.

@Guite Guite added upcoming and removed blocked labels Mar 17, 2014
@ghost
Copy link

ghost commented Apr 24, 2014

It's important to realise there is no longer any need to follow the whole module, type, func format anymore. There should only be one route to any resource so index.php?id=1 and index/1 should not really be allowed or possible. I am not entirely sure &theme= is something we need to maintain any more. This was a frankly terrible hack and the intention is to deprecate it entirely. The main use for this was to output RSS or XML (and it was a terrible implementation) and there is no evidence of wide use or need for "user skins". Symfony handles display of content in other formats like this http://symfony.com/doc/current/book/templating.html#template-formats

So basically a module can publish any routes it likes and we just need a convention so as not to collide.

@Guite
Copy link
Owner Author

Guite commented Apr 26, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants