from:"Carlos Antonio da Silva"

Re: [Rails-core] Appending multiple line numbers to run multiple tests

2015-12-05 Thread Carlos Antonio da Silva

I don't remember using that feature of rspec personally, but I see how it
can be useful, so I'd say to try out a PR with the change :)

Carlos Antonio da Silva - via celular
On Dec 5, 2015 2:00 PM, "siva subrahmanyam" <subbu9848155...@gmail.com>
wrote:

> In rspec we can run multiple specs as rspec spe/models/user_spec.rb:4:8 .
> So it would run specs defined at line number 4 and 8. But currently rails 
> testing
> didn't support this feature. Could we add it to rails. Thoughts please?
>
> --
> 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/d/optout.
>

-- 
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/d/optout.

Re: [Rails-core] update_attributes save only if columns changed?

2015-10-02 Thread Carlos Antonio da Silva

Save should already work with partial updates enabled, which means it won't
trigger an actual update on the database unless something has changed, so
there should be no need to check at this point.

Hope that helps.

On Fri, Oct 2, 2015 at 2:12 AM, Sean Teeling  wrote:

> Is there a reason why calling update_attributes saves even if no columns
> were changed? Currently the update_attributes aliases update which is
> defined:
>
> def update(attributes)
> with_transaction_returning_status do
> assign_attributes(attributes)
> save
> end
> end
>
> I was thinking it would be better to do `save if changed?`
>
> Thoughts? Sorry if this has been posted before
>
> --
> 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/d/optout.
>



-- 
At.
Carlos Antonio

-- 
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/d/optout.

Re: [Rails-core] Class list helper for HTML tags

2015-09-21 Thread Carlos Antonio da Silva

Hi Philippe,

you should be able to use Rails' ability to pass in an array of classes,
and Ruby's parentheses to create a scope, to handle this scenario for you:

*<%= content_tag_for :tr, @model, class: ['foo', ('ready' if
@model.ready?)] do %>*

That should give you the same html response you expect, without the need to
extend the framework :)

Hope that helps.

On Mon, Sep 21, 2015 at 5:48 AM, Philippe Hässig  wrote:

> Hi Core List
>
> The usual way to conditionally add classes to html tags is in the
> following form:
>
> 
>
> This is hard to read and nod very convenient. ReactJS has an Addon to use
> a Hash (Javascript Object) to conditionally add classes (
> https://github.com/JedWatson/classnames).
> Inspired by this I'd like to add a helper to ActionView which does exactly
> that. So you can write:
>
> 
>
> or
>
> <%= content_tag_for :tr, @model, class: class_list('foo', ready:
> @model.ready?) do %>
>
> How do you like this idea? Where should that go? New gem? The newly
> extracted content tag gem? Action View Helpers?
>
> Regards
> phil
>
>
> --
> 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/d/optout.
>



-- 
At.
Carlos Antonio

-- 
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/d/optout.

Re: [Rails-core] Errors inside custom setters

2015-09-10 Thread Carlos Antonio da Silva

Hi,

is there any reason why you could not move the validation to a proper
validation "callback" so that it'd work like any other validation does? I
mean, if you know the value is wrong in the moment you're setting, you
could allow it to be set and validate the same afterwards, but there's
probably something I'm not seeing - maybe you can share some code to help
out?

Anyway, if you really need to do that I'd recommend doing as you said,
detect on the setter but only add the error upon validation.

On Thu, Sep 10, 2015 at 4:13 PM, Kevin Deisz  wrote:

> Hi there,
>
> I've got a custom setter in a model that add errors in the case that the
> given value is invalid. In the case that it is invalid, I've had a lot of
> difficulty getting the model to validate false. It looks like in active
> model we call errors.clear before run_validations!. This makes sense to me,
> as you might save a record, validate false, update the values, and then not
> want to keep the old errors.
>
> Is there any way around this? Best I could come up with is to set an
> attr_accessor flag to :invalid if the setter was invalid and then validate
> absence of that attr_accessor.
>
> Would there be interest in a PR that extended errors to have some
> persistent values through the validation stack? As in, you set a sticky
> error that doesn't get removed when you call valid? Or something? Sorry,
> that part of this is not super thought-out.
>
> --
> *Kevin D. Deisz*
> *TrialNetworks* - part of DrugDev
> Software Developer
> 383 Elliot Street, Suite G
> Newton, MA 02464
> +1 617.952.4071 x134 (office)
> +1 703.615.0396 (mobile)
> kde...@trialnetworks.com
>
> --
> 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/d/optout.
>



-- 
At.
Carlos Antonio

-- 
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/d/optout.

Re: [Rails-core] Errors inside custom setters

2015-09-10 Thread Carlos Antonio da Silva

I see. Well, that doesn't mean you could not store "something" that
represents your `xml` attribute - or you could have an `xml_error` that
stores the error message in this case, and adds it to the errors instance
when validating (which is probably very similar or exactly what you're
doing already).

I'm not sure having "sticky" errors would be super helpful. For example,
you sure you want them to be "sticky" if you set xml twice on the same
instance? Would you have to clear that error yourself in this case, because
you're handing it on your own? It seems a lot to handle.

Anyway, those are my thoughts, maybe someone else has a new opinion on this
:).

Hope that helps.

On Thu, Sep 10, 2015 at 4:22 PM, Kevin Deisz <kevin.de...@gmail.com> wrote:

> Hi Carlos,
>
> It's not actually a persisted attribute. I effectively have
>
> class Thingy
>   def xml=(string)
> xml_doc = Nokogiri::XML(string) { |config| config.noblanks.strict }
> # more code here
>   rescue Nokogiri::XML::SyntaxError => error
> self.errors.add(:xml, error.message)
>   end
>
>   def xml
> # some code here, effectively to_xml
>   end
> end
>
>
> On Thu, Sep 10, 2015 at 3:16 PM, Carlos Antonio da Silva <
> carlosantoniodasi...@gmail.com> wrote:
>
>> Hi,
>>
>> is there any reason why you could not move the validation to a proper
>> validation "callback" so that it'd work like any other validation does? I
>> mean, if you know the value is wrong in the moment you're setting, you
>> could allow it to be set and validate the same afterwards, but there's
>> probably something I'm not seeing - maybe you can share some code to help
>> out?
>>
>> Anyway, if you really need to do that I'd recommend doing as you said,
>> detect on the setter but only add the error upon validation.
>>
>> On Thu, Sep 10, 2015 at 4:13 PM, Kevin Deisz <kevin.de...@gmail.com>
>> wrote:
>>
>>> Hi there,
>>>
>>> I've got a custom setter in a model that add errors in the case that the
>>> given value is invalid. In the case that it is invalid, I've had a lot of
>>> difficulty getting the model to validate false. It looks like in active
>>> model we call errors.clear before run_validations!. This makes sense to me,
>>> as you might save a record, validate false, update the values, and then not
>>> want to keep the old errors.
>>>
>>> Is there any way around this? Best I could come up with is to set an
>>> attr_accessor flag to :invalid if the setter was invalid and then validate
>>> absence of that attr_accessor.
>>>
>>> Would there be interest in a PR that extended errors to have some
>>> persistent values through the validation stack? As in, you set a sticky
>>> error that doesn't get removed when you call valid? Or something? Sorry,
>>> that part of this is not super thought-out.
>>>
>>> --
>>> *Kevin D. Deisz*
>>> *TrialNetworks* - part of DrugDev
>>> Software Developer
>>> 383 Elliot Street, Suite G
>>> Newton, MA 02464
>>> +1 617.952.4071 x134 (office)
>>> +1 703.615.0396 (mobile)
>>> kde...@trialnetworks.com
>>>
>>> --
>>> 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/d/optout.
>>>
>>
>>
>>
>> --
>> At.
>> Carlos Antonio
>>
>> --
>> 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/d/optout.
>>
>
>
>
> --
> *Kevin D. Deisz*
> *TrialNetworks* - part of DrugDev
> Software Developer
> 383 Elliot Street, Suite G
> Newton, MA 02464
> +1 617.952.4071 x134 (office)
> +1 703.615.0396 (mobile)
> kde...@trialnetworks.com
>
> --
> You received this message because you are subscribed to the

Re: [Rails-core] Re: Arguments to rails update rake task

2015-09-03 Thread Carlos Antonio da Silva

Makes sense to me, happy to see a pull request with such change.

On Thu, Sep 3, 2015 at 10:42 AM, siva subrahmanyam <
subbu9848155...@gmail.com> wrote:

>
> Hi All
>
> Could you share your thoughts?
>
>
> On Thursday, 27 August 2015 20:49:26 UTC+5:30, siva subrahmanyam wrote:
>>
>>
>>  Hi All
>>
>>  Recently I want to upgrade my rails application to 4.2.3. For that I am
>> using rails:update rake task to update my config. As I am using mongoid as
>> ORM I have to go explicitly re comment active record related configuration
>> after updation. So I am thinking it would be better if we able to pass
>> something like --skip-activerecord such that it would auto comment active
>> record related configuration. Thoughts please?
>>
>>  Thanks in advance
>>
>>
>>
>>
>> Regards
>>   Siva
>>
>>
>>
>>
>>
>>
>>
>> --
> 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/d/optout.
>



-- 
At.
Carlos Antonio

-- 
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/d/optout.

Re: [Rails-core] Authentication Token vs Bearer token

2015-09-03 Thread Carlos Antonio da Silva

This has been merged to Rails master:
https://github.com/rails/rails/pull/19094, so it should be out with Rails 5.

On Tue, Sep 1, 2015 at 2:59 PM, Yordis Prieto 
wrote:

> I am trying to use ActionController::HttpAuthentication::Token and the
> header for get the toke have to be Authenticate Token token="..." but I am
> trying to follow OAuth2 Bearer Token and I have no way to change Token key
> for Bearer.
>
> I suggest to allow us to customize the key or change the key for follow
> some standard
>
> --
> 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/d/optout.
>



-- 
At.
Carlos Antonio

-- 
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/d/optout.

Re: [Rails-core] Please fix the links in the Rails README.md on github.

2015-08-17 Thread Carlos Antonio da Silva

Can you be more clear on what the issue is with the links, and what you
expected?

On Fri, Aug 14, 2015 at 10:49 AM, Douglas Allen kb9...@gmail.com wrote:

 I have some work to do for my repo now because of this.
 Here is what I have for the first page.
 https://github.com/DouglasAllen/rails-v4.2.3-starter/blob/master/README.md

 --
 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/d/optout.




-- 
At.
Carlos Antonio

-- 
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/d/optout.

Re: [Rails-core] I18n Relative Time - DateHelpers with Prefixes/Suffixes

2015-07-13 Thread Carlos Antonio da Silva

Wouldn't that work with a translation of your own, that receives the time
ago as an argument that you can interpolate, like this:


*translate :time_ago, time: time_ago_in_words(Time.current)*

*# locale*
*en:*
*  time_ago: %{time} ago*

*pt-BR:*
*  time_ago: %{time} atrás*

*zomg:*
*  time_ago: prefix %{time} suffix*


That just works, without adding any new extension to the method/framework.

Hope that helps.

On Mon, Jul 13, 2015 at 3:23 PM, Andrew Turgeon andrew.p.turg...@gmail.com
wrote:

 Hi all,

 I am working on internationalization topics, specifically time
 localization, and have ran into an issue that could be a possible feature
 inclusion in a future release that I wanted to get others' opinions on.

 One of the popular formats in English to say a space in time relative to
 the present time would be to use 10 minutes ago. Right now, DateHelper
 http://api.rubyonrails.org/classes/ActionView/Helpers/DateHelper.html allows
 you to correctly get the text 10 minutes and then override any of that
 language by creating a yml file similar to the default en datetime
 translation
 https://github.com/rails/rails/blob/master/actionview/lib/action_view/locale/en.yml.
 The part that is missing is ago - so let's just add in ago into the
 override file right?

 The problem becomes this: If the someone uses the
 distance_of_time_in_words without one of the to or from specified as
 Time.now, it doesn't make sense anymore.

 I want to include ago for English but allow that relative time to be
 translated properly. I didn't want to include a separate translation key
 for ago because that could result in improper translation without
 context. In addition, other languages have prefixes instead of suffixes
 when specifying relative time.

 My proposal is to add some additional options for the
 distance_of_time_in_words method in DateHelper
 1) :include_prefix (default: false)
 2) :include_suffix (default: false)

 In the default yml file for datetime distance, there would be additional
 keys - :prefix and :suffix

 For English, suffix would be ago and prefix would be  - this would
 allow users to customize not only the language used for the distance of
 time in words, but also any prefix or suffix used for the language.

 Now, if I want my 10 minutes ago, instead of specifying

 %= time_ago_in_words(Time.now) % ago

 we can now specify

 %= time_ago_in_words(Time.now, :include_prefix = true) %

 Thoughts?

 -Andrew

  --
 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/d/optout.




-- 
At.
Carlos Antonio

-- 
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/d/optout.

Re: [Rails-core] Nokogiri adds a lot of weight to ActionView

2015-07-13 Thread Carlos Antonio da Silva

As a side note, the base functionality of the number helpers was moved to
Active Support
http://api.rubyonrails.org/classes/ActiveSupport/NumberHelper.html, so
you don't need to rely on Action View anymore in this scenario.

(I understand the concern about including nokogiri, just wanted to make
sure that everyone was aware of this).

On Mon, Jul 13, 2015 at 8:46 PM, Nicolás Sanguinetti godf...@gmail.com
wrote:

Um, deviating a little from your particular concern (which may or may not
be justified), but you really can’t complain about being forced to include
a gem multiple times when you’re including action view (and thus active
support, I18n, TZInfo, builder, erubis, and a couple more…) *just* to use a
method that you could very well implement yourself in very simple ruby.

