Url management and optional params and default values...

It would be very useful to have (also in the 1.0.x branch maybe), like in the zend framework, optional params in the url pattern with the option to set those optional params initial value in the rule. Also it would be useful to have the possibility to set params in a url route rule that don't come from the url itsenf but from the url route rule that we write

Any examples?

Note that what ZF implements only deals with URL parsing, while Yii deals with both URL parsing and creation.

ZF also deals with url creation. See the url() method

Besides this, perhaps some ideas from Rails can be borrowed regarding routing. I’m especially fond of the resource mapping in rails. Also the sensible default routes:

map.connect ':controller/:action/:id'

map.connect ':controller/:action/:id.:format'

that leave room for change is something I really like.

Quote

Any examples?

Note that what ZF implements only deals with URL parsing, while Yii deals with both URL parsing and creation.

$router->addRoute(


    'home',


    new Zend_Controller_Router_Route('', array('module' => 'default', 'controller' => 'index', 'action' => 'index', 'routegroup' => 'home', 'language' => 1)));
Here i setted two parameters, "routegroup" and "language" that are created when the route rule is applied in additiuon of the params already in the route url

The same can be achieved in Yii using:

'home'=>'default/index/index/routegroup/home/language/1'

Quote

The same can be achieved in Yii using:

'home'=>'default/index/index/routegroup/home/language/1'

so i put those params i want to be created automatically in the route portion of the rule?

Yes.

Quote

Yes.
ok thank you. Anyway it would be nice also to have the possibility to specify default values for optional params in the rule pattern

Quote

The same can be achieved in Yii using:

'home'=>'default/index/index/routegroup/home/language/1'

i tried like that but in that way my rule isn't applied anymore

Could you please create a ticket for this (about specifying default parameters in a URL rule)?

Quote

Could you please create a ticket for this (about specifying default parameters in a URL rule)?
ok i made a ticket. I would like also to see optional parameters in the rule pattern in future version of the framework thanks

Quote

ZF also deals with url creation. See the url() method

Besides this, perhaps some ideas from Rails can be borrowed regarding routing. I’m especially fond of the resource mapping in rails. Also the sensible default routes:

map.connect ':controller/:action/:id'

map.connect ':controller/:action/:id.:format'

that leave room for change is something I really like.

Somehow I overlooked your post. These are wonderful references. I have to say that rails URL management is really powerful.

Could you explain a bit about resource mapping? For default routes, it seems to be the equivalent way in Yii is the following. Correct me if I am wrong. Thanks!

'<controller:\w+>/<action:\w+>/<id:\d+>' => '<controller>/<action>'

Rails by default has the same routing rules as Yii: controller/action/id. Only in Rails it's configurable and can also be left out if you chose to do so. Note that this is only useful if all publicly available pages have rules explicitly made for them.

That's where resource mapping comes in. It gives a REST approach to routing so one url maps to one resource and the action used on the resource.

REST is not all that different from a default scaffolding controller in Yii. Difference is that the right http verb is used for an url. So GET for retrieval, POST for a new record, PUT to update a record and DELETE to delete a record. Since PUT and DELETE are not used by browsers they are emulated in forms by using hidden fields.

One of the pleasures that comes with the resource mapping is you get a bunch of helpers that help you out. So, after you mapped a resource like posts you get a couple of helpers for url generation regarding posts: posts_url(), new_post_url(), edit_post_url($id)

It might not all seem like a big deal but having used it I must say it's a joy.

You might also want to look at http://api.rubyonrai…se.html#M002615 for the ActiveRecord in Yii for it makes for a nice feature.

Thank you for your detailed explanation.

Yes, I did read about the RESTful urls section and thought it is nice. The only problem is how to generate the links that can use such HTTP verbs.

Regarding AR, I actually read through RoR’s AR implementation for reference. ;)

Normal links always use GET in rails. They refer to /posts/new or /post/1/edit, the forms on those pages use a hidden field to emulate POST or PUT. For delete links some javascript is used IIRC

To continue with the Rails REST resources and routing, as it is something that entered Rails and really revolutionized it and is holding me back from embracing Yii:

In the routing table you specify:

map.resources :users

Then you have seven actions in the controller that automatically get called:

/resources = resources_url = index action

/resources/:id => resource_url(resource) = show action

/resources/new => new_resource_url = new action

/resources (POST) => create action

/resources/1/edit => edit_resource_url(resource) = edit action

/resources/1 (PUT) => update action

/resources/1 (DELETE) => link_to("Delete", resource_url, :method => :delete) = destroy action

The POST and PUT are managed automatically by forms:

@user = User.new

form_for @user do |f|

This detects that the user is a new record and makes the form POST to the resources controller.

@user = User.find(params[:id])

form_for @user do |f|

This detects that the user is an existing record and makes the form PUT to the resources controller. It adds a hidden input named "_method" with a value of "put".

In the same way, link_to("Create instant user", users_path, :method => :post) would create a link that uses javascript to create a form and post it to the specified url.

It enforces some standards in the controller in that you have standardized names for CRUD actions. You can add actions and map them to methods quite easily:

map.resources :user, :member => [:activate => :get]

You can nest resources without headaches:

map.resources :user, :has_many => :posts

Then your posts controller can be invoked:

user_posts_url(user) = /users/:user_id/posts

Then in the controller you know if the posts action was executed in context of user nesting or not by presence of params[:user_id]. You can add before filters to load the user, etc.

Or do you have an admin user controller separate from the main user controller?

map.namespace :admin do |admin|

admin.resources :user

end

Then in the form, you want it to post to the correct controller:

form_for [:admin, @user] do |f|

f.input :username

f.input :first_name

Since the controller’s action names are specified, you can mix in a plugin such as resource_controller or resource_this, or extend a base controller with predefined rest actions, and the CRUD is taken care of. That leaves the views, which take care of themselves if you use the form builder, create your own form builder, or use a plugin like FormTastic.

Hope this is useful, perhaps too much at once. REST is a concept that at first may seem like "why do you need to do that, just define your actions, use the scaffolding" or whatever, but once you learn and use, makes other way feel inefficient and primitive.