search

newism / symfony2-standard-template

2 stars 5 forks source link

Scopes #24

Open leevigraham opened 10 years ago

leevigraham commented 10 years ago

In costimator we had:

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:

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.

image

image

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.

image

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:

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 commented 10 years ago

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

leevigraham commented 10 years ago

We could consider changing the template based on a listener:

leevigraham commented 10 years ago

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

leevigraham commented 10 years ago

We could also consider prefixes with placeholders:

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