padrino-core 0.9.1 → 0.9.2
Sign up to get free protection for your applications and to get access to all the features.
- data/README.rdoc +101 -279
- data/VERSION +1 -1
- data/lib/padrino-core/application/routing.rb +1 -1
- data/lib/padrino-core/cli/adapter.rb +3 -3
- data/padrino-core.gemspec +3 -3
- metadata +45 -92
data/README.rdoc
CHANGED
@@ -4,53 +4,39 @@ Padrino is the godfather of Sinatra.
|
|
4
4
|
|
5
5
|
== Preface
|
6
6
|
|
7
|
-
Padrino is a ruby framework
|
8
|
-
|
9
|
-
|
10
|
-
|
11
|
-
The extreme simplicity of this framework is quite refreshing. We have been using Sinatra a great deal
|
12
|
-
for recent projects. First for small and simple json and xml web services and then even
|
13
|
-
for more complex full-featured applications.
|
14
|
-
|
15
|
-
This gem represents an attempt to make it as fun and easy as possible to code increasingly advanced web applications in Sinatra.
|
7
|
+
Padrino is a ruby framework built upon the excellent {Sinatra Microframework}[http://www.sinatrarb.com].
|
8
|
+
Sinatra is a DSL for creating simple web applications in Ruby with speed and minimal effort.
|
9
|
+
This framework tries hard to make it as fun and easy as possible to code much more advanced web applications by
|
10
|
+
building upon the Sinatra philosophies and foundation.
|
16
11
|
|
17
12
|
== Introduction
|
18
13
|
|
19
14
|
Many people love Sinatra's simplicity and lightweight but often quickly come to miss a great deal
|
20
15
|
of functionality provided by other web frameworks such as Rails when building non-trivial applications.
|
21
16
|
|
22
|
-
The obvious question in these cases might be "Why not just use rails then?". This can often be a viable option
|
23
|
-
but still Rails is quite a large framework with a 'take it or leave it' attitude.
|
24
|
-
|
25
|
-
Personally, we have come to love the philosophy of Sinatra which acts as a thin layer on top of rack
|
26
|
-
often allowing middleware to do most of the work and pulling in additional complexity only when required.
|
27
|
-
|
28
17
|
Our goal with this framework is to match the essence of Sinatra and at the same time create a standard library
|
29
18
|
of tools, helpers and components that will make Sinatra suitable for more complex applications.
|
30
19
|
|
31
|
-
Here is a
|
32
|
-
|
33
|
-
|
34
|
-
|
35
|
-
|
36
|
-
|
37
|
-
|
38
|
-
|
39
|
-
|
40
|
-
|
41
|
-
|
42
|
-
|
43
|
-
|
44
|
-
|
45
|
-
|
46
|
-
|
20
|
+
Here is a brief overview of functionality provided by the Padrino framework:
|
21
|
+
|
22
|
+
Agnostic:: Full support for many popular testing, templating, mocking, and data storage choices.
|
23
|
+
Generators:: Create Padrino applications, models, controllers i.e: padrino-gen project.
|
24
|
+
Mountable:: Unlike other ruby frameworks, principally designed for mounting multiple apps.
|
25
|
+
Routing:: Full url named routes, named params, respond_to support, before/after filter support.
|
26
|
+
Tag Helpers:: View helpers such as: tag, content_tag, input_tag.
|
27
|
+
Asset Helpers:: View helpers such as: link_to, image_tag, javascript_include_tag.
|
28
|
+
Form Helpers:: Builder support such as: form_tag, form_for, field_set_tag, text_field.
|
29
|
+
Text Helpers:: Useful formatting like: relative_time_ago, js_escape_html, sanitize_html.
|
30
|
+
Mailer:: Fast and simple delivery support for sending emails (akin to ActionMailer).
|
31
|
+
Admin:: Builtin Admin interface (like Django)
|
32
|
+
Logging:: Provide a unified logger that can interact with your ORM or any library.
|
33
|
+
Reloading:: Automatically reloads server code during development.
|
34
|
+
Localization:: Full support of I18n language localization and can auto-set user’s locale.
|
35
|
+
|
36
|
+
Keep in mind, the user will be able to pull in these components
|
37
|
+
{seperately into existing Sinatra applications}[http://wiki.github.com/padrino/padrino-framework/standalone-usage-in-sinatra]
|
47
38
|
or use them altogether for a comprehensive upgrade to Sinatra (a full-stack Padrino application).
|
48
39
|
|
49
|
-
Note that all work has been created to be compatible with haml, erb, and erubis and that this gem is intended to be
|
50
|
-
template-agnostic in providing helpers wherever possible.
|
51
|
-
|
52
|
-
Please help me brainstorm and fork the project if you have any ideas to contribute.
|
53
|
-
|
54
40
|
== Installation
|
55
41
|
|
56
42
|
To install the padrino framework, simply grab the latest version from gemcutter:
|
@@ -60,20 +46,31 @@ To install the padrino framework, simply grab the latest version from gemcutter:
|
|
60
46
|
This will install the necessary padrino gems to get you started.
|
61
47
|
Now you are ready to use this gem to enhance your sinatra projects or to create new Padrino applications.
|
62
48
|
|
49
|
+
For a more detailed look at Padrino installation,
|
50
|
+
check out the {Installation Guide}[http://wiki.github.com/padrino/padrino-framework/installation].
|
51
|
+
|
63
52
|
== Usage
|
64
53
|
|
65
54
|
Padrino is a framework which builds on the existing functionality and Sinatra and provides a variety of
|
66
|
-
additional tools and helpers to
|
55
|
+
additional tools and helpers to build upon that foundation. This README and Padrino documentation in general will focus
|
67
56
|
on the enhancements to the core Sinatra functionality. To use Padrino, one should be familiar with the basic
|
68
|
-
usage of Sinatra itself.
|
57
|
+
usage of Sinatra itself.
|
58
|
+
|
59
|
+
Please check out the
|
60
|
+
{Understanding Sinatra}[http://wiki.github.com/padrino/padrino-framework/underlying-sinatra-overview] guide
|
61
|
+
to learn more about these fundamentals.
|
69
62
|
|
70
|
-
|
71
|
-
|
72
|
-
* {Sinatra Github Repo}[http://github.com/sinatra/sinatra]
|
63
|
+
For information on how to use a specific gem in isolation within an existing Sinatra project, checkout the guide for
|
64
|
+
{Using Padrino in Sinatra}[http://wiki.github.com/padrino/padrino-framework/standalone-usage-in-sinatra].
|
73
65
|
|
74
|
-
|
75
|
-
|
76
|
-
|
66
|
+
== Getting Started
|
67
|
+
|
68
|
+
Once a developer understands Sinatra, Padrino is quite easy to get comfortable with since Padrino is simply a superset
|
69
|
+
of existing Sinatra Functionality! Best way to get started with building Padrino applications is to read following resources:
|
70
|
+
|
71
|
+
* {Blog Tutorial}[http://wiki.github.com/padrino/padrino-framework/blog-tutorial] - Step-by-step guide to building a blog application with Padrino.
|
72
|
+
* {Quick Overview}[http://wiki.github.com/padrino/padrino-framework/basic-projects] - Outlines basic generation commands.
|
73
|
+
* {Padrino Examples}[http://wiki.github.com/padrino/padrino-framework/examples] - List of known Padrino applications which can serve as examples.
|
77
74
|
|
78
75
|
== Enhanced Base Application (padrino-core)
|
79
76
|
|
@@ -85,9 +82,6 @@ Padrino has support for an enhanced base application class <tt>Padrino::Applicat
|
|
85
82
|
expands the capabilities of Sinatra::Application and automatically provides the resulting application access to all of
|
86
83
|
the padrino framework's functionalities.
|
87
84
|
|
88
|
-
Similar in spirit to Sinatra itself, Padrino application layout is extremely flexible and can be as small as a single file.
|
89
|
-
However, Padrino provides many extensions which improve upon the ability to construct more complex applications.
|
90
|
-
|
91
85
|
=== Simple Application Definition
|
92
86
|
|
93
87
|
Let us first take a look at the simplest possible Padrino application:
|
@@ -105,12 +99,15 @@ Let us first take a look at the simplest possible Padrino application:
|
|
105
99
|
# and for read better we can divide with controllers
|
106
100
|
controller '/admin' do
|
107
101
|
get '/foo' do
|
108
|
-
'
|
102
|
+
'Url is /admin/foo'
|
109
103
|
end
|
110
104
|
end
|
111
105
|
end
|
112
106
|
|
113
|
-
=== Controllers
|
107
|
+
=== Enhanced Route Definitions and Controllers
|
108
|
+
|
109
|
+
For a complete overview of the Padrino routing and controller system,
|
110
|
+
check out the {Routing and Controller guide}[http://wiki.github.com/padrino/padrino-framework/controllers].
|
114
111
|
|
115
112
|
Suppose we wanted to add additional routes to our Padrino application, and we want to organize the routes
|
116
113
|
within a more structured layout. Simply add a <tt>controllers</tt> or <tt>app/controllers</tt> folder and create a file as such:
|
@@ -121,40 +118,23 @@ within a more structured layout. Simply add a <tt>controllers</tt> or <tt>app/co
|
|
121
118
|
"Text to return"
|
122
119
|
end
|
123
120
|
end
|
124
|
-
|
125
|
-
|
126
|
-
|
127
|
-
Padrino provides support for advanced routing functionality not available within Sinatra. This routing
|
128
|
-
supports named route aliases and easy access to url paths. The benefits of this is that instead of having to
|
129
|
-
hard-code route urls into every area of your application, now we can just define the urls in a
|
130
|
-
single spot and then attach an alias which can be used to refer to the url throughout the application.
|
131
|
-
|
132
|
-
=== Padrino Routing
|
133
|
-
|
134
|
-
Urls mapped here can then be defined within a controller:
|
121
|
+
|
122
|
+
You can also do more complex route alias definitions:
|
135
123
|
|
136
124
|
# app/controllers/example.rb
|
137
|
-
SimpleApp.controllers do
|
125
|
+
SimpleApp.controllers :posts do
|
138
126
|
get :index do
|
139
127
|
...
|
140
128
|
end
|
141
129
|
|
142
|
-
get :
|
143
|
-
#
|
130
|
+
get :show, :with => :id do
|
131
|
+
# url generated is '/posts/show/:id'
|
132
|
+
# access params[:id]
|
144
133
|
end
|
145
134
|
end
|
146
135
|
|
147
|
-
|
148
|
-
|
149
|
-
# app/views/example.haml
|
150
|
-
= link_to "Index", url_for(:index)
|
151
|
-
= link_to "Account", url_for(:account, :id => 1, :name => 'first')
|
152
|
-
|
153
|
-
=== Inline Route Alias Definitions
|
154
|
-
|
155
|
-
The routing plugin also supports inline route definitions in which the url and the named alias
|
156
|
-
are defined together within the controller:
|
157
|
-
|
136
|
+
as well as mapping the route aliases to an explicit url:
|
137
|
+
|
158
138
|
# app/controllers/example.rb
|
159
139
|
SimpleApp.controllers do
|
160
140
|
get :index, :map => '/index' do
|
@@ -165,70 +145,13 @@ are defined together within the controller:
|
|
165
145
|
# access params[:name] and params[:index]
|
166
146
|
end
|
167
147
|
end
|
168
|
-
|
169
|
-
|
170
|
-
|
171
|
-
=== Namespaced Route Aliases
|
172
|
-
|
173
|
-
There is also support for namespaced routes which are organized into a larger grouping:
|
174
|
-
|
175
|
-
# app/controllers/example.rb
|
176
|
-
SimpleApp.controllers :admin do
|
177
|
-
get :show do
|
178
|
-
"Im /admin/show"
|
179
|
-
end
|
180
|
-
|
181
|
-
get :index, :map => "/admin/:id" do
|
182
|
-
"Im /admin/#{params[:id]}"
|
183
|
-
end
|
184
|
-
end
|
185
|
-
|
186
|
-
You can then reference the urls using the same url_for method:
|
187
|
-
|
188
|
-
<%= link_to 'admin show page', url_for(:admin_show, :id => 25) %>
|
189
|
-
<%= link_to 'admin index page', url_for(:admin_index, :id => 25) %>
|
190
|
-
|
191
|
-
If you don't want named routes you can
|
192
|
-
|
193
|
-
# app/controllers/example.rb
|
194
|
-
SimpleApp.controllers "/admin" do
|
195
|
-
get "/show" do
|
196
|
-
"Im /admin/show"
|
197
|
-
end
|
198
|
-
|
199
|
-
get "other/:id" do
|
200
|
-
"Im /admin/#{params[:id]}"
|
201
|
-
end
|
202
|
-
end
|
203
|
-
|
204
|
-
=== Named Params
|
205
|
-
|
206
|
-
With Padrino you can use named params!! See these examples
|
207
|
-
|
208
|
-
# app/controllers/example.rb
|
209
|
-
SimpleApp.controllers :admin do
|
210
|
-
get :show, :with => :id do
|
211
|
-
"Im /admin/show/#{params[:id]}"
|
212
|
-
end
|
213
|
-
|
214
|
-
get :other, with => [:id, :name] do
|
215
|
-
"Im /admin/#{params[:id]}/#{params[:name]}"
|
216
|
-
end
|
217
|
-
end
|
218
|
-
|
219
|
-
You can then reference the urls using the same url_for method:
|
220
|
-
|
221
|
-
<%= link_to 'admin show page', url_for(:admin_show, :id => 25) %>
|
222
|
-
<%= link_to 'admin other page', url_for(:admin_index, :id => 25, :name => :foo) %>
|
223
|
-
|
224
|
-
=== Respond To
|
225
|
-
|
226
|
-
With Padrino you can simply respond to a given format see example:
|
227
|
-
|
148
|
+
|
149
|
+
and even configure the respond_to for each route:
|
150
|
+
|
228
151
|
# app/controllers/example.rb
|
229
152
|
SimpleApp.controllers :admin do
|
230
153
|
get :show, :with => :id, :respond_to => :js do
|
231
|
-
"
|
154
|
+
"Url is /admin/show/#{params[:id]}.#{params[:format]}"
|
232
155
|
end
|
233
156
|
|
234
157
|
get :other, with => [:id, :name], respond_to => [:html, :json] do
|
@@ -238,17 +161,25 @@ With Padrino you can simply respond to a given format see example:
|
|
238
161
|
end
|
239
162
|
end
|
240
163
|
end
|
241
|
-
|
242
|
-
|
243
|
-
|
244
|
-
|
245
|
-
|
164
|
+
|
165
|
+
For a complete overview of the routing and controller system, check out the
|
166
|
+
{Routing and Controller guide}[http://wiki.github.com/padrino/padrino-framework/controllers].
|
167
|
+
|
246
168
|
=== Rendering
|
247
169
|
|
248
|
-
Unlike Sinatra Padrino
|
170
|
+
Unlike Sinatra, Padrino supports automatic template lookups such as:
|
249
171
|
|
250
|
-
#
|
172
|
+
# searches for 'account/index.{erb,haml,...}
|
251
173
|
render 'account/index'
|
174
|
+
|
175
|
+
This render does not require any template engine to be specified and will choose the first one that is discovered.
|
176
|
+
The existing render function works as well if an engine type should be specified:
|
177
|
+
|
178
|
+
# example.haml
|
179
|
+
render :haml, 'account/index'
|
180
|
+
|
181
|
+
For a complete overview of the Padrino rendering system, check out the
|
182
|
+
{Routing and Controller guide}[http://wiki.github.com/padrino/padrino-framework/controllers].
|
252
183
|
|
253
184
|
=== Layout
|
254
185
|
|
@@ -261,26 +192,24 @@ With Padrino you can (like rails do) use for your custom layout, disable it
|
|
261
192
|
|
262
193
|
# Use the layout located in views/layouts/custom.haml
|
263
194
|
layout :custom
|
195
|
+
|
196
|
+
For a complete overview of the layout functionality,
|
197
|
+
check out the {Routing and Controller guide}[http://wiki.github.com/padrino/padrino-framework/controllers].
|
264
198
|
|
265
|
-
===
|
266
|
-
|
267
|
-
|
268
|
-
|
269
|
-
|
270
|
-
|
271
|
-
|
272
|
-
|
273
|
-
gem 'sinatra', :require => 'sinatra/base'
|
274
|
-
gem 'rack-flash'
|
275
|
-
|
276
|
-
This manifest file uses the standard <tt>bundler</tt> gem syntax of which details can be found in the
|
277
|
-
{Bundler README}[http://github.com/wycats/bundler]
|
278
|
-
This gem allows us to place all our dependencies into a single file. Padrino will then automatically require
|
279
|
-
all necessary files (if they exist on the system).
|
199
|
+
=== Mounting Applications
|
200
|
+
|
201
|
+
Padrino applications are all automatically mountable into other Padrino projects. This means that a given Padrino
|
202
|
+
project directory can easily mount multiple applications. This allows for better organization of complex applications,
|
203
|
+
re-usable applications that can be applied (i.e admin, auth, blog) and even more flexibility.
|
204
|
+
|
205
|
+
You can think of mountable applications as a 'full-featured' merb slice or rails engine. Instead of a separate construct,
|
206
|
+
any application can simply be packaged and mounted into another project.
|
280
207
|
|
281
|
-
|
282
|
-
|
283
|
-
|
208
|
+
Padrino stores application mounting information by default within <tt>config/apps.rb</tt>. This file is intended
|
209
|
+
to keep all information regarding what applications are mounted to which uri's.
|
210
|
+
|
211
|
+
For a complete look at mounting applications within a Padrino project,
|
212
|
+
check out the guide on {Mounting Applications}[http://wiki.github.com/padrino/padrino-framework/mounting-applications].
|
284
213
|
|
285
214
|
=== Auto Load Paths
|
286
215
|
|
@@ -289,34 +218,14 @@ functionality for easily splitting up your application into separate files. Padr
|
|
289
218
|
as a convention for establishing database connection. Also, any files within the <tt>lib</tt> folder will be required
|
290
219
|
automatically by Padrino.
|
291
220
|
|
292
|
-
|
293
|
-
|
294
|
-
within your application:
|
295
|
-
|
296
|
-
# app.rb
|
297
|
-
class SimpleApp < Padrino::Application
|
298
|
-
load_paths << ["app/special/*.rb", "some_file.rb"]
|
299
|
-
end
|
300
|
-
|
301
|
-
This will instruct Padrino to autoload these files (and reload them when changes are detected). By default, the load path
|
302
|
-
contains certain paths known to contain important files such as controllers, mailers, models, urls, and helpers.
|
303
|
-
|
304
|
-
Initializers are automatically required and 'registered' during the application startup process. Note that
|
305
|
-
the name of the module must be the name of the file appended with 'Initializer' (i.e sample.rb => SampleInitializer)
|
221
|
+
For a complete overview of auto-loaded paths within Padrino,
|
222
|
+
check out the {Padrino Development Guide}[http://wiki.github.com/padrino/padrino-framework/development-and-terminal-commands].
|
306
223
|
|
307
224
|
=== Application Logging
|
308
225
|
|
309
226
|
Padrino also supports robust logging capabilities. By default, logging information will
|
310
227
|
go to the STDOUT in development (for use in a console) and in an environment-specific log file <tt>log/development.log</tt>
|
311
228
|
in test and production environments.
|
312
|
-
|
313
|
-
You can modify the logging behavior or disable logging altogether:
|
314
|
-
|
315
|
-
# app.rb
|
316
|
-
class SimpleApp < Padrino::Application
|
317
|
-
disable :logging # Turns off logging
|
318
|
-
enable :log_to_file # Forces logging to be written to a file
|
319
|
-
end
|
320
229
|
|
321
230
|
To use the logger within a Padrino application, simply refer to the <tt>logger</tt> method accessible
|
322
231
|
within your app and any controller or views:
|
@@ -326,34 +235,8 @@ within your app and any controller or views:
|
|
326
235
|
get("/test") { logger.info "This is a test" }
|
327
236
|
end
|
328
237
|
|
329
|
-
|
330
|
-
|
331
|
-
|
332
|
-
=== Mounting Applications
|
333
|
-
|
334
|
-
Padrino applications are all automatically mountable into other Padrino projects. This means that a given Padrino
|
335
|
-
project directory can easily mount multiple applications. This allows for better organization of complex applications,
|
336
|
-
re-usable applications that can be applied (i.e admin, auth, blog) and even more flexibility.
|
337
|
-
|
338
|
-
You can think of mountable applications as a 'full-featured' merb slice or rails engine. Instead of a separate construct,
|
339
|
-
any application can simply be packaged and mounted into another project.
|
340
|
-
|
341
|
-
Padrino stores application mounting information by default within <tt>config/apps.rb</tt>. This file is intended
|
342
|
-
to keep all information regarding what applications are mounted to which uri's. An <tt>apps.rb</tt> file has
|
343
|
-
the following structure:
|
344
|
-
|
345
|
-
Padrino.mount("blog").to("/blog")
|
346
|
-
Padrino.mount("website").to("/website")
|
347
|
-
|
348
|
-
This would mount two applications onto the Padrino project, one served from the '/blog' uri namespace and the other
|
349
|
-
served from the '/website' uri namespace. Often a Padrino project directory requires a single 'core' application
|
350
|
-
which is served from the uri root. This can be easily configured using:
|
351
|
-
|
352
|
-
Padrino.mount_core("app_name") # mounts app with class AppName, in file <tt>app/app.rb</tt>
|
353
|
-
Padrino.mount_core("app_name", :app_file => Padrino.root('app.rb')) # now with file in <tt>app.rb</tt>
|
354
|
-
|
355
|
-
This will mount a 'core' application with class AppName from the file 'app.rb' to the uri root which will
|
356
|
-
act as a primary application.
|
238
|
+
For a complete overview of Padrino logger functionality, check out the
|
239
|
+
{Padrino Development Guide}[http://wiki.github.com/padrino/padrino-framework/development-and-terminal-commands].
|
357
240
|
|
358
241
|
=== Development Reloader
|
359
242
|
|
@@ -362,43 +245,10 @@ the need to restart the server. Through the use of a customized Rack middleware,
|
|
362
245
|
are monitored and reloaded whenever changes are applied.
|
363
246
|
|
364
247
|
This makes rapid development much easier and provides a better alternative to 'shotgun' or 'rerun'
|
365
|
-
which
|
366
|
-
|
367
|
-
An application can explicitly enable / disable reloading through the use of options:
|
368
|
-
|
369
|
-
# app.rb
|
370
|
-
class SimpleApp < Padrino::Application
|
371
|
-
disable :reload # reload is disabled in all environments
|
372
|
-
enable :reload # enabled in all environments
|
373
|
-
end
|
374
|
-
|
375
|
-
By default, reloading is enabled in development and disabled in the test and production environments.
|
376
|
-
|
377
|
-
If you want to build a standalone app you need to take some precautions see example:
|
378
|
-
|
379
|
-
# simple_demo.rb
|
380
|
-
PADRINO_ROOT = File.dirname(__FILE__) unless defined? PADRINO_ROOT
|
381
|
-
require 'padrino-core'
|
382
|
-
|
383
|
-
class SimpleDemo < Padrino::Application
|
384
|
-
set :reload, true
|
385
|
-
|
386
|
-
get "/" do
|
387
|
-
"This is a simple Demo!!!"
|
388
|
-
end
|
389
|
-
end
|
248
|
+
which requires the application server to be restarted which makes requests take much longer to complete.
|
390
249
|
|
391
|
-
|
392
|
-
|
393
|
-
Padrino.run! unless Padrino.loaded? # If you enable reloader prevent to re-run the app
|
394
|
-
|
395
|
-
Padrino.load!
|
396
|
-
|
397
|
-
Now you can run simple_demo.rb with:
|
398
|
-
|
399
|
-
$ ruby simple_demo.rb
|
400
|
-
|
401
|
-
Browse http://localhost:3000 edit your file and refresh your page for see changes!
|
250
|
+
For a complete overview of code reloading in development,
|
251
|
+
check out the {Padrino Development Guide}[http://wiki.github.com/padrino/padrino-framework/development-and-terminal-commands].
|
402
252
|
|
403
253
|
=== Terminal Commands
|
404
254
|
|
@@ -408,7 +258,7 @@ common tasks such as starting / stopping the application, executing the unit tes
|
|
408
258
|
The following commands are available:
|
409
259
|
|
410
260
|
# starts the app server (non-daemonized)
|
411
|
-
$ padrino start
|
261
|
+
$ padrino start
|
412
262
|
# starts the app server (daemonized) with given port, environment and adapter
|
413
263
|
$ padrino start -d -p 3000 -e development -a thin
|
414
264
|
|
@@ -421,39 +271,11 @@ The following commands are available:
|
|
421
271
|
# Run/List tasks
|
422
272
|
$ padrino rake
|
423
273
|
|
424
|
-
|
425
|
-
|
426
|
-
lib/tasks/**/*.rake
|
427
|
-
tasks/**/*.rake
|
428
|
-
test/test.rake
|
429
|
-
spec/spec.rake
|
430
|
-
|
431
|
-
In this way you can customize project tasks.
|
432
|
-
|
433
|
-
Using these commands can simplify common tasks making development that much smoother.
|
434
|
-
|
435
|
-
=== Special Folders
|
436
|
-
|
437
|
-
Padrino load these paths:
|
438
|
-
|
439
|
-
project/lib
|
440
|
-
project/models
|
441
|
-
project/shared/lib
|
442
|
-
project/shared/models
|
443
|
-
project/each_app/models
|
444
|
-
|
445
|
-
This mean that you are free to store for example +models+ where you prefer, if you have two or more apps with same
|
446
|
-
models you can use +project+/+shared+/+models+ or +root+/+models+.
|
447
|
-
|
448
|
-
If you have only one app you still use +project+/+app+/+models+ (this is the default padrino-gen choice)
|
449
|
-
|
450
|
-
Remember that if you need to load other paths you can use:
|
451
|
-
|
452
|
-
Padrino.set_load_paths("path/one")
|
453
|
-
|
454
|
-
and if you need to load dependencies use:
|
274
|
+
You can also create custom rake tasks as well. Using these commands can simplify common tasks
|
275
|
+
making development that much smoother.
|
455
276
|
|
456
|
-
|
277
|
+
For a complete overview of Padrino terminal commands, check out the
|
278
|
+
{Padrino Commands Guide}[http://wiki.github.com/padrino/padrino-framework/development-and-terminal-commands].
|
457
279
|
|
458
280
|
== Copyright
|
459
281
|
|
data/VERSION
CHANGED
@@ -1 +1 @@
|
|
1
|
-
0.9.
|
1
|
+
0.9.2
|
@@ -216,7 +216,7 @@ module Padrino
|
|
216
216
|
end
|
217
217
|
|
218
218
|
# Build our controller
|
219
|
-
controller = Array(@_controller).collect
|
219
|
+
controller = Array(@_controller).collect { |c| c.to_s }
|
220
220
|
|
221
221
|
unless controller.empty?
|
222
222
|
# Now we need to add our controller path only if not mapped directly
|
@@ -13,7 +13,7 @@ module Padrino
|
|
13
13
|
|
14
14
|
fork do
|
15
15
|
Process.setsid
|
16
|
-
|
16
|
+
exit if fork
|
17
17
|
File.umask 0000
|
18
18
|
puts "=> Padrino server has been daemonized with pid #{Process.pid}"
|
19
19
|
STDIN.reopen "/dev/null"
|
@@ -25,11 +25,10 @@ module Padrino
|
|
25
25
|
|
26
26
|
if pid
|
27
27
|
File.open(pid, 'w'){ |f| f.write("#{Process.pid}") }
|
28
|
-
at_return { File.delete(pid) if File.exist?(pid) }
|
29
28
|
end
|
30
29
|
|
31
30
|
Padrino.run!(options.host, options.port, options.adapter)
|
32
|
-
|
31
|
+
exit
|
33
32
|
end
|
34
33
|
else
|
35
34
|
Padrino.run!(options.host, options.port, options.adapter)
|
@@ -43,6 +42,7 @@ module Padrino
|
|
43
42
|
print "=> Sending SIGTERM to process with pid #{pid} wait "
|
44
43
|
Process.kill(15, pid) rescue nil
|
45
44
|
1.step(5) { |i| sleep i; print "."; $stdout.flush }
|
45
|
+
File.delete("tmp/pids/server.pid")
|
46
46
|
puts " done."
|
47
47
|
end
|
48
48
|
end
|
data/padrino-core.gemspec
CHANGED
@@ -5,11 +5,11 @@
|
|
5
5
|
|
6
6
|
Gem::Specification.new do |s|
|
7
7
|
s.name = %q{padrino-core}
|
8
|
-
s.version = "0.9.
|
8
|
+
s.version = "0.9.2"
|
9
9
|
|
10
10
|
s.required_rubygems_version = Gem::Requirement.new(">= 0") if s.respond_to? :required_rubygems_version=
|
11
11
|
s.authors = ["Padrino Team", "Nathan Esquenazi", "Davide D'Agostino", "Arthur Chiu"]
|
12
|
-
s.date = %q{2010-
|
12
|
+
s.date = %q{2010-03-01}
|
13
13
|
s.default_executable = %q{padrino}
|
14
14
|
s.description = %q{The Padrino core gem required for use of this framework}
|
15
15
|
s.email = %q{padrinorb@gmail.com}
|
@@ -70,7 +70,7 @@ Gem::Specification.new do |s|
|
|
70
70
|
s.rdoc_options = ["--charset=UTF-8"]
|
71
71
|
s.require_paths = ["lib"]
|
72
72
|
s.rubyforge_project = %q{padrino-core}
|
73
|
-
s.rubygems_version = %q{1.3.
|
73
|
+
s.rubygems_version = %q{1.3.5}
|
74
74
|
s.summary = %q{The required Padrino core gem}
|
75
75
|
|
76
76
|
if s.respond_to? :specification_version then
|
metadata
CHANGED
@@ -1,12 +1,7 @@
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
2
2
|
name: padrino-core
|
3
3
|
version: !ruby/object:Gem::Version
|
4
|
-
|
5
|
-
segments:
|
6
|
-
- 0
|
7
|
-
- 9
|
8
|
-
- 1
|
9
|
-
version: 0.9.1
|
4
|
+
version: 0.9.2
|
10
5
|
platform: ruby
|
11
6
|
authors:
|
12
7
|
- Padrino Team
|
@@ -17,149 +12,109 @@ autorequire:
|
|
17
12
|
bindir: bin
|
18
13
|
cert_chain: []
|
19
14
|
|
20
|
-
date: 2010-
|
15
|
+
date: 2010-03-01 00:00:00 +01:00
|
21
16
|
default_executable: padrino
|
22
17
|
dependencies:
|
23
18
|
- !ruby/object:Gem::Dependency
|
24
19
|
name: sinatra
|
25
|
-
|
26
|
-
|
20
|
+
type: :runtime
|
21
|
+
version_requirement:
|
22
|
+
version_requirements: !ruby/object:Gem::Requirement
|
27
23
|
requirements:
|
28
24
|
- - ">="
|
29
25
|
- !ruby/object:Gem::Version
|
30
|
-
segments:
|
31
|
-
- 0
|
32
|
-
- 9
|
33
|
-
- 4
|
34
26
|
version: 0.9.4
|
35
|
-
|
36
|
-
version_requirements: *id001
|
27
|
+
version:
|
37
28
|
- !ruby/object:Gem::Dependency
|
38
29
|
name: i18n
|
39
|
-
|
40
|
-
|
30
|
+
type: :runtime
|
31
|
+
version_requirement:
|
32
|
+
version_requirements: !ruby/object:Gem::Requirement
|
41
33
|
requirements:
|
42
34
|
- - ">="
|
43
35
|
- !ruby/object:Gem::Version
|
44
|
-
segments:
|
45
|
-
- 0
|
46
|
-
- 3
|
47
|
-
- 2
|
48
36
|
version: 0.3.2
|
49
|
-
|
50
|
-
version_requirements: *id002
|
37
|
+
version:
|
51
38
|
- !ruby/object:Gem::Dependency
|
52
39
|
name: usher
|
53
|
-
|
54
|
-
|
40
|
+
type: :runtime
|
41
|
+
version_requirement:
|
42
|
+
version_requirements: !ruby/object:Gem::Requirement
|
55
43
|
requirements:
|
56
44
|
- - ">="
|
57
45
|
- !ruby/object:Gem::Version
|
58
|
-
segments:
|
59
|
-
- 0
|
60
|
-
- 6
|
61
|
-
- 2
|
62
46
|
version: 0.6.2
|
63
|
-
|
64
|
-
version_requirements: *id003
|
47
|
+
version:
|
65
48
|
- !ruby/object:Gem::Dependency
|
66
49
|
name: thor
|
67
|
-
|
68
|
-
|
50
|
+
type: :runtime
|
51
|
+
version_requirement:
|
52
|
+
version_requirements: !ruby/object:Gem::Requirement
|
69
53
|
requirements:
|
70
54
|
- - ">="
|
71
55
|
- !ruby/object:Gem::Version
|
72
|
-
segments:
|
73
|
-
- 0
|
74
|
-
- 13
|
75
|
-
- 0
|
76
56
|
version: 0.13.0
|
77
|
-
|
78
|
-
version_requirements: *id004
|
57
|
+
version:
|
79
58
|
- !ruby/object:Gem::Dependency
|
80
59
|
name: bundler
|
81
|
-
|
82
|
-
|
60
|
+
type: :runtime
|
61
|
+
version_requirement:
|
62
|
+
version_requirements: !ruby/object:Gem::Requirement
|
83
63
|
requirements:
|
84
64
|
- - "="
|
85
65
|
- !ruby/object:Gem::Version
|
86
|
-
segments:
|
87
|
-
- 0
|
88
|
-
- 9
|
89
|
-
- 7
|
90
66
|
version: 0.9.7
|
91
|
-
|
92
|
-
version_requirements: *id005
|
67
|
+
version:
|
93
68
|
- !ruby/object:Gem::Dependency
|
94
69
|
name: activesupport
|
95
|
-
|
96
|
-
|
70
|
+
type: :runtime
|
71
|
+
version_requirement:
|
72
|
+
version_requirements: !ruby/object:Gem::Requirement
|
97
73
|
requirements:
|
98
74
|
- - "="
|
99
75
|
- !ruby/object:Gem::Version
|
100
|
-
segments:
|
101
|
-
- 2
|
102
|
-
- 3
|
103
|
-
- 5
|
104
76
|
version: 2.3.5
|
105
|
-
|
106
|
-
version_requirements: *id006
|
77
|
+
version:
|
107
78
|
- !ruby/object:Gem::Dependency
|
108
79
|
name: shoulda
|
109
|
-
|
110
|
-
|
80
|
+
type: :development
|
81
|
+
version_requirement:
|
82
|
+
version_requirements: !ruby/object:Gem::Requirement
|
111
83
|
requirements:
|
112
84
|
- - ">="
|
113
85
|
- !ruby/object:Gem::Version
|
114
|
-
segments:
|
115
|
-
- 2
|
116
|
-
- 10
|
117
|
-
- 3
|
118
86
|
version: 2.10.3
|
119
|
-
|
120
|
-
version_requirements: *id007
|
87
|
+
version:
|
121
88
|
- !ruby/object:Gem::Dependency
|
122
89
|
name: mocha
|
123
|
-
|
124
|
-
|
90
|
+
type: :development
|
91
|
+
version_requirement:
|
92
|
+
version_requirements: !ruby/object:Gem::Requirement
|
125
93
|
requirements:
|
126
94
|
- - ">="
|
127
95
|
- !ruby/object:Gem::Version
|
128
|
-
segments:
|
129
|
-
- 0
|
130
|
-
- 9
|
131
|
-
- 7
|
132
96
|
version: 0.9.7
|
133
|
-
|
134
|
-
version_requirements: *id008
|
97
|
+
version:
|
135
98
|
- !ruby/object:Gem::Dependency
|
136
99
|
name: rack-test
|
137
|
-
|
138
|
-
|
100
|
+
type: :development
|
101
|
+
version_requirement:
|
102
|
+
version_requirements: !ruby/object:Gem::Requirement
|
139
103
|
requirements:
|
140
104
|
- - ">="
|
141
105
|
- !ruby/object:Gem::Version
|
142
|
-
segments:
|
143
|
-
- 0
|
144
|
-
- 5
|
145
|
-
- 0
|
146
106
|
version: 0.5.0
|
147
|
-
|
148
|
-
version_requirements: *id009
|
107
|
+
version:
|
149
108
|
- !ruby/object:Gem::Dependency
|
150
109
|
name: webrat
|
151
|
-
|
152
|
-
|
110
|
+
type: :development
|
111
|
+
version_requirement:
|
112
|
+
version_requirements: !ruby/object:Gem::Requirement
|
153
113
|
requirements:
|
154
114
|
- - ">="
|
155
115
|
- !ruby/object:Gem::Version
|
156
|
-
segments:
|
157
|
-
- 0
|
158
|
-
- 5
|
159
|
-
- 1
|
160
116
|
version: 0.5.1
|
161
|
-
|
162
|
-
version_requirements: *id010
|
117
|
+
version:
|
163
118
|
description: The Padrino core gem required for use of this framework
|
164
119
|
email: padrinorb@gmail.com
|
165
120
|
executables:
|
@@ -229,20 +184,18 @@ required_ruby_version: !ruby/object:Gem::Requirement
|
|
229
184
|
requirements:
|
230
185
|
- - ">="
|
231
186
|
- !ruby/object:Gem::Version
|
232
|
-
segments:
|
233
|
-
- 0
|
234
187
|
version: "0"
|
188
|
+
version:
|
235
189
|
required_rubygems_version: !ruby/object:Gem::Requirement
|
236
190
|
requirements:
|
237
191
|
- - ">="
|
238
192
|
- !ruby/object:Gem::Version
|
239
|
-
segments:
|
240
|
-
- 0
|
241
193
|
version: "0"
|
194
|
+
version:
|
242
195
|
requirements: []
|
243
196
|
|
244
197
|
rubyforge_project: padrino-core
|
245
|
-
rubygems_version: 1.3.
|
198
|
+
rubygems_version: 1.3.5
|
246
199
|
signing_key:
|
247
200
|
specification_version: 3
|
248
201
|
summary: The required Padrino core gem
|