I mean, you were pulling like 8 or 9 gems (without counting nokogiri) just
so you can avoid formatting a number a little bit, rounding it off, and
prepending a “$” (or your currency of choice) to a string.

…but *then* you complain that now you have to install an extra gem?

o_O

Cheers,
-foca

On Tue, Jul 14, 2015 at 12:37 AM, iybet...@gmail.com iybet...@gmail.com
wrote:

Rails goes out of its way to avoid forcing an installation of bcrypt
because it is a binary library. See
https://github.com/rails/rails/blob/v4.2.3/Gemfile#L21

Nokogiri forces installation of 2 binary libraries (libxml2 and libxslt),
so one would expect it not to be a dependency of any of the core components
of Rails.

However, starting with actionview 4.2.0, nokogiri is now a dependency.

That means every time actionview appears in a Gemfile.lock, so does
nokogiri. I would often include ActionView 4.1 in non-Rails projects just
to use number_to_currency, but now with the nokogiri dependency, the
overhead is hardly worth it.

Consider the fact that I'm deploying about 5 such projects to the same
server, all using separate BUNDLE_PATH's. That means 5 installations of
nokogiri, none of which are being used. This adds time to every
`capistrano bundler:install` and a significant amount of disk space is
wasted on this. For any other gem, this wouldn't make much of a
difference, but nokogiri is really big and takes a long time to install,
and Rails has already set a precedent by not including the (much lighter)
bcrypt.

Is the rails-core team open to the following solutions:
---

1) Separate the parts of actionview that depend on rails-dom-testing into
a separate gem

Create an actionview-testing gem, which would only be necessary in the
Gemfile's test group, thus saving even more overhead in production. This
would depend on action-view and rails-dom-testing, but actionview would not
depend on rail-dom-testing.

(The same approach that I suggest below for rails-html-sanitizer might
work for rails-dom-testing too, but it may add more complexity that carving
a separate gem--there are multiple code paths that can lead you to
rails-dom-testing methods, whereas there's a single method that's a
bottleneck for all entries to rails-html-sanitizer.)
---

2) In ActionView::Helpers::SanitizeHelper, move `require
rails-html-sanitizer` into the #sanitizer_vendor method.

If a LoadError is raised, handle it just as we do for bcrypt:
https://github.com/rails/rails/blob/v4.2.3/activemodel/lib/active_model/secure_password.rb#L60

Add rails-html-sanitizer to the Gemfile template so that it's
automatically in new Rails projects. Only upgrades and would need to
manually add this to the Gemfile, so we would have to add it to the upgrade
guide. Standalone actionview projects would also need to add it to their
Gemfile, but *rafaelfranca https://github.com/rafaelfranca* has
assured me that non-Rails projects should never be using
rails-html-sanitizer anyway:
https://github.com/rails/rails-html-sanitizer/issues/25#issuecomment-60833972
.
---

I would love to get started on a PR. I just need to know if it will be
considered.

--
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/d/optout.

--
At.
Carlos Antonio

--
You received this message because you are

Re: [Rails-core] Generating ActiveRecord model table name to include namespace

2015-02-03 Thread Carlos Antonio da Silva

The first suggestion, as far as I understood, was related to something like
inherits_table_prefix_from_*namespace, *which seems pretty much the same as
setting the table name prefix.

In any case, I've seen many many cases where people organize their models
in namespaces, but the tables might not have the namespace prefix. Making
this a default would likely be a considerable breaking change, and I'm
leaned to think it would be unnecessary overhead.

Best.

On Tue, Feb 3, 2015 at 8:52 AM, Matthew Dunbar m...@mattdsworld.com wrote:

 Suggesting that we can auto generate the prefix based on the module name,
 rather than setting it with the existing method. Then eventually this feels
 like a sensible default to me.

 On Sunday, February 1, 2015 at 7:39:58 AM UTC-5, Carlos Antonio da Silva
 wrote:

 Not sure I get what's the actual difference between a new option like
 that and setting the table name prefix on the module, which will work for
 all classes under it? Can you expand on that a bit?

 On Sat, Jan 31, 2015 at 4:52 AM, Matthew Dunbar ma...@mattdsworld.com
 wrote:

 I will implement this myself, looking for feedback on if it'd be
 accepted and how the community feels about the long term of this being
 enabled by default.

 I often run into conflicts between table names when running multiple
 fairly heavyweight engines that all deal with e-commerce (and in turn many
 have tables such as most recently payments that conflict). The current
 solution is to manually specify the table prefix in the appropriate gem /
 module.

 I am suggesting that we add a inherits_prefix_from_namespace flag to
 models, then eventually in the long term (perhaps rails 5) defaulting this
 to be enabled.

 Ideally this would work as follows:

 module Example
   module Widgets
 class Test  ActiveRecord::Base
   inherits_table_prefix_from_namespace: true
 end
   end
 end

 Rather than having its table name be *tests* , the table name would be
 *example_widgets_tests*.

 In the case that a prefix is specified, the table name would be
 *prefix_example_widgets_tests* (rather than *prefix_tests*).

  --
 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-co...@googlegroups.com.
 To post to this group, send email to rubyonra...@googlegroups.com.
 Visit this group at http://groups.google.com/group/rubyonrails-core.
 For more options, visit https://groups.google.com/d/optout.




 --
 At.
 Carlos Antonio

  --
 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/d/optout.




-- 
At.
Carlos Antonio

-- 
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/d/optout.

Re: [Rails-core] Generating ActiveRecord model table name to include namespace

2015-02-01 Thread Carlos Antonio da Silva

Not sure I get what's the actual difference between a new option like that
and setting the table name prefix on the module, which will work for all
classes under it? Can you expand on that a bit?

On Sat, Jan 31, 2015 at 4:52 AM, Matthew Dunbar m...@mattdsworld.com
wrote:

 I will implement this myself, looking for feedback on if it'd be accepted
 and how the community feels about the long term of this being enabled by
 default.

 I often run into conflicts between table names when running multiple
 fairly heavyweight engines that all deal with e-commerce (and in turn many
 have tables such as most recently payments that conflict). The current
 solution is to manually specify the table prefix in the appropriate gem /
 module.

 I am suggesting that we add a inherits_prefix_from_namespace flag to
 models, then eventually in the long term (perhaps rails 5) defaulting this
 to be enabled.

 Ideally this would work as follows:

 module Example
   module Widgets
 class Test  ActiveRecord::Base
   inherits_table_prefix_from_namespace: true
 end
   end
 end

 Rather than having its table name be *tests* , the table name would be
 *example_widgets_tests*.

 In the case that a prefix is specified, the table name would be
 *prefix_example_widgets_tests* (rather than *prefix_tests*).

  --
 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/d/optout.




-- 
At.
Carlos Antonio

-- 
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/d/optout.

Re: [Rails-core] Inconsistent file name suffix on mailer generator

2014-12-16 Thread Carlos Antonio da Silva

I don't particularly see any problem on adding the mailer suffix to the
generated file, and in fact Rails 5 might be the best release for doing so.

On Tue, Dec 16, 2014 at 7:23 PM, Carlos Souza carloshrso...@gmail.com
wrote:

Is there a reason why mailers created through generators don't have a
_mailer suffix ?

https://github.com/rails/rails/blob/master/actionmailer/lib/rails/generators/mailer/mailer_generator.rb#L10

I find it somewhat confusing that controllers
https://github.com/rails/rails/blob/master/railties/lib/rails/generators/rails/controller/controller_generator.rb#L10
and jobs
https://github.com/rails/rails/blob/master/activejob/lib/rails/generators/job/job_generator.rb#L19
follow this convention, but mailers don't.

- Carlos Souza

--
At.
Carlos Antonio

--
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/d/optout.

Re: [Rails-core] Specifying controller action for an action in a route definition

2014-12-08 Thread Carlos Antonio da Silva

As far as I remember, you should use the *controller* option to point the
resource to a specific controller. And if you need to customize each
action, maybe you're not creating a resource at all, maybe you need to
review what *resource(s) *you are working with.

Hope that helps :)

On Sat, Dec 6, 2014 at 12:34 AM, Jeffrey Guenther 
guenther.jeff...@gmail.com wrote:

 Hi Rails Core Team,

 I've noticed that you can set the controller method use by a route doing:
 resources :assessments, only: [:create], to: :create_asessment_for_company

 Is this unintended? If this is by design, how can I set the method for
 each action in the array? I tried something like the following, but it
 didn't work.
 resources :assessments do
 member do
 get 'result'
 end
 resources :respondents, only: [:new, :create], :
 new_respondent_for_assessment, to: :create_respondent_for_assessment do
   collection do
 post invite, to: :invite_all
 get invite, to: :new_invite
   end
 end
   end

 Is there a way to do this? I've looked through the rails guides and the
 ActiveDispatch docs and couldn't see a way. Is this a feature, you'd accept
 a pull request for?

 The reason why I'm trying to do this is my actions return JS and I need
 different JS to run depending on the context of the request aka. Is the
 respondent being edited in general, or is the action happening in the
 scope of the assessment. I'm trying to use the URL in what I understand
 is a RESTful way to identify a particular context.

 Thanks,
 Jeff

  --
 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/d/optout.




-- 
At.
Carlos Antonio

-- 
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/d/optout.

Re: [Rails-core] Method for combining :if and :unless on validates when nesting with_options

2014-12-05 Thread Carlos Antonio da Silva

I think you can also combine multiple conditions with an array of methods
to be called:

*with_options if: [:something?, :something_else?] do*
*...*
*end*

It's a bit simpler/cleaner than the block form, but I don't think that
works in a nested way as you are imagining (and I think it might be better
to just keep it as is).

Hope that helps.

On Fri, Dec 5, 2014 at 5:02 PM, Griffin Smith wildgriffi...@gmail.com
wrote:

 I feel like one of the more common use cases for with_options is an :if or
 an :unless argument to validates, like so:

 with_options if: :something? do
   validates :thing, presence: true
   validates :other_thing, numericality: { greater_than: 7 }
 end

 This breaks down when trying to nest multiple with_options blocks, because
 the second :if overrides the first when calling Hash#merge. It would be
 nice if I could do:

 with_options if: :something? do
   validates :thing, presence: true
   validates :other_thing, presence: true

   with_options if: :something_else? do
 validates :third_thing, presence: true # only runs if something? 
 something_else?
   end
 end

 Currently to get this to behave as expected I have to do:

 with_options if: :something? do
   validates :thing, presence: true
   validates :other_thing, presence: true
 end

 with_options if: - { something?  something_else? } do
 validates :third_thing, presence: true # only runs if something? 
 something_else?
 end

  --
 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/d/optout.




-- 
At.
Carlos Antonio

-- 
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/d/optout.

Re: [Rails-core] Find an ActiveRecord::Error in an object by attribute name and error type.

2014-12-05 Thread Carlos Antonio da Silva

You should be able to use the *#added?
http://api.rubyonrails.org/classes/ActiveModel/Errors.html#method-i-added-3F*
method
for this.

Hope that helps.

On Fri, Dec 5, 2014 at 5:54 PM, Daniel Gomez Sierra 
danielgomezsie...@gmail.com wrote:

 Is there a way to know if a record has an error with a certain attribute
 and error type after validating it? I was wondering if there is a way to
 accomplish this task by using something similar as the
 ActiveModel::Errors.get method but passing two arguments instead of one.
 For instance:

 ActiveModel::Errors.get(:user_id, :blank)   # =  [can't be blank]

 If this is not implemented yet, I'd like to help with these changes.
 Thanks!

 --
 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/d/optout.




-- 
At.
Carlos Antonio

-- 
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/d/optout.

Re: [Rails-core] Attributes escaping not following SGML

2014-11-28 Thread Carlos Antonio da Silva

Which Rails version?

Just ran the exact same code in 4.0.11  4.1.17 and got this:

 include ActionView::Helpers::TagHelper
 = Object
  tag 'input', value: 'abc dsfa'
 = input value=\abc quot;dsfaquot;\ /


2014-11-28 13:18 GMT-02:00 Bráulio Bhavamitra brau...@eita.org.br:

 Hello all,

 On rails console:

 include ActionView::Helpers::TagHelper
 tag 'input', value: 'abc dsfa'
 = input value=\abc \dsfa\\ /

 Then in the result html you see:
 input value=abc dsfa /

 Anybody had that problem too? I couldn't find it on stackoverflow.

 http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.2
 http://stackoverflow.com/questions/2373074/single-vs-double-quotes-vs

 cheers
 bráulio

 --
 Lute pela sua ideologia. Seja um com sua ideologia. Viva pela sua
 ideologia. Morra por sua ideologia P.R. Sarkar

 EITA - Educação, Informação e Tecnologias para Autogestão
 http://cirandas.net/brauliobo
 http://eita.org.br

 Paramapurusha é meu pai e Parama Prakriti é minha mãe. O universo é meu
 lar e todos nós somos cidadãos deste cosmo. Este universo é a imaginação da
 Mente Macrocósmica, e todas as entidades estão sendo criadas, preservadas e
 destruídas nas fases de extroversão e introversão do fluxo imaginativo
 cósmico. No âmbito pessoal, quando uma pessoa imagina algo em sua mente,
 naquele momento, essa pessoa é a única proprietária daquilo que ela
 imagina, e ninguém mais. Quando um ser humano criado mentalmente caminha
 por um milharal também imaginado, a pessoa imaginada não é a propriedade
 desse milharal, pois ele pertence ao indivíduo que o está imaginando. Este
 universo foi criado na imaginação de Brahma, a Entidade Suprema, por isso
 a propriedade deste universo é de Brahma, e não dos microcosmos que também
 foram criados pela imaginação de Brahma. Nenhuma propriedade deste mundo,
 mutável ou imutável, pertence a um indivíduo em particular; tudo é o
 patrimônio comum de todos.
 Restante do texto em
 http://cirandas.net/brauliobo/blog/a-problematica-de-hoje-em-dia

 --
 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/d/optout.




