Rails Routing from the Outside In¶ ↑
This guide covers the user-facing features of Rails routing.
After reading this guide, you will know:
-
How to interpret the code in
routes.rb
. -
How to construct your own routes, using either the preferred resourceful style or the
match
method. -
What parameters to expect an action to receive.
-
How to automatically create paths and URLs using route helpers.
-
Advanced techniques such as constraints and Rack endpoints.
The Purpose of the Rails Router¶ ↑
The Rails router recognizes URLs and dispatches them to a controller's action. It can also generate paths and URLs, avoiding the need to hardcode strings in your views.
Connecting URLs to Code¶ ↑
When your Rails application receives an incoming request for:
GET /patients/17
it asks the router to match it to a controller action. If the first matching route is:
get '/patients/:id', to: 'patients#show'
the request is dispatched to the patients
controller's
show
action with { id: '17' }
in
params
.
Generating Paths and URLs from Code¶ ↑
You can also generate paths and URLs. If the route above is modified to be:
get '/patients/:id', to: 'patients#show', as: 'patient'
and your application contains this code in the controller:
@patient = Patient.find(17)
and this in the corresponding view:
<%= link_to 'Patient Record', patient_path(@patient) %>
then the router will generate the path /patients/17
. This
reduces the brittleness of your view and makes your code easier to
understand. Note that the id does not need to be specified in the route
helper.
Resource Routing: the Rails Default¶ ↑
Resource routing allows you to quickly declare all of the common routes for
a given resourceful controller. Instead of declaring separate routes for
your index
, show
, new
,
edit
, create
, update
and
destroy
actions, a resourceful route declares them in a single
line of code.
Resources on the Web¶ ↑
Browsers request pages from Rails by making a request for a URL using a
specific HTTP method, such as GET
, POST
,
PATCH
, PUT
and DELETE
. Each method
is a request to perform an operation on the resource. A resource route maps
a number of related requests to actions in a single controller.
When your Rails application receives an incoming request for:
DELETE /photos/17
it asks the router to map it to a controller action. If the first matching route is:
resources :photos
Rails would dispatch that request to the destroy
method on the
photos
controller with { id: '17' }
in
params
.
CRUD, Verbs, and Actions¶ ↑
In Rails, a resourceful route provides a mapping between HTTP verbs and URLs to controller actions. By convention, each action also maps to particular CRUD operations in a database. A single entry in the routing file, such as:
resources :photos
creates seven different routes in your application, all mapping to the
Photos
controller:
| HTTP Verb | Path | Controller#Action | Used for | | ——— | —————- | —————– | ——————————————– | | GET | /photos | photos#index | display a list of all photos | | GET | /photos/new | photos#new | return an HTML form for creating a new photo | | POST | /photos | photos#create | create a new photo | | GET | /photos/:id | photos#show | display a specific photo | | GET | /photos/:id/edit | photos#edit | return an HTML form for editing a photo | | PATCH/PUT | /photos/:id | photos#update | update a specific photo | | DELETE | /photos/:id | photos#destroy | delete a specific photo |
NOTE: Because the router uses the HTTP verb and URL to match inbound requests, four URLs map to seven different actions.
NOTE: Rails routes are matched in the order they are specified, so if you
have a resources :photos
above a get
'photos/poll'
the show
action's route for
the resources
line will be matched before the get
line. To fix this, move the get
line above
the resources
line so that it is matched first.
Path and URL Helpers¶ ↑
Creating a resourceful route will also expose a number of helpers to the
controllers in your application. In the case of resources
:photos
:
-
photos_path
returns/photos
-
new_photo_path
returns/photos/new
-
edit_photo_path(:id)
returns/photos/:id/edit
(for instance,edit_photo_path(10)
returns/photos/10/edit
) -
photo_path(:id)
returns/photos/:id
(for instance,photo_path(10)
returns/photos/10
)
Each of these helpers has a corresponding _url
helper (such as
photos_url
) which returns the same path prefixed with the
current host, port and path prefix.
Defining Multiple Resources at the Same Time¶ ↑
If you need to create routes for more than one resource, you can save a bit
of typing by defining them all with a single call to
resources
:
resources :photos, :books, :videos
This works exactly the same as:
resources :photos resources :books resources :videos
Singular Resources¶ ↑
Sometimes, you have a resource that clients always look up without
referencing an ID. For example, you would like /profile
to
always show the profile of the currently logged in user. In this case, you
can use a singular resource to map /profile
(rather than
/profile/:id
) to the show
action:
get 'profile', to: 'users#show'
Passing a String
to get
will expect a
controller#action
format, while passing a Symbol
will map directly to an action:
get 'profile', to: :show
This resourceful route:
resource :geocoder
creates six different routes in your application, all mapping to the
Geocoders
controller:
| HTTP Verb | Path | Controller#Action | Used for | | ——— | ————– | —————– | ——————————————— | | GET | /geocoder/new | geocoders#new | return an HTML form for creating the geocoder | | POST | /geocoder | geocoders#create | create the new geocoder | | GET | /geocoder | geocoders#show | display the one and only geocoder resource | | GET | /geocoder/edit | geocoders#edit | return an HTML form for editing the geocoder | | PATCH/PUT | /geocoder | geocoders#update | update the one and only geocoder resource | | DELETE | /geocoder | geocoders#destroy | delete the geocoder resource |
NOTE: Because you might want to use the same controller for a singular
route (/account
) and a plural route
(/accounts/45
), singular resources map to plural controllers.
So that, for example, resource :photo
and resources
:photos
creates both singular and plural routes that map to the same
controller (PhotosController
).
A singular resourceful route generates these helpers:
-
new_geocoder_path
returns/geocoder/new
-
edit_geocoder_path
returns/geocoder/edit
-
geocoder_path
returns/geocoder
As with plural resources, the same helpers ending in _url
will
also include the host, port and path prefix.
WARNING: A long-standing bug
prevents form_for
from working automatically with singular
resources. As a workaround, specify the URL for the form directly, like so:
form_for @geocoder, url: geocoder_path do |f|
Controller Namespaces and Routing¶ ↑
You may wish to organize groups of controllers under a namespace. Most
commonly, you might group a number of administrative controllers under an
Admin::
namespace. You would place these controllers under the
app/controllers/admin
directory, and you can group them
together in your router:
namespace :admin do resources :articles, :comments end
This will create a number of routes for each of the articles
and comments
controller. For
Admin::ArticlesController
, Rails will create:
| HTTP Verb | Path | Controller#Action | Named Helper | | ——— | ———————— | ———————- | —————————- | | GET | /admin/articles | admin/articles#index | admin_articles_path | | GET | /admin/articles/new | admin/articles#new | new_admin_article_path | | POST | /admin/articles | admin/articles#create | admin_articles_path | | GET | /admin/articles/:id | admin/articles#show | admin_article_path(:id) | | GET | /admin/articles/:id/edit | admin/articles#edit | edit_admin_article_path(:id) | | PATCH/PUT | /admin/articles/:id | admin/articles#update | admin_article_path(:id) | | DELETE | /admin/articles/:id | admin/articles#destroy | admin_article_path(:id) |
If you want to route /articles
(without the prefix
/admin
) to Admin::ArticlesController
, you could
use:
scope module: 'admin' do resources :articles, :comments end
or, for a single case:
resources :articles, module: 'admin'
If you want to route /admin/articles
to
ArticlesController
(without the Admin::
module
prefix), you could use:
scope '/admin' do resources :articles, :comments end
or, for a single case:
resources :articles, path: '/admin/articles'
In each of these cases, the named routes remain the same as if you did not
use scope
. In the last case, the following paths map to
ArticlesController
:
| HTTP Verb | Path | Controller#Action | Named Helper | | ——— | ———————— | ——————– | ———————- | | GET | /admin/articles | articles#index | articles_path | | GET | /admin/articles/new | articles#new | new_article_path | | POST | /admin/articles | articles#create | articles_path | | GET | /admin/articles/:id | articles#show | article_path(:id) | | GET | /admin/articles/:id/edit | articles#edit | edit_article_path(:id) | | PATCH/PUT | /admin/articles/:id | articles#update | article_path(:id) | | DELETE | /admin/articles/:id | articles#destroy | article_path(:id) |
TIP: If you need to use a different controller namespace inside a
namespace
block you can specify an absolute controller path,
e.g: get '/foo' => '/foo#index'
.
Nested Resources¶ ↑
It's common to have resources that are logically children of other resources. For example, suppose your application includes these models:
class Magazine < ActiveRecord::Base has_many :ads end class Ad < ActiveRecord::Base belongs_to :magazine end
Nested routes allow you to capture this relationship in your routing. In this case, you could include this route declaration:
resources :magazines do resources :ads end
In addition to the routes for magazines, this declaration will also route
ads to an AdsController
. The ad URLs require a magazine:
| HTTP Verb | Path | Controller#Action | Used for | | ——— | ———————————— | —————– | ————————————————————————– | | GET | /magazines/:magazine_id/ads | ads#index | display a list of all ads for a specific magazine | | GET | /magazines/:magazine_id/ads/new | ads#new | return an HTML form for creating a new ad belonging to a specific magazine | | POST | /magazines/:magazine_id/ads | ads#create | create a new ad belonging to a specific magazine | | GET | /magazines/:magazine_id/ads/:id | ads#show | display a specific ad belonging to a specific magazine | | GET | /magazines/:magazine_id/ads/:id/edit | ads#edit | return an HTML form for editing an ad belonging to a specific magazine | | PATCH/PUT | /magazines/:magazine_id/ads/:id | ads#update | update a specific ad belonging to a specific magazine | | DELETE | /magazines/:magazine_id/ads/:id | ads#destroy | delete a specific ad belonging to a specific magazine |
This will also create routing helpers such as magazine_ads_url
and edit_magazine_ad_path
. These helpers take an instance of
Magazine as the first parameter (magazine_ads_url(@magazine)
).
Limits to Nesting¶ ↑
You can nest resources within other nested resources if you like. For example:
resources :publishers do resources :magazines do resources :photos end end
Deeply-nested resources quickly become cumbersome. In this case, for example, the application would recognize paths such as:
/publishers/1/magazines/2/photos/3
The corresponding route helper would be
publisher_magazine_photo_url
, requiring you to specify objects
at all three levels. Indeed, this situation is confusing enough that a
popular article
by Jamis Buck proposes a rule of thumb for good Rails design:
TIP: Resources should never be nested more than 1 level deep.
Shallow Nesting¶ ↑
One way to avoid deep nesting (as recommended above) is to generate the collection actions scoped under the parent, so as to get a sense of the hierarchy, but to not nest the member actions. In other words, to only build routes with the minimal amount of information to uniquely identify the resource, like this:
resources :articles do resources :comments, only: [:index, :new, :create] end resources :comments, only: [:show, :edit, :update, :destroy]
This idea strikes a balance between descriptive routes and deep nesting.
There exists shorthand syntax to achieve just that, via the
:shallow
option:
resources :articles do resources :comments, shallow: true end
This will generate the exact same routes as the first example. You can also
specify the :shallow
option in the parent resource, in which
case all of the nested resources will be shallow:
resources :articles, shallow: true do resources :comments resources :quotes resources :drafts end
The shallow
method of the DSL creates a scope inside of which
every nesting is shallow. This generates the same routes as the previous
example:
shallow do resources :articles do resources :comments resources :quotes resources :drafts end end
There exist two options for scope
to customize shallow routes.
:shallow_path
prefixes member paths with the specified
parameter:
scope shallow_path: "sekret" do resources :articles do resources :comments, shallow: true end end
The comments resource here will have the following routes generated for it:
| HTTP Verb | Path | Controller#Action | Named Helper | | ——— | ——————————————– | —————– | ———————— | | GET | /articles/:article_id/comments(.:format) | comments#index | article_comments_path | | POST | /articles/:article_id/comments(.:format) | comments#create | article_comments_path | | GET | /articles/:article_id/comments/new(.:format) | comments#new | new_article_comment_path | | GET | /sekret/comments/:id/edit(.:format) | comments#edit | edit_comment_path | | GET | /sekret/comments/:id(.:format) | comments#show | comment_path | | PATCH/PUT | /sekret/comments/:id(.:format) | comments#update | comment_path | | DELETE | /sekret/comments/:id(.:format) | comments#destroy | comment_path |
The :shallow_prefix
option adds the specified parameter to the
named helpers:
scope shallow_prefix: "sekret" do resources :articles do resources :comments, shallow: true end end
The comments resource here will have the following routes generated for it:
| HTTP Verb | Path | Controller#Action | Named Helper | | ——— | ——————————————– | —————– | ————————— | | GET | /articles/:article_id/comments(.:format) | comments#index | article_comments_path | | POST | /articles/:article_id/comments(.:format) | comments#create | article_comments_path | | GET | /articles/:article_id/comments/new(.:format) | comments#new | new_article_comment_path | | GET | /comments/:id/edit(.:format) | comments#edit | edit_sekret_comment_path | | GET | /comments/:id(.:format) | comments#show | sekret_comment_path | | PATCH/PUT | /comments/:id(.:format) | comments#update | sekret_comment_path | | DELETE | /comments/:id(.:format) | comments#destroy | sekret_comment_path |
Routing concerns¶ ↑
Routing Concerns allows you to declare common routes that can be reused inside other resources and routes. To define a concern:
concern :commentable do resources :comments end concern :image_attachable do resources :images, only: :index end
These concerns can be used in resources to avoid code duplication and share behavior across routes:
resources :messages, concerns: :commentable resources :articles, concerns: [:commentable, :image_attachable]
The above is equivalent to:
resources :messages do resources :comments end resources :articles do resources :comments resources :images, only: :index end
Also you can use them in any place that you want inside the routes, for example in a scope or namespace call:
namespace :articles do concerns :commentable end
Creating Paths and URLs From Objects¶ ↑
In addition to using the routing helpers, Rails can also create paths and URLs from an array of parameters. For example, suppose you have this set of routes:
resources :magazines do resources :ads end
When using magazine_ad_path
, you can pass in instances of
Magazine
and Ad
instead of the numeric IDs:
<%= link_to 'Ad details', magazine_ad_path(@magazine, @ad) %>
You can also use url_for
with a set of objects, and Rails will
automatically determine which route you want:
<%= link_to 'Ad details', url_for([@magazine, @ad]) %>
In this case, Rails will see that @magazine
is a
Magazine
and @ad
is an Ad
and will
therefore use the magazine_ad_path
helper. In helpers like
link_to
, you can specify just the object in place of the full
url_for
call:
<%= link_to 'Ad details', [@magazine, @ad] %>
If you wanted to link to just a magazine:
<%= link_to 'Magazine details', @magazine %>
For other actions, you just need to insert the action name as the first element of the array:
<%= link_to 'Edit Ad', [:edit, @magazine, @ad] %>
This allows you to treat instances of your models as URLs, and is a key advantage to using the resourceful style.
Adding More RESTful Actions¶ ↑
You are not limited to the seven routes that RESTful routing creates by default. If you like, you may add additional routes that apply to the collection or individual members of the collection.
Adding Member Routes¶ ↑
To add a member route, just add a member
block into the
resource block:
resources :photos do member do get 'preview' end end
This will recognize /photos/1/preview
with GET, and route to
the preview
action of PhotosController
, with the
resource id value passed in params[:id]
. It will also create
the preview_photo_url
and preview_photo_path
helpers.
Within the block of member routes, each route name specifies the HTTP verb
will be recognized. You can use get
, patch
,
put
, post
, or delete
here . If you
don't have multiple member
routes, you can also pass
:on
to a route, eliminating the block:
resources :photos do get 'preview', on: :member end
You can leave out the :on
option, this will create the same
member route except that the resource id value will be available in
params[:photo_id]
instead of params[:id]
.
Adding Collection Routes¶ ↑
To add a route to the collection:
resources :photos do collection do get 'search' end end
This will enable Rails to recognize paths such as
/photos/search
with GET, and route to the search
action of PhotosController
. It will also create the
search_photos_url
and search_photos_path
route
helpers.
Just as with member routes, you can pass :on
to a route:
resources :photos do get 'search', on: :collection end
Adding Routes for Additional New Actions¶ ↑
To add an alternate new action using the :on
shortcut:
resources :comments do get 'preview', on: :new end
This will enable Rails to recognize paths such as
/comments/new/preview
with GET, and route to the
preview
action of CommentsController
. It will
also create the preview_new_comment_url
and
preview_new_comment_path
route helpers.
TIP: If you find yourself adding many extra actions to a resourceful route, it's time to stop and ask yourself whether you're disguising the presence of another resource.
Non-Resourceful Routes¶ ↑
In addition to resource routing, Rails has powerful support for routing arbitrary URLs to actions. Here, you don't get groups of routes automatically generated by resourceful routing. Instead, you set up each route within your application separately.
While you should usually use resourceful routing, there are still many places where the simpler routing is more appropriate. There's no need to try to shoehorn every last piece of your application into a resourceful framework if that's not a good fit.
In particular, simple routing makes it very easy to map legacy URLs to new Rails actions.
Bound Parameters¶ ↑
When you set up a regular route, you supply a series of symbols that Rails
maps to parts of an incoming HTTP request. Two of these symbols are
special: :controller
maps to the name of a controller in your
application, and :action
maps to the name of an action within
that controller. For example, consider this route:
get ':controller(/:action(/:id))'
If an incoming request of /photos/show/1
is processed by this
route (because it hasn't matched any previous route in the file), then
the result will be to invoke the show
action of the
PhotosController
, and to make the final parameter
"1"
available as params[:id]
. This
route will also route the incoming request of /photos
to
PhotosController#index
, since :action
and
:id
are optional parameters, denoted by parentheses.
Dynamic Segments¶ ↑
You can set up as many dynamic segments within a regular route as you like.
Anything other than :controller
or :action
will
be available to the action as part of params
. If you set up
this route:
get ':controller/:action/:id/:user_id'
An incoming path of /photos/show/1/2
will be dispatched to the
show
action of the PhotosController
.
params[:id]
will be "1"
, and
params[:user_id]
will be "2"
.
NOTE: You can't use :namespace
or :module
with a :controller
path segment. If you need to do this then
use a constraint on :controller that matches the namespace you require.
e.g:
get ':controller(/:action(/:id))', controller: /admin\/[^\/]+/
TIP: By default, dynamic segments don't accept dots - this is because
the dot is used as a separator for formatted routes. If you need to use a
dot within a dynamic segment, add a constraint that overrides this – for
example, id: /[^\/]+/
allows anything except a slash.
Static Segments¶ ↑
You can specify static segments when creating a route by not prepending a colon to a fragment:
get ':controller/:action/:id/with_user/:user_id'
This route would respond to paths such as
/photos/show/1/with_user/2
. In this case, params
would be { controller: 'photos', action: 'show', id:
'1', user_id: '2' }
.
The Query String¶ ↑
The params
will also include any parameters from the query
string. For example, with this route:
get ':controller/:action/:id'
An incoming path of /photos/show/1?user_id=2
will be
dispatched to the show
action of the Photos
controller. params
will be { controller:
'photos', action: 'show', id: '1', user_id:
'2' }
.
Defining Defaults¶ ↑
You do not need to explicitly use the :controller
and
:action
symbols within a route. You can supply them as
defaults:
get 'photos/:id', to: 'photos#show'
With this route, Rails will match an incoming path of
/photos/12
to the show
action of
PhotosController
.
You can also define other defaults in a route by supplying a hash for the
:defaults
option. This even applies to parameters that you do
not specify as dynamic segments. For example:
get 'photos/:id', to: 'photos#show', defaults: { format: 'jpg' }
Rails would match photos/12
to the show
action of
PhotosController
, and set params[:format]
to
"jpg"
.
NOTE: You cannot override defaults via query parameters - this is for security reasons. The only defaults that can be overridden are dynamic segments via substitution in the URL path.
Naming Routes¶ ↑
You can specify a name for any route using the :as
option:
get 'exit', to: 'sessions#destroy', as: :logout
This will create logout_path
and logout_url
as
named helpers in your application. Calling logout_path
will
return /exit
You can also use this to override routing methods defined by resources, like this:
get ':username', to: 'users#show', as: :user
This will define a user_path
method that will be available in
controllers, helpers and views that will go to a route such as
/bob
. Inside the show
action of
UsersController
, params[:username]
will contain
the username for the user. Change :username
in the route
definition if you do not want your parameter name to be
:username
.
HTTP Verb Constraints¶ ↑
In general, you should use the get
, post
,
put
, patch
and delete
methods to
constrain a route to a particular verb. You can use the match
method with the :via
option to match multiple verbs at once:
match 'photos', to: 'photos#show', via: [:get, :post]
You can match all verbs to a particular route using via: :all
:
match 'photos', to: 'photos#show', via: :all
NOTE: Routing both GET
and POST
requests to a
single action has security implications. In general, you should avoid
routing all verbs to an action unless you have a good reason to.
NOTE: 'GET' in Rails won't check for CSRF token. You should never write to the database from 'GET' requests, for more information see the security guide on CSRF countermeasures.
Segment Constraints¶ ↑
You can use the :constraints
option to enforce a format for a
dynamic segment:
get 'photos/:id', to: 'photos#show', constraints: { id: /[A-Z]\d{5}/ }
This route would match paths such as /photos/A12345
, but not
/photos/893
. You can more succinctly express the same route
this way:
get 'photos/:id', to: 'photos#show', id: /[A-Z]\d{5}/
:constraints
takes regular expressions with the restriction
that regexp anchors can't be used. For example, the following route
will not work:
get '/:id', to: 'articles#show', constraints: { id: /^\d/ }
However, note that you don't need to use anchors because all routes are anchored at the start.
For example, the following routes would allow for articles
with to_param
values like 1-hello-world
that
always begin with a number and users
with
to_param
values like david
that never begin with
a number to share the root namespace:
get '/:id', to: 'articles#show', constraints: { id: /\d.+/ } get '/:username', to: 'users#show'
Request-Based Constraints¶ ↑
You can also constrain a route based on any method on the Request
object that returns a String
.
You specify a request-based constraint the same way that you specify a segment constraint:
get 'photos', to: 'photos#index', constraints: { subdomain: 'admin' }
You can also specify constraints in a block form:
namespace :admin do constraints subdomain: 'admin' do resources :photos end end
NOTE: Request constraints work by calling a method on the Request
object with the same name as the hash key and then compare the return
value with the hash value. Therefore, constraint values should match the
corresponding Request object method return type. For example:
constraints: { subdomain: 'api' }
will match an
api
subdomain as expected, however using a symbol
constraints: { subdomain: :api }
will not, because
request.subdomain
returns 'api'
as a
String.
Advanced Constraints¶ ↑
If you have a more advanced constraint, you can provide an object that
responds to matches?
that Rails should use. Let's say you
wanted to route all users on a blacklist to the
BlacklistController
. You could do:
class BlacklistConstraint def initialize @ips = Blacklist.retrieve_ips end def matches?(request) @ips.include?(request.remote_ip) end end Rails.application.routes.draw do get '*path', to: 'blacklist#index', constraints: BlacklistConstraint.new end
You can also specify constraints as a lambda:
Rails.application.routes.draw do get '*path', to: 'blacklist#index', constraints: lambda { |request| Blacklist.retrieve_ips.include?(request.remote_ip) } end
Both the matches?
method and the lambda gets the
request
object as an argument.
Route Globbing and Wildcard Segments¶ ↑
Route globbing is a way to specify that a particular parameter should be matched to all the remaining parts of a route. For example:
get 'photos/*other', to: 'photos#unknown'
This route would match photos/12
or
/photos/long/path/to/12
, setting params[:other]
to "12"
or "long/path/to/12"
.
The fragments prefixed with a star are called “wildcard segments”.
Wildcard segments can occur anywhere in a route. For example:
get 'books/*section/:title', to: 'books#show'
would match books/some/section/last-words-a-memoir
with
params[:section]
equals 'some/section'
,
and params[:title]
equals
'last-words-a-memoir'
.
Technically, a route can have even more than one wildcard segment. The matcher assigns segments to parameters in an intuitive way. For example:
get '*a/foo/*b', to: 'test#index'
would match zoo/woo/foo/bar/baz
with params[:a]
equals 'zoo/woo'
, and params[:b]
equals
'bar/baz'
.
NOTE: By requesting '/foo/bar.json'
, your
params[:pages]
will be equal to 'foo/bar'
with the request format of JSON. If you want the old 3.0.x behavior back,
you could supply format: false
like this:
get '*pages', to: 'pages#show', format: false
NOTE: If you want to make the format segment mandatory, so it cannot be
omitted, you can supply format: true
like this:
get '*pages', to: 'pages#show', format: true
Redirection¶ ↑
You can redirect any path to another path using the redirect
helper in your router:
get '/stories', to: redirect('/articles')
You can also reuse dynamic segments from the match in the path to redirect to:
get '/stories/:name', to: redirect('/articles/%{name}')
You can also provide a block to redirect, which receives the symbolized path parameters and the request object:
get '/stories/:name', to: redirect { |path_params, req| "/articles/#{path_params[:name].pluralize}" } get '/stories', to: redirect { |path_params, req| "/articles/#{req.subdomain}" }
Please note that this redirection is a 301 “Moved Permanently” redirect. Keep in mind that some web browsers or proxy servers will cache this type of redirect, making the old page inaccessible.
In all of these cases, if you don't provide the leading host
(http://www.example.com
), Rails will take those details from
the current request.
Routing to Rack Applications¶ ↑
Instead of a String like 'articles#index'
, which
corresponds to the index
action in the
ArticlesController
, you can specify any Rack application as the endpoint for a
matcher:
match '/application.js', to: Sprockets, via: :all
As long as Sprockets
responds to call
and returns
a [status, headers, body]
, the router won't know the
difference between the Rack application and an action. This is an
appropriate use of via: :all
, as you will want to allow your
Rack application to handle all verbs as it considers appropriate.
NOTE: For the curious, 'articles#index'
actually
expands out to ArticlesController.action(:index)
, which
returns a valid Rack application.
If you specify a rack application as the endpoint for a matcher remember that the route will be unchanged in the receiving application. With the following route your rack application should expect the route to be '/admin':
match '/admin', to: AdminApp, via: :all
If you would prefer to have your rack application receive requests at the root path instead use mount:
mount AdminApp, at: '/admin'
Using root
¶ ↑
You can specify what Rails should route '/'
to with
the root
method:
root to: 'pages#main' root 'pages#main' # shortcut for the above
You should put the root
route at the top of the file, because
it is the most popular route and should be matched first.
NOTE: The root
route only routes GET
requests to
the action.
You can also use root inside namespaces and scopes as well. For example:
namespace :admin do root to: "admin#index" end root to: "home#index"
Unicode character routes¶ ↑
You can specify unicode character routes directly. For example:
get 'こんにちは', to: 'welcome#index'
Customizing Resourceful Routes¶ ↑
While the default routes and helpers generated by resources
:articles
will usually serve you well, you may want to customize
them in some way. Rails allows you to customize virtually any generic part
of the resourceful helpers.
Specifying a Controller to Use¶ ↑
The :controller
option lets you explicitly specify a
controller to use for the resource. For example:
resources :photos, controller: 'images'
will recognize incoming paths beginning with /photos
but route
to the Images
controller:
| HTTP Verb | Path | Controller#Action | Named Helper | | ——— | —————- | —————– | ——————– | | GET | /photos | images#index | photos_path | | GET | /photos/new | images#new | new_photo_path | | POST | /photos | images#create | photos_path | | GET | /photos/:id | images#show | photo_path(:id) | | GET | /photos/:id/edit | images#edit | edit_photo_path(:id) | | PATCH/PUT | /photos/:id | images#update | photo_path(:id) | | DELETE | /photos/:id | images#destroy | photo_path(:id) |
NOTE: Use photos_path
, new_photo_path
, etc. to
generate paths for this resource.
For namespaced controllers you can use the directory notation. For example:
resources :user_permissions, controller: 'admin/user_permissions'
This will route to the Admin::UserPermissions
controller.
NOTE: Only the directory notation is supported. Specifying the controller
with Ruby constant notation (eg. controller:
'Admin::UserPermissions'
) can lead to routing problems and
results in a warning.
Specifying Constraints¶ ↑
You can use the :constraints
option to specify a required
format on the implicit id
. For example:
resources :photos, constraints: { id: /[A-Z][A-Z][0-9]+/ }
This declaration constrains the :id
parameter to match the
supplied regular expression. So, in this case, the router would no longer
match /photos/1
to this route. Instead,
/photos/RR27
would match.
You can specify a single constraint to apply to a number of routes by using the block form:
constraints(id: /[A-Z][A-Z][0-9]+/) do resources :photos resources :accounts end
NOTE: Of course, you can use the more advanced constraints available in non-resourceful routes in this context.
TIP: By default the :id
parameter doesn't accept dots -
this is because the dot is used as a separator for formatted routes. If you
need to use a dot within an :id
add a constraint which
overrides this - for example id: /[^\/]+/
allows anything
except a slash.
Overriding the Named Helpers¶ ↑
The :as
option lets you override the normal naming for the
named route helpers. For example:
resources :photos, as: 'images'
will recognize incoming paths beginning with /photos
and route
the requests to PhotosController
, but use the value of the :as
option to name the helpers.
| HTTP Verb | Path | Controller#Action | Named Helper | | ——— | —————- | —————– | ——————– | | GET | /photos | photos#index | images_path | | GET | /photos/new | photos#new | new_image_path | | POST | /photos | photos#create | images_path | | GET | /photos/:id | photos#show | image_path(:id) | | GET | /photos/:id/edit | photos#edit | edit_image_path(:id) | | PATCH/PUT | /photos/:id | photos#update | image_path(:id) | | DELETE | /photos/:id | photos#destroy | image_path(:id) |
Overriding the new
and edit
Segments¶ ↑
The :path_names
option lets you override the
automatically-generated new
and edit
segments in
paths:
resources :photos, path_names: { new: 'make', edit: 'change' }
This would cause the routing to recognize paths such as:
/photos/make /photos/1/change
NOTE: The actual action names aren't changed by this option. The two
paths shown would still route to the new
and edit
actions.
TIP: If you find yourself wanting to change this option uniformly for all of your routes, you can use a scope.
scope path_names: { new: 'make' } do # rest of your routes end
Prefixing the Named Route Helpers¶ ↑
You can use the :as
option to prefix the named route helpers
that Rails generates for a route. Use this option to prevent name
collisions between routes using a path scope. For example:
scope 'admin' do resources :photos, as: 'admin_photos' end resources :photos
This will provide route helpers such as admin_photos_path
,
new_admin_photo_path
, etc.
To prefix a group of route helpers, use :as
with
scope
:
scope 'admin', as: 'admin' do resources :photos, :accounts end resources :photos, :accounts
This will generate routes such as admin_photos_path
and
admin_accounts_path
which map to /admin/photos
and /admin/accounts
respectively.
NOTE: The namespace
scope will automatically add
:as
as well as :module
and :path
prefixes.
You can prefix routes with a named parameter also:
scope ':username' do resources :articles end
This will provide you with URLs such as /bob/articles/1
and
will allow you to reference the username
part of the path as
params[:username]
in controllers, helpers and views.
Restricting the Routes Created¶ ↑
By default, Rails creates routes for the seven default actions
(index
, show
, new
,
create
, edit
, update
, and
destroy
) for every RESTful route in your application. You can
use the :only
and :except
options to fine-tune
this behavior. The :only
option tells Rails to create only the
specified routes:
resources :photos, only: [:index, :show]
Now, a GET
request to /photos
would succeed, but
a POST
request to /photos
(which would ordinarily
be routed to the create
action) will fail.
The :except
option specifies a route or list of routes that
Rails should not create:
resources :photos, except: :destroy
In this case, Rails will create all of the normal routes except the route
for destroy
(a DELETE
request to
/photos/:id
).
TIP: If your application has many RESTful routes, using :only
and :except
to generate only the routes that you actually need
can cut down on memory use and speed up the routing process.
Translated Paths¶ ↑
Using scope
, we can alter path names generated by resources:
scope(path_names: { new: 'neu', edit: 'bearbeiten' }) do resources :categories, path: 'kategorien' end
Rails now creates routes to the CategoriesController
.
| HTTP Verb | Path | Controller#Action | Named Helper | | ——— | ————————– | —————— | ———————– | | GET | /kategorien | categories#index | categories_path | | GET | /kategorien/neu | categories#new | new_category_path | | POST | /kategorien | categories#create | categories_path | | GET | /kategorien/:id | categories#show | category_path(:id) | | GET | /kategorien/:id/bearbeiten | categories#edit | edit_category_path(:id) | | PATCH/PUT | /kategorien/:id | categories#update | category_path(:id) | | DELETE | /kategorien/:id | categories#destroy | category_path(:id) |
Overriding the Singular Form¶ ↑
If you want to define the singular form of a resource, you should add
additional rules to the Inflector
:
ActiveSupport::Inflector.inflections do |inflect| inflect.irregular 'tooth', 'teeth' end
Using :as
in Nested Resources¶ ↑
The :as
option overrides the automatically-generated name for
the resource in nested route helpers. For example:
resources :magazines do resources :ads, as: 'periodical_ads' end
This will create routing helpers such as
magazine_periodical_ads_url
and
edit_magazine_periodical_ad_path
.
Overriding Named Route Parameters¶ ↑
The :param
option overrides the default resource identifier
:id
(name of the dynamic segment used to generate
the routes). You can access that segment from your controller using
params[<:param>]
.
resources :videos, param: :identifier
videos GET /videos(.:format) videos#index POST /videos(.:format) videos#create new_videos GET /videos/new(.:format) videos#new edit_videos GET /videos/:identifier/edit(.:format) videos#edit
Video.find_by(identifier: params[:identifier])
Inspecting and Testing Routes¶ ↑
Rails offers facilities for inspecting and testing your routes.
Listing Existing Routes¶ ↑
To get a complete list of the available routes in your application, visit
http://localhost:3000/rails/info/routes
in your browser while
your server is running in the development environment. You
can also execute the rake routes
command in your terminal to
produce the same output.
Both methods will list all of your routes, in the same order that they
appear in routes.rb
. For each route, you'll see:
-
The route name (if any)
-
The HTTP verb used (if the route doesn't respond to all verbs)
-
The URL pattern to match
-
The routing parameters for the route
For example, here's a small section of the rake routes
output for a RESTful route:
users GET /users(.:format) users#index POST /users(.:format) users#create new_user GET /users/new(.:format) users#new edit_user GET /users/:id/edit(.:format) users#edit
You may restrict the listing to the routes that map to a particular
controller setting the CONTROLLER
environment variable:
$ CONTROLLER=users bin/rake routes
TIP: You'll find that the output from rake routes
is much
more readable if you widen your terminal window until the output lines
don't wrap.
Testing Routes¶ ↑
Routes should be included in your testing strategy (just like the rest of your application). Rails offers three built-in assertions designed to make testing routes simpler:
-
assert_generates
-
assert_recognizes
-
assert_routing
The assert_generates
Assertion¶ ↑
assert_generates
asserts that a particular set of options
generate a particular path and can be used with default routes or custom
routes. For example:
assert_generates '/photos/1', { controller: 'photos', action: 'show', id: '1' } assert_generates '/about', controller: 'pages', action: 'about'
The assert_recognizes
Assertion¶ ↑
assert_recognizes
is the inverse of
assert_generates
. It asserts that a given path is recognized
and routes it to a particular spot in your application. For example:
assert_recognizes({ controller: 'photos', action: 'show', id: '1' }, '/photos/1')
You can supply a :method
argument to specify the HTTP verb:
assert_recognizes({ controller: 'photos', action: 'create' }, { path: 'photos', method: :post })
The assert_routing
Assertion¶ ↑
The assert_routing
assertion checks the route both ways: it
tests that the path generates the options, and that the options generate
the path. Thus, it combines the functions of assert_generates
and assert_recognizes
:
assert_routing({ path: 'photos', method: :post }, { controller: 'photos', action: 'create' })


Travel Easy
Home
Weather
Map
Distance
Hotel
Contact
Image
Name
Price
Clear Cart
Logout
Enjoy your hotel experience !
Search for Hotels , Add Your favorite to your card !
All
Australia
Brazil
Canada
France
Germany
Mexico
New Zealand
Italy
South Africa
Spain
Portugal
U.S.A.
United Kingdom
Target
Hotel Name
Hotel Price
Add To Card
Address:
Telephone:
Rating:
Website:


To add a game to this event, create a new game from the game submission page. In the submission form, associate it with this event.


JOURNAL 75
NOTE
PROGRAMMING
The Hand Gestures
Wed, 01 Mar 2017 @
General Notes
7 Habits of Highly Effective People
Tue, 21 Feb 2017 @
General Notes
Neurogenesis – Keep Your Brain Growing
Tue, 07 Feb 2017 @
General Notes
Writing is Thinking
Tue, 07 Feb 2017 @
General Notes
Hackathon – Build Something !
Thu, 02 Feb 2017 @
General Notes
Dr John Medinna Talks Google
Fri, 27 Jan 2017 @
General Notes
The FORD Method
Wed, 25 Jan 2017 @
General Notes
The Miracle of Linux Live CD
Fri, 20 Jan 2017 @
General Notes
The Feynman Technique
Thu, 19 Jan 2017 @
General Notes
How To Learn Any Language in 6 Months - Part 2
Thu, 19 Jan 2017 @
General Notes
How To Learn Any Language in 6 Months
Tue, 17 Jan 2017 @
General Notes


- MandatoryCompiler - Class in org.jamplate.impl.compiler
-
A compiler that delegates to another compiler and raises an exception if that other
compiler failed to compile.
- MandatoryCompiler(Compiler) - Constructor for class org.jamplate.impl.compiler.MandatoryCompiler
-
Construct a new compiler wrapper that wraps the given compiler
and throws
an exception if it fails to compile.
- matcher(Tree, Pattern) - Static method in class org.jamplate.impl.util.Parsing
-
Construct a new matcher over the current content of the document of the given
tree
with the range of the reference of the given tree
as the
region of it.
- Memories - Class in org.jamplate.impl.util
-
Utilities for memories.
- MEMORY - Static variable in class org.jamplate.impl.Meta
-
The key for the memory default allocations.
- Memory - Class in org.jamplate.model
-
The memory is a structure that saves the variables at the runtime.
- Memory() - Constructor for class org.jamplate.model.Memory
-
Construct a new empty memory.
- Memory(Memory) - Constructor for class org.jamplate.model.Memory
-
Construct a new copy of the given memory
.
- MergeByOrderParser - Class in org.jamplate.impl.parser
-
A parser that merges the clashing sketches resulting from another parser going from the
first to the last tree sequentially.
- MergeByOrderParser(Parser) - Constructor for class org.jamplate.impl.parser.MergeByOrderParser
-
Construct a sequential clash merging parser merging the results of invoking the
given parser
.
- MergeByWeightParser - Class in org.jamplate.impl.parser
-
A parser that uses multiple other parsers for parsing.
- MergeByWeightParser(Parser...) - Constructor for class org.jamplate.impl.parser.MergeByWeightParser
-
Construct a new parser that uses the given parsers
preferring the results
from the parsers at the start that the results from the parsers that at the end
when a clash occur between their results.
- MergeByWeightParser(List<Parser>) - Constructor for class org.jamplate.impl.parser.MergeByWeightParser
-
Construct a new parser that uses the given parsers
preferring the results
from the parsers at the start that the results from the parsers that at the end
when a clash occur between their results.
- MergeFlatByOrderParser - Class in org.jamplate.impl.parser
-
A merging parser that does not allow two trees having any dominance between each other.
- MergeFlatByOrderParser(Parser) - Constructor for class org.jamplate.impl.parser.MergeFlatByOrderParser
-
Construct a new parser that filters the results to have no dominance between
etcher.
- MergeFlatByWeightParser - Class in org.jamplate.impl.parser
-
- MergeFlatByWeightParser(Parser...) - Constructor for class org.jamplate.impl.parser.MergeFlatByWeightParser
-
Construct a new parser that uses the given parsers
preferring the results
from the parsers at the start that the results from the parsers that at the end
when a clash occur between their results.
- MergeFlatByWeightParser(List<Parser>) - Constructor for class org.jamplate.impl.parser.MergeFlatByWeightParser
-
Construct a new parser that uses the given parsers
preferring the results
from the parsers at the start that the results from the parsers that at the end
when a clash occur between their results.
- Message - Interface in org.jamplate.diagnostic
-
A diagnostic message containing the details about an error, warning or even a note.
- MessageImpl - Class in org.jamplate.impl.diagnostic
-
A basic implementation of the interface
Message
.
- MessageImpl(Throwable, String, String, boolean, Tree...) - Constructor for class org.jamplate.impl.diagnostic.MessageImpl
-
Construct a new message.
- MessageImpl(String, String, String, boolean, Tree...) - Constructor for class org.jamplate.impl.diagnostic.MessageImpl
-
Construct a new message.
- MessageImpl(Throwable, Memory, String, String, boolean, Tree...) - Constructor for class org.jamplate.impl.diagnostic.MessageImpl
-
Construct a new message.
- MessageImpl(String, Memory, String, String, boolean, Tree...) - Constructor for class org.jamplate.impl.diagnostic.MessageImpl
-
Construct a new message.
- MessageKind - Class in org.jamplate.impl.diagnostic
-
A class containing message kinds constants.
- messagePhrase - Variable in class org.jamplate.impl.diagnostic.MessageImpl
-
The message phrase.
- MessagePriority - Class in org.jamplate.impl.diagnostic
-
A class containing message priorities constants.
- Meta - Class in org.jamplate.impl
-
A class containing common meta keys.
- meta - Variable in class org.jamplate.impl.model.CompilationImpl
-
The additional meta-data of this compilation.
- meta - Variable in class org.jamplate.impl.model.EnvironmentImpl
-
The additional meta-data of this sketch.
- meta - Variable in class org.jamplate.model.Sketch
-
The additional meta-data of this sketch.


|
EccentricsEccentricity, we like to say, is the rich-man's crazy. Nobody likes the scary crazy, where it is a personal threat to life and limb to have the afflicted within arm's reach of us. But when there seems to be a little knock in the gears, a slight hiccup in the thought process, we often take a light-hearted look at it, and in fact consider it a sign of life's rich pageant. Whether these little mental oddities lead to dangerous situations or horrifying conditions down the road is not our immediate concern. We just motion to our dates and snicker as we go back to our warm, normal homes.For example, you can't do better than to learn about the reign of Emperor Norton, the first emperor of the United States.
|


ansible.plugins.connection package¶
-
class
ansible.plugins.connection.
ConnectionBase
(play_context, new_stdin, *args, **kwargs)[source]¶ Bases:
object
A base class for connections to contain common code.
-
has_pipelining
= False¶
-
become_methods
= ['sudo', 'su', 'pbrun', 'pfexec', 'runas', 'doas', 'dzdo']¶
-
module_implementation_preferences
= ('',)¶
-
allow_executable
= True¶
-
connected
¶ Read-only property holding whether the connection to the remote host is active or closed.
-
set_host_overrides
(host, hostvars=None)[source]¶ An optional method, which can be used to set connection plugin parameters from variables set on the host (or groups to which the host belongs)
Any connection plugin using this should first initialize its attributes in an overridden def __init__(self):, and then use host.get_vars() to find variables which may be used to set those attributes in this method.
-
transport
¶ String used to identify this Connection class from other classes
-
exec_command
(*args, **kwargs)[source]¶ Run a command on the remote host.
Parameters: - cmd (bytestring) – byte string containing the command
- in_data – If set, this data is passed to the command’s stdin. This is used to implement pipelining. Currently not all connection plugins implement pipelining.
- sudoable – Tell the connection plugin if we’re executing a command via a privilege escalation mechanism. This may affect how the connection plugin returns data. Note that not all connections can handle privilege escalation.
Returns: a tuple of (return code, stdout, stderr) The return code is an int while stdout and stderr are both byte strings.
When a command is executed, it goes through multiple commands to get there. It looks approximately like this:
[LocalShell] ConnectionCommand [UsersLoginShell (*)] ANSIBLE_SHELL_EXECUTABLE [(BecomeCommand ANSIBLE_SHELL_EXECUTABLE)] Command
LocalShell: Is optional. It is run locally to invoke the Connection Command
. In most instances, theConnectionCommand
can be invoked directly instead. The ssh connection plugin which can have values that need expanding locally specified via ssh_args is the sole known exception to this. Shell metacharacters in the command itself should be processed on the remote machine, not on the local machine so no shell is needed on the local machine. (Example,/bin/sh
)ConnectionCommand: This is the command that connects us to the remote machine to run the rest of the command. ansible_ssh_user
,ansible_ssh_host
and so forth are fed to this piece of the command to connect to the correct host (Examplesssh
,chroot
)UsersLoginShell: This shell may or may not be created depending on the ConnectionCommand used by the connection plugin. This is the shell that the ansible_ssh_user
has configured as their login shell. In traditional UNIX parlance, this is the last field of a user’s/etc/passwd
entry We do not specifically try to run theUsersLoginShell
when we connect. Instead it is implicit in the actions that theConnectionCommand
takes when it connects to a remote machine.ansible_shell_type
may be set to inform ansible of differences in how theUsersLoginShell
handles things like quoting if a shell has different semantics than the Bourne shell.ANSIBLE_SHELL_EXECUTABLE: This is the shell set via the inventory var ansible_shell_executable
or viaconstants.DEFAULT_EXECUTABLE
if the inventory var is not set. We explicitly invoke this shell so that we have predictable quoting rules at this point.ANSIBLE_SHELL_EXECUTABLE
is only settable by the user because some sudo setups may only allow invoking a specific shell. (For instance,/bin/bash
may be allowed but/bin/sh
, our default, may not). We invoke this twice, once after theConnectionCommand
and once after theBecomeCommand
. After the ConnectionCommand, this is run by theUsersLoginShell
. After theBecomeCommand
we specify that theANSIBLE_SHELL_EXECUTABLE
is being invoked directly.BecomeComand ANSIBLE_SHELL_EXECUTABLE: Is the command that performs privilege escalation. Setting this up is performed by the action plugin prior to running exec_command
. So we just get passed :param cmd which has the BecomeCommand already added. (Examples: sudo, su) If we have a BecomeCommand then we will invoke a ANSIBLE_SHELL_EXECUTABLE shell inside of it so that we have a consistent view of quoting.Command: Is the command we’re actually trying to run remotely. (Examples: mkdir -p $HOME/.ansible, python $HOME/.ansible/tmp-script-file)
-
Submodules¶
ansible.plugins.connection.accelerate module¶
-
class
ansible.plugins.connection.accelerate.
Connection
(*args, **kwargs)[source]¶ Bases:
ansible.plugins.connection.ConnectionBase
raw socket accelerated connection
-
transport
= 'accelerate'¶
-
has_pipelining
= False¶
-
become_methods
= frozenset(['pbrun', 'pfexec', 'dzdo', 'sudo', 'su', 'doas'])¶
-
ansible.plugins.connection.chroot module¶
-
class
ansible.plugins.connection.chroot.
Connection
(play_context, new_stdin, *args, **kwargs)[source]¶ Bases:
ansible.plugins.connection.ConnectionBase
Local chroot based connections
-
transport
= 'chroot'¶
-
has_pipelining
= True¶
-
become_methods
= frozenset(['pbrun', 'pfexec', 'dzdo', 'runas', 'sudo', 'doas'])¶
-
ansible.plugins.connection.docker module¶
-
class
ansible.plugins.connection.docker.
Connection
(play_context, new_stdin, *args, **kwargs)[source]¶ Bases:
ansible.plugins.connection.ConnectionBase
Local docker based connections
-
transport
= 'docker'¶
-
has_pipelining
= True¶
-
become_methods
= frozenset(['pbrun', 'pfexec', 'dzdo', 'runas', 'sudo', 'doas'])¶
-
ansible.plugins.connection.funcd module¶
ansible.plugins.connection.jail module¶
ansible.plugins.connection.libvirt_lxc module¶
-
class
ansible.plugins.connection.libvirt_lxc.
Connection
(play_context, new_stdin, *args, **kwargs)[source]¶ Bases:
ansible.plugins.connection.ConnectionBase
Local lxc based connections
-
transport
= 'libvirt_lxc'¶
-
has_pipelining
= True¶
-
become_methods
= frozenset(['pbrun', 'pfexec', 'dzdo', 'runas', 'sudo', 'doas'])¶
-
ansible.plugins.connection.local module¶
-
class
ansible.plugins.connection.local.
Connection
(play_context, new_stdin, *args, **kwargs)[source]¶ Bases:
ansible.plugins.connection.ConnectionBase
Local based connections
-
transport
= 'local'¶
-
has_pipelining
= True¶
-
ansible.plugins.connection.lxc module¶
-
class
ansible.plugins.connection.lxc.
Connection
(play_context, new_stdin, *args, **kwargs)[source]¶ Bases:
ansible.plugins.connection.ConnectionBase
Local lxc based connections
-
transport
= 'lxc'¶
-
has_pipelining
= True¶
-
become_methods
= frozenset(['pbrun', 'pfexec', 'runas', 'sudo', 'su', 'doas', 'dzdo'])¶
-
ansible.plugins.connection.lxd module¶
-
class
ansible.plugins.connection.lxd.
Connection
(play_context, new_stdin, *args, **kwargs)[source]¶ Bases:
ansible.plugins.connection.ConnectionBase
lxd based connections
-
transport
= 'lxd'¶
-
has_pipelining
= True¶
-
ansible.plugins.connection.paramiko_ssh module¶
-
class
ansible.plugins.connection.paramiko_ssh.
MyAddPolicy
(new_stdin, connection)[source]¶ Bases:
object
Based on AutoAddPolicy in paramiko so we can determine when keys are added and also prompt for input.
Policy for automatically adding the hostname and new host key to the local L{HostKeys} object, and saving it. This is used by L{SSHClient}.
-
class
ansible.plugins.connection.paramiko_ssh.
Connection
(play_context, new_stdin, *args, **kwargs)[source]¶ Bases:
ansible.plugins.connection.ConnectionBase
SSH based connections with Paramiko
-
transport
= 'paramiko'¶
-
ansible.plugins.connection.ssh module¶
-
class
ansible.plugins.connection.ssh.
Connection
(*args, **kwargs)[source]¶ Bases:
ansible.plugins.connection.ConnectionBase
ssh based connections
-
transport
= 'ssh'¶
-
has_pipelining
= True¶
-
become_methods
= frozenset(['pbrun', 'pfexec', 'dzdo', 'sudo', 'su', 'doas'])¶
-
ansible.plugins.connection.winrm module¶
ansible.plugins.connection.zone module¶
-
class
ansible.plugins.connection.zone.
Connection
(play_context, new_stdin, *args, **kwargs)[source]¶ Bases:
ansible.plugins.connection.ConnectionBase
Local zone based connections
-
transport
= 'zone'¶
-
has_pipelining
= True¶
-
become_methods
= frozenset(['pbrun', 'pfexec', 'dzdo', 'runas', 'sudo', 'doas'])¶
-


Host (Presumed) Proteins
{{ $iter := .Site.Data.page_structures.proteins.host.presumed }}
{{ if not $iter }}
No information has been recorded in the Exchange about presumed host proteins
The information might be out there! The Exchange only knows what people tell it, so if you know of information
regarding presumed host proteins, please submit an issue to help add it to the Exchange!
{{ else}}
{{ range .Site.Data.page_structures.proteins.host.presumed }}
{{ .name }}
{{ .desc }}
PLACEHOLDER DATA!
{{ end }}
{{ end}}


--- layout: default ---
This website was built as a personal project demonstration for a fitness product/outcome. Below you can view and download a pdf of the product/outcome, which contains a scientific analysis of some necessary concepts to get started with fitness and dieting. After reading this document, you should be able to:
Understand the nationwide impact of obesity and the importance of fitness
If wanted, make dietary modifications based on concepts outlined
Avoid some misconceptions related to dieting and fitness
Understand research about the effects of certain dietary items
Have the ability to improve your physical and mental state
And many more!


Converts a Scala scala.xml.NodeSeq to a String for rendering nodes as HTML, XML, XHTML etc
Converts an Scuery Transformer to output
A helper class to represent a template view which can be passed into JAXRS for rendering
Renders a View using the Scalate template engine


response sea ice circulation Arctic loss atmospheric CMIP North RCP. jet surface climate Atlantic mean shift {border-style poleward SST px;} #ffffff;} forcing winter Climate late multimodel Climate, warming Figure change future heat https://doi.org/./JCLI-D--. midlatitude AMIP AMIPsstco experiments (Figure models pressure AMIPxCO Research impact wind Pacific Polvani, Sea flux increase scenario (see Atmospheric Geophysical Shepherd, consistent global latitude projected px; single‐model zonal {font-family AMIPFuture Dynamics, Figures Kushner, associated evidence font-size model projections radiative responses results shows Northern concentration double; early hPa https://doi.org/./s--- influence northern present previous role seasonal simulations Deser Deser, Global Hemisphere Letters, Nature Tomas, Zappa, border-color border-width changes cold confidence coupling difference differences different historical https://doi.org/./GL impacts increased models. projections. scaling similar solid; studies tropospheric using vortex westerly winter, {font-style {font-weight %yr (Figures (a) (b) (e.g., Change, JFM Multimodel Response S). amplification assumptions bold comparing courier; direct em; experiments, experiments. features forcing, greenhouse identified induced large largest linearity loss, lower obtained ocean particular, pt;} response. robust robustness seasonality southward state stratospheric suggests temperature tends time variability weakening −CO


paper-mining cvpr knowledge-graph by maker-knowledge-mining
Conference on Computer Vision and Pattern Recognition
The Conference on Computer Vision and Pattern Recognition is the IEEE annual conference on computer vision and pattern recognition. It is considered, together with ICCV, the top level conference in computer vision. It has an 'A' rating from the Australian Ranking of ICT Conferences and an 'A1' rating from the Brazilian ministry of education. It was first held in San Francisco in 1985.
CVPR Best Paper Award
These awards are picked by committees delegated by the program chairs of the conference.
CVPR Best Paper Award recipients
Awarded at CVPR 2013:
Best Paper: Fast, Accurate Detection of 100,000 Object Classes on a Single Machine, Thomas Dean, Jay Yagnik, Mark Ruzon, Mark Segal, Jonathon Shlens, and Sudheendra Vijayanarasimhan
Best Paper Runner-Up: Lost! Leveraging the Crowd for Probabilistic Visual Self-Localization, Marcus Brubaker, Andreas Geiger, and Raquel Urtasun
Best Student Paper: Discriminative Non-blind Deblurring, Uwe Schmidt, Carsten Rother, Sebastian Nowozin, Jeremy Jancsary, and Stefan Roth
Awarded at CVPR 2012:
Best Paper: A Simple Prior-free Method for Non-Rigid Structure-from-Motion Factorization, Yuchao Dai, Hongdong Li, Mingyi He
Best Student Paper: Max-Margin Early Event Detectors, Minh Hoai, Fernando De la Torre
Awarded at CVPR 2011:
Best Paper: Real-time Human Pose Recognition in Parts from Single Depth Images, Jamie Shotton, Andrew Fitzgibbon, Mat Cook, Toby Sharp, Mark Finocchio, Richard Moore, Alex Kipman, Andrew Blake
Best Paper Honorable Mention: Discrete-Continuous Optimization for Large-scale Structure from Motion, David Crandall, Andrew Owens, Noah Snavely, Daniel Huttenlocher
Best Student Paper: Recognition Using Visual Phrases, Ali Farhadi, Mohammad Amin Sadeghi
Best Student Paper Honorable Mention: Separating Reflective and Fluorescent Components of An Image, Cherry Zhang, Imari Sato
Awarded at CVPR 2010:
Best Paper: Efficient Computation of Robust Low-Rank Matrix Approximations in the Presence of Missing Data using the L1 Norm, Anders Eriksson and Anton van den Hengel
Best Student Paper: Visual Event Recognition in Videos by Learning from Web Data, Lixin Duan, Dong Xu, Wai-Hung Tsang, and Jiebo Luo
Best Student Paper Honorable Mention: Modeling Mutual Context of Object and Human Pose in Human-Object Interaction Activities, Bangpeng Yao and Li Fei-Fei
Awarded at CVPR 2009:
Best Paper: Single Image Haze Removal Using Dark Channel Prior, Kaiming He, Jian Sun, Xiaoou Tang
Best Paper Honorable Mention: Understanding and evaluating blind deconvolution algorithms, Anat Levin, Yair Weiss, Fredo Durand, Bill Freeman
Best Student Paper: Nonparametric Scene Parsing: Label Transfer via Dense Scene Alignment, Ce Liu, Jenny Yuen, Antonio Torralba
Best Student Paper Honorable Mention: A Tensor-Based Algorithm for High-Order Graph Matching, Olivier Duchenne, Francis Bach, In So Kweon, Jean Ponce
Awarded at CVPR 2008
Best Paper: Beyond Sliding Windows: Object Localization by Efficient Subwindow Search, Christoph H. Lampert, Matthew B.Blaschko,Thomas Hofmann
Best Paper: Global Stereo Reconstruction under Second Order Smoothness Priors, Oliver Woodford, Ian Reid, Philip Torr, Andrew Fitzgibbon
Best Student Paper: Fast Image Search for Learned Metrics, Prateek Jain, Brian Kulis, Kristen Grauman
Awarded at CVPR 2007
Best Paper: Dynamic 3D Scene Analysis from a Moving Vehicles, Bastian Leibe, Nico Cornelis, Kurt Cornelis, and Luc Van Gool
Best Paper Honorable Mention: Spectral Matting, Anat Levin, Alex Rav-Acha, and Dani Lischinski
Best Paper Honorable Mention: Human Detection via Classification on Riemannian Manifolds, Oncel Tuzel, Fatih Porikli, and Peter Meer
Best Student Paper: Tracking in Low Frame Rate Video: A Cascade Particle Filter with Discriminative Observers of Different Life Spans, Yuan Li, Haizhou Ai, Takayoshi Yamashita, Shihong Lao, and Masato Kawade
Awarded at CVPR 2006
Best Paper: Putting Objects in Perspective, Derek Hoiem, Alexei Efros, Martial Hebert
Best Paper Honorable Mention:Incremental learning of object detectors using a visual shape alphabet, Andreas Opelt, Axel Pinz, Andrew Zisserman
Awarded at CVPR 2005
Best Paper: Real-Time Non-Rigid Surface Detection, Julien Pilet, Vincent Lepetit, Pascal Fua
Best Paper Honorable Mention: A Non-Local Algorithm for Image Denoising, Antoni Buades, Bartomeu Coll, Jean-Michel Morel
Bi-Layer Segmentation of Binocular Stereo Video, Vladimir Kolmogorov, Antonio Criminisi, Andrew Blake, Geoffrey Cross, Carsten Rother
Video Epitomes, Vincent Cheung, Brendan J. Frey, Nebojsa Jojic
Awarded at CVPR 2003
Best Paper: Object Class Recognition by Unsupervised Scale-Invariant Learning, Rob Fergus, Pietro Perona, and Andrew Zisserman
Best Paper Honorable Mention: Constraint on Five Points in Two Images, Tomas Werner
Best Student Paper: Vector-Valued Image Regularization with PDE's: A Common Framework for Different Applications, David Tschumperle and Rashid Deriche
Awarded at CVPR 2001
Best Paper: Morphable 3D models from video, Matthew Brand
Best Paper Runner Up: Robust on-line appearance models for visual tracking, A. Jepson, D. Fleet, T.F. El-Maraghi
Best Student Paper: Tracking and modeling non-rigid objects with rank constraints, L. Torresani, D. Yang, E. Alexander, C. Bregler
Outstanding Student Paper: Dense image matching with global and local statistical criteria: a variational approach, G. Hermosillo, O. Faugeras
Outstanding Student Paper: JPDAF based HMM for real-time contour tracking, Y. Chen, Y. Rui, T. Huang
Outstanding Student Paper: Model-based curve evolution techniques for image segmentation, A. Tsai, A. Yezzi, W. Wells, C. Tempany, D. Tucker, A. Fan, E. Grimson, A. Willsky
Longuet-Higgins Prize
The Longuet-Higgins Prize recognizes CVPR papers from ten years ago that have made a significant impact on computer vision research.
PAMI Young Researcher Award
The Pattern Analysis and Machine Intelligence (PAMI) Young Researcher Award is an award given by the Technical Committee on Pattern Analysis and Machine Intelligence (TCPAMI) of the IEEE Computer Society at the CVPR to a researcher within 7 years of completing their Ph.D. for outstanding early career research contributions. Candidates are nominated by the computer vision community, with winners selected by a committee of senior researchers in the field. This award was originally instituted in 2012 by the Elsevier journal Image and Vision Computing, also presented at the CVPR, and the ICV continues to sponsor the award.
PAMI Young Researcher Award recipients
2013: Anat Levin and Kristen Grauman
2012 (as the IVC Outstanding Young Researcher Award): Deva Ramanan
from wiki http://en.wikipedia.org/wiki/Conference_on_Computer_Vision_and_Pattern_Recognition


| 703 | (A) | and bade thaym bebe of that brothe for the byschoppe saułłe |
| 706 | (C) | He badde hem drynke hit in broth . for þe bysshoppis sowle |
| 698 | (D) | And bad hem byb þat beuerache for þe bisshops sou? |
| 680 | (E) | & bad hem drynk alle abowte . for þe bysshoppes sowle . |
| (Ex) | ---- no text ---- | |
| 720 | (L) | & bade hem bible of þat broþ for þe bischopes soule |
| 659 | (P) | And bad hym bebe of þe brothe for þe byschop saule |
| 688 | (U) | And bad hem bibble it in brotħ / for the bysshop soule |
| (V) | ---- no text ---- |


We're sorry but this website doesn't work properly without JavaScript enabled. Please enable it to continue.


DBus hardware access - From TI view (registers)
Well, the whole doc is focused on link from a PC view. This topic
add a TI view.
While I was working on TiEmu II, I had to fix linkport support which
was quite broken. Unfortunately, I didn't know very much about how
linkport works on TI side. This was quite annoying. Then, I decided to
dis-assemble low-level linkport routines and the result of this work is
below.
| DBus
Control & Status |
|||||||||||||||
| Control ($60000C) |
Status ($60000D) | ||||||||||||||
| 15 |
14 |
13 |
12 |
11 |
10 |
9 |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
| AE |
LD |
LTO |
CLE |
CA |
CTX |
CRX |
SLE |
STX |
SRX |
SLI |
SA |
EA? |
| AE |
Autostart Enable |
Bit set and bit 3 of $600005 set
: wake-up calc on Dbus activity. |
| LD |
Link Disable |
Set it to 1 when you want to use
direct access to register $60000E. Disable byte sender/receiver. |
| LTO |
Link Time-out Disable |
Disable link time-out (red/white
are low for more than 2 seconds). |
| CLE |
Link Error Interrupt Enable |
Allow SLE to trigger interrupt. |
| CA |
AutoStart Interrupt Enable | Allow SA to trigger interrupt. |
| CTX |
TX buffer empty Interrupt Enable | Allow STX to trigger interrupt (and triggers interrupt immediately given that STX is usually set). |
| CRX |
RX buffer full Interrupt Enable | Allow SRX to trigger interrupt. |
| SLE |
Link Error |
Dbus error (timing or protocol
violation). |
| STX |
TX buffer empty |
Transmit buffer is empty. |
| SRX |
RX buffer full |
Receive buffer is empty. |
| SLI |
Link Interrupt |
Never used (at least in TI AMS).
SLI = SLE | STX | SRX | SA. |
| SA |
AutoStart |
Link activity on DBus port. |
| EA ? |
External Activity ? |
External activity (DBus lines
are toggling). Used by AMS >= 2.08 |
| Always 1. | ||
| Always 0. |
| DBus
Direct & Data |
|||||||||||||||
| Direct ($60000E) |
Data ($60000F) | ||||||||||||||
| 15 |
14 |
13 |
12 |
11 |
10 |
9 |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
| D1I (white) |
D0I (red) |
D1O |
D0O |
RX/TX
1-byte buffer |
| D1I |
D1 input |
Live status of
D1/ring/white (1=pulled down). |
| D0I |
D0 input |
Live status of D0/tip/red
(1=pulled down). |
| D1O |
D1 output |
Activate (pull down)
D1/ring/white. |
| D0O |
D0 output |
Activate (pull down)
D1/ring/white. |
You may find some informations in the TIGCC documentation.


Running INITS
Setting the parameter file for the INITS package
The INITS program uses one or more ascii input files to set parameters, including
the details of the power spectrum, the grid size, and output file names.
Each line of the parameter file is interpreted independently and can contain
only a single parameter. Parameters are specified in the form:
ParameterName = VALUE
Spaces are ignored, and the parameter statement must be contained on
a single line. Lines which begin with the pound symbol (#) are assumed
to be comments and ignored.
First, set the parameters in the file. There are a large number of parameters,
but many don't need to be set since reasonable default values are provided.
Modifying the provided example (cleverly called SampleParameterFile in
the code bundle)
is probably the easiest route, but for reference there is a list of the
parameters, their meanings and default values.
Generating a single grid initialization (for KRONOS and simple
Enzo runs) is relatively straightforward. Generating a multi-grid initialization
for Enzo is somewhat more complicated, and we only sketch the full procedure
here.
Single grid initialization
To run a single grid initialization, you must set at least the following
parameters: Rank, GridDims, ParticleDims, as well
as the appropriate Cosmology and Power Spectrum parameters. A sample
parameter
file is available, which sets up a small, single grid cosmology simulation
(that is, single grid for the initial conditions, once Enzo is
used, additional grids will be created).
After creating or modifying a parameter file, and compiling inits, run
the code with:
inits [-d] parameter_file
Where parameter_file is the name of your modified parameter
file (the -d turns on a debug option). This will produce a number
of HDF files containing the initial grids and particles, which are in the
correct units for use in KRONOS or Enzo.
Multiple-grid initialization
The multi-grid initialization requires running inits once for each grid
to be generated. Typically, one uses this option to examine an object that
collapses out of a small region of the top-grid, and so you are interested
in simulating this small region with higher initial resolution. We will
assume here that two grids are to be used, but the extension to a larger
number is relatively straightforward.
The most difficult part is finding the region to be refined. This can
be done with an iterative approach. Generate a single-grid initialization
and run the simulation at relatively low resolution. Once you have identified
an object (see the analysis section), you can use the findinit
utility, which is part of the analysis package (see the instructions
on obtaining Enzo). After setting the MACHINE_NAME macro in the
file amr_mpi/anyl/Makefile, (and making enzo itself, which is
a pre-requisite), compile with make findinit. This should generate
the findinit utility which can be run with:
findinit enzo_final_output enzo_initial_output object_file
Here, enzo_initial_output and enzo_final_output refer
to the initial and final outputs (usually at z=0) of the low resolution
enzo run. The position and radius of the object of interest should be in
object_file.
This file contains just a single line with four numbers, separated by spaces.
The first three specify the position of the object, (as floats ranging
from 0 to 1) and the fourth is the radius (again in units of the box size).
You can find the position of various objects with enzohop, and its radius
with enzo_anyl (see the analysis section).
The way findinit works is to extract all the particles within
the sphere centered on the object from the final output and then identify
them in the initial output. It returns two points which are the two corners
of a volume containing all of the particles at the initial time (although
this fails if the region wraps around the edge of the box). It also outputs
an ascii file which contains the initial positions of all the particles
identified.
To generate a subgrid which corresponds to this region, create two new
parameter files (by, for example, copying the old one), one each for the
top grid and for the subgrid. The cosmology and power spectrum parameters
can be left unchanged, but you will have to modify the grid
parameters. Assuming that the refinement factor is 2, you will have
to set MaxDims to double the original GridDims, set GridRefinement and
ParticleRefinement to 2 in the top grid parameter file (and 1 in the subgrid
parameter file). Set StartIndex, and GridDims/ParticleDims in the subgrid
to cover the region. The output names should also be modified slightly,
adding .0 to the end of the topgrids names and .1 to the sub grid names
(this convention is assumed by Enzo when reading more than a single
grid).
Once the parameter files are prepared, the top grid can be generated
with:
inits [-d] -s SubGridParameterFile TopGridParameterFile
The -s flag provides the name of the sub-grid parameter file,
which is required by inits so that the particles are not replicated
in the sub-grid region. The sub-grids are made with the usual command line:
inits [-d] SubGridParameterFile
Subgrids with MaxDims of 512 or larger will take some time and require
a fair amount of memory since the entire region is generated and then the
desired section extracted.
A sample parameter file setup with a top
grid and one refined grid
is available.
INITS Parameter Dictionary
-
Cosmology Parameters:
-
CosmologyOmegaMatterNow - This is the contribution of all non-relativistic
matter (including HDM) to the energy density at the current epoch (z=0),
relative to the value required to marginally close the universe. It includes
dark and baryonic matter. Default: 1.0
-
CosmologyOmegaLambdaNow - This is the contribution of the cosmological
constant to the energy density at the current epoch, in the same units
as above. Default: 0.0
-
CosmologyOmegaWDMNow - This is the contribution due to warm dark
matter alone. Ignored unless PowerSpectrumType = 13 or 14. Default: 0.0
-
CosmologyOmegaHDMNow - This is the contribution due to hot dark
matter alone. Default: 0.0
-
CosmologyOmegaBaryonNow - The baryonic contribution alone. Default:
0.06
-
CosmologyComovingBoxSize - The size of the volume to be simulated
in Mpc/h (at z=0). Default: 64.0
-
CosmologyHubbleConstantNow - The Hubble constant at z=0, in units
of 100 km/s/Mpc. Default: 0.5
-
CosmologyInitialRedshift - The redshift for which the initial conditions
are to be generated. Default: 20.0
-
Power Spectrum Parameters
-
PowerSpectrumType - This integer parameter indicates the routine
to be used for generating the power spectrum. Default: 1 The following
are currently available:
-
1
-
CDM approximation from BBKS (Bardeen et al 1986) as modified by Peacock
and Dodds (1994), to include, very roughly, the effect of baryons. This
should not be used for high baryon universes or for simulations in which
precision in the PS is important.
-
2
-
CHDM approximate PS from Ma (1996). Roughly good for hot fractions from
0.05 to 0.3.
-
3
-
Power-law (scale-free) spectra.
-
4
-
Reads in a power-spectrum from a file (not working).
-
5
-
CHDM approximate PS from Ma (1996), modified for 2 equal mass neutrinos.
-
6
-
A CDM-like Power spectrum with a shape parameter (Gamma), that is specified
by the parameter PowerSpectrumGamma.
-
11
-
The Eisenstein and Hu fitting functions for low and moderate baryon fraction,
including the case of one massive neutrino.
-
12
-
The Eisenstein and Hu fitting functions for low and moderate baryon fraction,
for the case of two massive neutrinos.
-
13
-
A Warm Dark Matter (WDM) power spectrum based on the formulae of Bode et al.
(2001 ApJ 556, 93). The WDM equivalent of the Eisenstein & Hu fitting function
with one massive neutrino (so a WDM version of #11).
-
14
-
A Warm Dark Matter (WDM) power spectrum based on the formulae of Bode et al.
(2001 ApJ 556, 93). The WDM equivalent of the CDM BBKS approximation of
Bardeen et al 1986 (the WDM version of #1).
-
20
-
A transfer function from CMBFast is input for this option, based on the
filenames described below.
-
PowerSpectrumSigma8 - The amplitude of the linear power spectrum
at z=0 as specified by the rms amplitude of mass-fluctuations in a top-hat
sphere of radius 8 Mpc/h. Default: 0.6
-
PowerSpectrumPrimordialIndex - This is the index of the mass power
spectrum before modification by the transfer function. A value of 1 corresponds
to the scale-free primordial spectrum. Default: 1.0.
-
PowerSpectrumRandomSeed - This is the initial seed for all random
number generation, which should be negative. The random number generator
(Numerical Recipes RAN3) is machine-independent, so the same seed will
produce the same results (with other parameters unchanged). Note also that
because the spectrum is sampled strictly in order of increasing k-amplitude,
the large-scale power will be the same even if you increase or decrease
the grid size. Default: -123456789
-
PowerSpectrumkcutoff - The spectrum is set to zero above this wavenumber
(i.e. smaller scales are set to zero), which is in units of 1/Mpc. It only
works for power spectrum types 1-6. A value of 0 means no cutoff. Default:
0.0
-
PowerSpectrumkmin/kmax - These two parameters control the range
of the internal lookup table in wavenumber (units 1/Mpc). Reasonably sized
grids will not require changes in these parameters. Defaults: kmin = 1e-3,
kmax = 1e+4.
-
PowerSpectrumNumberOfkPoints - This sets the number of points in
the PS look-up table that is generated for efficiency purposes. It should
not require changing. Default: 10000.
-
PowerSpectrumFileNameRedshiftZero - For input power spectra, such
as those from CMBFAST, two transfer functions are required: one at z=0
to fix the amplitude (via Sigma8) and the other at the initial redshift
to give the shape and amplitude relative to z=0. No default.
-
PowerSpectrumFileNameInitialRedshift - see above.
-
PowerSpectrumGamma - The shape parameter (Omega*h); ignored unless
PowerSpectrumType = 6.
-
PowerSpectrumWDMParticleMass - The mass of the dark matter
particle in KeV for the Bode et al. warm dark matter (WDM) case. Ignored
unless PowerSpectrumType = 13 or 14. Default: 1.0.
-
PowerSpectrumWDMDegreesOfFreedom - The number of degrees of freedom
of the warm dark matter particles for the Bode et al. warm dark matter model.
Ignored unless PowerSpectrumType = 13 or 14. Default: 1.5.
-
PowerSpectrumGamma - The shape parameter (Omega*h); ignored unless
PowerSpectrumType = 6.
-
GridParameters: Basic
-
Rank - Dimensionality of the problem, 1 to 3 (warning: not recently
tested for Rank !=2). Default: 3
-
GridDims - This sets the actual dimensions of the baryon grid that
is to be created (and so it may be smaller than MaxDims in some cases).
Example: 64 64 64 No default.
-
ParticleDims - Dimensions of the particle grid that is to be created.
No default.
-
InitializeGrids - Flag indicating if the baryon grids should be
produced (set to 0 if inits is being run to generate particles only). Default:
1
-
InitializeParticles - Flag indicating if the particles should be
produced (set to 0 if inits is being run to generate baryons only). Default:
1
-
ParticlePositionName - This is the name of the particle position
output file. This HDF file contains one to three Scientific Data Sets (SDS),
one for dimensional component. Default: ParticlePositions
-
ParticleVelocityName - The particle velocity file name, which must(!)
be different from the one above, otherwise the order of the SDS's will
be incorrect. Default: ParticleVelocities
-
ParticleMassName - This is the name of the particle mass file, which
is generally not needed (both KRONOS and enzo generate their own if not
provided). Default: None
-
GridDensityName - The name of the HDF which contains the grid density
SDS. Default: GridDensity
-
GridVelocityName - The name of the HDF file which contains the SDS's
for the baryonic velocity (may be the same as GridDensityName). Default:
GridVelocity
-
GridParameters: Advanced
-
MaxDims - All dimensions are specified as one to three numbers deliminated
by spaces (and for those familiar with the KRONOS or ZEUS method of specifying
dimensions, the ones here do not include ghost zones). An example is: 64
64 64. MaxDims are the dimensions of the conceptual high-resolution
grid that covers the entire computational domain. For a single-grid initialization
this is just the dimension of the grid (or of the particle grid if there
are more particles than grid points). For multi-grid initializations, this
is the dimensions of the grid that would cover the region at the highest
resolution that will be used. It must be identical across all parameter
files (for multi-grid initializations). The default is the maximum of GridDims
or ParticleDims, whichever is larger (in other words unless you are using
a multi-grid initialization, this parameter does not need to be set). Confused
yet?
-
GridRefinement - This integer is the sampling, for the baryon grid,
in each dimension, relative to MaxDims. For single-grid initializations,
this is generally 1. For multi-grids, it is the refinement factor relative
to the finest level. In other words, if the grid covered the entire
computational region, then each value in MaxDims would equal GridDims times
the GridRefinement factor. Default: 1
-
ParticleRefinement - Similar function as above, but for the particles.
Note that it can also be used to generate fewer particles than grids (i.e.
the GridRefinement and ParticleRefinement factors do not have to be the
same). Default: 1
-
StartIndex - For single-grid initializations, this should be the
zero vector. For multi-grid initializations it specifies the index (a triplet
of integers in 3D) of the left-hand corner of the grid to be generated.
It is specified in terms of the finest conceptual grid and so ranges from
0 to MaxDims-1. Note also that for AMR, the start and end of a sub-grid
must lie on the cell-boundary of it's parent. That means that this number
must be divisible by the Refinement factor. The end of the sub-grid will
be at index: StartIndex + GridRefinement*GridDims. The co-ordinate
system used by this parameter is always the unshifted one (i.e. it does
not change if NewCenter is set). StartIndex may also be set by the
next parameter which is in the shifted co-ordinate system. Default: 0 0
0
-
StartIndexInNewCenterTopGridSystem - This is an alternative mechanism
for setting StartIndex (for a multi-grid initialization). It differs
in two ways: (1) the index is specified in the root (or top) grid co-ordinate
system so that is ranges from zero to GridDims-1 of the root grid; (2)
it is in the shifted co-ordinate system, so that setting NewCenter (or
NewCenterFloat) changes the meaning of this parameter. Note that
in some ways this is easier, since if NewCenter is set, then this parameter
is always relative to the center of the root grid (see the multi-grid initializtion
example above). If set, this over-rides the value of StartIndex.
Also, if used, this parameter requires that the next one be set as well
as the RootGridDims parameter. Default: none
-
EndIndexInNewCenterTopGridSystem - This parameter forms a pair with
the previous parameter and specifies the ending index (including the final
point) of the region to be refined. As before, it is in the shifted
top grid co-ordinate system. If set, this over-rides the setting
of GridDims. Default: none
-
RootGridDims - This informative parameter tells inits the value
of the root grid dimensions (in a multi-grid initialization). It
is required if the parameters StartI/EndndexInNewCenterTopGridSystem or
NewCenterFloat are specified. Default: none
-
NewCenter - In some cases, for multi-grid initializations, the end
of the sub-grid (as calculated above) may extend beyond the edge of the
computational volume, and be greater than MaxDims-1. This happens when
the region of interest wraps around the grid boundary. In this case, it
is desirable to shift the volume (which is periodic) so that this no longer
occurs. This can be done by specifying a value for NewCenter, which makes
this index (specified in terms of the finest conceptual grid, i.e. MaxDims)
the new center. It affects all grids, including the top grid. The
value of the index+1 must be divisible by the GridRefinement factor of
the root grid. Since these rules are somewhat obscure, you can also
set NewCenter by specifying a float location (see below). Default:
MaxDims/2 - 1
-
NewCenterFloat - This triplet of float values between 0 and 1 sets
the location of the new center of the grid (see above). It is an
easier alternative to setting the integer NewCenter parameter itself.
The nearest location which meets the new center requirements outlined above
will be chosen. Note that if you do specify NewCenterFloat, then
the RootGridDims parameter must also be set. Default: none
Go to the Enzo home page
© 2004 Laboratory for Computational Astrophysics
last modified February 2004
by B.W. O'Shea


Google Earth Enterprise Documentation Home | Fusion tutorial
Importing and Exporting Style Templates
Often when you define the display rules for one set of data, you can use the same display rules (sometimes with minor tweaking) for other similar sets of data. In fact, to make your data look consistent across different layers, you probably want to use the same display rules. To do so, you can simply export as a style template the display rules you want to reuse and then import that style template into other projects.
For example, if a project contains two resources with different providers, and you want the data to look the same except for the copyright information, you can define the display rules for one resource, export the display rules as a template, and then import the template for the other resource. Another example is that you might want to define display rules for a small set of data and then use those same rules on a larger set of data. There are many more circumstances in which you can save time by using style templates.
This lesson guides you through the process of defining display rules for a small set of data (the state of California) and then exporting those rules as a style template. In a subsequent exercise, you import that same style template for a larger set of data (the entire US). Since you already defined display rules for population by county in the state of California in the last chapter, most of the work is already done.
Note: If you have not completed Configuring Display Rules for Polygon Data, you must complete at least the first three exercises in that lesson (Define and Build a Vector Resource Using Polygon Data, Define, Configure, and Build a Vector Project, and Define and Build an Imagery Project) before continuing with this lesson.
- Export the Display Rules
- Import the Template
- Define, Build, Push, and Publish a Database for Your Data
- View Your Data in Google Earth EC
Export the Display Rules
- Select Asset Manager from the Tools menu.
The Asset Manager appears.
- Navigate to the
/ASSET_ROOT/Projects/Vector
folder you created in Configuring Display Rules for Polygon Data. - Double-click CACountyPopulation to open it in the Vector Project Editor.
- Right-click CACountyPopulation, and select Export Configuration as Template from the context menu.
The Export Template dialog appears.
- Navigate to your home folder, and click to create a new folder; name the new folder templates.
- Open the templates folder, enter Counties in the File name field, and click Save.
You return to the Vector Project Editor.
- Close the Vector Project Editor.
Import the Template
This exercise walks you through importing the template you created in the previous exercise into a new project.
To define a project and import a template:
- Click on the toolbar. The Vector Project Editor appears.
- Click . The Open dialog appears.
- Navigate to the
ASSET_ROOT/Resources/Vector
folder. - Select USPopulation, and click Open.
The US Population resource appears in the Vector Project Editor.
- Right-click USPopulation, and select Import Configuration from Template from the context menu.
The Import Template dialog appears.
- Navigate to the folder where you saved the template in the previous exercise.
- Select Counties.khdsp.
- Check the box next to Apply display rules but not Apply legend settings at the bottom of the dialog.
If you check the box next to Apply legend settings, this step would apply all of the legend settings for the project from which the template was created to this project, including changing the name of the layer. (See Chapter 5 in the Google Earth Enterprise Fusion Reference Guide for details about these settings.)
- Click Open.
You return to the Vector Project Editor.
- Right-click USPopulation, and select Layer Properties from the context menu.
The Layer Properties dialog appears.
- Click Off next to Initial State to change it to On.
Changing the initial state to on results in the US Population layer being automatically checked (turned on) in Google Earth EC.
- Right-click USPopulation, and select Configure Display Rules from the context menu.
The Configure Display Rules dialog appears.
- Set Max Resolution Level to 14 (or to 12 if you want to save some time).
Tip: Leaving the level set at the default, 18, results in unduly long processing time.
- Click OK.
You return to the Vector Project Editor.
- Select File > Save.
The Save dialog appears.
- Navigate to the
ASSET_ROOT/Projects/Vector
folder. - Enter USPopulation as the name of your project.
- Click Save.
The new project appears in the Asset Manager when you select ASSET_ROOT/Projects/Vector in the asset navigation tree.
Define, Build, Push, and Publish a Database for Your Data
This exercise walks you through the process of defining, building, pushing, and publishing a database using the projects you created in the previous exercise.
To define, build, and push a database:
- Click on the toolbar. The Database Editor appears with no projects selected.
- Click next to Vector Project. The Open dialog appears.
- Navigate to
ASSET_ROOT/Projects/Vector
. - Select the USPopulation project, and click Open. The US Population project appears in the Database Editor next to Vector Project.
- Repeat steps 2 through 4 to add BlueMarble as the imagery project. You do not need to add a terrain project for this exercise. Both projects appear on the list.
- Select File > Save.
- Navigate to the
ASSET_ROOT/Databases
folder. - Enter USPopulation for the name of your database, and click Save.
The name of the database appears on the right when you select the
/ASSET_ROOT/Databases
folder in the asset navigation tree. - Right-click USPopulation, and select Build from the context menu.
Google Earth Enterprise Fusion builds the database. The build process might take a little longer than it has for previous databases, because it is building the project as well, since you did not build the project at the end of the previous exercise.
- Right-click USPopulation, and select Push from the context menu. The Push Database dialog appears.
- Select the server association on the Server Associations drop-down list. The most recent version of the selected database is the default selection on the Version drop-down list.
- Click Push.
Google Earth Enterprise Fusion runs the process of pushing the database to the Google Earth Enterprise Server, and displays a success message when it is done.
To publish a database:
- Access the Google Earth Enterprise Server Admin console in a browser window by going to myserver.mydomainname.com/admin, replacing myserver and mydomainname with your server and domain.
- Sign in with the default credentials:
- Username: geapacheuser
- Password:geeadmin
- Click Databases to display the list of databases pushed to the Server.
- Check the box next to the database you want to publish. The Publish button on the Databases page appears.
- Click Publish. The Publish dialog appears.
- Specify a Publish point, where the database will be accessible from. For example, if you specify USPopulation-v001, it will be accessible from myserver.mydomainname.com/USPopulation-v001.
To learn more about the options available in the Publish dialog, see Create Search Tabs, Snippet profiles, and WMS.
- Click Publish. The Databases page updates to indicate the published status of your database.
View Your Data in Google Earth EC
This exercise walks you through the process of building, publishing, and viewing your database in Google Earth EC.
To build, publish, and view your database:
- Launch Google Earth EC.
The Select Server dialog appears.
- Enter or select the host name or IP address of your server in the Server field, and specify the Publish point that you selected when you published your map database. For example, if you specify USPopulation-v001, it will be accessible from myserver.mydomainname.com/USPopulation-v001.
- Click Sign In.
Caution: If you have logged in to this server with Google Earth EC previously, log out, clear your cache, and log back in. See clearing your cache.
- Zoom in until you can see part of the US.
- Turn and tilt the Earth so you can see the heights of the counties.
Google Earth EC displays all of the counties in the US labeled with the names of the counties. The closer you zoom in, the more spread out the counties look and the more county names you can see. As with the database you created in Configuring Display Rules for Polygon Data, each county’s height indicates its relative population. Counties with higher populations are taller, and counties with lower populations are shorter.
Note: If you cannot see the vector data, make sure the check box next to US Population in the Layers panel is checked.
If this were a real project, you might decide that displaying the names of the counties makes this view too cluttered. You can go back into the vector project, modify the display rules, rebuild and publish the database, and then view your data in Google Earth EC again. Repeat this process as many times as required to get the result you want.


An isotonic fluid used for diluting blood samples in red blood cell counts. Contains mercuric chloride, sodium sulfate and sodium chloride.
A fluid circulating through the heart, arteries, capillaries, and veins, carrying nutriment and oxygen to body cells, and removing waste products and carbon dioxide. It consists of the liquid portion and the formed elements.
The fluid excreted by the kidneys, stored in the bladder, and discharged through the urethra.
The solid waste that is left after food is digested. Stool forms in the intestines and passes out of the body through the anus.


Simple Steps to Skyrocket Your Time Management Skills
You have probably wished there were more than 24 hours a day to get more work done and spend more time on other meaningful things in your life. Unfortunately, you can not add more hours to a day, but the good news is that you can always learn to use them more wisely.
Plan the work
Productivity is not about doing more things – it is about doing the right things. It is all about planning: mapping the tasks required to achieve the desired goal, and prioritizing: ensuring you are doing the right things. Start by setting up a defined master plan for your project. Then, break the plan down into tasks and subtasks. Set deadlines for the entire project, including each task and subtask – and stick to them. Productivity expert Brian Tracy says that every minute you spend in planning saves 10 minutes in execution. It takes only about 10 to 12 minutes for you to plan out your day, but this small investment of time will save you up to two hours (100 to 120 minutes) in wasted time and diffused effort through the day.
Work the plan
The next step is to perform the defined tasks and sub-tasks in the prioritized order and ahead of set deadlines. David Allen, the creator of the Getting Things Done (GTD) productivity method, recommends having a to-do list for each day: write tasks down in an organized, clear, and simple way. But remember to be realistic about what you can accomplish in a day and do not set yourself up for failure with an unrealistically long agenda. It is recommended that you keep a list of three to eight tasks that you absolutely need to do each day.
Make every second count with time management software
To stick to the project master plan and not miss deadlines, try tracking your time on work, meetings, etc., with time management software. It is eye-opening to dig into work reports that reflect on your productivity and pinpoint ‘time-wasters’ – it improves your work results, optimizes your workload, and improves your planning skills. Did you know that a whopping 87% of high-performing companies use time management or project management software? And for modern organizations, the success of a project initiative will be tied to the tools they use. Spreadsheets are still ruling in the world of general project management, but for time management, centralization, collaboration, and sharing information – spreadsheets are still quite limited.
Declutter your workspace
An organized desk means fewer distractions, a clearer mind, increased productivity, and boosted creativity – so you can get more high-quality work done in less time. David Allen suggests that the workspace should function like a cockpit – all the controls easily accessible as required. This allows maximum focus on your activities, quick over-viewing of the work to be done, and easy ad-hoc processing of all forms of input (from email, paper mail, phone, and live conversation). In addition to decluttering your physical workspace, psychologist Dr. Jean Pollack also points out the importance of ditching the digital clutter. She suggests that digital clutter affects us in the same mental way as physical clutter – it creates confusion. Thus, give your space a quick clean-up at least once per month (and more often if you’re just getting started). Mark decluttering on your calendar, whether it is decluttering digital files or your workspace.