padrino / padrino-framework Goto Github PK

when using bundle lock and datamapper as orm, the application fails to start due to an unitialized constant DataMapper::Timestamps::Model (NameError)

/Library/Ruby/Gems/1.8/gems/rake-0.8.7/lib/rake.rb:2503:in const_missing': uninitialized constant DataMapper::Timestamps::Model (NameError) from /Library/Ruby/Gems/1.8/gems/dm-timestamps-0.10.2/lib/dm-timestamps.rb:58 from /Volumes/Storage/workspace/personal/propers/properdivision/.bundle/environment.rb:206:inrequire'
from /Volumes/Storage/workspace/personal/propers/properdivision/.bundle/environment.rb:206:in require' from /Volumes/Storage/workspace/personal/propers/properdivision/.bundle/environment.rb:201:ineach'
from /Volumes/Storage/workspace/personal/propers/properdivision/.bundle/environment.rb:201:in require' from /Volumes/Storage/workspace/personal/propers/properdivision/.bundle/environment.rb:200:ineach'
from /Volumes/Storage/workspace/personal/propers/properdivision/.bundle/environment.rb:200:in require' from ./config/boot.rb:18 from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:ingem_original_require'
from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in require' from /Library/Ruby/Gems/1.8/gems/padrino-core-0.8.5/bin/../lib/padrino-core/cli/base.rb:22:instart'
from /Library/Ruby/Gems/1.8/gems/thor-0.13.3/lib/thor/task.rb:33:in send' from /Library/Ruby/Gems/1.8/gems/thor-0.13.3/lib/thor/task.rb:33:inrun'
from /Library/Ruby/Gems/1.8/gems/thor-0.13.3/lib/thor/invocation.rb:109:in invoke' from /Library/Ruby/Gems/1.8/gems/thor-0.13.3/lib/thor/invocation.rb:116:incall'
from /Library/Ruby/Gems/1.8/gems/thor-0.13.3/lib/thor/invocation.rb:116:in invoke' from /Library/Ruby/Gems/1.8/gems/thor-0.13.3/lib/thor.rb:137:instart'
from /Library/Ruby/Gems/1.8/gems/thor-0.13.3/lib/thor/base.rb:378:in start' from /Library/Ruby/Gems/1.8/gems/thor-0.13.3/lib/thor.rb:124:instart'
from /Library/Ruby/Gems/1.8/gems/padrino-core-0.8.5/bin/padrino:7
from /usr/bin/padrino:19:in `load'
from /usr/bin/padrino:19

this error can be reproduced by creating a project using datamapper as the orm, and bundle lock the application.

In the latest versions of Padrino, the routing system is now merged into padrino-core. One user sent me a message expressing a concern that in sinatra_more, users could add routing to an existing Sinatra application. However, in Padrino, the cool routing system is not a separate plugin and therefore cannot be used in a plain Sinatra application.

In my opinion, the routing system (minus the controller stuff) should be extracted into a seperate padrino-routing gem again allowing it to be used in a plain jane Sinatra application. I like the idea that the major components of Padrino can all be used standalone and cherry-picked. I created a wiki page to that effect:

http://wiki.github.com/padrino/padrino-framework/standalone-usage-in-sinatra

Let me know what you think about this idea. I think it benefits us to keep the functionality modular. Perhaps the controller stuff should only be in core but the routing system itself (named aliases, with, parent, etc) can be applied to any sinatra-based app?

Could be as simple to use in an existing sinatra app as:

# app.rb
require 'sinatra/base'
require 'padrino-routing'

class Application < Sinatra::Base
  register Padrino::Routing
end

and this would afford the app the superior routing functionality.

What do you think about remove:

• erb_template
• haml_template

And "private" the render_template (so can be used only from partial method)

?

I ask this because now we have too much way for do the same thing:

• erb
• erubius
• haml
• sass
• builder
• erb_template
• haml_template
• render_template

Personally I love the single/two way for do a thing and for me the better choice is:

render :haml, :'path/to/my/view'

That is more explicit and concise.

What do you think about?

Wanted to try Padrino.
I followed those steps (http://gist.github.com/307591)
But RSpec wasn't installed with bundle install, than padrino ar:migrate wasn't working.

Helpers for check_box_group, radio_button_group which create a set of checkboxes or radio buttons for a form. Pass in a set of options (similar to select helper now) and it returns a set of the checkboxes or radio buttons. add tests as well.

f.radio_button_group :attr, :caption => "...", :options => "same as select options"
f.check_box_group   :attr, :caption => "...", :options => "same as select options"

• fix this issue by allowing all controllers to work after a reload
• write a regression test which ensures this is fixed

stacktrace of example of the error

http://pastebin.com/m4ef93d20

Application works fine, but in console, doesn't recognize(or load) route definitions (in time).

• Add support for destroying existing controller, model, migrations, mailer (--destroy)
• Using thor revoke behavior to perform destroy

What about include in core our Sinatra instead of apply extensions?

These are my reason:

• Less extension, more fast, more robust code
• Sinatra repo is not super super active so is simple for use follow their changes
• Some people think that because we use Sinatra Padrino is the same as +sinatra_more+ or +monk+ or others.

We need a way to allow padrino rake to list available tasks. I tried padrino rake -T but this didn't work. Would work like:

padrino rake -T # or padrino rake list

and then prints out available rake tasks.

anchor tag on url_for ain't there
url_for(:page,:name => 'portfolio', :anchor => "site")

• Add support for configuring generators model, controller, migrations, mailer
• Which component choices to use, where to generate the files, skipping

Make generator for app support creating apps which are not core but are secondary within an existing application directory.

Colon if implied, no colon when set explicitly

f.text_field_block :attr,  :caption => "Hello" # no colon
f.text_field_block :attr # with colon

• rake db:create, db:create:all, db:test:prepare, gems, log:clear, middleware, etc
• perhaps more support for migration controls (for ORMs) such as migrate:down, migrate:up, etc
• creating and migrating databases using padrino binary (or rake and using any of the orms)
• (maybe ties into generator if needed)

If somebody uses Passenger for development, we should allow them to have the log written to a file instead of the console via a configuration option. Right now logger appears to force development to go to the stdout, no?

Whenever we run tests the reload tests change the number on the sample apps and this makes them get recommitted nearly every single time we commit a new revision. Can you have these tests change the number back at the end or somehow prevent this from happening?

If I create a migration increase correctly the number. But when I destroy we don't need to handle version number.

create  db/migrate/001_create_accounts.rb
remove  db/migrate/002_create_accounts.rb

I have tests for my app in test/. If I update a test file and then refresh the app in my browser, it seems that the test file is getting included in Padrino's auto-reloader, which of course causes the app to choke and sputter because the test files weren't meant to be loaded that way. In padrino-core/reloader.rb, is Padrino::Reloader::Stat#rotation loading every .rb file in my project? If so, it would probably be a good idea to exclude test/ or spec/ -- or even better, just reload files in the project root, app/ and lib/ (and possibly config/ too).

when using the admin functionality in the app with the admin_uploader, everything works fine until bundle lock.

/Library/Ruby/Gems/1.8/gems/dm-core-0.10.2/lib/dm-core/model/relationship.rb:381:in method_missing': undefined methodmount_uploader' for Upload:Class (NoMethodError)
from /Library/Ruby/Gems/1.8/gems/dm-core-0.10.2/lib/dm-core/model/property.rb:239:in method_missing' from /Volumes/Storage/workspace/personal/propers/properdivision/app/models/upload.rb:8 from /Library/Ruby/Gems/1.8/gems/padrino-core-0.8.5/lib/padrino-core/loader.rb:76:inrequire'
from /Library/Ruby/Gems/1.8/gems/padrino-core-0.8.5/lib/padrino-core/loader.rb:76:in require_dependencies' from /Library/Ruby/Gems/1.8/gems/padrino-core-0.8.5/lib/padrino-core/loader.rb:74:ineach'
from /Library/Ruby/Gems/1.8/gems/padrino-core-0.8.5/lib/padrino-core/loader.rb:74:in require_dependencies' from /Library/Ruby/Gems/1.8/gems/padrino-core-0.8.5/lib/padrino-core/application.rb:16:ininherited'
from /Volumes/Storage/workspace/personal/propers/properdivision/app/app.rb:1
from /Library/Ruby/Gems/1.8/gems/padrino-core-0.8.5/lib/padrino-core/loader.rb:76:in require' from /Library/Ruby/Gems/1.8/gems/padrino-core-0.8.5/lib/padrino-core/loader.rb:76:inrequire_dependency'
from /Library/Ruby/Gems/1.8/gems/padrino-core-0.8.5/lib/padrino-core/loader.rb:74:in each' from /Library/Ruby/Gems/1.8/gems/padrino-core-0.8.5/lib/padrino-core/loader.rb:74:inrequire_dependency'
from /Library/Ruby/Gems/1.8/gems/padrino-core-0.8.5/lib/padrino-core/mounter.rb:58:in app_object' from /Library/Ruby/Gems/1.8/gems/padrino-core-0.8.5/lib/padrino-core/mounter.rb:19:ininitialize'
from /Library/Ruby/Gems/1.8/gems/padrino-core-0.8.5/lib/padrino-core/mounter.rb:124:in new' from /Library/Ruby/Gems/1.8/gems/padrino-core-0.8.5/lib/padrino-core/mounter.rb:124:inmount'
from /Library/Ruby/Gems/1.8/gems/padrino-core-0.8.5/lib/padrino-core/mounter.rb:115:in mount_core' from /Volumes/Storage/workspace/personal/propers/properdivision/config/apps.rb:20 from /Library/Ruby/Gems/1.8/gems/padrino-core-0.8.5/lib/padrino-core/loader.rb:76:inrequire'
from /Library/Ruby/Gems/1.8/gems/padrino-core-0.8.5/lib/padrino-core/loader.rb:76:in require_dependencies' from /Library/Ruby/Gems/1.8/gems/padrino-core-0.8.5/lib/padrino-core/loader.rb:74:ineach'
from /Library/Ruby/Gems/1.8/gems/padrino-core-0.8.5/lib/padrino-core/loader.rb:74:in require_dependencies' from /Library/Ruby/Gems/1.8/gems/padrino-core-0.8.5/lib/padrino-core/loader.rb:13:inload!'
from ./config/boot.rb:21

Right now when you run generator with no internet, the js cant be fetched and the generator fails. Simply vendor versions of each script with padrino instead of going to the internet.

Padrino should support cucumber support within the generator for testing.

Now we have a good class for log all (or not :D).

We need to unify all application/db/core log through a single class/method.

When we use multiple apps we have a problem with __SINATRA__ images.

Now console handle models, but how load their settings?
I mean db host/password/user for console environment?

padrino-cache gem needs to be worked on. supports fragment and page caching through file store or memcache. supports cache_key from models and the like.

• url_for should support calling to_param on objects url_for(:show, :post => @post) would invoke @post.to_param to get the string to include in url

Hey guys Im working (80% just done) for a static padrino-admin based on web-app-theme

What do you prefer? Current ExtJS version or a web-app-theme

ExtJS Version:

Pro:

• Beautiful and very very user friendly and super fast for end user
• Few few few html/erb/haml code to manage!
• A lot of features (sortable grids, inline editing, popups, ajax uploads etc...)

Cons:

• Need license for commercial use
• It's hard customize the look & feel and personalize
• Some people totally hate javascripts

Static Version

Pro:

• A lot of people love them
• It's simple to customize (with templates)
• Every one know html/css
• No license

Cons:

• No ExtJS extra features like (sortable, dragging, windows etc...)
• Less user friendly

Gemspec is wrong (sass and test/unit)

abstract form builder needs to be loaded before standard form builder

Add padrino rake task which bumps versions of all gems and then another pushes them to gemcutter.

Use this gem: http://github.com/dazuma/versionomy

create rake version:bump:patch, minor, major tasks which bump the version number of all the text files, generates the gemspec.

allow the reply_to option to be set within the mailer

reply_to "[email protected]"

Would be nice if you post something quick about it in the wiki, tried to follow up on the current MongoMapper orm implementation, but for some reason i see it's not working so well when i try it with mongoid.

my fork (including my changes) are in http://github.com/eladmeidar/padrino-framework

Today we finished porting to new static version of padrino-admin.

Here some screenshots: http://twitpic.com/14xjah http://twitpic.com/14xja3 http://twitpic.com/14xj9l http://twitpic.com/14xj9c http://twitpic.com/14xj8n

So my questions:

• We need to redesign style and layout instead of web-app-theme template ?
• We need to add some jquery functions? If yes what you want?
• We need a builtin uploader (with carrierwave) like extjs version?

What do you want in padrino-admin ?

Send us your idea or your template!

Thanks!

See: http://github.com/nesquena/sinatra_more/issues#issue/2

Add regression tests for this issue and patch in padrino

Padrino needs a simple to use before/after filter mechanism that supports running methods before and after a particular set of routes rather than global configuration. Sinatra does not have a mechanism to support this.

Our grouping system could work like this: http://gist.github.com/309381

SimpleApp.controllers :posts do
  # These are public actions, no authentication required
  get :index do; ... end;
  get :show, :with => :id do; ... end;

  # These actions require being authenticated
  group :authenticated do
    before { ensure_user_logged_in! }

    post :create do; ... end
    delete :destroy, :with => :id do; ... end

    after { log_user_modifications! }
  end
end

Route groupings would be separate from controller definitions (but can be embedded within them to further group routes) and would not affect the route url.

Another thing what about

Blog.controllers :frontend, :comments do
    ...
end

Blog.controllers :backend, :comments do
    ...
end

A namespace that accept args.

In this way for those that need a backend (like us with padrino admin) didn't duplicate routes.

Another good enhancement is auto mapping:

namespace :frontend, :comments do
  get(:index){}
end
# mapped url is: /frontend/comments

• padrino-gen controller User :index [:admin, :index]
• padrino-gen mailer User method1 method2 method3

Found a way for fix slash when we use rack.map

• Implement the initial admin gem which supports viewing the data and authentication
• Check another way for build json configurations instead of rjs

Im checking sample app and I notice that after changes in helpers I din't see anymore submit tag.

• Add view helpers (pluralize, simple_format, any other ones worthy)
• ajax helpers from rails
• add ajax adapters for the various js components (rightjs, jquery, prototype)

Mailer views_path should be set properly based on calculated views_path from padrino if possible

Padrino appears to be incompatible with sinatra_warden plugin. This plugin defines routes such as in http://github.com/jsmestad/sinatra_warden/blob/master/lib/sinatra_warden/sinatra.rb#L49

app.post '/unauthenticated/?' do
  # ...
end

app.get '/login/?' do
  # ...
end

and the stacktrace is:

/Library/Ruby/Gems/1.8/gems/usher-0.6.7/lib/usher/util/parser.rb:99:in `parse': undefined method `[]' for nil:NilClass (NoMethodError)
from /Library/Ruby/Gems/1.8/gems/usher-0.6.7/lib/usher/util/parser.rb:30:in `generate_route'
from /Library/Ruby/Gems/1.8/gems/usher-0.6.7/lib/usher.rb:348:in `get_route'
from /Library/Ruby/Gems/1.8/gems/usher-0.6.7/lib/usher.rb:208:in `add_route'
from /Library/Ruby/Gems/1.8/gems/padrino-core-0.8.5/lib/padrino-core/application.rb:383:in `route'
from /Library/Ruby/Gems/1.8/gems/sinatra-0.9.4/lib/sinatra/base.rb:761:in `post'

The basic problem is that the Usher routing system does not support trailing question marks apparently in their routes. Padrino replaces the existing Sinatra routing and this appears to be a difference in what is an acceptable path definition.

Thoughts? We could just be OK with the fact this plugin doesn't work and all routes ending in a question mark will raise an obscure usher error. It is unfortunate though.

The word 'rake' is still in ARGV when when padrino-core/cli/base.rb calls Rake.application.init on line 51. If I patch in an "ARGV.shift' right before that call, the task 'taskname' runs correctly.

padrino-core 0.8.1
rake 0.8.7

Use existing orm extensions by requiring them during padrino-gen to create a uniform and consistent set of steps to configure the database.

• ActiveRecord: http://github.com/bmizerany/sinatra-activerecord
• Sequel: http://github.com/rtomayko/sinatra-sequel
• Datamapper: http://github.com/achiu/sinatra-datamapper/tree/
• Mongomapper:
• Couchdb

Basically, the generator needs to be modified to utilize the features from these extensions and require the appropriate rake tasks to make them work. Change database setup file to reflect new database setup following the orm extension instructions.

• Multiple apps
• Log of ActiveRecord/MongoMapper/DM/etc...

• based on ORM components
• fix the number prefix on migrations (http://guides.rubyonrails.org/migrations.html#whats-in-a-name)
• allow for special names to be interpreted (http://guides.rubyonrails.org/migrations.html#creating-a-standalone-migration)