-- 
At.
Carlos Antonio

-- 
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/d/optout.

Re: [Rails-core] Method to find inside of relation

2014-11-14 Thread Carlos Antonio da Silva

You should be able to use find_by and pass in a hash with attributes and
respective values to find a record.

Please take a look at the docs for find_by on the api guides.

Carlos Antonio da Silva - via celular
On Nov 14, 2014 7:44 PM, Sunny Juneja jr.su...@gmail.com wrote:

 Hey, I ran into this problem fairly recently. I needed to get a large
 number of records and search them over and over again on different
 attributes. I found myself writing code that looked a lot like this.

 records = Model.where(...)

 records.select { |r| r.attribute1 == attribute1  r.attribute2 ==
 attribute2  ... }

 Although this is a simple case, I found myself rewriting this over and
 over again.

 Is there anything equivalent that might fit the form

 records = Model.where(...)
 records.find_in_relation(attribute1: attribute1, attribute2: attribute2,
 attribute3, ...)

 Was just wondering if there was a place for such syntactical sugar or a
 desire to add some. If there is too simple a change to warrant, I
 understand.

  --
 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/d/optout.


-- 
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/d/optout.

Re: [Rails-core] t(.key) convenience pollutes global i18n namespace

2014-11-06 Thread Carlos Antonio da Silva

I think it's fine adding a default namespace for such lookups, it should be
preferred over the non-namespaced version (eg in docs and everywhere), but
I don't think we need to actually break existing functionality.

We could just add this and leave the existing one in place as a fallback,
or deprecate it. I'm still not sure deprecating is the best solution right
now, so I'd like to hear other thoughts about it, but I'm ok on adding the
namespace.

On Thu, Nov 6, 2014 at 10:33 AM, Joshua Cody joshc...@gmail.com wrote:

 Nicolas, for a PR, do you feel like we should:

 1) accept a backwards-incompatible change and begin nesting under “views:”

 2) create a sort of lookup hierarchy like in ActiveRecord model
 translations that first looks in “views:” then the current path

 3) keep the same default but introduce an ActionView setting for a
 namespace that folks can opt in to

 On Tuesday, November 4, 2014 2:06:08 AM UTC-6, Nicolas Cavigneaux wrote:


 Le 3 nov. 2014 à 15:14, Joshua Cody josh...@gmail.com a écrit :

  Considering the Rails guides give an example structure of nesting view
 translations under views, it feels like using the period convenience with
 the t() helper should by default look to the views i18n namespace, or at
 least provide an ActionView setting for a view namespace. This would bring
 the behavior of views more in line with that of models and keep from
 polluting the global i18n namespace with view-specific translations.
 
  Maybe I'm totally off-base—does anyone have opinions on this?

 Hi Joshua, I agree with you. I always felt it was some kind of pollution
 too. It would be nice if t() helper used with period was using a namespace.

 —
 Nicolas Cavigneaux
 http://www.bounga.org
 http://www.cavigneaux.net

  --
 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/d/optout.




-- 
At.
Carlos Antonio

-- 
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/d/optout.

Re: [Rails-core] ActionMailer deliver_later and i18n in 4.2

2014-10-23 Thread Carlos Antonio da Silva

Rather than doing something like:

*I18n.with_locale(:en) { Mailer.zomg(foo, bar).deliver_later }*

You can do

*Mailer.zomg(:en foo, bar).deliver_later*

And within the mailer

*def zomg(locale, foo, bar)*
* I18n.with_locale(locale) do*
**
* end*
*end*

Right now that's the simplest thing that I can think of, and it's so simple
that I'm not even sure Rails should have any special handling for that -
but maybe it should.

On Thu, Oct 23, 2014 at 4:57 AM, Igor Kapkov igasg...@gmail.com wrote:

Yeah, I understand how to do it now, but don't understand how it'll work
in 4.2. Let's look at example. I send confirmation instructions
`UserMailer.confirmation(@user).deliver_later` and I have 2 views
`app/views/user_mailer/confirmation.en.html.erb`
`app/views/user_mailer/confirmation.ru.html.erb`. And `deliver_later`
just add the job
https://github.com/rails/rails/blob/04b40b3debebc24e11a1d9c81ea313125500185b/actionmailer/lib/action_mailer/delivery_job.rb
but this job wont know nothing about user locale.

I'm not asking for help how to solve this, I just worried that this
scenario currently not mentioned or solved as I see.

среда, 22 октября 2014 г., 23:12:24 UTC+8 пользователь Carlos Antonio da
Silva написал:

You should probably be passing in the locale you want as an argument to
your mailers, and set the locale there before actually creating the mail
object/rendering the view.

On Wed, Oct 22, 2014 at 1:07 PM, Mohamed Wael Khobalatte
wael.kh...@gmail.com wrote:

There shouldn't be any problem since deliver_later will simply invoke
your deliver_now at some point, and that should run as you expect.

On Wed, Oct 22, 2014 at 2:31 PM, Igor Kapkov igas...@gmail.com wrote:

Hi all,

previously if we needed in sending a mail in different locale we used
`I18n.with_locale`. I didn't find any about that in sources and
docs/guides. How it'll work with `deliver_later` and ActiveJob?

Best Regards,
Igas

--
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-co...@googlegroups.com.
To post to this group, send email to rubyonra...@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

--
Mohamed Wael Khobalatte

--
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-co...@googlegroups.com.
To post to this group, send email to rubyonra...@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

--
At.
Carlos Antonio

--
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/d/optout.

Re: [Rails-core] ActionMailer deliver_later and i18n in 4.2

2014-10-22 Thread Carlos Antonio da Silva

You should probably be passing in the locale you want as an argument to
your mailers, and set the locale there before actually creating the mail
object/rendering the view.

On Wed, Oct 22, 2014 at 1:07 PM, Mohamed Wael Khobalatte 
wael.khobala...@gmail.com wrote:

 There shouldn't be any problem since deliver_later will simply invoke your
 deliver_now at some point, and that should run as you expect.

 On Wed, Oct 22, 2014 at 2:31 PM, Igor Kapkov igasg...@gmail.com wrote:

 Hi all,

 previously if we needed in sending a mail in different locale we used
 `I18n.with_locale`. I didn't find any about that in sources and
 docs/guides. How it'll work with `deliver_later` and ActiveJob?

 Best Regards,
 Igas

 --
 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/d/optout.




 --
 Mohamed Wael Khobalatte

  --
 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/d/optout.




-- 
At.
Carlos Antonio

-- 
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/d/optout.

Re: [Rails-core] Using rescue_from Exception to render a 500 page with the application layout will not catch all Exceptions

2014-10-08 Thread Carlos Antonio da Silva

I don't know if rescue_from Exception should catch everything as you
expect, what I do know is that you can use the router to point to a normal
controller / action(s) and use any layout you want for that.

Check this post at Plataformatec's blog:
http://blog.plataformatec.com.br/2012/01/my-five-favorite-hidden-features-in-rails-3-2/,
it details a bit how the feature works.

On Wed, Oct 8, 2014 at 5:01 PM, Tim Raymond xtjraymo...@gmail.com wrote:

 I'm not really sure whether this is a doc bug or a regular bug, so I
 figured I would open a thread here to figure out which.

 If you use `rescue_from Exception` to render a dynamic 500 page with your
 application layout, and the exception was triggered from the application
 layout to begin with, it will escape the dynamic error page and render the
 one in `public`. Granted, this sounds obvious, but the documentation for
 rescue_from states that Exceptions raised inside exception handlers are
 not propagated up, when in this situation that's clearly not the case.

 I have a reproduction of this issue here:
 https://github.com/timraymond/rails-issue-rescue-from and a Docker image
 of it, if that's your cup of tea:
 https://registry.hub.docker.com/u/timraymond/rails-issue/ (docker pull
 timraymond/rails-issue). If you visit the /explode path, the exception
 raised there will be successfully caught by the dynamic 500 page. If you
 visit the /greet/:name path, it will escape the dynamic 500 page because
 of the exception raised in the application layout. The conditional in the
 layout is contrived, but is intended to represent complex logic that can
 trigger an exception in the layout when rendering some actions but not
 others.

 I see in the edge guides that there's also a way to get this functionality
 by creating a route for /500. I'm not sure if this would be similarly
 affected if an exception was raised by a layout, but it's something to
 consider as well, and perhaps someone who is more familiar with that
 feature can chime in :)

 Let me know if I should open this up on GitHub as an issue, or if docrails
 needs to be updated to reflect that some exceptions can escape.

 --
 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/d/optout.




-- 
At.
Carlos Antonio

-- 
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/d/optout.

Re: [Rails-core] Feature idea: remove internal div from form_for, form_tag and button_to

2014-09-22 Thread Carlos Antonio da Silva

Great, thank you.

On Mon, Sep 22, 2014 at 4:40 AM, Claudio B. claud...@gmail.com wrote:

Carlos Antonio, you are right!

I didn't realize that because the documentation of the method still
includes the old format (with the wrapping divs).

I created a PR to update the documentation accordingly:
http://github.com/rails/rails/pull/17001

Thanks

On Sunday, September 21, 2014 3:56:18 PM UTC-7, Carlos Antonio da Silva
wrote:

I believe this has been added to Rails 4.2/master already:
https://github.com/rails/rails/commit/89ff1f82f01bd70e12ec1b45049be3
0ac262df30

Cheers.

On Sun, Sep 21, 2014 at 7:48 PM, Claudio B. clau...@gmail.com wrote:

Hello Rails team, and thanks for your amazing work!

I would like to create a Pull Request so that form helpers do not add an
extra div inside the form tag.

I looked back in the history of the code, and I found that the div was
initially added after this discussion of 2006
https://groups.google.com/forum/#%21searchin/rubyonrails-core/hidden$20method$20tag$20should/rubyonrails-core/o7eHdDT4WPg/0ddlr27rdMoJ
to make forms [x]HTML4 Strict-compliant.

Another message from 2007
https://groups.google.com/forum/#%21searchin/rubyonrails-core/hidden$20field$20and$20wrapping/rubyonrails-core/3TwPS3QBe8g/-CUGT-Ug5a8J
confirmed the reason why behind the div.

Now it's 2014, and HTML 5 finally allows form elements to include
input elements directly, without a wrapping div.

What is your opinion? Should I go on and submit a pull request?

Also… how concerned are you about backward compatibility?
If you think it's appropriate, I could add a new boolean option to
form_for, button_to… so people can decide if they want the div or not.

Thanks!
http://github.com/claudiob

--
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-co...@googlegroups.com.
To post to this group, send email to rubyonra...@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

--
At.
Carlos Antonio

--
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/d/optout.

Re: [Rails-core] Feature idea: ActiveRecord::Relation.size always returns an integer

2014-09-11 Thread Carlos Antonio da Silva

size in this case is an pretty much an alias for count, thus it's gonna
work the same way as count when grouping.

Is there any particular reason to know how many records returned if you are
grouping?

On Wed, Sep 10, 2014 at 11:16 AM, Shinohara Teruki ts.3...@gmail.com
wrote:

 ActiveRecord::Relation.size returns a Hash when I use a group method.
 I think that a size method is expected to return integer typically.

 I propose this  implementation:

 def size
   if loaded?
 @records.length
   else
 count_value = count(:all)
 count_value.is_a?(Hash) ? count_value.length : count_value
   end
 end

 This is a current implementation:

 #
 https://github.com/rails/rails/blob/master/activerecord/lib/active_record/relation.rb
 # Returns size of the records.
 def size
   loaded? ? @records.length : count(:all)
 end


 A count method is implemented on calculations.rb.

 https://github.com/rails/rails/blob/master/activerecord/lib/active_record/relation/calculations.rb


 What do you think?

 Thank you

 --
 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/d/optout.




-- 
At.
Carlos Antonio

-- 
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/d/optout.

Re: [Rails-core] Validation the presence of an ActiveRecord belongs_to association should imply a valid associated object?

2014-09-11 Thread Carlos Antonio da Silva

Well, the presence validation does exactly what it says, no matter which
type of attribute we're talking about. For example, it doesn't work with
booleans because it'd never allow `false` to be saved.

To actually validate that the associated object is valid itself, you should
add the association validation, or add the validate option to the
belongs_to call, which will validate the associated object when saving the
parent.

Hope that helps :)

