[Rails-core] ERb Changes
There was a thread on the Rails main which spawned this idea and I wanted to mention it here in the sacred grounds of rails-core to see what the thoughts were. I'm trying to gauge the perceived probability of this being a worth-while patch. This is currently a bit of rails code that I have repeated many times in many applications.<% for @row in @rows -%> <%= start_form_tag %> <%= text_field :row, :name %> <%= hidden_field(:row, :id) %> <%= end_form_tag %> <% end -%> Its a bit much with the <% and %>. It might be worth making a helper for this code in an application, but then again, its probably not. Its hard to read and repetitious.Therefore, I am proposing the addition of this method in the parser. def o(input) _erabout << input + "\n" endWhich would produce this in the most basic use.<% o "hello" %> <%= "hello %> #these two lines are equal#Taking it a bit further <% for user in @users o user.name + ""end %> #Now, to show how this could really increase code readability... here is a re-write of the code earliest in this post. <% for @row in @rows o start_form_tag o text_field(:row, :name) o hidden_field(:row, :id) o end_form_tag end %>Now, I am afraid of anyone of the temptation that will come to ex-PHP coders who will want to start doing<%o ""o "" o myvar%>However, I believe this is a feature that, when used properly, could really improve ERb readability. I would not suggest making this a "recommended" way to output information, but just a useful helper for creating excellent looking ERb code. Thoughts?-hampton catlinPS: I know this must seem trivial after the "Oracle Debacle of 2006". ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] ERb Changes
I'm more referring to those instances when a full partial with Builder is a bit overkill but then again, line-by-line ERb is a little inelegant and awkward.I just feel that some system like this (and, I like Adam's implementation better) would have low overhead and possibly enable more beautiful code in these "edge-cases". However, looks like this method will end up in my /lib ;)Thanks for the quick feedback.-hampton.On 4/6/06, David Heinemeier Hansson <[EMAIL PROTECTED]> wrote: > > #Now, to show how this could really increase code readability... here is a> > re-write of the code earliest in this post.> >> > <% for @row in @rows> >o start_form_tag > >o text_field(:row, :name)> >o hidden_field(:row, :id)> >o end_form_tag> > end %>>> No comment on whether this is a good idea in general.>> However, it would seem to me to make more sense to maintain the > syntactic indicator that you're inside a tag, and have it be this> instead:>> <% for @row in @rows>% start_form_tag>% text_field(:row, :name)>% hidden_field(:row, :id) >% end_form_tag> end %>This is why we have Builder and default .rxml templates. If you have abig block of code you'd rather not mix with HTML, then make a partialthat uses Builder. rhtml and rxml can be mixed and matched as you please.--David Heinemeier Hanssonhttp://www.loudthinking.com -- Broadcasting Brainhttp://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information managerhttp://www.rubyonrails.com -- Web-application framework___ Rails-core mailing listRails-core@lists.rubyonrails.orghttp://lists.rubyonrails.org/mailman/listinfo/rails-core ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] What are your expectations when updating related objects ?
Here is my problem with such a system.If we took this code bit... > def edit> @contact = Contact.find(params[:id])> @phone = @contact.phone> @phone.attributes = params[:phone] > return if @contact.update_attributes(params[:contact])> # handle validation errors> endAs far as @contact.phone is concerned there is no difference between the caller keeping the reference or acting on it immediately. The @contact would keep the reference to @ contact.phone (I believe it does this already) which is the same reference in @phone. So, in the above example, one would assume that the changes in @phone would be ignored since it seems to be its own independent object. So, at the end of this, @phone's changes would be saved with the saving of @contact. This is totally unexpected. The current setup might take a moment to go... "oh yeah! duh!" but I don't believe it would break expectations the way that the alternative would. -hampton.On 4/17/06, John Wilger <[EMAIL PROTECTED]> wrote: On 4/17/06, Francois Beausoleil <[EMAIL PROTECTED]> wrote:> I'm just wondering what your expectations would be if you saw that code:>> def edit > @contact = Contact.find(params[:id])> @contact.phone.attributes = params[:phone]> return if @contact.update_attributes(params[:contact])> # handle validation errors> end> > What do you expect the phones table to contain: the old values or the> new values ?As Rick already said, AR currently requires you to save the individualAR instances.It would make sense to have the whole tree saved when you save the top-level object, otherwise you have to _know_ which objects areactually tied to database tables and which are just "normal"properties. If one of the purposes of an object-relational mapper isto let the developer concentrate on the application code rather than the database, this is one area where we lose that advantage.However, there are a few isues I can forsee if this was implimented.First there is the potential for huge SQL queries to be madeunecessarily. It may also cause issues when the objects in the subtree are associated with more than one parent object. While these issuescould be resolved, is it worth it to spend time on such things?I, for one, would trade being able to save the whole tree with onecall to save for the other (probably more useful and time-saving) improvements to AR that would likely get dsplaced in order toimpliment this. Besides, if you really need this on a specific set ofmodel classes, it's possible to impliment the behavior using thecallbacks; and the risks I mentioned would at least be localized to that one specific hierarchy.--Regards,John Wilgerhttp://johnwilger.com---Alice came to a fork in the road. "Which road do I take?" she asked. "Where do you want to go?" responded the Cheshire cat."I don't know," Alice answered."Then," said the cat, "it doesn't matter."- Lewis Carrol, Alice in Wonderland ___Rails-core mailing listRails-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
Re: [Rails-core] ganging up on tests and docs
Hey man, I'm up for helping with the docs.My vote: RJS docs.Once you get a list up, make sure to pass the link out here."Let's get it on!" (TM)-hampton.
On 4/26/06, Kevin Clark <[EMAIL PROTECTED]> wrote:
I'll take it. I'll post on my blog about it tonight and get some sortof todo list so we can track who's working on what docs/tests and tryto get sd.rb in on the action (best way to learn about it is to haveto write about it ;) ).
KevOn 4/26/06, Scott Barron <[EMAIL PROTECTED]> wrote:>> On Apr 26, 2006, at 9:57 AM, Tobias Lütke wrote:>> > I don't understand this blog post. The graph looks more then
> > healthy to me.>> The graph doesn't mean much, really. It says that as the code LOC> (measured by whatever he's using to measure LOC) has increased, the> test LOC has increased in roughly the same proportion, and that test
> LOC is some degree lower, in terms of LOC, than code LOC.>> I think what he's driving at is that these lines should be converging> rather than increasing at the same rate. Meaning we should be
> refactoring (lowering the code line) and adding more tests> (increasing the test line). Or that when adding features, the test> line rises at a greater rate than the code line.>> But, test:code LOC ratio doesn't really mean anything. It indicates
> nothing about the coverage of the tests or the quality> ("correctness") of the tests. It makes a big assumption that the> writers of tests are creating perfect tests that cover all scenarios
> the test is intended to cover, and that's never going to be the case,> whether the tests are written by humans or generated automatically.>> There is no one metric for "test quality", there are several
> measurements that can be made. In the context of those other> measurements, this graph might have meaning, perhaps it would> demonstrate a correlation between code:test and coverage, but on its
> own it's pretty pointless, and is just being used an excuse to rant> about something.>> Of course we've got code that could use refactoring, of course there> are areas that could use increased test coverage, and of course we
> could benefit from increased and clarified documentation. What> project isn't like that?>> I agree with Chad and strongly encourage folks to add documentation> and test coverage. Everyone would benefit. A contest could be a
> neat idea if you can come up with some kind of metrics to determine a> "winner", and that they are fair and published.>> -Scott>>> ___
> Rails-core mailing list> Rails-core@lists.rubyonrails.org> http://lists.rubyonrails.org/mailman/listinfo/rails-core
>___Rails-core mailing listRails-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
Re: [Rails-core] ganging up on tests and docs
Isn't having to read the source code for methods A, B, C, and D to figure out what method E does part of the fun?Jokes aside, I absolutely agree. I do think non-public (and non-generated) documentation would be extremely helpful. Often times it is a bit confusing reading the source code if there isn't a bit of a help. So writing comments on methods which are :nodoc: is still useful to those who are digging into the code for the first time or doing plugins. Someone writing a plugin might want to use something that's a bit more low level to keep their plugin as dry as possible and we should encourage that. Having an active documentation writing spree as is suggested in this thread is absolutely a good idea for the public documentation. What I am suggesting is that we focus on this... If you change an "inner" method, write a line or two of method documentation. Just, while you're there writing your patch for some else, just snap in a few programmers notes. If we all do that passively as we work on other stuff, then eventually we will have some smashingly good internal documentation for the project.Thoughts?-hampton On 4/26/06, Jamis Buck <[EMAIL PROTECTED]> wrote: I don't think the presence or absence of documentation ought toindicate whether or not an API is published. The published API iscarved in stone. Any other API is subject to change without notice.As long as we indicate which are part of the published API and which are not, we're fine.Regardless, lack of documentation is a bad thing, for any level ofthe API.- Jamis___Rails-core mailing list Rails-core@lists.rubyonrails.orghttp://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] Filtering with ActiveRecord
I wanted to hit the sonar button and see what the general reaction is to this plugin I've created.Basically the problem it solves is filtering with ActiveRecord.Lets say we have a large set of student records. And, we want to be able to quickly filter down to students with the last name "Smith". Currently, we'd write this.
Student.find_by_last_name(params[:student][:last_name])-or-Student.find(:all, :conditions => [ "last_name = ?", params[:student][:last_name] ])Doing any sort of reusable filtering is a bit peevy. For instance, we might have a certain student, and want to find if this student has any people with his/her same first name:
Student.find(:all, :conditions => [ "last_name = ?", @student.last_name]) and if I want to find with same first and several other attributes, my find becomes more complex. So, you always end up writing some semi-ugly looking code to build the condition string.
Wouldn't it be nice if ActiveRecord could make this a bit easier.For instance,@student.find_matches(:on => [ :last_name, :city ])Viola, it builds a find to get matches. Only explicit matches, you can also use a similar thing for finding with forms.
Let's say you have params[:student] = { :last_name = "Catlin" }. And, anything could have been passed in. Maybe a bunch of different attributes, and we'd like to filter based on that.Student.find_with
(params[:student])...which really works as...Student.find_with(:last_name = "Catlin)Do you guys think this is useful? Its already written and I've been using it on a few projects. I've personally found it useful, but is this the kind of thing that you guys think AR might need? Thoughts/comments/flames welcome.
-hampton.
___
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Filtering with ActiveRecord
Tom,I like what you've done with fixing conditions on the regular find. But, I still like being able to find similar with existing model objects and etc. So, I've extended your code with what I was doing in my code (aka, Razor) but used the really solid foundation you wrote with slice. I think putting our code together like this makes a much more solid plugin.
diff: http://unspace.ca/sliceandrazor.diffzip: http://unspace.ca/slicerazor.zipBoth of our specifications from the previous emails still exist, but with the added avantage of being able to do this with AR objects.
@user.find_matches_on(:last_name, :created_on => :less_than)My original use would not allow for the specification of predicates. But, using your backend, it was simple (flatten that trailing options hash into :created_on_less_than).
Your way of finding via attribute conditions is the same:User.find(:all, :conditions => { :last_name => "Catlin", :created_on_less_than => Time.now} ) #yoursThough, I added this "shortcut".
User.find_with(params[:user])I think it makes really, really nice semantic sense to have this. If someone wants a more full fledged find with limits and offsets, they are free to be more verbose. But, I think find_with(attrib) is a nice addition to ActiveRecord in the style of find_by_*.
Thoughts? Comments? Flames?-hampton.On 5/14/06, Tom Ward <[EMAIL PROTECTED]> wrote:
On 5/13/06, Hampton <[EMAIL PROTECTED]> wrote:> Let's say you have params[:student] = { :last_name = "Catlin" }. And,> anything could have been passed in. Maybe a bunch of different attributes,
> and we'd like to filter based on that.>> Student.find_with (params[:student])>> ...which really works as...>> Student.find_with(:last_name = "Catlin)I've been exploring similar areas with my 'slice and dice' plugin
(svn://rubyforge.org//var/svn/popdog/slice_and_dice/tags/REL-0.1). Italters sanitize_sql to allow conditions passed in a hash (in additionto strings and arrays). i.e:Student.find :all, :conditions => ["last_name = ?", "Catlin"]
can be written as:Student.find :all, :conditions => {:first_name => "Catlin"}This condition hash (hopefully) works not just in finder methods, butalso calculations, etc. It also allows slightly more complex clauses:
Book.find :all, :conditions => {:price_more_than => 50}Book.count :conditions => {:title_starts_with => "Zen and the art of"}It'd be great if you released your code as a plugin. I'd like to see
how you've gone about implementing it, and anything I can learn/stealfor my own. If you've any comments on what I've done, I'd be glad tohear them too.Tom--email : tom at
popdog.net___Rails-core mailing listRails-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
Re: [Rails-core] resend: is there a list of standard keywords in trac?
I'm stepping out there to day this. There are obviously keywords which are re-used time and time again and perhaps could be put in an official list.However, I'm not surprised that people are not jumping towards codifying the keywords list into a strict guildline. If you want to give the new usersadvice, then grab the most popular ones you see and write somedescription. Making keywords "official" at this point is probably overkill, but not so far in the future as to be useless.> or should I just tell potential contributors to ignore them?I think that's overkill. How about, "If you notice your patch being ignoredor want to mark it for attention, then please use sensible keywords when creating a patch or bug listing.How does that work?-hampton.On 5/15/06, Josh Susser < [EMAIL PROTECTED]> wrote:Trying this again, since it was ignored last time (May 10). I've had over 1700 downloads of the PDF slides from my presentation. Would benice to include the keyword list in the update I'm putting togethernow. Is there any interest in using keywords on tickets, or should I just tell potential contributors to ignore them?-In putting together my talk about contributing to Rails, I realized Icouldn't find any write-up anywhere of what keywords are used fortickets in Trac. It seems that people just put any old keywords on tickets, sort of like tagging photos in flickr. But I know there areat least a few keywords that matter, like "docs" and perhaps "tiny",and ones used at release time like "needs_review". Does someone know of a standard list? If not, would it be possible to put our nogginstogether and come up with a list of keywords that the core team caresabout?--Josh Susser http://blog.hasmanythrough.com___Rails-core mailing listRails-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
Re: [Rails-core] Filtering with ActiveRecord
Introducing Patch #5143!http://dev.rubyonrails.org/ticket/5143This patch allows for a hash to be passed into the :condition parameter of the ActiveRecord::Base#find method. The functionality is described in detail in the patch and in the documentation that is with it. If anyone can run the unit tests with the patch to see if it functions correctly with Oracle and Postgres, it would be much appreciated!-hampton. I would look sympathetic to a patch that allowed for hash definitions of :conditions, though. ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Filtering with ActiveRecord
Is there anything I can do to help this patch get vetted quickly and efficiently?-hampton.On 5/21/06, Hampton < [EMAIL PROTECTED]> wrote:Introducing Patch #5143! http://dev.rubyonrails.org/ticket/5143This patch allows for a hash to be passed into the :condition parameter of the ActiveRecord::Base#find method. The functionality is described in detail in the patch and in the documentation that is with it. If anyone can run the unit tests with the patch to see if it functions correctly with Oracle and Postgres, it would be much appreciated!-hampton. I would look sympathetic to a patch that allowed for hash definitions of :conditions, though. ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] AR: DAAP connection adapter?
No, it wouldn't work for AR. And, its not because of the read only nature of DAAP. The real issue is that DAAP is deceptively named. DAAP is not really the database itself, but a service allowing you to get information about an internal music database. Daap is not a reusable database for mulitple database configurations. Basically it goes only as far as "what songs do you have?" and "can i hear one?" that's the connection information passed and delt with. ActiveRecord is meant for versitile databases to make them easier to work with. It would be rather pointless to create a layer for DAAP as its structured and would require a model for each structured data type. Since there is a gem for DAAP it would be trivial to use that object within a project and actively use the DAAP connection during your webserver existance. (I'm not saying it would be fast.)-hampton. On 5/25/06, Jeroen Janssen <[EMAIL PROTECTED]> wrote: Hi,I was wondering if anyone has worked on a Active Record ConnectionAdapter for DAAP yet (possibly using the daapclient gem).If not, any indication on how difficult it is to write a connectionadapter (I'm fairly new to ruby and rails, but I have a fair amount of programming experience)?As far as I currently see, the 'connection' would be readonly, is thata problem for AR?Best regards,Jeroen Janssen___ Rails-core mailing listRails-core@lists.rubyonrails.orghttp://lists.rubyonrails.org/mailman/listinfo/rails-core ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Routing rewrite, checked in
I have an application that broke.This may be an unwanted behaviour, or not, but I was working with this as a feature for using some crazy-routing for pretty urls.url = "" => {"action"=>"index", "id"=>"21", "controller"=>"video"}
then, I would do this.redirect_to(:controller => "video")The url it redirects to is..."video/index/21"While, I would expect (and the previous behaviour was)..
"video"Am I crazy?-hampton.That means its understanding the deletion of the :do directive, but is keeping the :id and :action around.On 6/1/06,
Jamis Buck <[EMAIL PROTECTED]> wrote:
Just a quick update--the routing rewrite has been checked in. We'vealready noticed a few things broken and have patching them thismorning, but we'd love to hear from those of you willing to testtheir apps with the bleeding edge.
Thanks!- Jamis___Rails-core mailing listRails-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
Re: [Rails-core] Routing rewrite, checked in
Let me give you a more full example of what changes after the upgrade. I fully acknowledge this is a hackish way to keep a pretty URL. Whether this is the Best Way doesn't really matter. What should matter is that this breaks applications.
Routing in question:map.connect ':controller/:page_number', :requirements => { :page_number => (/^[0-9]+$/) }We start on a page with the url{"action"=>"index", "id"=>"21", "controller"=>"video"}
or/video/index/21Then, during the rendering of this page, url_for is called as...url_for(:page_number => 3)As of revision 4340ish, this would translate into (good thing in my application!)
"/video/3"As of the current revision, this translates into"/video/3?id=21"Certainly I can re-code things to work with the new revision, but if backwards compatibility is important then this shouldn't happen.
-hampton.On 6/1/06, Abdur-Rahman Advany <[EMAIL PROTECTED]> wrote:
You need to set the id or action to nil, unless you change thecontroller to something else than video it will include all the params...try redirect_to(:controller => "video", :action ="" nil)
-- AbdulHampton wrote:> I have an application that broke.>> This may be an unwanted behaviour, or not, but I was working with this> as a feature for using some crazy-routing for pretty urls.
>> url = "" {"action"=>"index", "id"=>"21",> "controller"=>"video"}>> then, I would do this.
>> redirect_to(:controller => "video")>> The url it redirects to is...>> "video/index/21">> While, I would expect (and the previous behaviour was)..
>> "video">> Am I crazy?>> -hampton.>> That means its understanding the deletion of the :do directive, but is> keeping the :id and :action around.
>> On 6/1/06, *Jamis Buck* <[EMAIL PROTECTED]> [EMAIL PROTECTED]>> wrote:>> Just a quick update--the routing rewrite has been checked in. We've
> already noticed a few things broken and have patching them this> morning, but we'd love to hear from those of you willing to test> their apps with the bleeding edge.>> Thanks!
>> - Jamis> ___> Rails-core mailing list> Rails-core@lists.rubyonrails.org
> 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 mailing listRails-core@lists.rubyonrails.orghttp://lists.rubyonrails.org/mailman/listinfo/rails-core
___
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Routing rewrite, checked in
Further:I was trying to fix my code to use the nil method, and here was the result:url_for(:page_number => 3, :id => nil)"/video/2?id="That's definitely not the desired behaviour.
-hampton.On 6/1/06, Hampton <[EMAIL PROTECTED]> wrote:
Let me give you a more full example of what changes after the upgrade. I fully acknowledge this is a hackish way to keep a pretty URL. Whether this is the Best Way doesn't really matter. What should matter is that this breaks applications.
Routing in question:map.connect ':controller/:page_number', :requirements => { :page_number => (/^[0-9]+$/) }We start on a page with the url{"action"=>"index", "id"=>"21", "controller"=>"video"}
or/video/index/21Then, during the rendering of this page, url_for is called as...url_for(:page_number => 3)As of revision 4340ish, this would translate into (good thing in my application!)
"/video/3"As of the current revision, this translates into"/video/3?id=21"Certainly I can re-code things to work with the new revision, but if backwards compatibility is important then this shouldn't happen.
-hampton.
___
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
[Rails-core] Plugin Discussions
With the other two debates raging on this list, I thought it might be good to breach a subject which fits in nicely with the topics being discussed; that of plugins.Feature-plugins are a great way to incubate big new features because they can easily get testing bases and are good for high-risk plugins (think globalize and file_column). Small-feature plugins should be posted here and tested by people interested in patching for feedback on the tweaks. Small-feature/low risk plugins are too hard to make it worthwhile for regular-users to download a special plugin which could break upon upgrading (just the nature of monkey-patching). They would only really be interesting to the people reading this post. Thus its my feeling that "make a plugin" is far too common of a response on here. I do believe plugins make a great way to build a new patch (its how I do it)... I don't think every simple change to rails-core needs a "substantial user base" to be useful. Though, I think they should be encouraged to be posted here before an official patch is made. So, I would say, "Can you give us a proof of concept plugin?" instead of "make a plugin and get people to use it." Perhaps its a matter of misunderstanding, but I believe clarification of meaning would be helpful to keep the misunderstandings to a minimum. Thoughts? Feelings? Flames? Or, is this a non-issue?-hampton. ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
[Rails-core] Tests Broken!
Looks like some changes made in the Ennumerable extensions had some majorly negative effects on the Summing ability of AR. Sample Errors off mysql: 2) Error: test_should_group_by_summed_field_with_conditions_and_having(CalculationsTest): ArgumentError: wrong number of arguments (2 for 0) ./test/../lib/active_record/associations/association_proxy.rb:123:in `sum' ./test/../lib/active_record/associations/association_proxy.rb:123:in `method_missing' ./test/../lib/active_record/associations/has_many_association.rb:95:in `method_missing' ./test/calculations_test.rb:166:in `test_should_group_by_summed_field_with_conditions_and_having' 3) Error: test_should_sum_scoped_field(CalculationsTest): ArgumentError: wrong number of arguments (1 for 0) ./test/../lib/active_record/associations/association_proxy.rb:123:in `sum' ./test/../lib/active_record/associations/association_proxy.rb:123:in `method_missing' ./test/../lib/active_record/associations/has_many_association.rb:95:in `method_missing' ./test/calculations_test.rb:152:in `test_should_sum_scoped_field' Working on a way around this right now -hampton. ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Tests Broken!
This patch fixes the errors I was getting. On 6/24/06, Coda Hale <[EMAIL PROTECTED]> wrote: On 6/24/06, Hampton <[EMAIL PROTECTED]> wrote: > Looks like some changes made in the Ennumerable extensions had some > majorly negative effects on the Summing ability of AR. Enumerable#sum was overriding AR::Calculations#sum. I opened a ticket for this (#5500 [http://dev.rubyonrails.org/ticket/5500]) with a patch which manually routes #sum to #calculate in AssociationCollection. The unit tests all pass now (MySQL). -- Coda Hale http://blog.codahale.com ___ 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
Re: [Rails-core] Understanding Active Records innards
Pete-I've been toying with a few chapters of a book to do just that.About half is API and uses. Then the other half of the book explains *how* it works. And some of the fun/cool tricks going on inside in the guts to make the usibility so simple. But, its quite a while from being done...-hampton.On 6/29/06, Peter Michaux <[EMAIL PROTECTED] > wrote:Hi,I've used Rails quite a bit. I want to understand the major Rails components well enough to read the Rails source without greatstruggle. Eventually I'd like to know how all the components are wiredtogether but I'd be happy to start with understanding Active Recordthoroughly. For me, the best way to understand something is to build it. I imagine building a simple version of Active Record with just onetype 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 ofexercise exist? Would a tutorial about this be helpful for others? Isthere anyone who can direct me to the most important parts of ActiveRecord? (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 listRails-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
Re: [Rails-core] [Security] validates_numericality_of can be tricked into accepting anything
Nice catch!
+1 from me!
-hampton.
On 7/30/06, Andreas Schwarz <[EMAIL PROTECTED]> wrote:
(I would have posted this to the tracker, but I get an error message
when I try to create a ticket.)
validates_numericality_of uses the regular expression /^[\+\-]?\d+$/,
but because ^ and $ match the start/end of a line, as long as one line
in the input string matches the value is accepted. The solution is to
use \A and \Z instead of ^ and $.
A patch is attached.
Index: activerecord/test/validations_test.rb
===
--- activerecord/test/validations_test.rb (revision 4630)
+++ activerecord/test/validations_test.rb (working copy)
@@ -1013,7 +1013,7 @@
end
-class ValidatesNumericalityTest
+class ValidatesNumericalityTest < Test::Unit::TestCase
NIL = [nil, "", " ", " \t \r \n"]
BIGDECIMAL_STRINGS = %w(12345678901234567890.1234567890) # 30 significent
digits
FLOAT_STRINGS = %w(0.0 +0.0 -0.0 10.0 10.5 -10.5 -0.0001 -090.1 90.1e1
-90.1e5 -90.1e-5 90e-5)
@@ -1021,7 +1021,7 @@
FLOATS = [0.0, 10.0, 10.5, -10.5, -0.0001] + FLOAT_STRINGS
INTEGERS = [0, 10, -10] + INTEGER_STRINGS
BIGDECIMAL = BIGDECIMAL_STRINGS.collect! { |bd| BigDecimal.new(bd) }
- JUNK = ["not a number", "42 not a number", "0xdeadbeef", "00-1", "--3", "+-3", "+3-1",
"-+019.0", "12.12.13.12"]
+ JUNK = ["not a number", "42 not a number", "0xdeadbeef", "00-1", "--3", "+-3", "+3-1",
"-+019.0", "12.12.13.12", "123\nnot a number"]
def setup
Topic.write_inheritable_attribute(:validate, nil)
@@ -1061,7 +1061,7 @@
def invalid!(values)
values.each do |value|
topic = Topic.create("title" => "numeric test", "content" => "whatever",
"approved" => value)
-assert !topic.valid?, "#{value} not rejected as a number"
+assert !topic.valid?, "#{value.inspect} not rejected as a number"
assert topic.errors.on(:approved)
end
end
@@ -1069,7 +1069,7 @@
def valid!(values)
values.each do |value|
topic = Topic.create("title" => "numeric test", "content" => "whatever",
"approved" => value)
-assert topic.valid?, "#{value} not accepted as a number"
+assert topic.valid?, "#{value.inspect} not accepted as a number"
end
end
end
Index: activerecord/lib/active_record/validations.rb
===
--- activerecord/lib/active_record/validations.rb (revision 4630)
+++ activerecord/lib/active_record/validations.rb (working copy)
@@ -554,9 +554,11 @@
# provided.
#
# class Person < ActiveRecord::Base
- # validates_format_of :email, :with => /^([EMAIL
PROTECTED])@((?:[-a-z0-9]+\.)+[a-z]{2,})$/i, :on => :create
+ # validates_format_of :email, :with => /\A([EMAIL
PROTECTED])@((?:[-a-z0-9]+\.)+[a-z]{2,})\Z/i, :on => :create
# end
#
+ # Note: use \A and \Z to match the start and end of the string, ^ and $
match the start/end of a line.
+ #
# A regular expression must be provided or else an exception will be
raised.
#
# Configuration options:
@@ -670,7 +672,7 @@
# Validates whether the value of the specified attribute is numeric by
trying to convert it to
# a float with Kernel.Float (if integer is false) or applying
it to the regular expression
- # /^[\+\-]?\d+$/ (if integer is set to true).
+ # /\A[\+\-]?\d+\Z/ (if integer is set to true).
#
# class Person < ActiveRecord::Base
# validates_numericality_of :value, :on => :create
@@ -691,7 +693,7 @@
if configuration[:only_integer]
validates_each(attr_names,configuration) do |record, attr_name,value|
-record.errors.add(attr_name, configuration[:message]) unless
record.send("#{attr_name}_before_type_cast").to_s =~ /^[+-]?\d+$/
+record.errors.add(attr_name, configuration[:message]) unless
record.send("#{attr_name}_before_type_cast").to_s =~ /\A[+-]?\d+\Z/
end
else
validates_each(attr_names,configuration) do |record, attr_name,value|
___
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
