Scopes

[leevigraham]

In costimator we had:

• Request scope
• Query scope

I think these kinda worked well in practice but still seemed a bit hacky. I'm not sure how to improve on them though.

IMO the goals of any web app with a scope / context hierarchy should be:

• Browsing resources automatically filtered by scope and then filtered by search criteria
• The ability to view all your relationships at the highest level

Probably best if I provide an example in the real world:

As a user I want to see all my todos (resource) across all projects (scopes) to gauge my list. I probably don't want to go into each project and checkout the todo lists individually. I probably want to see them all in one spot. However if I'm focussing on a specific project then I probably just ant to see the projects todos.

Basecamp Classic provides two different UI's for project todo lists and the users todo lists across all projects. Basecamp has an "everything page" with sub pages for each of the collections of resources.

Jira is a bit weird as well probably for legacy reasons. They have a project issues page with an overview and stats (not bad) which links to a global issue page already fitlered.

A third scope we have to consider is system admins that see everything.

---

My initial thoughts were to have a switch context route which would take the new context and save it to the users session then everything would be magically scoped. I don't really like the approach as it makes all links un-shareable because each user will have their own scope saved to the session.

An example from costimator:

http://beta.costimator.com.au/vg-1/venue-departments could also be referred to as: http://beta.costimator.com.au/venue-departments?requestScope=vg-1

There is also an issue with scopes in the urls when it comes to editing a resource that also defines a scope:

http://beta.costimator.com.au/vg-1/venue-groups/1/edit should really be http://beta.costimator.com.au/vg-1/edit or http://beta.costimator.com.au/venue-groups/1/edit

Im sure we could work around this with slightly more complex routing rules:

• /venue-groups -> Browse Venue Groups
• /venue-groups/1 -> Read Venue Group
• /venue-groups/1/edit -> Edit Venue Group
• /venue-groups/1/venue-departments -> Browse Venue Departments with scope set to Venue Group 1.
• /distributor-groups/1/venue-departments -> Browse Venue Departments with scope set to Distributor Group 1.
• /admin/venue-departments -> Browse Venue Departments with scope set to Distributor Group 1.

The last two routes could possibly be defined as:

venue_departments:
    path:     /{scope}/venue-departments
    defaults: { _controller: AcmeDemoBundle:VenueDepartments:browse }
    requirements:
        scope: (admin|(distributor-groups|venue-groups)/\d+)

{scope} in the case above would be admin, venue-groups/1 or distributor-groups/1 Still this would always require a scope in the URL which wasn't a problem for sub resources. It could still be a problem for editing a resource that also defines a scope.

How can the issue of scopes be resolved?

// @iainsaxon @ianbelcher

[leevigraham]

http://brentertainment.com/2012/02/28/contextualizing-your-symfony2-application-with-the-service-container/

[leevigraham]

We could consider changing the template based on a listener:

• http://stackoverflow.com/a/11939369/1982031
• http://stackoverflow.com/a/12403233/1982031

[leevigraham]

We could also consider fully customisable routes with expressions: http://symfony.com/doc/current/book/routing.html#completely-customized-route-matching-with-conditions

[leevigraham]

We could also consider prefixes with placeholders:

http://stackoverflow.com/questions/10366763/is-this-possible-to-have-placeholder-in-routes-prefix