On Wed, Sep 10, 2014 at 10:47 PM, Aaron Kromer aaron.kro...@gmail.com
wrote:

 This behavior has been around for awhile (since at least 3.2.x; I didn't
 test further back). I'm a bit surprised this didn't trip my up before, but
 I'm sure it did and I just took the quick way out.

 To set some groundwork here is what the Active Record Validations Guide
 http://guides.rubyonrails.org/active_record_validations.html#presence
 presence validation (emphasis mine):


 If you want to be sure that an association is present, you'll need to
 test whether the associated object itself is present, and not the foreign
 key used to map the association.


 class LineItem  ActiveRecord::Base
  belongs_to :order
  validates :order, presence: true
 end

 *In order to validate associated records whose presence is required, you
 must specify the :inverse_of option for the association*:


 class Order  ActiveRecord::Base
   has_many :line_items, inverse_of: :order
 end

 If you validate the presence of an object associated via a has_one or
 has_many relationship, it will check that the object is neither blank? nor
 marked_for_destruction?.


 However, using inverse_of doesn't work. Note that this section of docs
 states that only has_one and has_many relationships will check only blank?
 and marked_for_destruction?.

 Compare this with the API docs for the same validation
 http://api.rubyonrails.org/classes/ActiveRecord/Validations/ClassMethods.html#method-i-validates_presence_of
 :

 Validates that the specified attributes are not blank (as defined by
 Object#blank?), and, if the attribute is an association, that the
 associated object is not marked for destruction. Happens by default on save.


 That gives the indication that it doesn't seem to matter if you use
 inverse_of or not. Nor, will the presence validator ever validate the
 association. However, this causes some very odd behavior. Namely, it's
 possibly to save a record which, when pulled immediately back out of the
 database is not valid. This is because a null value has been saved in the
 place of the association's reference id.

 Here's code which demonstrates this:

 # Activate the gem you are reporting the issue against.
 gem 'activerecord', '4.1.6.rc2'
 require 'active_record'
 require 'minitest/autorun'
 require 'logger'


 # Ensure backward compatibility with Minitest 4
 Minitest::Test = MiniTest::Unit::TestCase unless defined?(Minitest::Test)


 # This connection will do for database-independent bug reports.
 ActiveRecord::Base.establish_connection(adapter: 'sqlite3', database:
 ':memory:')
 ActiveRecord::Base.logger = Logger.new(STDOUT)


 ActiveRecord::Schema.define do
   create_table :posts do |t|
 t.string :name
   end


   create_table :comments do |t|
 t.integer :post_id
   end
 end

 class Post  ActiveRecord::Base
   has_many :comments, inverse_of: :post
   validates_presence_of :name
 end

 class Comment  ActiveRecord::Base
   belongs_to :post, inverse_of: :comments
   validates_presence_of :post
 end

 class BugTest  Minitest::Test
   def setup
 Post.delete_all
 Comment.delete_all
   end

   def test_association_persists_valid_objects
 post = Post.new(name: Demoing confusing behavior)
 assert post.valid?
 refute post.persisted?

 comment = Comment.create(post: post)
 assert comment.valid?
 assert comment.persisted?
 assert post.persisted?
 assert_equal 1, Post.count
 assert_equal 1, Comment.count
   end


   def test_valid_present_belongs_to_association
 post = Post.new
 refute post.valid?, Post was valid but should be invalid

 Comment.create post: post
 assert_equal 0, Comment.count, Comment was saved with invalid Post
   end


   def test_showing_why_presence_should_mean_valid
 comment = Comment.create(post: Post.new)

 if (persisted_comment = Comment.first)
   assert_equal comment, persisted_comment, Assigned and persisted
 comments are different
   assert persisted_comment.valid?, Persisted comment isn't valid
 else
   refute comment.valid?, Assigned comment is valid
 end
   end
 end


 Searches online seem to just take this as by design. Yet, it doesn't
 really make sense. The suggestions to workaround this are to either set
 the presence validation on the reference id field or adding an association
 validation.

 Setting the presence validation on the reference id field has the downside
 that it doesn't verify that the associated model object exists (without
 foreign keys defined in the database). The

Re: [Rails-core] strong parameters safety issue enables accidental mass assignment

2014-08-06 Thread Carlos Antonio da Silva

Generally speaking I believe developers should be careful/responsible for
handling what they are sending to their models for mass assignment, and
there's where strong params help. The ideal solution indeed would be for
Parameters not to inherit from Hash, which is something Rails will likely
be changing in the near future. This would avoid people calling methods
that are inherited from Hash in the Parameters object, such as
symbolize_keys. It won't avoid people actually converting the Parameters
object into a Hash with, say, a to_h/to_hash call, but at least that would
make it more explicit.

Thanks for sharing your thoughts on that.


On Wed, Aug 6, 2014 at 1:51 PM, johannes.schlumber...@appfolio.com wrote:

 Hello,

 Recently I was looking into upgrading one of our Rails 3.2 apps to use
 strong_parameters. I encountered what seems like a flaw to me and I would
 like
 to spark discussion about this, hoping for personal learning and potential
 improvement of the rails framework.

 The switch from protected attributes to strong parameters looks from the
 outside
 like access control for mass assignment moves from the model to the
 controllers
 (where, I agree, they belong). However looking at the implementation of
 strong
 parameters, it seems easy for developers to accidentally introduce bugs.

 How is that?
 @params in a controller is of type ActiveController::Parameters, which
 inherits
 from HashWithIndifferentAccess which in turn inherits from a Ruby Hash.
  Strong
 Parameters extends ActiveController::Parameters to have a 'permitted?'
 function,
 essentially acting as the whitelist of permitted parameters for mass
 assignment
 [1].

 Strong Parameters also overrides ActiveRecords sanitize_for_mass_assignment
 function, where it checks if the attributes respond to 'permitted?'. The
 implementation assumes that if the attributes Hash does not respond to
 'permitted?' the mass assignment decision should be deferred to
 ActiveRecord. If
 it responds to 'permitted?' and the mass assigned attributes are not on the
 whitelist it will raise an exception [2].
 The 'permitted?' function here acts as a weird capability [3]. It is weird
 because a capability that is not present will usually deny an action (mass
 assignment) while here the action gets permitted in the absence of the
 capability.

 Why does that matter?
 It matters because it is possible for a developer to accidentally lose that
 capability accidentally very easily on the way from the controller (where
 permit happened and the capability gets created) to the model (where the
 capability gets used). This loss does happen silently and effectively
 disables
 mass assignment protection.

 How does that happen?
 The only class aware of the 'permitted?' capability is
 ActiveController::Parameters, if we call a method that is not aware of the
 capability it can get lost as a side effect:

 class SomeModel  ActiveRecord::Base
   #fields :name, :protected_secret_field
   include ActiveModel::ForbiddenAttributesProtection
 end

 #imagine a request w/ params = {'name' = 1, 'protected_secret_field' =
 2}:
 params.reject!{|k,_|['controller', 'action'].include? k}
 params.permit(:name)
 SomeModel.new(params) #Exception, world is OK
 SomeModel.new(params.symbolize_keys) #No Exception, secret overwritten

 symbolize_keys returns an object of type Hash, that no longer has the
 'permitted?' function, so strong parameter protection is effectively
 disabled.

 Both of these patterns are found quite a bit in our codebases - often in a
 not
 such simple form though.

 In some sense the problem is, that there is non-framework code on the
 codepath between where the whitelist is defined and where it is used, and
 it is
 easy to accidentally lose the whitelist which disables mass assignment
 protection. This problem did not exist with protected attributes, since
 there
 was no codepath.

 Using 'attr_accessible :name' on the model would have prevented these
 problems,
 however I am under the impression that strong_parameters is to replace
 this old
 way.

 Am I the only one worried about this (I have not found any discussion
 online) or
 is this a known problem? If it is known, what is the proposed solution?
 I understand that developers need to take care when handling user input,
 and
 such should not call e.g. symbolize_keys. But the same is true for mass
 assignment vulnerabilities as a whole - in a world where programmers do
 not make
 mistakes mass assignment errors do not exist.

 A possible solution could be to not attach this capability onto the
 parameters
 Hash but store it separately and then retrieve it at mass assignment time
 - so
 it is not the developers responsibility to babysit it. In an alternative
 implementation 'permit/permit!' could be used to declare a list of mass
 assignable parameters for a given action in a controller (optionally on a
 per
 model basis, default empty list) and store it on the request or as a thread
 local variable. The

Re: [Rails-core] Re: reality of fixtures as a default?

2014-08-06 Thread Carlos Antonio da Silva

We have been using fixtures lately in some projects at Plataformatec and
it's been work great.

The ability to have a pre-defined set of fixtures and modify them for each
test works very well for most of our scenarios, and when it does not or it
gets a little complex we build helpers to generate the scenario we need
(generally by modifying existing fixtures, or generating new records based
off the current fixtures attributes). Plus being able to use transactions
most of the time is really good.

One of the most common problem I've seen with fixtures is that people keep
growing and growing them by adding new records every time a new scenario
appears - and I think that's somewhat related to the factores background,
where adding a new trait was just easy and didn't impact the world. In
case of fixtures it's generally better imo to modify your set rather than
adding new records, so that you can have a small and very controlled world
all the time, and work with it.

Anyway, as Chad said this question is more suited for the talk mailing
list, so I'd recommend you posting there :)


On Wed, Aug 6, 2014 at 5:20 PM, Chad Woolley thewoolley...@gmail.com
wrote:

 This list is for rails core discussion, so this question is probably
 better suited for rubyonrails-talk.

 But I'll answer anyway (it would be great to get something like
 fixture_builder into Rails someday, none of the alternatives are good IMO):

 I use factories + fixtures via https://github.com/rdy/fixture_builder

 As for mutually exclusive datasets, depending on your app, maybe they
 can co-exist in the same fixture set.  E.g., have them be separate
 accounts or projects.

 If not, you can pass flags into fixture_builder to tell it which set of
 fixtures to build.

 -- Chad


 On Wed, Aug 6, 2014 at 5:16 AM, Pruss Wan pruss...@gmail.com wrote:

 Hi,

 Is there anybody out there who is really using fixtures exclusively? And
 if so, how do you deal with scenarios when there is a need for multiple
 fixture sets? (datasets that are mutually exclusive) Or is that the part
 where the more popular factories come in?

 For those who are wondering why I even bother, I am in a situation where
 I have plenty of real data to test and debug with, and if these could be
 extracted to fixtures which are maintainable, there might be some value in
 this approach for integration tests.


 Thanks

 --
 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/d/optout.


  --
 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/d/optout.




-- 
At.
Carlos Antonio

-- 
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/d/optout.

Re: [Rails-core] Feature Request: Remove or replace *_path helpers for mailers

2014-06-18 Thread Carlos Antonio da Silva

+1 from my side, never seen a use case for *_path on mailers.


On Wed, Jun 18, 2014 at 12:47 PM, Xavier Noria f...@hashref.com wrote:

 On Wed, Jun 18, 2014 at 5:45 PM, richard schneeman 
 richard.schnee...@gmail.com wrote:

 If we go down this route, the error message should be crystal clear:

 The method `user_path` cannot be used in a mailer as relative links in
 emails do not work. Use `user_url` instead

 Also need to make sure that it raises when rendered with mail_view.


 That'd be really awesome.

  --
 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/d/optout.




-- 
At.
Carlos Antonio

-- 
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/d/optout.

Re: [Rails-core] Allow hash for conditional class attribute in tag helper

2014-03-05 Thread Carlos Antonio da Silva

Or wrap with ():

  *link_to(post.title, post, class: [post, (active if post.active?)])*


On Wed, Mar 5, 2014 at 2:47 PM, Nicolás Sanguinetti 
h...@nicolassanguinetti.info wrote:

 Sorry, it should be [post, post.active?  active]


 On Wed, Mar 5, 2014 at 3:23 PM, Stefan Schüßler sos...@gmail.com wrote:

 That array syntax is invalid.

 On Wednesday, March 5, 2014 6:16:01 PM UTC+1, Nicolás Sanguinetti wrote:

 You can pass Arrays to the `class:` option and it will do what you
 expect it to:

 link_to(post.title, post, class: [post, active if post.active?])

 Cheers,
 -foca


 On Wed, Mar 5, 2014 at 1:36 PM, Stefan Schüßler sos...@gmail.comwrote:

 When dealing with conditional class attribute values in HTML tags, I
 often find myself writing code like:

   link_to(post.title, post, class: post #{post.active? ? active :
 })

 The code would be much cleaner if we allowed a hash syntax:

   link_to(post.title, post, class: {post = true, active =
 post.active?})

 The implementation is straightforward:

   https://github.com/sos4nt/rails/commit/a9ed04f75ce9db46af6cbdefa64dfb
 09fb3eb73a

 What do you think?

 -Stefan

 --
 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-co...@googlegroups.com.
 To post to this group, send email to rubyonra...@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.




-- 
At.
Carlos Antonio

-- 
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] how adding a version when generating a new rails project

2014-03-03 Thread Carlos Antonio da Silva

Indeed I don't think there's need to track versions on a web application,
since it's way more common for people to use tags or similar with git or
some other scm, when they do.

In any case, it's fairly easy to add that to your application if you want
or need it:

*module Todo*
*  class Application  Rails::Application*
*config.version = '1.0'*
*  end*

*  def self.version*
*Application.config.version*
*  end*
*end*

That should do the trick.


On Mon, Mar 3, 2014 at 1:57 PM, Geoff Harcourt geoff.harco...@gmail.comwrote:

  Hi Rain,

 I don't think that web applications are like software libraries in this
 respect. Engineering teams that are pushing software out the door are
 already tracking their versions with commits to their source control.
 SemVer is great because it helps convey things like breaking changes, but
 web apps don't really have the same kind of backwards-compatibility
 problems that libraries might (APIs served by the app might, but that's a
 different issue). If your team is always shipping, and therefore making
 lots of small deploys to production, separately tracking a version number
 is a step that will result in merge conflicts and possibly misleading data
 in the event that multiple pushes are made on a single version of the app.

 - Geoff



 On Monday, March 3, 2014 at 4:22 AM, Rain Chen wrote:

 every lib/gem will have a version, but seems everyone forgot the project
 itself.
 I preferred a config.version option in the applicaiton.rb after running rails
 new project

 module Todo
   class Application  Rails::Application
 ...
 config.version = '1.0.0'
   endend

 then in rails console, we can get the project's version using:
 Todo.version
 = 1.0.0

 there are versions for db migrations, but why not the project? I think
 this can be a standard for a rails project

 any thought for this idea?


  --
 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.




-- 
At.
Carlos Antonio

-- 
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] Rails 4.1

2014-02-25 Thread Carlos Antonio da Silva

Hello Sergio,

the rc1 is out, and basecamp is running 4.1 in production for some time
already, so you should definitely start your new project with it! :)

There might be a new rc in the upcoming days depending on the regressions
we find, and then the final version coming after that (assuming no more
regressions are found). So please, try the new rc and let us know if it's
all good or you find any issues.

Thanks!


On Tue, Feb 25, 2014 at 5:09 PM, Sergio Campamá sergiocamp...@gmail.comwrote:

 Hi,

 Is there a release date for 4.1? I'm starting a new project for the
 company I work for, and I want to use the new enums feature.

 Best regards!
 --
 Sergio Campamá
 sergiocamp...@gmail.com

   --
 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.




