Re: Re: [Rails-core] Pull requests on Github
Funding for some core team members to be able to dedicate more time to Rails development? That can only help. On Thu, Jul 18, 2013 at 8:48 AM, Rafael Mendonça França rafaelmfra...@gmail.com wrote: I don't think we need to do something. If you look at projects with same size of Rails or closer you will see we are very active. We just released a major feature and, well, I think we deserve some kind of rest. When we need to work you will see that issue page decreasing like crazy. Rafael Mendonça França http://twitter.com/rafaelfranca https://github.com/rafaelfranca On Thu, Jul 18, 2013 at 7:54 AM, Marc Schütz schue...@gmx.net wrote: Thanks for the responses so far. This certainly wasn't meant to criticize the people who work on Rails and put in a lot of their free time. It's just that, quite obviously, for whatever reasons, the Rails team isn't able to keep up with the large number of pull requests (and bug reports anyway). It seems Andrew Vit also talked about this about a month ago, which I hadn't seen before I posted. It was suggested in Andrew's thread and in this one to triage bugs and help reviewing. However, while this might be useful, I don't think lack of reviewing is the real problem. I took a closer look at the open PR's on page 4 (i.e. to avoid the really new ones). Of these, there are: New features: 5 Refactoring:7 Bug fixes: 11 Documentation: 2 Total: 25 With votes from the community: 2 With comm. feedback/suggestions: 8 Open questions for submitter/WIP: 6 Feedback from core team: 12 This means that for most PRs, there has already been some kind of review/feedback from either the community or the core team (i.e. those that I think are members). Open questions/WIP are those where the submitter still needs to do something. There are some others with open questions, but these are waiting for feedback from the core team. Many of the PR's end with someone requesting a specific team members opinion, after which nothing happens. So... I'd like to ask again, what can be done? Give more people commit access? Funding for some core team members to be able to dedicate more time to Rails development? Maybe a better way to prioritize PR's, as Andrew suggested? Make it easier to decide which features are desired? Other options? -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Rails-core] [HELP] - Ruby Drag and Drop script on screen element in Mac OS
Hi Muthu, Actually it isn't that hard. To drag and drop you need 2 things: 1. *Drag:* Click the element, and while holding the mouse button pressed, move the mouse around. You don't need to press the button too hard as this might either break the mouse or make it too difficult to move the mouse with precision (depending on your motor skills). 2. *Drop: *When you have dragged the element to where you want it, simply release the mouse button that you have pressed. DO NOT TURN OFF YOUR MONITOR OR CLOSE YOUR EYES before this step as this might make it too hard to figure out where the element will drop. The above instructions should work with any modern mouse, as long as you press the left mouse button. Don't worry, it isn't that hard to localize this button. Here is an explanation in case you need some extra help: [image: Inline image 1] Hope that helps, but please do write back if you need more help. On Thu, Jun 20, 2013 at 3:51 AM, Muthu Selvan pearl.sel...@gmail.comwrote: Hi All , I am new to the ruby , i want click the object on element ( any object , Ex: Calculator) after click i need Drag and Drop the element continuously for some time , please let me know how to do it in ruby in Mac OS ? Thanks , Muthu Selvan SR -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Rails-core] Correct Use or Naming of Migrations
Keep the discussion on topic, will you? If you want to bash about how Rails sucks for not using foreign keys then open a new thread for that. On Mon, Feb 18, 2013 at 10:32 AM, Rodrigo Rosenfeld Rosas rr.ro...@gmail.com wrote: Em 18-02-2013 09:27, Godfrey Chan escreveu: ... 2. You are correct that schema_format = :ruby does not support vendor-specific features like HStores or other advanced SQL features like foreign key constraints. Foreign key is a basic concept in RDBMS for several years and implemented in all major RDBMS vendors, such as Oracle, PostgreSQL, Firebird, MS SQL Server and MySQL (it is also supported by default nowadays since InnoDB is now the default engine) among many others used in production systems. I can't really recall any RDBMS vendor that doesn't support foreign keys (no one should be really using MyISAM as MySQL engine). It is part of the ANSI SQL specs: http://en.wikipedia.org/wiki/Foreign_key Foreign keys are defined in the ANSI SQL Standard, through a FOREIGN KEY constraint. The syntax to add such a constraint to an existing table is defined in SQL:2003 as shown below... While I agree that HStores, PG schemas and other similar features can be considered advanced ones, foreign keys by no means could be confused as an advanced SQL feature. It's simply essential for any serious application relying on RDBMS, just like transactions support, unique constraints and so forth. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Rails-core] #asset_url helper method
If I remember correctly, asset_path will return the full URL if you set config.action_mailer.asset_host = http://my.assets.com; in your environment file. On Mon, Oct 29, 2012 at 2:24 PM, Scott Carleton carleton.sc...@gmail.comwrote: I haven't had time to test but you're saying the asset_path helper will provide the full url by default? In console within production environment it seems to only return the path which isn't sufficient for html emails. On Friday, October 19, 2012 9:29:57 AM UTC-4, Rafael Mendonça França wrote: I think this is how all the assets helpers work by default. https://github.com/rails/**rails/blob/**e826a5c749f9a4029a3b2a7e3d3714** 98feeb9b10/actionpack/lib/**action_view/asset_paths.rb#**L108https://github.com/rails/rails/blob/e826a5c749f9a4029a3b2a7e3d371498feeb9b10/actionpack/lib/action_view/asset_paths.rb#L108 Rafael Mendonça França http://twitter.com/**rafaelfranca http://twitter.com/rafaelfranca https://github.com/**rafaelfranca https://github.com/rafaelfranca On Thu, Oct 18, 2012 at 8:44 PM, Scott Carleton carleto...@gmail.comwrote: Just putting this out there before I make a pull request. Is there any interest in an asset_url method as a view helper? It would work by using the config.action_controller.**asset_host if it exists and prepending this to the results of asset_path. I have found this necessary when writing html emails and needing a full url path for assets. Since my CDN in the asset_host mirrors my assets in my app it makes perfect sense. Might not be a common enough use case to put into core though. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To view this discussion on the web visit https://groups.google.com/d/** msg/rubyonrails-core/-/**itwdyjwfSJIJhttps://groups.google.com/d/msg/rubyonrails-core/-/itwdyjwfSJIJ . To post to this group, send email to rubyonra...@googlegroups.**com. To unsubscribe from this group, send email to rubyonrails-co...@** googlegroups.com. For more options, visit this group at http://groups.google.com/** group/rubyonrails-core?hl=enhttp://groups.google.com/group/rubyonrails-core?hl=en . -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/eXzbI8y1Cg0J. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Being strict on differentiating between IEC prefixes and SI prefixes.
I'm -1 for this. On Tue, Oct 2, 2012 at 4:53 AM, Jarl Friis j...@softace.dk wrote: One of the greatest things about rails is that it is so standards-compliant, no other framework that I have seen have complied to the HTTP standard (think REST) in such a degree that Rails does. Kudos to you all for that. I think we (Rails community) should follow the line of standards compliance and also take it to the binary prefixes [1], i.e. kilobytes, megabytes, etc. For more than half a decade SI units has been a standard (occupying the prefixes kilo, mega, ...) Since the introduction of computers the prefixes has been misused in the IT industry for powers of 1024 but used correctly (for marketing reasons) by storage manufacturers to mean powers of 1000. In 1999 IEC published the new standard for powers of 1024 (known as binary prefixes[1]). In 2008 this was harmonized with ISO standard in ISO/IEC IEC 8-13:2008 I think it is a good time (for Rails 4) for Rails to conform to these standards. That means that every time a power of 1024 is used the IEC prefixes kibi, mebi, and so on are used and vice versa. Further every time a power of 1000 is used the SI prefixes are used, that is, kilo, mega, and so on and vice versa. I have created a pull request (https://github.com/rails/rails/pull/7819) that implements two things (in two separate commits): 1) Rename all use of 1024 to use IEC prefix names a) Rename of core extension: 2.kilobytes = 2.kibibyte == 2*1024 b) Rename all use of these helpers within the Rails project. c) Ensure that number the prefixes are KiB, MiB when dividing by powers of 1024, and using KB, MB when dividing by powers of 1000 (that is when options[:prefix] = :si) 2) (Re)Introduced the posibility to use SI prefix names (meaning powers of 1000) Introduced SI prefix helpers 2.kilobytes == 2*1000 Impact on Rails itself: None: All the useages has been renamed to use the semantically equivalent method (that is IEC names). Impact on Rails projects: The use of core extensions 2.kilobytes, 2.megabytes will mean something else; A power of 1000 in Rails4 as opposed to a power of 1024 in Rails3. But the old behaviour can still be achieved by using IEC names instead such as 2.kibibytes or 2.mebibytes. Footnotes: [1] http://en.wikipedia.org/wiki/Binary_prefix Jarl -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Being strict on differentiating between IEC prefixes and SI prefixes.
Thanks Geoff, whatever that means. On Tue, Oct 2, 2012 at 3:19 PM, Geoff Harcourt geoff.harco...@gmail.comwrote: OK, pushed. I can't push my own database data up, so I'll get four questions up there for you. -Geoff -- Geoff Harcourt On Tuesday, October 2, 2012 at 4:07 PM, dburry wrote: One of the great things I like about rails is not always being tied to full backwards compatibility causing a more and more bloated core every major release. In my mind a plugin that puts everything back would solve that issue, for those who need it. That other objection still gives me pause though... I suspect the difference between IEC and SI units is still not commonly known even among programmers. So this may not be the right time to do this yet? I dunno, just my thoughts, I'd be happy either way. Just to be clear, this is not just a visual change in prefix, but much a more basic functional mathematical change of how the units are calculated and converted too. A mere prefix would be superficial in comparison. Dave On Tuesday, October 2, 2012 10:30:30 AM UTC-7, Allen Madsen wrote: This pull request poses two problems in my mind. The changes are not backwards compatible, which could lead to some serious head scratching. Secondly, even though they're a standard now, they're not commonly used, which leads to more head scrathing. Allen Madsen http://www.allenmadsen.com On Tue, Oct 2, 2012 at 11:52 AM, Andrés Mejía and...@gmail.com wrote: I'm -1 for this. On Tue, Oct 2, 2012 at 4:53 AM, Jarl Friis ja...@softace.dk wrote: One of the greatest things about rails is that it is so standards-compliant, no other framework that I have seen have complied to the HTTP standard (think REST) in such a degree that Rails does. Kudos to you all for that. I think we (Rails community) should follow the line of standards compliance and also take it to the binary prefixes [1], i.e. kilobytes, megabytes, etc. For more than half a decade SI units has been a standard (occupying the prefixes kilo, mega, ...) Since the introduction of computers the prefixes has been misused in the IT industry for powers of 1024 but used correctly (for marketing reasons) by storage manufacturers to mean powers of 1000. In 1999 IEC published the new standard for powers of 1024 (known as binary prefixes[1]). In 2008 this was harmonized with ISO standard in ISO/IEC IEC 8-13:2008 I think it is a good time (for Rails 4) for Rails to conform to these standards. That means that every time a power of 1024 is used the IEC prefixes kibi, mebi, and so on are used and vice versa. Further every time a power of 1000 is used the SI prefixes are used, that is, kilo, mega, and so on and vice versa. I have created a pull request (https://github.com/rails/**rails/pull/7819https://github.com/rails/rails/pull/7819) that implements two things (in two separate commits): 1) Rename all use of 1024 to use IEC prefix names a) Rename of core extension: 2.kilobytes = 2.kibibyte == 2*1024 b) Rename all use of these helpers within the Rails project. c) Ensure that number the prefixes are KiB, MiB when dividing by powers of 1024, and using KB, MB when dividing by powers of 1000 (that is when options[:prefix] = :si) 2) (Re)Introduced the posibility to use SI prefix names (meaning powers of 1000) Introduced SI prefix helpers 2.kilobytes == 2*1000 Impact on Rails itself: None: All the useages has been renamed to use the semantically equivalent method (that is IEC names). Impact on Rails projects: The use of core extensions 2.kilobytes, 2.megabytes will mean something else; A power of 1000 in Rails4 as opposed to a power of 1024 in Rails3. But the old behaviour can still be achieved by using IEC names instead such as 2.kibibytes or 2.mebibytes. Footnotes: [1] http://en.wikipedia.org/wiki/**Binary_prefixhttp://en.wikipedia.org/wiki/Binary_prefix Jarl -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To post to this group, send email to rubyonra...@googlegroups.**com. To unsubscribe from this group, send email to rubyonrails-co...@** googlegroups.com. For more options, visit this group at http://groups.google.com/** group/rubyonrails-core?hl=enhttp://groups.google.com/group/rubyonrails-core?hl=en . -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To post to this group, send email to rubyonra...@googlegroups.**com. To unsubscribe from this group, send email to rubyonrails-co...@** googlegroups.com. For more options, visit this group at http://groups.google.com/** group/rubyonrails-core?hl=enhttp://groups.google.com/group/rubyonrails-core?hl=en . -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core
Re: [Rails-core] Test Locations in Rails 4
+1. I never saw the point of the existing naming scheme. On Sat, Sep 29, 2012 at 6:39 PM, Luís Ferreira zamith...@gmail.com wrote: Yes, seems obvious. Just pointing that out. But the changes seem really nice and makes the placing of test files more obvious and semantic. On Sep 30, 2012, at 12:36 AM, Mike Moore wrote: On Sep 29, 2012, at 5:17 PM, Luís Ferreira zamith...@gmail.com wrote: One question though, where do routing tests go? /test/routes -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. Cumprimentos, Luís Ferreira -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Behavior of first_or_create
I would definitely expect User.where(:first_name = 'Scarlett').first_or_create(:last_name = O'Hara) to call User.create(:first_name = 'Scarlett', :last_name = O'Hara) if that's not what's happening then I think it's a bug and should be fixed. Matt, do you have a minimal app that shows the problem? I would like to write a test case for Rails that shows this strange behavior. On Tue, Jul 24, 2012 at 2:43 PM, Matt Jones al2o...@gmail.com wrote: I just ran across a weird glitch (IMHO) in find_or_create. The arguments passed to it are *not* added to the conditions for the 'first' part. This is odd, given that it's intended to replace find_or_create_by_* methods, which *did* use the specified values as conditions. I'm unsure on whether this behavior is entirely undesirable, but it's definitely not what I had expected in my use case (ensuring that a join table record exists). Perhaps there should be a variant (find_or_create_exactly, perhaps?) that uses the supplied attributes as additional conditions. If nothing else, the documentation should be updated to reflect this scenario - the last case in the examples *almost* describes this scenario, but the block form used there makes it unclear what: User.where(:first_name = 'Scarlett').first_or_create(:last_name = O'Hara) would do. I also found that DataMapper implements the behavior I was expecting in their first_or_create method: https://github.com/datamapper/dm-core/blob/master/lib/dm-core/model.rb#L448 Thoughts? --Matt Jones -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Could we add a new list for engines developers?
+1 for the forum idea. On Sun, Jul 22, 2012 at 6:32 PM, Ryan Bigg radarliste...@gmail.com wrote: All this talk of categorization sounds almost like there should be some kind of Rails forum for discussing things in, rather than isolated mailing lists. There's an engine for that. https://github.com/radar/forem On Sunday, 22 July 2012 at 5:36 AM, Luís Ferreira wrote: Yes, but engines kinda sucked before 3.1. Now a lot more people are using them. +1 for the list. On Jul 21, 2012, at 2:29 AM, Andrew Kaspick wrote: Here's a past one... http://www.mail-archive.com/engine-users@lists.rails-engines.org/ dead! On Fri, Jul 20, 2012 at 8:28 PM, Ryan Bigg radarliste...@gmail.comwrote: rails-talk is a ghetto. A new engines list would be best. On Saturday, 21 July 2012 at 11:27 AM, Andrew Kaspick wrote: Engine lists have been created in the past, but they're not very active or are dead. -1 to a new engine list and +1 to just asking the questions in rails-talk first On Fri, Jul 20, 2012 at 7:41 PM, TuteC tuteco...@gmail.com wrote: +1 Agree that a Rails engine is in the frontier between custom app code and Rails architecture, yet a client (and not core) of Rails. On Fri, Jul 20, 2012 at 1:20 PM, Rodrigo Rosenfeld Rosas rr.ro...@gmail.com wrote: It is not always clear whether we should use Rails-talk or Rails-core list. In the same way we have a list for Rails documentation and we had one for i18n, would you consider a new list oriented to Engine/Plugins developers? This would be a list we could subscribe for engine-related questions that would't have a very big traffic like the Rails-talk one and I think such a list could be pretty useful for gem authors. Would that be wanted? -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. Cumprimentos, Luís Ferreira -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] perform_deliveries to be set per email / interceptors should he able to stop delivery
-1. I don't see the point of this option. If you don't want to send an email, then don't call the mailer method and that's it. Also: 3. The email content may be spammy and you want to prevent that delivery Well, don't spam your users in the first place! On Thu, Jul 19, 2012 at 7:37 AM, Aditya adityavasu...@gmail.com wrote: It would be nice to have mail interceptor be able to modify the message to prevent delivery. Alternatively it would be nice to also prevent delivery in the mailer itself. The use cases are as follows: 1. User is unsubscribed and you really want to prevent emails being sent to such users. 2. User has a guest account with a temp internal email address, which you do not want to send emails to. 3. The email content may be spammy and you want to prevent that delivery. As such you could do each by wrapping more code around the MyMailer.mail_action(args)/.deliver pattern but it gets repetitive quickly. This is not environment specific which is already handled very well in Rails since ages, this is more transactional. If we can already do this easily, feel free to point me to the right direction. Happy to send patch in due time if this is acceptable. Possible routes i'm thinking are to add options to mail itself (:perform_delivery = determine_delivery(args)) and/or adding ability to prevent delivery from interceptor. Suggestions/Ideas? /cc @mikel https://github.com/mikel @josevalimhttps://github.com/josevalim @spastorino https://github.com/spastorino -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/Xq3K3q2q4QIJ. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Re: Defining #blank for Array.
I use it. It makes total sense to me. If you have a piece of paper with a list of 10 blank lines, how do you know there are exactly 10 blank lines instead of 3 or 7 or 13? On Tue, Jul 10, 2012 at 1:55 PM, Michael Boutros michael.bout...@gmail.comwrote: Do you think anyone currently uses #blank? on enumerables in its current state? It doesn't make sense the way it is right now. Imagine a piece of paper with a list of 10 blank lines. Wouldn't you call that a blank list? On Monday, July 9, 2012 10:50:34 AM UTC-4, Xavier Noria wrote: On Mon, Jul 9, 2012 at 4:38 PM, Michael Boutros michael.bout...@gmail.com wrote: Yes. Your implementation makes sense. I mean, I believe that if blank? was defined on enumerables as all?(:blank?) from the very first day, one could have accepted that definition just fine. But the current definition also makes sense to me. Since this is a fundamental predicate in Active Support that has had this semantic since forever, this modification would be backwards incompatible, and the current definition is also just fine in my opinion, I think we should keep it the way it is. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/WL4-tEq6TT0J. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Virtual attribute
I like the idea because I've also suffered with this problem before. What about passing the class as the second argument like in serialize? class Monkey ActiveRecord::Base attr_virtual :birth_date, Date end On Thu, Jul 5, 2012 at 2:38 PM, Aleksey Magusev lex...@gmail.com wrote: Periodically i need to use *attr_accessor* in models, which will be used in views like *date_select*. In this case will be raised errorhttps://github.com/rails/rails/blob/master/activerecord/lib/active_record/attribute_assignment.rb#L166 because of klass methodhttps://github.com/rails/rails/blob/master/activerecord/lib/active_record/attribute_assignment.rb#L171 call for nil. What do you all think about adding attar_virtual method in ActiveModel to solve this problem? Variants: 1) Columns hash https://gist.github.com/3055907 2) Struct https://gist.github.com/3055890 3) Class https://gist.github.com/3055931 and more. References: http://stackoverflow.com/questions/4971523/attr-accessor-for-a-date-and-problems-using-select-date http://stackoverflow.com/questions/5463337/in-rails-is-there-a-way-to-specify-a-type-youd-like-an-attr-accessor-to-be-an ... -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/73EswiuEVy0J. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] ActiveRecord update_attribute vs update_attributes
+1 for making update_attribute run validations. On Wed, Jun 13, 2012 at 10:37 AM, MikeGehard mike.geh...@gmail.com wrote: Greetings all, I would like to start a conversation about the subtle difference between update_attribute and update_attributes, namely that update_attribute skips validations and update_attributes does not skip validations. I know this has been around for a while but is Rails 4 the time to make them both respect validations? I am willing to do the work if the core team feels like it would be a worthwhile breaking change. I don't have a ton of context on the history but as I talk to more and more beginners (and advanced) Rails folks, that subtle difference does trip people up. Thanks, Mike -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/tdnUJ-TqutEJ. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Why locales are not in assets?
You can put them anywhere you want. If you want to put them in assets, just
add
config.i18n.load_path += Dir[Rails.root.join('assets', 'locales',
'*.{rb,yml}').to_s]
to your config/application.rb file.
On Thu, Apr 5, 2012 at 11:35 AM, Rafael Mendonça França
rafaelmfra...@gmail.com wrote:
You can put it inside the app directory too. Both are loaded.
--
*Rafael Mendonça França*
http://twitter.com/rafaelfranca
https://github.com/rafaelfranca
Sent with Sparrow http://www.sparrowmailapp.com
On Thursday, 5 April, 2012 at 13:05, Alexey wrote:
I give up about calling them assets, but maybe locales can be at least in
app/ directory?
On Wednesday, April 4, 2012 11:40:51 PM UTC+2, Ryan Bigg wrote:
You're right that they're not downloadable. They're still used in the
process of generating assets that are downloadable. The ones that are
downloadable live in public/assets anyway.
--
You received this message because you are subscribed to the Google Groups
Ruby on Rails: Core group.
To view this discussion on the web visit
https://groups.google.com/d/msg/rubyonrails-core/-/FJeSmbkwA0MJ.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
--
You received this message because you are subscribed to the Google Groups
Ruby on Rails: Core group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
--
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Generating new project creates a few files with bad syntax Rails 3.2.1
I don't mean to offend, but you are one of the most annoying people to ever write to this list. On Fri, Mar 2, 2012 at 6:05 PM, Mark Peterson playersp...@gmail.com wrote: On Friday, March 2, 2012 5:37:17 PM UTC-5, Mark Peterson wrote: On Friday, March 2, 2012 5:25:30 PM UTC-5, Prem Sichanugrist wrote: Oh, I put the period in the `` because the sentence ended there. Sorry if that's confused you. The correct code is this: some_method(name: 'bob', age: 25) - Prem Any programmer worth his salt disobeys the imperfection of quotation punctuation rules :) Putting a period inside the quotes is like having two opening tags but only one closing tag. Should I not tempt Oxford Grammar? Then template that sentiment in your feelings for Java. :) -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/CCxXxD59MokJ. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] New to Ruby on Rails - Assigning variation (like size or color) to products
This list is used to discuss Rails' internal details. For this kind of questions, use Rails Talk: http://groups.google.com/group/rubyonrails-talk/ On Wed, Feb 22, 2012 at 6:13 PM, Kisha M Richardson kisha.richard...@gmail.com wrote: Hey Everyone, I'm completely new to ruby. I'm building my 1st little app to aid the learning process (nothing like learning by doing) and to support others who want to raise a little seed money to fund traction efforts without equity or debt strings attached I'm plugging away trying to learn the basics of Rails for the last couple of weeks and have realized that I simply to don't know enough Ruby, to truly build what I'm trying to build. I need help with two things: #1 - Can you all recommend your Top 3 must have books that will help me become more proficient with in the actual language of ruby and ruby recipes. Suggestions on books that aid in exploring Active Record in depth would also be humbly appreciated. #2 - As mentioned, I'm building a little store. I'm trying to allow users to select a unique size for the t-shirt. I'm using version 3.2.1 - I've created a model called product_variation and tried to use the new 'store' -- i.e., ActiveRecord::Base.store for declaring simple single-column key/value stores (which I think is new in 3.2.1) - THEN I even an entire whole scaffold, called product_instance - to sit between product line_item to attempt to create a special instance of the product (i.e., category - product -* product_instance* - line_item - cart - order). No luck in making the actual connection. I know this has EVERYTHING to do with me being new to the language, but If could get a little guidance on how to resolve this it would be extremely appreciated. - GIT HUB: Here is my git hub link https://github.com/kisha/seedtp_alpha2 (the tag for the sizes is there but the logic behind it is blowing up) - HEROKU: Here is yesterday's version of the site on heroku (made a few adjustments but just so that you have a visual) http://stproject.herokuapp.com Again, Thanks in advance for the help Sincere Regards, Kisha Richardson -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Automatic parameter bindings in controllers by argument names (like in Merb)
I don't know if this was discussed already, but it's definitely a great
idea!
On Wed, Sep 7, 2011 at 8:54 PM, Rodrigo Rosenfeld Rosas
rr.ro...@gmail.comwrote:
Is there any reason why Rails decided not to support argument binding in
controller actions like Merb?
https://github.com/wycats/**merb/tree/master/merb-action-**argshttps://github.com/wycats/merb/tree/master/merb-action-args
The idea is to be able to do stuff like this:
class MyController ApplicationController
def find(term, limit=10, offset=0)
# if params[:limit] exists, it would be passed as the limit argument
when the method is called by ActionDispatcher. Otherwise, 10 would be
assumed
# raise BindingNotPresent unless params[:term].present?
end
end
Grails 2 will also bring such kind of feature and, as types can be
optionally declared in Groovy, it is able to automatically type cast params
too.
As a curious note, Perl 6 has a great feature (among several others) that
will enable you to write a main function that will bind arguments from the
command line to the function params names too:
http://perlgeek.de/en/article/**5-to-6#post_14http://perlgeek.de/en/article/5-to-6#post_14
---
# file doit.pl
#!/usr/bin/perl6
sub MAIN($path, :$force, :$recursive, :$home = '~/') {
# do stuff here
}
# command line
$ ./doit.pl --force --home=/home/someoneelse file_to_process
---
I like this style of automatic bindings.
I'm not sure if one can inspect method arguments names in Ruby 1.8 though,
but I guess this is possible since it seems that Merb supported this feature
on Ruby 1.8 too...
Was this feature already suggested on this list? If so, what was the reason
it was rejected? Performance impact, maybe?
Thanks in advance,
Rodrigo.
--
You received this message because you are subscribed to the Google Groups
Ruby on Rails: Core group.
To post to this group, send email to
rubyonrails-core@googlegroups.**comrubyonrails-core@googlegroups.com
.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@**googlegroups.comrubyonrails-core%2bunsubscr...@googlegroups.com
.
For more options, visit this group at http://groups.google.com/**
group/rubyonrails-core?hl=enhttp://groups.google.com/group/rubyonrails-core?hl=en
.
--
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Javascript is now a first-class code citizen - Really?!
I like Jasmine too.
On Wed, Aug 31, 2011 at 1:45 PM, Wael Nasreddine
wael.nasredd...@gmail.comwrote:
On Aug 31, 2011, at 20:14, Nicolás Sanguinetti
h...@nicolassanguinetti.info wrote:
On Wed, Aug 31, 2011 at 3:10 PM, Wael Nasreddine
wael.nasredd...@gmail.com wrote:
+1 too, jasmine for unit testing and capybara for integration tests
Well… make Jasmine optional and I'm a happy camper :)
From our experience with all rails features, rspec, test-unit, haml,
erb etc.. I don't think anything would be mandatory, but instead
through generators and we choose whatever we want... Anyway Jasmine is
my preference for unit testing and what i said is mere suggestion :)
Wael
Regards,
Wael
--
Wael Nasreddine
Sent from my iPhone
On Aug 31, 2011, at 19:46, Everton Moreth everton.mor...@gmail.com
wrote:
A standard javascript testing library would be awesome.
Today we struggle with lots of different aproaches to test javascript,
using
only selenium, capybara/selenium, cucumber/capybara/selenium, jasmine,
etc... And other non Rails techniques. It would be great if we could
rely
and focus on a single framework to develop to and help.
+1
Everton Moreth
On Wed, Aug 31, 2011 at 10:06 AM, Rodrigo Rosenfeld Rosas
rr.ro...@gmail.com wrote:
Hi guys,
While reading the 3.1 release notes in Rails Guides, I've stumbled
across
this phrase:
The major change in Rails 3.1 is the Assets Pipeline. It makes CSS and
JavaScript first-class code citizens and enables proper organization,
including use in plugins and engines.
Then, I started thinking that it might not be really true. I guess,
that
it is time for Rails to adopt a default testing framework for
Javascript
(both unit and integration).
There should also exist a Javascript generator that would generate the
empty test file too. It would also be interesting if we could generate
views
with --include-javascript, which would include a new file, like, for
instance, with jQuery:
jQuery(function($){
// place your code here.
})
Is there already something like this in Rails? I don't remember reading
anything about Javascript TDD natively with Rails.
It seems like Capybara has became the defacto solution for this kind of
test. Maybe it could be the default Javascript test framework (using
webkit
by default, maybe).
Any thoughts?
Cheers,
Rodrigo.
--
You received this message because you are subscribed to the Google
Groups
Ruby on Rails: Core group.
To post to this group, send email to rubyonrails-core@googlegroups.com
.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
--
You received this message because you are subscribed to the Google
Groups
Ruby on Rails: Core group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
--
You received this message because you are subscribed to the Google
Groups
Ruby on Rails: Core group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
--
You received this message because you are subscribed to the Google Groups
Ruby on Rails: Core group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
--
You received this message because you are subscribed to the Google Groups
Ruby on Rails: Core group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
--
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
