il "router" (anche se è improprio chiamarlo così) serve a centralizzare la logica degli eventi e degli stati dei widgets, ed a creare le url internamente con un meccanismo simile alle named-routes (ti dico la route, ti passo i parametri e mi costruisci il link).
Serve anche a personalizzare completamente le uri.. es: non ti piace la query string? usa le uri (anche scavalcando il router di laravel)
funziona così:

• gira prima di quello di laravel, il dispatch viene fatto nel service provider, non fà redirect e non è bloccante: anche piu' di una route puo' essere verificata es. http://www.rapyd.com/rapyd-demo/grid?ord=-author_id&page=2 ne matcha/esegue 2.
• fa un match fra http method, uri e query string, nel caso si verifichi il match esegue la closure..
• la closure viene usata per fare queue di eventi relativi ai widget, usando la Event di laravel (Mi piacerebbe creare una piccola classe event mia per fare esperienza, ma va bene così.)

obiettivo attuale..

• fare named route, obbligatoriamente (per poterle lavorare nei widget devono avere un nome)
• il terzo parametro potenzialmente deve poter essere solo la closure da eseguire (per compatibilità con il router di laravel)

<?php
\Zofe\Rapyd\Router::get(null, 'ciccio=(\d+)',  function($x) {
    die('hai richiesto ?ciccio='.$x);
}));

• deve essere possibile definire una route con un array, per semplificare la possibilità di salvarli in un file di configurazione, sovrascrivibile dagli utenti finali es:

<?php
Zofe\Rapyd\Router::route(array(
    'method'=>'patch',
    'qs'=>'update=(\d+)',
    'as'=>'update', 
    'remove'=>array('orderby'), 
   'action'=>function($id) {
    //closure..
}));

• prevedere oltre al ->persist(false); un ->remove(array(named.route1, named.route2)); per permettere la rimozione di uno o più parametri (es. se sto' costruendo il link per fare l'orderby, devo necessariamente resettare la paginazione, e via dicendo).. verificare la possibilità di fare un removeAll()
• i link interni andranno fatti così (già funziona)

<?php
$orderby = Rapyd::linkRoute('orderby', '-', 'title');
// on /rapyd-demo/grid?ord=-id&page=2&custom=3
// will output  /rapyd-demo/grid?custom=3&ord=-title

• spostare la logica degli "sniff action/status" nelle closure :
  al momento nelle closure ho previsto queue di eventi dei vari widget.
  Poi nei widget andranno creati i singoli metodi e i listener, poi al build o nel costruttore.. a seconda dei casi ci và un Event::flush('nomewidget.*') per scatenare gli eventi.

In questo modo si dovrebbe riuscire a fare a meno del controller, e (poichè si usano gli eventi) dovrebbe essere semplice, per chi ne ha la necessità, controllare il comportamento dei widget, e "crearne di nuovi".

problema con paginazione & dataset (come scavalcare il paginator di laravel)
risolto con nel listener:

Paginator::setCurrentPage($pag)

e l'override di link nel dataset

$links = $this->paginator->links($view);
$links = preg_replace('@href="(.*\?page=(\d+))"@U', 
                  'href="'.Rapyd::linkRoute('page', '$2').'"', $links);

sembra funzionare bene tutta la logica.. si dovrebbe fare un handler ma al momento basta:

• creare i metodi nei widget
• fare i listen sul metodo statico principale (source)
• e al build fare il flush/fire degli eventi:

<?php
...

    public function sort($direction, $field)
    {
       ...
    }

    public function page($page)
    {
        \Paginator::setCurrentPage($page);
    }

    public static function source($source)
    {
        $ins = new static();
        $ins->source = $source;

        \Event::listen('dataset.sort', array($ins, 'sort'));
        \Event::listen('dataset.page', array($ins, 'page'));
       ....
     }

    public function build()
    {
        \Event::flush('dataset.sort');
        \Event::flush('dataset.page');
        ....

Limiti:
Ora come ora.. si è limitati comunque all'uso della PK nelle route di CRUD, perchè il "find" dei record viene appunto fatto su id.

Laravel di suo ha una roba potentissima che è il Route model binding, http://laravel.com/docs/4.2/routing#route-model-binding
per fare DI del model, definendo eventualmente il modo con cui viene caricato model.
Si puo' trovare un modo di sfruttarlo?

https://github.com/zofe/burp