-- 
At.
Carlos Antonio

-- 
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] rails issue #13854

2014-02-14 Thread Carlos Antonio da Silva

In general we only backport issues to 4-0-stable, not to 3-2 anymore.

If it hasn't been backported to 4-0 yet, you can ask in the issue for
someone to backport it (it seems a simple fix so it's probably ok to
backport).

Hope that clarifies it :)

On Fri, Feb 14, 2014 at 5:15 PM, nardele salomon del.soft...@gmail.comwrote:

 Hi,

 I contact, asking for his help with a simple question:

 I found a mistake in the active record, very impactful for my development.

 I created an 'issue' on github here https://github.com/rails/
 rails/issues/13854

 The error has been corrected, but only on the master branch, which is the
 4.1.0-beta.

 Doubt it.

 The versions 3.2 and 4.0 do not receive corrections from active record?

 I am very grateful if you could help me understand this mechanism,
 because I hope to contribute much more to the rails project.

 [],
 Nardele Salomon  (from Brazil)

 --
 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.




-- 
At.
Carlos Antonio

-- 
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] rails 4.1 unable to get all enum types

2014-02-05 Thread Carlos Antonio da Silva

This is available on master only, not on the released beta version. I think
you have the constant User::USERTYPES available, the implementation changed
afterwards.

Also, please use the Rails Talk or stack overflow for questions, this list
is mainly for feature discussions. Thanks!


On Wed, Feb 5, 2014 at 6:47 PM, desheng li desheng@gmail.com wrote:

 I just upgrade my app to rails 4.1.0.beta1

 I have a class

 class User  ActiveRecord::Base
 enum usertype: { :employee = 10, :boss = 30, :manager = 40, :admin = 
 50 }}

 All the enum feature works well like user.boss? # ture

 But when I try to get all user types by

 User.usertypes

 I got a undefined method for usertypes

 Any helps?

 This is the link the I learn from
 http://edgeapi.rubyonrails.org/classes/ActiveRecord/Enum.html

 --
 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.




-- 
At.
Carlos Antonio

-- 
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] single quotes for controller generated routes

2014-01-13 Thread Carlos Antonio da Silva

No reason as far as I am aware of, in general Rails uses single quotes for
generated controller views where it doesn't need double quotes, so I think
it's ok changing the generated controller route too.

Please make sure to review the documentation and guides looking to fix
examples too, if you decide to send a pull request.


On Mon, Jan 13, 2014 at 6:11 PM, Cristian Messel mess...@gmail.com wrote:

 Hello Ruby on Rails: Core Community,

 My name is Cristian and this is my first contribution.

 https://github.com/mess110/rails/tree/controller_generator_route_quotes

 What does it do? Currently, when rails generates a controller it adds a
 route to routes.rb (ex: get home/index). All the routes in routes.rb are
 written with single quotes. Except the controller generated route. It is
 written with double quotes. This patch attempts to fix that.

 Example:

 rails new test-app
 cd test-app
 rails g controller home index
 cat config/routes.rb | grep home

 Before this patch

   get home/index

 After this patch

   get 'home/index'

 I ran the generator tests. I would like to hear the community's opinion.
 Is there a specific reason why double quotes are used? If not, I will
 create the pull request.

 Cheers,
 Cris

 --
 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.




-- 
At.
Carlos Antonio

-- 
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] small extension to link_to_if

2013-12-17 Thread Carlos Antonio da Silva

You can already achieve basically the same functionality with Ruby and
conditional modifiers:

%= link_to an_url,.. do %
  Menu Label for admin
% end if user_role.admin? %

%= link_to an_url,.. do %
  Menu Label for user
% end if user_role.user? %

%= link_to an_url,.. do %
  Menu Label for gues
% end if user_role.guest? %

I don't think there's need for new methods in this scenario. Thanks! 3


On Tue, Dec 17, 2013 at 1:34 PM, angelo capilleri capill...@gmail.comwrote:

 Sure,
 the purpose of my example above is only to introduce this.

 When you have a sidebar partial with 3 or more dinamic menu, ex:

 ```ruby
 % if user_role.admin? %
   %= link_to an_url,.. do %
 Menu Label for admin
   % end  %
  % end %

 % if user_role.user?%
   %= link_to an_url,.. do %
 Menu Label for user
   % end  %
  % end %

 % if user_role.guest?%
   %= link_to an_url,.. do %
 Menu Label for gues
   % end  %
  % end %
 ```
 Whit this helper we can have the following code:

 ```ruby
   %= link_to_if! user_role.admin? an_url,.. do %
 Menu Label for admin
   % end  %

   %= link_to_if! user_role.user? an_url,.. do %
 Menu Label for user
   % end  %

   %= link_to_if! role.guest?, an_url,.. do %
 Menu Label for guest
   % end  %
 ```
 In other word has the same role of link_to_if(unless) but allows to get to
 not display nothing in the conditional false case

 Il giorno martedì 17 dicembre 2013 16:11:34 UTC+1, Rafael Mendonça França
 ha scritto:

 Angelo,

 thank you for your suggestion, but is not this already possible using a
 normal `if` statement?

 ```ruby
 % if conditional %
   %= link_to ... %
 % end %
 ```

 I see a point to having a helper if you use this same pattern in a lot of
 places. But, for this case, I recommend to define a helper in your
 application.

 Rafael Mendonça França
 http://twitter.com/rafaelfranca
 https://github.com/rafaelfranca


 On Tue, Dec 17, 2013 at 12:43 PM, angelo capilleri capi...@gmail.comwrote:

  Hi

 I frequently use link_to in the context of conditional statement,
 What do you think about a link helper that return nil when the condition
 is false
 ex:

 # condtional = nil || false

 %= link_to_if conditional, an_url, allow_hide: true %  # = nil

 or

 %= link_to_if! conditional, an_url %  # = nil

 Thank you!


  --
 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-co...@googlegroups.com.
 To post to this group, send email to rubyonra...@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.




-- 
At.
Carlos Antonio

-- 
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] couldn't find file 'jquery.ui.all'

2013-06-29 Thread Carlos Antonio da Silva

jquery-rails 3.0+ has removed jquery-ui as you can see in the
changeloghttps://github.com/rails/jquery-rails/blob/master/CHANGELOG.md#300-29-may-2013.
There's a jquery-ui-rails I think, check the readme for more info.

(and be aware of what Steve has commented ;)


On Sat, Jun 29, 2013 at 9:36 AM, Steve Klabnik st...@steveklabnik.comwrote:

 This list is for discussions of features and behavior of the
 framework, not for help. Please post to rubyonrails-talk or Stack
 Overflow.

 --
 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.





-- 
At.
Carlos Antonio

-- 
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] Re: false.present? is false. Is it desired behaviour?

2013-06-27 Thread Carlos Antonio da Silva

As you can see here:
https://github.com/rails/rails/blob/master/activesupport/lib/active_support/core_ext/object/blank.rb#L55,
blank? is also implemented in FalseClass to always return true, so yes, it
was deliberate :)


On Thu, Jun 27, 2013 at 8:17 AM, Amitav Mohanty
amitavmohant...@gmail.comwrote:

 Hey

 On Wed, Jun 26, 2013 at 10:04 PM, Piotr Sarnacki dro...@gmail.com wrote:

 While technically you could say that false is present, it would be
 really unintuitive for most of the people as present? is supposed to be
 just opposite of blank? and is used to check for truthiness. Additionally
 present? is used in Rails app for a long time, so even if part of Rails
 Core had agreed with your arguments, I would be really surprised seeing
 this changed.


 To analyze the cause, I had looked at the definition of blank?

 def blank?
   respond_to?(:empty?) ? empty? : !self
 end

 Since false does not respond to :empty?, it seems to be false being blank
 is just a by-product of the !self part of the function definition. What I
 wanted to understand is whether this was deliberate.

 Regards,
 Amitav




 On Tue, Jun 25, 2013 at 7:10 PM, Matt Jones al2o...@gmail.com wrote:


 On Jun 25, 2013, at 7:36 AM, James Pinto wrote:

 I understand where you're coming from,
 and I completely disagree

 false is blank, but it's not nil,
 however, in some cases, falseness should not be validated

 validates_presence_of :aggrees_with_contract* is correct, requires
 the user to check the contract*
 validates_presence_of :displays_photo_for_guests *is incorrect,
 because it's only a question and it's ok if the user forgets or chooses not
 to mark*


 If it's OK if the user doesn't send this value, *why* are you validating
 for it to be present? Set a default for your boolean column (which you
 should be doing anyways :) ) and have a nice life.

 --Matt Jones


  --
 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.






 --
 Piotr Sarnacki
 http://piotrsarnacki.com

 --
 You received this message because you are subscribed to a topic in the
 Google Groups Ruby on Rails: Core group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/rubyonrails-core/A-1oZuShUaM/unsubscribe
 .
 To unsubscribe from this group and all its topics, 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.






-- 
At.
Carlos Antonio

