I’m finding over and over again that I often need to modify a controller and using a route to do so helps because I get back button support. But I’m starting to ask the “why do I need a route” just to filter or sort or page an existing controller?
In the simple example below I paginate a list of people (nothing special here). But what I dislike about it is that because I have a route, I need to create a model. The only model that made sense was a simple “page” model as the route was specific to the page you wanted to view.
If creating this “pseudo” model wasn’t bad enough, the entire “responsibility” of the PageRoute is to modify state on another controller (not a good feeling here either). So my question is 2 fold -am I just “doing it wrong” or is the “ember way” to create routes like this even though they simply modify another controller (and have no real state of their own) ?
Could you factor the “things that need to be paged” so that you can cram them each into a generic model object that has the properties necessary for paging? Would that even help?
It still feels strange that I need to create a model for something like this. Assume I only need to page a controller -why would I need to create a model for this? It only modifies state on an existing controller? I just wanted to spur up a discussion about what alternatives to the routing stuff exist / or should be added before a solid 1.0 release of the framework
You could have an action trigger an event that bubbles up to the events hash on the application route. From there just do what you need to do on the whatever controller, no need to have a model that doesn’t do anything.
@toranb I have created a model for my PageRoute and change my pageable controllers state as you did. But for more common, I created a more generic PageRoute as follows: