[Rails-core] Fwd: [Rails] Re: validates_numericality_of positive integer
Maybe the core could make a request?
Peter
-- Forwarded message --
From: Bob Silva <[EMAIL PROTECTED]>
Date: Jan 23, 2006 7:34 PM
Subject: RE: [Rails] Re: validates_numericality_of positive integer
To: [EMAIL PROTECTED]
I hacked together a plugin to add a few parameters to
validates_numericality_of based on your needs and my laziness for explicit
checks.
>From the README:
Adds the following parameters:
(plus the messages generated as an error)
:gt => ## "must be greater than ##"
:gte => ##"must be greater than or equal to ##"
:eq => ## "must be equal to ##"
:lt => ## "must be less than ##"
:lte => ##"must be less than or equal to ##"
:odd => ##"must be an odd number"
:even => ## "must be an even number"
:within => ##..## "must be within ## and ##"
Usage: (in your case)
validates_numericality_of :foo, :integer_only => true, :gt => 0
validates_numericality_of :age, :integer_only => true, :within => 13..100
If RoR team would like to integrate into Rails, have at it. I don't do well
with rejection, so I won't offer it as a patch unless requested.
Download it at:
http://www.umesd.com/better_validates_numericality_of.zip
I'll get it downloadable via script/plugin in due time. Gotta write a few
unit tests first.
Enjoy,
Bob Silva
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:rails-
> [EMAIL PROTECTED] On Behalf Of Wilson Bilkovich
> Sent: Monday, January 23, 2006 2:49 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [Rails] Re: validates_numericality_of positive integer
>
> On 1/23/06, Peter Michaux <[EMAIL PROTECTED]> wrote:
> > anyone?
> >
> > On 1/19/06, Peter Michaux <[EMAIL PROTECTED]> wrote:
> > > Hi,
> > >
> > > What is the simplest way to validate a positive integer?
> > >
> > > validates_numericality_of :foo, :integer_only => true
> > >
> > > how do I add the positive part? Do I need another validation statement
> > > for pattern matching or do I have to write a validate() funciton for
> > > my model?
> > >
>
> I'd go with this, personally:
> def validate
> unless foo_before_type_cast.to_s =~ /^[+]?\d+$/
> errors.add("foo", "is not a valid number")
> end
> end
>
> 500 and +500 are valid, -500, -500.00, 400.12, etc, are not.
> ___
> Rails mailing list
> [EMAIL PROTECTED]
> http://lists.rubyonrails.org/mailman/listinfo/rails
___
Rails mailing list
[EMAIL PROTECTED]
http://lists.rubyonrails.org/mailman/listinfo/rails
___
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Armageddon?
On 4/22/06, David Heinemeier Hansson <[EMAIL PROTECTED]> wrote: > No and no. Going sockets add complexity. Which is fine when you need > it, but Campfire doesn't. You can make polling really, really cheap. > And we did. What did you do to make is so cheap? In Campfire how is this different than three people working on one todo list? Thanks, Peter ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] ganging up on tests and docs
On 4/26/06, Josh Susser <[EMAIL PROTECTED]> wrote: Hey folks, I think Ryan has a good point here: http://blog.zenspider.com/archives/2006/04/where_is_our_ma.html I'll follow that up by saying that besides tests, there's also a lot of documentation work that needs done too. Is there something we can do to improve the situation? PHP style docs website with user comments please:) ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
[Rails-core] Armeggedon development
Hi, What is the status of Armeggedon development? ETA? Is there a preview or code available? Any preliminary docs or blogs? What is required on the server and client sides to make this technology happen? Will Armeggedon depend on prototype.js (please say no)? Can people help develop this? I am developing the admin of an online store with multiple admin users. I'd like to use something like armeggedon to push db changes to admin clients to avoid stale browser data. I don't want to reinvent the wheel if its debut is very soon. Thanks, Peter ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
[Rails-core] Rails wiki needs to by by resgistration only
Hi, The Rails wiki is constantly being attacked. The main page needs to be rolled back almost every time I visit. Can the wiki be made to work with registered users only? Perhaps with an obscured visual key you must type to register? Thanks, Peter ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Too. Many. Scriptaculous. Tickets.
On 6/2/06, Kevin Clark <[EMAIL PROTECTED]> wrote: +1 for no more enhancement tickets. If they want someone to do it, mail one of the lists or do it themselves. Plugins over patches in general. Bugs should still be filed. Why turn down the volunteered creativity and enthusiasm of people interested in these libraries? They could become interested enough to make big code contributions. I think open source projects should be very welcoming and closing the brain storming down would be an unfortunate move. Only if there is another official chanel for enhancement ideas it would be ok to stop the enhancement tickets. Peter ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
[Rails-core] Understanding Active Records innards
Hi, I've used Rails quite a bit. I want to understand the major Rails components well enough to read the Rails source without great struggle. Eventually I'd like to know how all the components are wired together but I'd be happy to start with understanding Active Record thoroughly. For me, the best way to understand something is to build it. I imagine building a simple version of Active Record with just one type of validation, one type of association, and one database adapter. A stripped down Active Record with the same file and class/module structure as the real thing. Does a tutorial about this sort of exercise exist? Would a tutorial about this be helpful for others? Is there anyone who can direct me to the most important parts of Active Record? (I've looked through David Black's book and it doesn't seem to cover the detail of Rails I'm interested in learning.) Thanks, Peter ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Understanding Active Records innards
On 6/29/06, Andrew Kaspick <[EMAIL PROTECTED]> wrote: Why not just implement some ActiveRecord patches? Seems like a good way to learn how it works while helping improve the code base. Patches could be the result but I'd like to have a solid understanding too. Peter ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
[Rails-core] help finishing a patch for label helpers? [#362]
Hi,
I found a plugin on the web for a label helper and modified it to be
more like the rails core form elements behave (errors etc). I really
think this could be good to DRY forms especially with the new CRUD for
everything and likely more reliance on scaffolding. In my _form.rhtml
partial I can now write (abreviated)
<% form_for :category, @category,
:url => {:action=>'update'} do |f| %>
<%= f.label :name %>
<%= f.text_field :name %>
<%= f.label :description, 'The description' %>
<%= f.text_area :description %>
<% end %>
I'm not a rails wizard and don't feel like I could make a quality
patch. Can someone help or tell me what's wrong with my plugin?
View the plugin code online
http://dev.actioncommerce.org/trac/browser/trunk/vendor/plugins/label_helpers/lib/label_helper.rb
Checkout the plugin
svn checkout
http://www.actioncommerce.org/svn/actioncommerce/trunk/vendor/plugins/label_helpers
Thanks,
Peter
The plugin I found doesn't work with form_for and doesn't behave like
the other rails form_helpers. It appends an error string instead of
wrapping the element. I don't think that is as flexible
http://www.eric-stewart.com/svn/rails/plugins/label_helpers/lib/label_helper.rb
___
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] help finishing a patch for label helpers? [#362]
On 7/4/06, Nicholas Seckar <[EMAIL PROTECTED]> wrote: Have you seen the labelling form builder in the test case for form_for? No I haven't. Do you mean in svn? Does it work like my example? Thanks, Peter ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] help finishing a patch for label helpers? [#362]
On 7/4/06, Erik Kastner <[EMAIL PROTECTED]> wrote:
>From rails/actionpack/test/template/form_helper_test.rb
http://dev.rubyonrails.org/browser/trunk/actionpack/test/template/form_helper_test.rb
starting at line 345
class LabelledFormBuilder < ActionView::Helpers::FormBuilder
(field_helpers - %w(hidden_field)).each do |selector|
src = <<-END_SRC
def #{selector}(field, *args, &proc)
"\#{field.to_s.humanize}: " +
super + ""
end
END_SRC
class_eval src, __FILE__, __LINE__
end
end
Thanks for the link.
I think this is a good idea but is not so flexible. If I am reading
this correctly, this will produce
Foo or even better just as the whole form is
part of a .
I think this
<%= f.label :name %>
would be a nice addition to the core also. I've been wanting this for
a long time. The label can also be nicely wrapped in and hiding this can be set individually like
the input elements.
The only reason I don't submit a patch is I don't know if I've got it
right and I don't know if the higher-ups would be receptive.
Peter
___
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] help finishing a patch for label helpers? [#362]
On 7/4/06, Rick Olson <[EMAIL PROTECTED]> wrote: I personally rarely use a plain label helper. It's usually less to type out than the actual label field. But it is not as DRY to type it out directly which, I think, is the whole point of the form builder. <%= f.label_for :name %> is a lot less than name. and the potential for error wrapping is nice with a helper. I'll check out your plugin. Thanks for the link. Peter ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] help finishing a patch for label helpers? [#362]
On 7/4/06, Rick Olson <[EMAIL PROTECTED]> wrote: > I think this is a good idea but is not so flexible. If I am reading > this correctly, this will produce > > Foohttp://svn.techno-weenie.net/projects/plugins/labeled_form_helper/ as more of a proof of concept than anything. Rick, it looks like a little more than hacking. What is stopping your patch from going into the core? Peter ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] help finishing a patch for label helpers? [#362]
On 7/5/06, Rick Olson <[EMAIL PROTECTED]> wrote: The actual label_tag and label helpers are fine, I was just expressing my opinion on the custom LabelingFormBuilder thing that adds labels to other helpers. I don't remember why I never submitted it as a patch. Maybe the rails-core channel wasn't as receptive that particular night :) Rick, Before submitting -- hoping you will -- would you consider adding a class attribute to the label tag called "labelWithError" and an option to suppress this? Peter ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
[Rails-core] Re: help finishing a patch for label helpers? [#362]
Hi, How would people feel about an error_message_on helper? <%= f.label_for :name %> <%= f.text_field :name %> <%= f.error_message_on :name %> I think it would be nice if this returned the error message in a so all messages could be styled easily and consistently. Peter ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
[Rails-core] trac still down
Hi, What's up with the Rails trac? Thanks, Peter ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] trac still down
Hi Marcel, Thanks for the update. Peter On 7/15/06, Marcel Molina Jr. <[EMAIL PROTECTED]> wrote: On Sat, Jul 15, 2006 at 11:31:31AM -0700, Peter Michaux wrote: > What's up with the Rails trac? Between the mailing list and trac, the machine that they've been hosted on for the past year and some now can't take it anymore. We are in the process of splitting the services up across multiple machines. Sorry for the down time. marcel -- Marcel Molina Jr. <[EMAIL PROTECTED]> ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
[Rails-core] If controllers inherit then why not views? / DRY, REST & other buzzwords.
Hi, If I have controllers that inherit actions and helper methods then why not views that "inherit" templates and partials? I've been trying to DRY up my code and make it more REST friendly after the fallout of DHH's "A World of Resources" slides and blog post. With a move towards more RESTful controller design, we are going to have more controllers with the basic 7 actions (index, show, edit, update, new, create, destroy). Much of the functionality of these actions can be moved into ApplicationController to keep our code DRY. This is a move away from scaffold-type controllers and is shown on http://www.artofmission.com/articles/2006/07/05/rest-ful-technique-make-your-controllers-even-smaller It would be great if views could be shared in the same way instances inherit from superclasses. Following the art of mission example, when rendering the page create or edit pages == views/application/new.rhtml == Create a new record <%= render :partial=>'form' %> == views/application/edit.rhtml == Edit a new record <%= render :partial=>'form' %> == views/page/edit.rhtml (overrides views/application/edit.rhtml) == Edit a new PAGE <%= render :partial=>'form' %> == views/page/_form.rhtml == <%= form_tag %> ... <%= end_form_tag %> So when page/new is being rendered views/application/new.rhtml and views/page/_form.rhtml are used since Rails can't find a template called views/page/new.rhtml. When page/edit is being rendered view/page/edit.rhtml and views/page/_from.rhtml are used. So Rails would always starts looking for templates in the view directory corresponding to the controller and keep looking up view directories in a search path that match the controllers inheritance path. For each partial the process would be just the same. I tried to keep this short. All I'm trying to say is make view directories work like classes and make templates work like instance methods. Sound like it would be nice and DRY to effectively share views? Thanks, Peter ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
[Rails-core] [PATCH] Inflector docs minor bug fixes and extra examples
Hi, I can't seem to make a new ticket on trac so I've attached is a pretty simple patch for the inflector docs. I found a couple minor bugs in these docs and added a few extra examples were appropriate. I haven't figured out how to unit test docs yet. Hopefully that's ok :) Peter enhanced_inflector_docs.diff Description: Binary data ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
[Rails-core] Prototype.js needs a couple more people with commit?
Hi, I have been watching for any development in Prototype.js. The last time I was able to check Rails trac (which seems to be down now), it has been a long time since any substantial changes were to Prototype.js. Sam Stevenson seems to be the sole maintainer but his elusiveness makes this feel like a very non-community project which isn't very Rails-ish. The last I read about Sam's plans are from May 23 http://sam.conio.net/ which is a long time ago in the fast moving Rails world. And even those comments don't seem to have a well defined direction. There are quite a few people on the Rails spinoffs list that would like to contribute to the the library. Prototype.js seems to need a class-based OOP overhaul. When IE 7 is released there will likely be the need for some changes. Currently there are known bugs in Prototype.js and patches on trac waiting to be applied. Work needs to get done and if Prototype.js falls too far behind it will be a lot of work to catch up in the future. Eventually Rails apps will start to have problems if they depend on Prototype.js. The majority of the Rails core has multiple maintainers and if one person is busy then others can watch tickets, make commits, etc. Is it time for a couple more people to be added to the Prototype.js commit list? Thank you, Peter ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