-- 
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] Is this a bug in Rails? undefined method `change' for Infinity:Float (NoMethodError)

2013-03-12 Thread Carlos Antonio da Silva

Alright, great to know that was fixed in 3.2.13.rc :). I'll check what we
can do regarding i18n. Thanks!


On Tue, Mar 12, 2013 at 6:00 PM, byrnejb byrn...@harte-lyne.ca wrote:



 On Tuesday, 12 March 2013 16:40:23 UTC-4, Carlos Antonio da Silva wrote:

 There was a problem with i18n versions, so someone locked it to 0.6.1
 before releasing the first rc =(. It's already fixed but the rc is locked
 and probably 3.2.13 will be, need to check that.


 On Tue, Mar 12, 2013 at 5:38 PM, James B. Byrne byr...@harte-lyne.cawrote:

 Bundler could not find compatible versions for gem i18n:
   In Gemfile:
 rails (= 3.2.13.rc2) ruby depends on
   i18n (= 0.6.1) ruby


  i18n (0.6.4)

 Unfortunately, I have another dependency that requires I18n (0.6.4) so
 downgrading is not an option I am prepared to consider.  Is there some
 reason that RoR-3.2.12 works with 0.6.4 and 3.2.13 does not?



 I extracted the bits of interest and tested them against ror-3.2.13rc2.
 The test now passes.   So, I will roll this back into the project and go on
 from there.

 --
 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.






-- 
At.
Carlos Antonio

-- 
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] Re: Home page route instead of root?

2013-03-11 Thread Carlos Antonio da Silva

Another point to take into account is that the root route can be used for
any namespace, which is the root for that particular namespace. With no
namespace, it's the root page, ou home page as you say.


On Mon, Mar 11, 2013 at 1:54 PM, Richard Schneeman 
richard.schnee...@gmail.com wrote:

 I've had similar questions from students, though I don't remember if any
 have specifically addressed it as `home`. What if we added the word home
 to the description of the root path that is included (and commented out) by
 default after `rails new`? If students don't read or ctrl-f for home in
 the default routes file, changing the name generated wouldn't help anyway.

 Adding aliases could be a can of worms, why not 'welcome' or 'core' or
 'main' etc. This is a relatively trivial in the grand scheme of things to
 discuss, open up a PR (i would prefer documentation for now) and we
 can talk about it there.

 --
 Richard Schneeman
 http://heroku.com
 @schneems http://twitter.com/schneems

 On Monday, March 11, 2013 at 11:11 AM, Ryan Bigg wrote:

 http://transitionculture.org/wp-content/uploads/bikeshed2.jpg


 On 11 March 2013 07:23, Apoorv Parijat apoorvpari...@gmail.com wrote:

 For a domain, say example.org, you would call example.org/ as the
 root domain. The root domain points to the home page
 of the website. The idea of root should be made clear to students from
 the beginning.

 I think, since root is not that obscure, we can just let it be ?


 On Monday, 11 March 2013 04:12:38 UTC+5:30, Jeff Cohen wrote:

 Maybe it's just me, but I think home might be a better description than
 root.  Students ask me how do I indicate which action is my home page,
 not how do I indicate which action is my root page.  If this sounds
 appealing I can try to dig through the router code and see if I can submit
 a PR in time for Rails 4, and make home an alias for root.

 But if there's actually a good reason for keeping it as root, let me
 know and save me the effort :-)

 Thanks!
 Jeff

  --
 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.




  --
 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.






-- 
At.
Carlos Antonio

-- 
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] Re: Model generator: Invoke active_record only 1x for mulitiple models?

2013-02-23 Thread Carlos Antonio da Silva

Yes, zeus is a nice one to speed up development lifecycle. There's also
spring http://github.com/jonleighton/spring, a new tool from jonleighton
that's under test and is likely to be the default integration with Rails as
part of the development process, I recommend you guys to take a look.

Pete, I think the path that zeus and spring are taking is the way to go,
since it does not help only with model generators, but speeds up
generators, console, tests, and everything else related to our development
workflow.


On Sat, Feb 23, 2013 at 4:48 PM, Borna Novak dosadni...@gmail.com wrote:

 Pete,

 this project saved a couple of years of my life already:
 https://github.com/burke/zeus

 Basically, it runs rake jobs, generators, destroyers, tests... in under a
 second by preloading the various environments and then just forking an
 appropriate existing process when a command is triggered, real life-saver


 Borna


 On Friday, February 22, 2013 5:37:36 PM UTC+1, Pete wrote:

 Currently (3.2.12), Rails needs 1 separate command per model/migration
 to be generated. Each such **rails g ... command invokes **active_record 
 once.


 When a project needs to generate a larger number of models/migrations,
 this process can take up lots **of time.

 So, this...

 rails g model_a name:**string [...]
 rails g model_b name:**string [...]
 rails g model_c name:**string [...]
 ...etc...

 invoke  active_record
 createdb/migrate/**201302...
 createapp/models/**model_a.rb
 [...]
 invoke  active_record
 createdb/migrate/**201302...
 createapp/models/**model_b.rb
 [...]
 invoke  active_record
 createdb/migrate/**201302...
 createapp/models/**model_c.rb
 [...]
 ...etc...

 ...should become something (**speedier) like this:

 rails g model_a name:string [...], model_b name:string [...],
 model_c name:string [...] ...**etc...

 invoke  active_record
 createdb/migrate/**201302...
 createapp/models/**model_a.rb
 [...]
 createdb/migrate/**201302...
 createapp/models/**model_b.rb
 [...]
 createdb/migrate/**201302...
 createapp/models/**model_c.rb
 [...]
 ...etc...

  --
 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.






-- 
At.
Carlos Antonio

-- 
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] ActiveModel ::Errors

2013-01-30 Thread Carlos Antonio da Silva

How about:

   [:start, :stop].each { |attr| errors.add(a,date must be) }

It seems good enough to me, without the need of new APIs. Wdyt?


On Wed, Jan 30, 2013 at 2:16 PM, angelo capilleri capill...@gmail.comwrote:

 I want made a PR to get the possibility to add more attribute for
 errors.add method:

 Ex.
 Now:
 ...
 validate dates_must_be_coherent

 def dates must be coherent
if start.present?  stop.present?  start  stop
 errors.add(:start,date must be )
 errors.add(:stop,date must be)
  end
 end

 with the PR:

 def dates must be coherent
if start.present?  stop.present?  start  stop
 errors.add([:start, :stop],date must be )
  end
 end

 Thanks for reviews!!

 --
 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.






-- 
At.
Carlos Antonio

-- 
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] ActiveRecord::Persistence.increment! requires a row lock to ensure isolated updates

2013-01-23 Thread Carlos Antonio da Silva



 If this is indeed your use case, what I'm advocating here is much 
 simpler than that. I just want to be able to increment numeric columns 
 in active record without declaring them as counter cache columns. 


You should still be able to do that by calling increment_counter or 
update_counters class methods, they're generic methods for updating 
counter columns, which mean any numeric column should work, they're not 
bound to counter cache columns (even though the filename kinda implies 
that).

object.class.increment_counter(:attr_name, object.id)
object.class.update_counters(object.id, :attr_name = 1)

I believe that should work fine for this purpose.

On Wednesday, January 23, 2013 11:28:08 PM UTC-2, ajsharp wrote:

 On Wed, Jan 23, 2013 at 4:41 PM, Gabriel Sobrinho 
 gabriel@gmail.com javascript: wrote: 
  Since I have to keep a cache column of the paid value for the debt, I 
 have 25 workers (sidekiq) that can call `increment!(:paid_value,  
 paid_value)` and it should keep the total paid value. 
  
  [SNIP] 
  
  Yes, I'm thinking about that and seems there is no way to handle this in 
 a 
  smart way. 
  
  Developers can think from what reason I've incremented by 100 and it 
  incremented by 300 until he figure out that was incremented by other 
  threads too. 
  

 Gabriel: I may be confused about your use case, but it sounds like 
 your concern is around ensuring that the database client that makes an 
 update can rely on the fact that his update was the only one made. Or, 
 at least, your application has an audit concern, where, you need to 
 be able to prove how values were mutated. There are a couple of ways 
 to handle this, optimistic locking is one, row-level locks are 
 another, or designing a double-entry transaction model is another (so 
 you don't rely on locks at all). 

 If this is indeed your use case, what I'm advocating here is much 
 simpler than that. I just want to be able to increment numeric columns 
 in active record without declaring them as counter cache columns. 

  Maybe some documentation on increment(!)/decrement(!) methods explaining 
  that is not safe to use it concurrently will avoid to think they are. 

 That'd certainly be helpful, but the same logic applies to any method 
 you use. Any sort of CRUD application is subject to concurrent access 
 and update problems. Are you simply suggesting documenting 
 #increment!/#decrement! because they *don't* behave in the way that 
 I'm advocating for in this thread? 


-- 
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.
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] Re: ActiveRecord::Persistence.increment! requires a row lock to ensure isolated updates

2013-01-22 Thread Carlos Antonio da Silva

I may be wrong but that's my understanding: #increment happens at instance
level, so it takes into account the current value at that particular
instance, whereas .update_counters is just a straight sql query, so it can
operate using column + value directly. If you want to allow the database to
determine the value, use the latter.

On Tue, Jan 22, 2013 at 12:54 PM, ChuckE honeyryderch...@gmail.com wrote:

 The same update statement would work for MySQL as well.





-- 
At.
Carlos Antonio

-- 
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] Docrails Git Workflow

2013-01-07 Thread Carlos Antonio da Silva

Separate repo here as well.


On Mon, Jan 7, 2013 at 5:50 PM, Gosha Arinich m...@goshakkk.name wrote:

 I have always cloned it separately as well.

 Cheers,
 Gosha Arinich

 On Monday, January 7, 2013 at 10:45 PM, James Gifford wrote:

 I have always cloned docrails separately.

 --
 James Gifford
 2162238574

 On Jan 7, 2013, at 13:00, Tim Raymond xtjraymo...@gmail.com wrote:

 Hey everyone,

 For those of you who contribute to docrails, I'm trying to get a sense for
 the crowd-favorite git workflow. I found
 http://www.slideshare.net/martinsvalin/contribute-to-rails suggesting
 that it be added as a remote and pulled into another branch off an
 already-cloned rails repo. This worked fine for me, and I was able to push
 changes, but I'm wondering if cloning docrails separately is more
 commonplace (or if there are any hazards with the method I used). The
 guides are ambiguous in this area and I'd love to update them to cover this
 once I hear from the community.

 Thanks,
 Tim

 --
 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/-/mCWapaXPMHoJ.
 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.




-- 
At.
Carlos Antonio

-- 
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] content_tag_for for combining more AR instances

2013-01-06 Thread Carlos Antonio da Silva

This behavior was added recently and it's meant to render a collection of
records, so I don't think it's worth changing it. But, as you can see here:
https://github.com/rails/rails/blob/master/actionpack/lib/action_view/helpers/record_tag_helper.rb#L81,
you can add a third argument that's the prefix used in dom_id/dom_class,
which means you could mix and match like this:

content_tag_for :div, @invoice_items, dom_id(@invoice)

Allowing you to use the collection of items in content_tag_for, prefixed by
the dom_id of the current @invoice. I think that should work fine.

On Sun, Jan 6, 2013 at 7:56 PM, Fabrizio Regini freege...@gmail.com wrote:

 release




-- 
At.
Carlos Antonio

-- 
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: Deferrable constraints in Migrations DSL

2012-11-29 Thread Carlos Antonio da Silva

Gary, I'd say never, most of the core prefer not to :)


On Thu, Nov 29, 2012 at 8:42 PM, Gary Weaver garyswea...@gmail.com wrote:

 And, just for record, I don't like Cucumber ;)


 I didn't like it either, but these guys make it look easy, at least to me
 :) : https://github.com/gregbell/active_admin/tree/master/features

 I think it depends on what it is being used for. I'd rather be writing
 rspecs though. When is Rails going to give up and just use rspec? :)



 On Thu, Nov 29, 2012 at 5:06 PM, Rafael Mendonça França 
 rafaelmfra...@gmail.com wrote:

 We can't accept a feature without know what are the impacts in the
 codebase.

 This is valid for everyone, either the core members.

 I can say that I want this feature and accept it, but nothing stops the
 core members to revert it. And don't expect me to defend your feature,
 since you should be the interested.

 Would be more wast of time if we accept it now and, when you come up with
 the code, we rejected it because it add more complexity in the framework
 that we want.

 Also, what is the difference of writing 10 huge emails and get the
 feature reject? I think is the same. With working code you have more
 chances. And, as I said in my last email, either if we don't accept, you
 will have working code that solves your problem.

 If you don't want to scratch your itch and provide a patch, I'm sorry,
 but don't expect we to accept.

 And, just for record, I don't like Cucumber ;)

 Rafael Mendonça França
 http://twitter.com/rafaelfranca
 https://github.com/rafaelfranca



 On Thu, Nov 29, 2012 at 7:27 PM, Rodrigo Rosenfeld Rosas 
 rr.ro...@gmail.com wrote:

  Well, then we have a real problem here. I don't start coding anything
 before discussing them. I consider it a waste of time (in the case the
 feature has been rejected).

 So I don't think how I could ever contribute to Rails. I won't ever
 write a patch before getting it accepted first. I've done it once after
 some previous discussion and after the issue became totally abandoned with
 no feedback I decided that I wouldn't ever do it again. Too much effort to
 code to get it rejected or ignored later.

 I don't understand why code is needed to discuss a feature or a new API.
 Some people have a hard work trying to get RSpec to read as plain English
 but if you try to spec your requested API in plain English, since it is not
 code, people won't even consider it.

 Just pretend my feature requests are Cucumber features ;)

 Em 29-11-2012 15:03, Rafael Mendonça França escreveu:

 Rodrigo, sorry but I think you misunderstood. I don't use MySQL,
 actually I even don't like it. I prefer to use PostgreSQL. If you take 10
 minutes you can see a lot of pull requests adding features for PostgreSQL
 in Rails.

  What I said is that I don't think the feature as it was implemented is
 a good fit for core. I've been using database constraints but I've always
 used SQL to create them.

  Also I don't like to discuss features without seeing the code. I need
 to see how the feature was implemented to say if I would accept or not. It
 don't need to be a full patch but something to, at least, make explicit
 what are the benefits and the drawbacks of adding a feature to the
 framework.

  We should always look after the cost of maintainability. Add a new
 feature to Rails is as easy as pressing a green button. Discuss it is even
 easier. Maintain it is not. I prefer to put into Rails features that I want
 to maintain in the future and I believe that are good for the framework.
 This is how Rails work since the beginning.

  I'm not saying that I don't believe in your proposed feature, neither
 that I don't want constraints in the framework. But, without seeing the
 code I can't discuss anything.

  That said, lets see that patch. At least, if it is not accepted, you
 can easily create a plugin that you can maintain and don't need to worry if
 it will break in the next Rails release.

 Rafael Mendonça França
 http://twitter.com/rafaelfranca
 https://github.com/rafaelfranca



 On Thu, Nov 29, 2012 at 2:19 PM, Rodrigo Rosenfeld Rosas 
 rr.ro...@gmail.com wrote:

  Em 29-11-2012 09:42, Rodrigo Rosenfeld Rosas escreveu:

  Em 29-11-2012 09:21, Gary Weaver escreveu:
  ...

 If the Rails community can't convince itself about the importance of
 basic things in ACID databases like transactions, foreign keys and other
 constraints than I think I'm out of luck with regards to deferrable
 constraints... :( (yes, when I talk about transactions I mean the huge
 amount of Rails applications out there running MySql with MyISAM engine,
 that used to be the default one until recently in 5.5 when the InnoDB is
 now the default one).


 Sorry, but I've just became aware of this video and didn't resist
 posting it here :) I'm hoping Rails core members that still use MySQL could
 open their minds after watching this video:

 Why Not MySQL?
 http://www.youtube.com/watch?v=1PoFIohBSM4
   --
 You received this message because you are

Re: [Rails-core] has_secure_password

2012-11-28 Thread Carlos Antonio da Silva

min_cost doesn't need to be deprecated, since it was just added to master.
I think it's fine for it to be a cost number, similar to devise, though,
but others might have different opinions on that.

On Wed, Nov 28, 2012 at 8:29 PM, Robert Evans rob...@codewranglers.orgwrote:

 devise




-- 
At.
Carlos Antonio

-- 
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: [ANN] Rails 3.2.9.rc1 has been released

2012-10-31 Thread Carlos Antonio da Silva

Hello, the pull request has been merged and will be in 3.2.9, thanks!

On Wed, Oct 31, 2012 at 8:18 AM, Aliaksandr Rahalevich saks...@gmail.comwrote:

 Hi here. I have one failed spec in my application and it's caused by return
 value from ActiveRecord#update_column method. It looks like this method is
 broken to return correct value. Here is my pull request to solve this
 problem.
 https://github.com/rails/**rails/pull/8083https://github.com/rails/rails/pull/8083
 Please take a look on this.

  --
 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/-/unzdbMxzykkJ.

 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.




-- 
At.
Carlos Antonio

-- 
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] [Proposal] Team issuebusters

2012-09-11 Thread Carlos Antonio da Silva

We have done a lot of work on the issues this year, and we were able to bring 
the number down to almost a half - it was over 800 - and we didn't even know 
about what happened at RailsConf. The problem is that now it's getting harder 
to bring this number down.

Going through old and stale tickets is an awesome way to help for sure, some 
folks like Rafael, Prem, Steve, Richard and I (among others) have been trying 
to do this, and we're getting some of them closed as possible. But as we close, 
more and more keep coming, so the number stays the same. It was over 500 these 
days, not we got it back to ~470. I have around 50 or more tickets bookmarked 
here to take a look, but real life always happens :).

So please, if you can that'd be a great help. In any case, just pay attention 
to some issues that have people assigned to them, those are probably the ones 
that need work to be done and shouldn't be just closed. Trying to go through 
the issues list, and making sure bugs are still real bugs in master, are also 
another great way to help.  

When in doubt, just ping some of us to help.
Thanks.


--  
At.
Carlos Antonio


On Tuesday, September 11, 2012 at 12:50 PM, Godfrey Chan wrote:

 I thought this was obvious and it turns out I'm right :P Since you and steve 
 are probably focusing on newer tickets, I guess I can start going through the 
 stale tickets from the end and ping the reporters… if no one responded in a 
 while (a week or so?) then I'll ping one of you to close? Would that work?
  
 (Perhaps we can be more proactive in closing stale PRs that aren't receiving 
 enough attention from the core team, and ask the author to reopen if they are 
 still interested in pursuing that? That way we can escalate PRs that have 
 been re-opened a few times and make sure they get a final yes/no from the 
 core.)
  
 Godfrey
  
  
 On 2012-09-11, at 8:42 AM, Prem Sichanugrist wrote:
  We actually already have a team that's working on the issues (such as me 
  and Steve K.) We might be a little slow sometimes, but please trust me that 
  it's getting better than before now. :)
   
  I think currently everyone are so busy with Rails 4 release (we do want to 
  send some patches in as well) as they're right around the corner, so the 
  respond time might be a little slow. After the RC goes out, I'm planning to 
  do a big going-through the issues queue.
   
  If you would like to help us for now, feel free to go through those issues, 
  ping the appropriate person to respond to it, or ask if it can be close. 
  Rails Core team always appreciate your contribution, and I'm pretty sure 
  they won't hesitate to give you out the permission to manage tickets when 
  it's time.
   
  Thank you so much for stepping up for this.
   
  - Prem  
   
  On Tuesday, September 11, 2012 at 11:28 AM, Godfrey Chan wrote:
   
   As Richard pointed out in the other thread, we have a lot of open issues, 
   and it'd be nice if we could do something about that. Evan tried to get 
   people to review GH issues at Railsconf, and I believe there were some 
   success there. Any interest in formalizing this effort and make it 
   sustainable?

   There are a few things about these issues that is pretty mechanical and 
   almost anyone could do it (I'll be the first to volunteer):

   1. As new issues are coming in -
   - Tag them appropriately (activerecord, activesupport, etc) - I think 
   someone is already doing this and they might or might not need more help 
   doing this
   - Ask for logs and other clarifications from reporter if necessary
   - Do preliminary (re)searches in the source, find out who is most likely 
   to be the owner of the affected code and /cc (or perhaps even assign 
   the issue with the tag needs triage or something) them for feedback
   - Close inappropriate issues (inflector patches, feature requests, 
   questions etc) and direct the reporter to the right channels (stack 
   overflow, rails guides, mailing lists, etc)

   2. For older tickets -
   - Review if they are still relevant  
   - Ping the reporters or the code owner for updates, and close the issues 
   as appropriate

   While some of these (mostly the communications part) can be done by just 
   anyone, I believe certain parts of the flow (tagging and closing tickets) 
   requires repo-collab access, so some formalized recruiting and management 
   effort would be necessary to make this effective. If granting full 
   collaborator access is a problem, perhaps it is something that we could 
   try working out with Github?

   Anyways, I'm happy to help here, and I'm sure there would be a few others 
   on the list who wouldn't mind committing a few hours per week doing this. 
   So let me know how I could best spend my time helping out here.

   Godfrey

   --  
   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

Re: [Rails-core] [Proposal] Team issuebusters

2012-09-11 Thread Carlos Antonio da Silva

Ok, Rafael has just listed everything a lot better than I did :)

On Tue, Sep 11, 2012 at 1:07 PM, Carlos Antonio da Silva 
carlosantoniodasi...@gmail.com wrote:

 We have done a lot of work on the issues this year, and we were able to
 bring the number down to almost a half - it was over 800 - and we didn't
 even know about what happened at RailsConf. The problem is that now it's
 getting harder to bring this number down.

 Going through old and stale tickets is an awesome way to help for sure,
 some folks like Rafael, Prem, Steve, Richard and I (among others) have been
 trying to do this, and we're getting some of them closed as possible. But
 as we close, more and more keep coming, so the number stays the same. It
 was over 500 these days, not we got it back to ~470. I have around 50 or
 more tickets bookmarked here to take a look, but real life always happens
 :).

 So please, if you can that'd be a great help. In any case, just pay
 attention to some issues that have people assigned to them, those are
 probably the ones that need work to be done and shouldn't be just closed.
 Trying to go through the issues list, and making sure bugs are still real
 bugs in master, are also another great way to help.

 When in doubt, just ping some of us to help.
 Thanks.

 --
 At.
 Carlos Antonio

 On Tuesday, September 11, 2012 at 12:50 PM, Godfrey Chan wrote:

 I thought this was obvious and it turns out I'm right :P Since you and
 steve are probably focusing on newer tickets, I guess I can start going
 through the stale tickets from the end and ping the reporters… if no one
 responded in a while (a week or so?) then I'll ping one of you to close?
 Would that work?

 (Perhaps we can be more proactive in closing stale PRs that aren't
 receiving enough attention from the core team, and ask the author to reopen
 if they are still interested in pursuing that? That way we can escalate PRs
 that have been re-opened a few times and make sure they get a final yes/no
 from the core.)

 Godfrey


 On 2012-09-11, at 8:42 AM, Prem Sichanugrist wrote:

 We actually already have a team that's working on the issues (such as me
 and Steve K.) We might be a little slow sometimes, but please trust me that
 it's getting better than before now. :)

 I think currently everyone are so busy with Rails 4 release (we do want to
 send some patches in as well) as they're right around the corner, so the
 respond time might be a little slow. After the RC goes out, I'm planning to
 do a big going-through the issues queue.

 If you would like to help us for now, feel free to go through those
 issues, ping the appropriate person to respond to it, or ask if it can be
 close. Rails Core team always appreciate your contribution, and I'm pretty
 sure they won't hesitate to give you out the permission to manage tickets
 when it's time.

 Thank you so much for stepping up for this.

 - Prem

 On Tuesday, September 11, 2012 at 11:28 AM, Godfrey Chan wrote:

 As Richard pointed out in the other thread, we have a lot of open issues,
 and it'd be nice if we could do something about that. Evan tried to get
 people to review GH issues at Railsconf, and I believe there were some
 success there. Any interest in formalizing this effort and make it
 sustainable?

 There are a few things about these issues that is pretty mechanical and
 almost anyone could do it (I'll be the first to volunteer):

 1. As new issues are coming in -
 - Tag them appropriately (activerecord, activesupport, etc) - I think
 someone is already doing this and they might or might not need more help
 doing this
 - Ask for logs and other clarifications from reporter if necessary
  - Do preliminary (re)searches in the source, find out who is most likely
 to be the owner of the affected code and /cc (or perhaps even assign the
 issue with the tag needs triage or something) them for feedback
  - Close inappropriate issues (inflector patches, feature requests,
 questions etc) and direct the reporter to the right channels (stack
 overflow, rails guides, mailing lists, etc)

 2. For older tickets -
  - Review if they are still relevant
 - Ping the reporters or the code owner for updates, and close the issues
 as appropriate

 While some of these (mostly the communications part) can be done by just
 anyone, I believe certain parts of the flow (tagging and closing tickets)
 requires repo-collab access, so some formalized recruiting and management
 effort would be necessary to make this effective. If granting full
 collaborator access is a problem, perhaps it is something that we could try
 working out with Github?

 Anyways, I'm happy to help here, and I'm sure there would be a few others
 on the list who wouldn't mind committing a few hours per week doing this.
 So let me know how I could best spend my time helping out here.

 Godfrey

 --
 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

Re: [Rails-core] datetime_select - change order of time and date

2012-09-08 Thread Carlos Antonio da Silva

Yeah, I think it's fine to merge it in as long as we have some code to look
at :)

On Fri, Sep 7, 2012 at 2:31 PM, Godfrey Chan godfrey...@gmail.com wrote:

 For something like this you might want to just do it and send a PR, it
 sounds pretty reasonable so I don't think you'll have much trouble getting
 it merged :)

 On 2012-09-06, at 6:35 AM, Ex wrote:

 date_select has option :order which provide array containing :day, :month
 and :year.

 But datetime_select doesn't allow to provide, for example that:

 *:order = [:hour, :minute, :day, :month, :year**]*.

 I think that adding few elements, such as :hour, :minute for :order
 option in datetime_select would be very useful.

 --
 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/-/OhYr1Mh6MCAJ.
 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.




-- 
At.
Carlos Antonio

-- 
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: Feature feedback before working and pull request please..

2012-09-07 Thread Carlos Antonio da Silva

I believe you should be able to achieve the same just by overriding the
#user method in your class. I've commented on your last gist example with
an example code to make things more clear.

On Fri, Sep 7, 2012 at 2:28 PM, Joe Ferris jfer...@thoughtbot.com wrote:

 This looks useful to me. If you did implement this, it would be less rigid
 if you accepted a class instead of a class name, because that would allow
 you to pass anything that responds to #new.

 -Joe


 On Thursday, September 6, 2012 8:29:40 AM UTC-4, Kensodev wrote:

 Hey,

 For a while now, I am thinking about implementing a feature into Rails.
 Since it's not a simple single liner, I thought I should get feedback on
 it and maybe some guidelines before I continue on with coding it.

 The feature I would like to implement is nil_object pattern.

 Here's some code for example

 https://gist.github.com/**3655723 https://gist.github.com/3655723

 As you can see, the post belongs to a user and I am printing out the user
 display name for every post.

 This is a pretty common thing in every rails app I ever saw, some
 preload, some let it go N+1 without caring.

 The problem is, that if you don't have the user in the database, the view
 code will fail on NoMethodError for NilClass.

 To Avoid this here's what I want to do:

 https://gist.github.com/**3655751 https://gist.github.com/3655751

 This way, if the database has no record for that user, it will load the
 nil_user class and the code will now break.

 This can come in handy not only for the belongs_to but for the has_one
 relation as well.

 So... This is the feature I want to implement, thoughts? feedback?
 guidelines?

  --
 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/-/EX61uUxjIkQJ.

 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.




-- 
At.
Carlos Antonio

-- 
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] Suggestion: render filters

2012-09-07 Thread Carlos Antonio da Silva

Please show any real use case where this will be useful, to make things
more clear. Otherwise it's just hard to figure it out examples where it's
useful or not. Thanks.

On Wed, Sep 5, 2012 at 3:53 PM, Alexander Kurakin kuraga...@mail.ru wrote:

 Will not be useful functionality similar
 https://github.com/shell/rails3_before_render ? Something like
 ActionController filters but not before action. Filters before render. See
 also http://www.perfectline.ee/blog/ruby-on-rails-before-render-filter,
 http://penkin.co.uk/rails3_before_render-plugin/. And don't you know gem
 for this? Thanks.

 --
 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/-/VVF2HksqidUJ.
 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.




-- 
At.
Carlos Antonio

-- 
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 requirement for _attributes suffix for association names in mass assignment security and model data go away in Rails 4?

2012-08-14 Thread Carlos Antonio da Silva

As an addition, accepts_nested_attributes is a feature *meant* for
associations, whereas mass assignment helpers - attr_accessible and friends
- are not. I don't think it's that worth to change it in a way to check for
associations when they're called for each attribute, that'd be a lot of
effort for a not majority of use cases (ie it'd slow down the attribute
definitions to search for associations). Just my two cents :).

On Tue, Aug 14, 2012 at 11:55 AM, Steve Klabnik st...@steveklabnik.comwrote:

 Even better: mass assignment security is going away:
 https://github.com/rails/strong_parameters

 --
 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.




-- 
At.
Carlos Antonio

-- 
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] Looking for feedback on a change to ActiveModel

2012-07-28 Thread Carlos Antonio da Silva

I'd say it's unnecessary cluttering to the API, and could collide with someone 
using `model_name` in any sort of model already out there.

I think you may be overlooking the way to create your super simple object, 
probably one of these two would work quite fine:

Class.new(OpenStruct) do
  def self.model_name
@model_name ||= ActiveModel::Name.new(self)
  end
  def self.name
User
  end
end


Class.new(OpenStruct) do
  def self.name
User
  end

  extend ActiveModel::Naming
end



Also, I don't see why you couldn't just create a real class and extend Naming 
on it, should work just fine :). 

-- 
At.
Carlos Antonio


On Friday, July 27, 2012 at 7:25 PM, Amiel Martin wrote:

 
 Hello, I'm looking for feedback on a possible pull-request to rails.
 
 
 Here's the idea: right now any time an ActiveModel::Name is needed, it is 
 accessed through model.class.model_name.
 
 
 In other words, currently, it's something like this:
 
 # Somewhere in rails model.class.model_name class MyModel def self.model_name 
 ActiveModel::Name.new(self) end end 
 
 
 And I'd like it to be like this:
 
 # Somewhere in rails model.model_name class MyModel def self.model_name 
 ActiveModel::Name.new(self) end delegate :model_name, to: :'self.class' end 
 
 
 Here's a gist of what inspired me to try going this direction: 
 https://gist.github.com/3096204
 
 
 I started with this: 
 https://github.com/amiel/rails/commit/a64e5b4ccf9e851b06cd2eb64d824a9c2043c6e7,
  and realized that maybe I should get some feedback first.
 
 
 My initial questions are:
 
 Do you think this is a good idea? Also, I'm surprised this hasn't been done 
 already, have I missed a rejected pull request?
 How should the instance method model_name be added to ActiveModel classes? 
 The class method model_name is provided by extending ActiveModel::Naming. Is 
 it appropriate to use the extended hook inActiveModel::Naming to either 
 include another module or use define_method?
 What are some arguments for or against the change? I'm mostly looking for 
 arguments for the change to include in the pull request description, but I'm 
 also curious what the arguments against would be.
 
 
 This was all posted to a gist here: https://gist.github.com/3189699, feel 
 free to comment there or reply here.
 
 Thanks, 
 
 -Amiel 
 
 -- 
 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/-/ceX5k_DCZgkJ.
 To post to this group, send email to rubyonrails-core@googlegroups.com 
 (mailto:rubyonrails-core@googlegroups.com).
 To unsubscribe from this group, send email to 
 rubyonrails-core+unsubscr...@googlegroups.com 
 (mailto: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] Yet another pull request nag for 6654 -- postgresql-auto-reconnect-2

2012-07-02 Thread Carlos Antonio da Silva

Just commented on the issue, thanks.

-- 
At.
Carlos Antonio


On Monday, July 2, 2012 at 8:48 PM, Steve Jorgensen wrote:

 ... to fix a problem with PostgreSQL reconnect after connection loss  put 
 test coverage in place to keep it working in the future.
 -- 
 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/-/EecNy-qyKwgJ.
 To post to this group, send email to rubyonrails-core@googlegroups.com 
 (mailto:rubyonrails-core@googlegroups.com).
 To unsubscribe from this group, send email to 
 rubyonrails-core+unsubscr...@googlegroups.com 
 (mailto: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] custom validations only if all attributes are valid

2012-06-21 Thread Carlos Antonio da Silva

I agree with Steve, when we call valid?, we expect all validations to run. If 
you want to skip some validation in case errors already exist in the object for 
any particular reason, you can always to that as you said: `if errors.empty?`. 
This will give you the behavior you expect, although I'd recommend avoiding 
this and running all validations.

-- 
At.
Carlos Antonio


On Thursday, June 21, 2012 at 9:51 AM, Steve Klabnik wrote:

 I think I'd be much more annoyed by this kind of behavior. Okay,
 these two things are wrong. Let's fix them. Wait, now it's _still_
 wrong, with something totally unrelated?
 
 You could fix this case almost trivially by 'if age.to_i  16', right?
 I mean, I know you're talking about a more general case, but...
 
 -- 
 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 
 (mailto:rubyonrails-core@googlegroups.com).
 To unsubscribe from this group, send email to 
 rubyonrails-core+unsubscr...@googlegroups.com 
 (mailto: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] ActiveModel::Serializers::JSON support arbitrary keys

2012-06-21 Thread Carlos Antonio da Silva

Just linking the related discussion on issues tracker: 
https://github.com/rails/rails/issues/6811

-- 
At.
Carlos Antonio


On Thursday, June 21, 2012 at 11:22 AM, Pier-Olivier Thibault wrote:

 
 Is there a reason why AM:S doesn't support arbitrary keys to serialization? I 
 can see a lot of uses cases where arbitrary keys could come handy. Right now, 
 if one tries to do it, AM:S checks if the keys match a method of the model 
 and raises exception if it can't find any.
 
 class Client  ActiveRecordBase attr_accessible :name, :address, as: :creator 
 include ActiveModel::Serializers::JSON def attributes {label: name, value: 
 id} end 
 
 While I can easily create a method for all the keys I want to create, take 
 the example above, where a jquery plugin requires a data structure of value: 
 id, label: string. Does it really make sense to create a value and label 
 method in a model? I can see this becoming cumbersome real fast (different 
 values for different query).
 
 
 -- 
 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/-/td2Y13_PRhIJ.
 To post to this group, send email to rubyonrails-core@googlegroups.com 
 (mailto:rubyonrails-core@googlegroups.com).
 To unsubscribe from this group, send email to 
 rubyonrails-core+unsubscr...@googlegroups.com 
 (mailto: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] Rails production load order giving uninitialized constant (NameError)

2012-06-21 Thread Carlos Antonio da Silva

Perhaps you'd like to try the Ruby on Rails: Talk mailing list instead, for 
general questions and help. The Core list is meant to discuss new features and 
changes in Rails. Thanks.

-- 
At.
Carlos Antonio


On Thursday, June 21, 2012 at 5:16 PM, A L wrote:

 Hi,
 
 I have a related but separate question.  Again, please redirect me if I'm in 
 the wrong place.
 
 I've been getting this error in production (on Heroku) only (it happens when 
 the application is loading):
 
 2012-06-21T09:30:19+00:00 app[web.1 (http://web.1)]: 
 /app/app/controllers/spree/
 checkout_controller_decorator.rb:3:in `block in ': uninitialized constant 
 Spree::Calculator::CouldNotCalculateShipping (NameError)
 
 Here's the gist of my decorator files: https://gist.github.com/2965034
 
 I'm trying to rescue errors from my Spree calculators. I'm thinking it's an 
 issue with the load order, but am not familiar enough to know where to tweak 
 things.
 
 I've tried:
 
 require 'spree/calculator_decorator' 
 
 in the checkout_controller_decorator.rb.
 
 and adding:
 
 Dir.glob(File.join(File.dirname(__FILE__), ../app/**/*_decorator*.rb)) do 
 |c|
 Rails.configuration.cache_classes ? require(c) : load(c)
 end
 
 per http://guides.spreecommerce.com/logic_customization.html
 
 I'm thinking this isn't a Spree issue, but an engines issue that I'm getting 
 stuck on.  It's probably not even an issue, but just me not knowing how 
 everything is tied together in Rails and engines.
 
 Any help will be greatly appreciated. Even just to give me something else to 
 try or look.
 
 Thanks for reading! 
 
 -- 
 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/-/lXyOOJWdcvAJ.
 To post to this group, send email to rubyonrails-core@googlegroups.com 
 (mailto:rubyonrails-core@googlegroups.com).
 To unsubscribe from this group, send email to 
 rubyonrails-core+unsubscr...@googlegroups.com 
 (mailto: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] ActiveModel::Serializers::JSON support roles

2012-06-21 Thread Carlos Antonio da Silva

Steve, are you thinking about something like this in terms of code?


render json: SearchClient.new(@clients)
#or
render json: ContractWon.new(@clients)



class SearchClient
  def initialize(clients)
@clients = clients
  end
  
  def to_json(options=nil)
@clients.to_json(only: %w(foo bar)
  end
end

class ContractWon
  def initialize(clients)
@clients = clients
  end
  
  def to_json(options=nil)
@clients.to_json(only: %w(baz other)
  end
end


That's basically the approach I've been using lately, and it works quite 
fine for my needs :).

On Thursday, June 21, 2012 11:12:40 PM UTC-3, Steve Klabnik wrote:

 I think this would be useful, but I'm not sure that this just means 
 that there shouldn't be two serailizers instead of putting both in one 
 class. 


-- 
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/-/5gm_TzguGugJ.
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: Transaction during all migrations instead of each migrations

2012-06-19 Thread Carlos Antonio da Silva

Hey Simon, thanks for your comments.

Would you mind copying  pasting them to the issue I linked before? This way 
others can see it there while checking the related pull request, to decide 
whether or not the feature should be in.

Thanks! 

-- 
At.
Carlos Antonio


On Tuesday, June 19, 2012 at 1:15 PM, Simon de Boer wrote:

 I would be -1 on this sort of change.
 
 Changing the schema of a RDBS and deploying the dependent code should be 
 performed with great care, the basic concept of each migration being whole 
 change keeps things tidy.  Giving any impression to a developer that 
 enclosing a bunch of migrations as a transaction creates a highly-available 
 deploy would be a disservice.  There are so many other factors that go into 
 making HA happen.   Very few sites actually require anything close to HA, 
 those that do are going to be putting all sorts of tools around their deploy 
 process.
 
 The suggested code/schema upgrade should go this way, hopefully in as short a 
 period as possible, with some sanity checks between each step:
 Disable website
 Dump current database
 Migrate database
 Update code
 Re-enable website
 
 
 
 Lets say there were 10 migrations to do and #5 failed, being in the state 
 that 1-4 have run is where you want to be.  Now you can look at why #5 
 failed, fix it (check it in), and continue.
 
 This becomes particularly important if one of 1-4 were very long running 
 statements, large import, index updating, etc.  In these cases it becomes 
 even more important that the website be shut down because the DB is going to 
 be pinning its CPU and the user experience is going to suffer dramatically.
 
 If the change was implemented I would suggest that it be off by default in 
 development, where the situation of wanting the first few migrations to take 
 and then to begin debugging is the much more normal behaviour.
 
 Simon
 
 
 On Friday, 1 June 2012 14:56:32 UTC-4, Gabriel Sobrinho wrote:
  Hey, 
  
  What you think about using a transaction during the entire db:migrate 
  instead of each migration? 
  
  
  Currently if we deploy 10 migrations and the latest fails, the application 
  may be down because the database was changed but one of these migrations 
  have failed. 
  
  Think worse, one of these migrations can't be rollbacked so we can't 
  rollback the application to a good state without a human interaction. 
  
  
  Using just one transaction will make rails more high available during 
  deploys because the migrations only will be committed if everything is ok. 
  
  Note that will apply only to postgresql because mysql do not support ddl 
  transactions. 
  
  
  What you think, guys? 
  
  Cheers, 
  
  Gabriel Sobrinho 
  
 -- 
 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/-/B65FEZnJn9EJ.
 To post to this group, send email to rubyonrails-core@googlegroups.com 
 (mailto:rubyonrails-core@googlegroups.com).
 To unsubscribe from this group, send email to 
 rubyonrails-core+unsubscr...@googlegroups.com 
 (mailto: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] Transaction during all migrations instead of each migrations

2012-06-18 Thread Carlos Antonio da Silva

Hello guys,

just want to add that a new pull request was made adding this feature for
supported databases: https://github.com/rails/rails/pull/6768

Please feel free to comment there.
Cheers.

On Fri, Jun 1, 2012 at 3:58 PM, Rodrigo Rosenfeld Rosas
rr.ro...@gmail.comwrote:

 Em 01-06-2012 15:56, Gabriel Sobrinho escreveu:

  Hey,

 What you think about using a transaction during the entire db:migrate
 instead of each migration?


 +1


 --
 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
 .




-- 
At.
Carlos Antonio

-- 
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] Having 2 ActiveRecord test failures on master: Errors running test_postgresql using pg 9.1

2012-05-21 Thread Carlos Antonio da Silva

Hey Steve, 

I just want to add a comment that this is the first failing build with this 
particular problem: http://travis-ci.org/#!/rails/rails/builds/1391490. From 
here you can see the commit.

It's also worth mention that if you're working on any other change, you can 
send it as a separate pull request, no need to include fixing the build with 
it.

Thanks! 

-- 
At.
Carlos Antonio


On Monday, May 21, 2012 at 9:47 PM, Steve Jorgensen wrote:

 Thanks very much for the info and pointers, Prem. Since it's a PostgreSQL 
 adapter improvement that I'm working on, I'll give those failing tests some 
 attention as well.
 
 On Monday, May 21, 2012 5:34:38 PM UTC-7, Prem Sichanugrist wrote:
  Hey Steve,
  
  Sad, but true, that sometime our test suite is not always green. You can 
  verify the state of the test suite at Travis-CI website: 
  http://travis-ci.org/#!/rails/rails (http://travis-ci.org/#%21/rails/rails)
  
  Also, according to latest build, the test cases are indeed failing: 
  http://travis-ci.org/#!/rails/rails/builds/1394984 
  (http://travis-ci.org/#%21/rails/rails/builds/1394984) I don't think 
  anybody is fixing it right now, according to the rails issues list 
  (https://github.com/rails/rails/issues) so good luck :)
  
  Thanks,
  
  Prem
 snip 
 -- 
 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/-/wPfjGVTpsQMJ.
 To post to this group, send email to rubyonrails-core@googlegroups.com 
 (mailto:rubyonrails-core@googlegroups.com).
 To unsubscribe from this group, send email to 
 rubyonrails-core+unsubscr...@googlegroups.com 
 (mailto: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] Original MySQL Adapter

2012-05-18 Thread Carlos Antonio da Silva

Hey Erich, there's a discussion on this here: 
https://github.com/rails/rails/pull/6030, you can add any comment there if you 
want. Thanks!

-- 
At.
Carlos Antonio


On Thursday, May 17, 2012 at 9:38 AM, Erich Menge wrote:

 Just curious, is there a reason the original MySQL adapter gem is
 still supported? Or is it something that could be removed for Rails 4?
 
 -- 
 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 
 (mailto:rubyonrails-core@googlegroups.com).
 To unsubscribe from this group, send email to 
 rubyonrails-core+unsubscr...@googlegroups.com 
 (mailto: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?

2012-04-04 Thread Carlos Antonio da Silva

This library does exactly what you're talking about here: 
https://github.com/fnando/i18n-js

It's a small library to provide the I18n translations on the Javascript. It 
comes with Rails support. 

It is for sure worth to take a look.

-- 
At.
Carlos Antonio


On Wednesday, April 4, 2012 at 5:05 PM, Ryan Bigg wrote:

 That's quite an interesting twist on it. I never thought of doing it that 
 way, but now it would make sense to be able to have these made available to 
 client-side applications which can then use them to translate... but what are 
 the translation libraries like on the client-side these days? 
 
 On Wednesday, 4 April 2012 at 3:00 PM, Johnneylee Rollins wrote:
 
  This sounds like it could be more of a feature request than a complaint.
  
  Compiling yaml files for translation (Or whatever store) down to maybe json 
  for use might lend towards the more pro client-side views crowd. I haven't 
  even thought out the implications of such a thing, but it might be really 
  cool to do that. 
  
  ~Johnneylee
  
  On Wed, Apr 4, 2012 at 3:57 PM, Ryan Bigg radarliste...@gmail.com 
  (mailto:radarliste...@gmail.com) wrote:
   How are these files assets? They're not served to the end user, but are 
   rather used by the backend to display information in different languages 
   to the end-user, thereby making them configuration. 
   
   On Wednesday, 4 April 2012 at 2:54 PM, Alexey wrote:
   
Why in a standard rails application locales are in config directory
and not in assets?

-- 
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 
(mailto:rubyonrails-core@googlegroups.com).
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com 
(mailto: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 
   (mailto:rubyonrails-core@googlegroups.com).
   To unsubscribe from this group, send email to 
   rubyonrails-core+unsubscr...@googlegroups.com 
   (mailto:rubyonrails-core%2bunsubscr...@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 
  (mailto:rubyonrails-core@googlegroups.com).
  To unsubscribe from this group, send email to 
  rubyonrails-core+unsubscr...@googlegroups.com 
  (mailto: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 
 (mailto:rubyonrails-core@googlegroups.com).
 To unsubscribe from this group, send email to 
 rubyonrails-core+unsubscr...@googlegroups.com 
 (mailto: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.

65 matches

Mail list logo