Nabble - RubyOnRails Core

Rails Contributors

2009-11-29T12:45:04Z

Hey just a brief mail to let you know I've done some systematic work
on Rails Contributors in the past weeks: Tried to resolve every email
address, and checked all handlers that exist as github usernames.

At this moment there are 337 email addresses and 440 handlers resolved
(over time). Due to this pass the grand total of contributors has gone
from 1420 down to 1327, because some of the resolved emails or github
usernames corresponded to already existing full names.

Some email addresses are unreachable, and some github usernames belong
to people who are not the authors of the corresponding commits. They
are listed at the top of this file:

http://github.com/fxn/rails-contributors/blob/master/app/models/names_manager.rb

Please if you recognize any of them just drop me a line!

The listing is converging after all these months, and I think we can
already compute some meaningful-enough numbers/graphs, like new
contributors per month, etc. I'd like to add them in the future.

That's it. Best regards to all!

-- fxn

--

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@....
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.

Re: Re: ActionMailer with Mail gem - It is here

2009-11-25T21:20:00Z

On Wed, Nov 25, 2009 at 11:15 PM, James H. <james.herdman@...> wrote:

Ask and ye shall receive. So, there are 10 failures on JRuby 1.4 and a
TONNE a warnings. You can see the full output here: http://gist.github.com/242667

Thanks for the tests :)

A lot of the warnings actually come from the treetop parsers' auto generated ruby code. I'll be cleaning up as much as I can over the coming weeks.

The errors look fairly easy... most of them are probably test suite failures in terms of having these types of constructs:

if RUBY_VERSION < '1.9'
# force_encoding code
else
# don't force encoding
end

If you could form mail, and fix up those so they run in 1.9, 1.8 and jruby and do a pull request, I would be much obliged :)

Do you know if Carlhuda is intending on making changes in the mailer
department of Rails 3? I seem to recall Yehuda mentioning something to
this effect at one point. If I recall correctly it was about treating
mailers like controllers.

I was talking to Yehuda about extracting actionmailer out to allow other types of mailers, including things like IM clients etc. But from what I know, it won't make Rails 3.

Mikel

--
http://lindsaar.net/
Rails, RSpec and Life blog....

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@....
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.

Re: ActionMailer with Mail gem - It is here

2009-11-25T06:43:14Z

On Nov 25, 12:15 pm, "James H." <james.herd...@...> wrote:
> Ask and ye shall receive. So, there are 10 failures on JRuby 1.4 and a
> TONNE a warnings. You can see the full output here:http://gist.github.com/242667
>
quite a few of those are mocha errors.

missing "expects", "stubs" and such

--

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@....
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.

Re: ActionMailer with Mail gem - It is here

2009-11-25T04:15:28Z

Ask and ye shall receive. So, there are 10 failures on JRuby 1.4 and a
TONNE a warnings. You can see the full output here: http://gist.github.com/242667

Do you know if Carlhuda is intending on making changes in the mailer
department of Rails 3? I seem to recall Yehuda mentioning something to
this effect at one point. If I recall correctly it was about treating
mailers like controllers.

James

On Nov 24, 11:50 pm, Mikel Lindsaar <raasd...@...> wrote:

> On 25/11/2009, at 3:00, Chad Woolley <thewoolley...@...> wrote:
>
> > On Mon, Nov 23, 2009 at 4:29 PM, Mikel Lindsaar <raasd...@...>
> > wrote:
> >> So I just updated the mail gem to 1.3.0 and against my fork of
> >> actionmailer
> >> at github/mikel/rails, ActionMailer now passes all tests in MRI
> >> 1.8.6, 1.8.7
> >> and 1.9.1
>
> > Now how about JRuby? ;)
>
> Test it and let me know :)
>
>
>
>

--

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@....
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.

Re: ActionMailer with Mail gem - It is here

2009-11-24T20:50:15Z

On 25/11/2009, at 3:00, Chad Woolley <thewoolleyman@...> wrote:

> On Mon, Nov 23, 2009 at 4:29 PM, Mikel Lindsaar <raasdnil@...>
> wrote:
>> So I just updated the mail gem to 1.3.0 and against my fork of
>> actionmailer
>> at github/mikel/rails, ActionMailer now passes all tests in MRI
>> 1.8.6, 1.8.7
>> and 1.9.1
>
> Now how about JRuby? ;)

Test it and let me know :)

>

--

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@....
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.

Re: ActionMailer with Mail gem - It is here

2009-11-24T08:00:06Z

On Mon, Nov 23, 2009 at 4:29 PM, Mikel Lindsaar <raasdnil@...> wrote:
> So I just updated the mail gem to 1.3.0 and against my fork of actionmailer
> at github/mikel/rails, ActionMailer now passes all tests in MRI 1.8.6, 1.8.7
> and 1.9.1

Now how about JRuby? ;)

--

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@....
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.

in_place_edit_for API page

2009-11-23T20:12:22Z

Today I googled to see where in_place_edit_for wandered off to and I saw that the first result was this page: http://api.rubyonrails.org/classes/ActionController/Macros/InPlaceEditing/ClassMethods.html

Since this doesn't exist in Rails anymore, can we get it removed from the site? Otherwise, people may continue to think that this is still in Rails.

--
Ryan Bigg

Re: ActionMailer with Mail gem - It is here

2009-11-23T15:29:51Z

On Tue, Nov 24, 2009 at 1:15 AM, Ken Collins <ken@...> wrote:

KUDOS! Hell yes!

Heh, thanks.

So I just updated the mail gem to 1.3.0 and against my fork of actionmailer at github/mikel/rails, ActionMailer now passes all tests in MRI 1.8.6, 1.8.7 and 1.9.1

Mikel

--
http://lindsaar.net/
Rails, RSpec and Life blog....

Attribute option on Errors#full_messages

2009-11-23T14:01:15Z

I want to be able to display full validation messages next to form
elements. Currently I can only get validation errors without the
prefix for specific fields, or I can get message for all attributes,
at which point it's impossible to tell which message came from which
attribute.

I made a patch where you can supply an attribute name to full_messages
so that you can extract messages for particular fields, while
preserving backwards compatibility.

https://rails.lighthouseapp.com/projects/8994/tickets/3505-attribute-option-on-errorsfull_messages

Thanks,

Glenn

--

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@....
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.

Re: Re: Queue Abstraction Layer

2009-11-23T07:57:06Z

Seems to me it's analogous to caching from a service-oriented architecture pov - ActiveSupport::Queue like ActiveSupport::Cache ? Interface/implements approach? AMPQ-compliant interface? Starling? Also suggest that there may be different levels of the interface, starting with very simple transient push/pop all the way to full AMPQ.

This would allow work around ActiveWorker to focus exclusively on worker challenges like polling, starvation, backoff, sleep, wake, deployment, running in context, etc.

m

On Mon, Nov 23, 2009 at 7:40 AM, Amol Hatwar <amol@...> wrote:

Queues != Model. Josh, you are right indeed. +1 from me for AW & AQ :-)

Cheers,

Amol

On Nov 23, 2009, at 8:47 PM, Joshua Peek wrote:

> Interesting ideas.
>
> I think it be "ActionQueue" since its not a model layer (not sure).
>
> Maybe both belong in the same "pack" similar to ActionPack.
>
> So we have some root package called "ActionBackgroundShit" and it
> contains AW and AQ.
>
> actionbackgroundshit/lib/action_worker/*
> actionbackgroundshit/lib/action_queue/*
>
> On Mon, Nov 23, 2009 at 5:50 AM, mbiker <andy.w.freeman@...> wrote:
>> +1
>>
>> I would love to see the related scheduled job be part of this as well
>> since some processes can only have a single instance running at a
>> time.
>>
>> On Nov 22, 7:57 pm, Anthony Eden <anthonye...@...> wrote:
>>> I want to take a moment to talk about the notion of a queue
>>> abstraction layer in Rails and put a stake in the ground with my
>>> opinions on the topic while at the same time getting some feedback.
>>>
>>> My understanding is this: at the moment ActiveWorker (which can be
>>> seen in this repo:http://github.com/joshbuddy/rails) is the current
>>> track for how to integrate workers (and queues to an extent). There's
>>> nothing wrong with this approach, however my position is that workers
>>> != queues, and I don't necessarily want to define my workers in the
>>> context of Rails, yet I do want an abstraction layer for queues. The
>>> current design of ActiveWorker has the queues essentially as adapters,
>>> similar to how ActiveRecord works, so I can understand leaving this as
>>> part of ActiveWorker, but I do wonder if it's a good idea to couple
>>> these things together. Personally I don't think it is but then again
>>> others may disagree.
>>>
>>> Here's my proposal: there should be a queue abstraction layer (call it
>>> ActiveQueue if you like) with the following high-level requirements:
>>>
>>> * It should provide a generic interface to queues (messages queues and
>>> publish/subscribe)
>>> * It should provide a standard interface for drivers to implement and
>>> should provide a few basic driver implementations
>>> * It should allow other drivers to be added in through simple
>>> configuration (config/queue.yml)
>>> * It should define an interface for serializing messages (and provide
>>> JSON and XML serialization as the default?)
>>> * It should NOT define how to handle work units (i.e. this is not for
>>> defining asynchronous workers)
>>> * It should be used under the hood by ActiveWorker
>>>
>>> I actually have a need for this right now and would be willing to
>>> implement it to scratch my own itch, but I didn't want to do so
>>> without first getting some feedback from the core community to see if
>>> this is both interesting and useful.
>>>
>>> Thoughts?
>>>
>>> Sincerely,
>>> Anthony Eden
>>>
>>> --
>>> GMU/IT d- s: a32 C++(++++)$ UL@ P--- L+(++) !E W+++$ !N o? K? w--- !O
>>> M++ V PS+ PE Y PGP t+ !5 X- R tv b++ DI+ D++ G- e++ h---- r+++ y++++**
>>>
>>> http://anthony.mp
>>
>> --
>>
>> 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@....
>> To unsubscribe from this group, send email to rubyonrails-core%2Bunsubscribe@....
>> For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=.
>>
>>
>>
>
>
>
> --
> Joshua Peek
>
> --
>
> 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@....
> To unsubscribe from this group, send email to rubyonrails-core%2Bunsubscribe@....
> For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=.
>
>

--

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@....
To unsubscribe from this group, send email to rubyonrails-core%2Bunsubscribe@....
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=.

Re: Re: Queue Abstraction Layer

2009-11-23T07:40:27Z

Queues != Model. Josh, you are right indeed. +1 from me for AW & AQ :-)

Cheers,

Amol

On Nov 23, 2009, at 8:47 PM, Joshua Peek wrote:

> Interesting ideas.
>
> I think it be "ActionQueue" since its not a model layer (not sure).
>
> Maybe both belong in the same "pack" similar to ActionPack.
>
> So we have some root package called "ActionBackgroundShit" and it
> contains AW and AQ.
>
> actionbackgroundshit/lib/action_worker/*
> actionbackgroundshit/lib/action_queue/*
>
> On Mon, Nov 23, 2009 at 5:50 AM, mbiker <andy.w.freeman@...> wrote:
>> +1
>>
>> I would love to see the related scheduled job be part of this as well
>> since some processes can only have a single instance running at a
>> time.
>>
>> On Nov 22, 7:57 pm, Anthony Eden <anthonye...@...> wrote:
>>> I want to take a moment to talk about the notion of a queue
>>> abstraction layer in Rails and put a stake in the ground with my
>>> opinions on the topic while at the same time getting some feedback.
>>>
>>> My understanding is this: at the moment ActiveWorker (which can be
>>> seen in this repo:http://github.com/joshbuddy/rails) is the current
>>> track for how to integrate workers (and queues to an extent). There's
>>> nothing wrong with this approach, however my position is that workers
>>> != queues, and I don't necessarily want to define my workers in the
>>> context of Rails, yet I do want an abstraction layer for queues. The
>>> current design of ActiveWorker has the queues essentially as adapters,
>>> similar to how ActiveRecord works, so I can understand leaving this as
>>> part of ActiveWorker, but I do wonder if it's a good idea to couple
>>> these things together. Personally I don't think it is but then again
>>> others may disagree.
>>>
>>> Here's my proposal: there should be a queue abstraction layer (call it
>>> ActiveQueue if you like) with the following high-level requirements:
>>>
>>> * It should provide a generic interface to queues (messages queues and
>>> publish/subscribe)
>>> * It should provide a standard interface for drivers to implement and
>>> should provide a few basic driver implementations
>>> * It should allow other drivers to be added in through simple
>>> configuration (config/queue.yml)
>>> * It should define an interface for serializing messages (and provide
>>> JSON and XML serialization as the default?)
>>> * It should NOT define how to handle work units (i.e. this is not for
>>> defining asynchronous workers)
>>> * It should be used under the hood by ActiveWorker
>>>
>>> I actually have a need for this right now and would be willing to
>>> implement it to scratch my own itch, but I didn't want to do so
>>> without first getting some feedback from the core community to see if
>>> this is both interesting and useful.
>>>
>>> Thoughts?
>>>
>>> Sincerely,
>>> Anthony Eden
>>>
>>> --
>>> GMU/IT d- s: a32 C++(++++)$ UL@ P--- L+(++) !E W+++$ !N o? K? w--- !O
>>> M++ V PS+ PE Y PGP t+ !5 X- R tv b++ DI+ D++ G- e++ h---- r+++ y++++**
>>>
>>> http://anthony.mp
>>
>> --
>>
>> 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@....
>> To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@....
>> For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=.
>>
>>
>>
>
>
>
> --
> Joshua Peek
>
> --
>
> 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@....
> To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@....
> For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=.
>
>

Re: Re: Queue Abstraction Layer

2009-11-23T07:17:22Z

Interesting ideas.

I think it be "ActionQueue" since its not a model layer (not sure).

Maybe both belong in the same "pack" similar to ActionPack.

So we have some root package called "ActionBackgroundShit" and it
contains AW and AQ.

actionbackgroundshit/lib/action_worker/*
actionbackgroundshit/lib/action_queue/*

On Mon, Nov 23, 2009 at 5:50 AM, mbiker <andy.w.freeman@...> wrote:

> +1
>
> I would love to see the related scheduled job be part of this as well
> since some processes can only have a single instance running at a
> time.
>
> On Nov 22, 7:57 pm, Anthony Eden <anthonye...@...> wrote:
>> I want to take a moment to talk about the notion of a queue
>> abstraction layer in Rails and put a stake in the ground with my
>> opinions on the topic while at the same time getting some feedback.
>>
>> My understanding is this: at the moment ActiveWorker (which can be
>> seen in this repo:http://github.com/joshbuddy/rails) is the current
>> track for how to integrate workers (and queues to an extent). There's
>> nothing wrong with this approach, however my position is that workers
>> != queues, and I don't necessarily want to define my workers in the
>> context of Rails, yet I do want an abstraction layer for queues. The
>> current design of ActiveWorker has the queues essentially as adapters,
>> similar to how ActiveRecord works, so I can understand leaving this as
>> part of ActiveWorker, but I do wonder if it's a good idea to couple
>> these things together. Personally I don't think it is but then again
>> others may disagree.
>>
>> Here's my proposal: there should be a queue abstraction layer (call it
>> ActiveQueue if you like) with the following high-level requirements:
>>
>> * It should provide a generic interface to queues (messages queues and
>> publish/subscribe)
>> * It should provide a standard interface for drivers to implement and
>> should provide a few basic driver implementations
>> * It should allow other drivers to be added in through simple
>> configuration (config/queue.yml)
>> * It should define an interface for serializing messages (and provide
>> JSON and XML serialization as the default?)
>> * It should NOT define how to handle work units (i.e. this is not for
>> defining asynchronous workers)
>> * It should be used under the hood by ActiveWorker
>>
>> I actually have a need for this right now and would be willing to
>> implement it to scratch my own itch, but I didn't want to do so
>> without first getting some feedback from the core community to see if
>> this is both interesting and useful.
>>
>> Thoughts?
>>
>> Sincerely,
>> Anthony Eden
>>
>> --
>> GMU/IT d- s: a32 C++(++++)$ UL@ P--- L+(++) !E W+++$ !N o? K? w--- !O
>> M++ V PS+ PE Y PGP t+ !5 X- R tv b++ DI+ D++ G- e++ h---- r+++ y++++**
>>
>> http://anthony.mp
>
> --
>
> 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@....
> To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@....
> For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=.
>
>
>

--
Joshua Peek

--

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@....
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=.

Re: ActionMailer with Mail gem - It is here

2009-11-23T06:15:49Z

KUDOS! Hell yes!

- Ken

On Nov 23, 2009, at 12:11 AM, Mikel Lindsaar wrote:

On Mon, Nov 23, 2009 at 10:17 AM, Chad Woolley <thewoolleyman@...> wrote:

On Sun, Nov 22, 2009 at 5:48 AM, Mikel Lindsaar <raasdnil@...> wrote:
> So, I have integrated edge ActionMailer with the Mail gem, removing TMail in
> the process.
> Currently, ActionMailer is running with 131 tests, 309 assertions, 0
> failures, 0 errors
> This is using ActionMailer from http://github.com/mikel/rails as well as the
> Mail gem version 1.2.8

Which interpreters?

Mail will run on Ruby 1.8.6, 1.8.7 and 1.9.1 with no spec failures

My ActionMailer fork with Mail runs without error on 1.8.7.

Currently we have a few failures for ActionMailer + Mail on 1.9.1, but they will be fixed soon, no big deal.

Mikel

--
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@....
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=.

Re: Queue Abstraction Layer

2009-11-23T03:50:31Z

+1

I would love to see the related scheduled job be part of this as well
since some processes can only have a single instance running at a
time.

On Nov 22, 7:57 pm, Anthony Eden <anthonye...@...> wrote:

> I want to take a moment to talk about the notion of a queue
> abstraction layer in Rails and put a stake in the ground with my
> opinions on the topic while at the same time getting some feedback.
>
> My understanding is this: at the moment ActiveWorker (which can be
> seen in this repo:http://github.com/joshbuddy/rails) is the current
> track for how to integrate workers (and queues to an extent). There's
> nothing wrong with this approach, however my position is that workers
> != queues, and I don't necessarily want to define my workers in the
> context of Rails, yet I do want an abstraction layer for queues. The
> current design of ActiveWorker has the queues essentially as adapters,
> similar to how ActiveRecord works, so I can understand leaving this as
> part of ActiveWorker, but I do wonder if it's a good idea to couple
> these things together. Personally I don't think it is but then again
> others may disagree.
>
> Here's my proposal: there should be a queue abstraction layer (call it
> ActiveQueue if you like) with the following high-level requirements:
>
> * It should provide a generic interface to queues (messages queues and
> publish/subscribe)
> * It should provide a standard interface for drivers to implement and
> should provide a few basic driver implementations
> * It should allow other drivers to be added in through simple
> configuration (config/queue.yml)
> * It should define an interface for serializing messages (and provide
> JSON and XML serialization as the default?)
> * It should NOT define how to handle work units (i.e. this is not for
> defining asynchronous workers)
> * It should be used under the hood by ActiveWorker
>
> I actually have a need for this right now and would be willing to
> implement it to scratch my own itch, but I didn't want to do so
> without first getting some feedback from the core community to see if
> this is both interesting and useful.
>
> Thoughts?
>
> Sincerely,
> Anthony Eden
>
> --
> GMU/IT d- s: a32 C++(++++)$ UL@ P--- L+(++) !E W+++$ !N o? K? w--- !O
> M++ V PS+ PE Y PGP t+ !5 X- R tv b++ DI+ D++ G- e++ h---- r+++ y++++**
>
> http://anthony.mp

Re: Queue Abstraction Layer

2009-11-22T23:17:37Z

+1 on the concept ... I feel that Rails has been without this for a
while. With the recent surge of activity on queue services, I think
this is an awesome suggestion ... it would be great to have a standard
Rails-ish way of setting up multiple work queues.

I think that a good starting point for where to look for inspiration
is http://github.com/defunkt/resque#readme ... which has a ton of
really good design choices.

If there was a common interface to queues such as Resque that could be
abstracted in front of any choice of queue backend, I feel like it
would be a huge win for Rails.

Paul

On Sun, Nov 22, 2009 at 4:57 PM, Anthony Eden <anthonyeden@...> wrote:

> I want to take a moment to talk about the notion of a queue
> abstraction layer in Rails and put a stake in the ground with my
> opinions on the topic while at the same time getting some feedback.
>
> My understanding is this: at the moment ActiveWorker (which can be
> seen in this repo: http://github.com/joshbuddy/rails ) is the current
> track for how to integrate workers (and queues to an extent). There's
> nothing wrong with this approach, however my position is that workers
> != queues, and I don't necessarily want to define my workers in the
> context of Rails, yet I do want an abstraction layer for queues. The
> current design of ActiveWorker has the queues essentially as adapters,
> similar to how ActiveRecord works, so I can understand leaving this as
> part of ActiveWorker, but I do wonder if it's a good idea to couple
> these things together. Personally I don't think it is but then again
> others may disagree.
>
> Here's my proposal: there should be a queue abstraction layer (call it
> ActiveQueue if you like) with the following high-level requirements:
>
> * It should provide a generic interface to queues (messages queues and
> publish/subscribe)
> * It should provide a standard interface for drivers to implement and
> should provide a few basic driver implementations
> * It should allow other drivers to be added in through simple
> configuration (config/queue.yml)
> * It should define an interface for serializing messages (and provide
> JSON and XML serialization as the default?)
> * It should NOT define how to handle work units (i.e. this is not for
> defining asynchronous workers)
> * It should be used under the hood by ActiveWorker
>
> I actually have a need for this right now and would be willing to
> implement it to scratch my own itch, but I didn't want to do so
> without first getting some feedback from the core community to see if
> this is both interesting and useful.
>
> Thoughts?
>
> Sincerely,
> Anthony Eden
>
> --
> GMU/IT d- s: a32 C++(++++)$ UL@ P--- L+(++) !E W+++$ !N o? K? w--- !O
> M++ V PS+ PE Y PGP t+ !5 X- R tv b++ DI+ D++ G- e++ h---- r+++ y++++**
>
> http://anthony.mp
>
> --
>
> 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@....
> To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@....
> For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=.
>
>
>

--

Paul Campbell
paul@...
- - - - - - - - - - - - - - - - - - -
blog http://www.pabcas.com
twitter http://www.twitter.com/paulca
github http://www.github.com/paulca
phone +353 87 914 8162
- - - - - - - - - - - - - - - - - - -

--

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@....
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=.

Re: ActionMailer with Mail gem - It is here

2009-11-22T21:11:50Z

On Mon, Nov 23, 2009 at 10:17 AM, Chad Woolley <thewoolleyman@...> wrote:

On Sun, Nov 22, 2009 at 5:48 AM, Mikel Lindsaar <raasdnil@...> wrote:
> So, I have integrated edge ActionMailer with the Mail gem, removing TMail in
> the process.
> Currently, ActionMailer is running with 131 tests, 309 assertions, 0
> failures, 0 errors
> This is using ActionMailer from http://github.com/mikel/rails as well as the
> Mail gem version 1.2.8

Which interpreters?

Mail will run on Ruby 1.8.6, 1.8.7 and 1.9.1 with no spec failures

My ActionMailer fork with Mail runs without error on 1.8.7.

Currently we have a few failures for ActionMailer + Mail on 1.9.1, but they will be fixed soon, no big deal.

Mikel

Queue Abstraction Layer

2009-11-22T16:57:17Z

I want to take a moment to talk about the notion of a queue
abstraction layer in Rails and put a stake in the ground with my
opinions on the topic while at the same time getting some feedback.

My understanding is this: at the moment ActiveWorker (which can be
seen in this repo: http://github.com/joshbuddy/rails ) is the current
track for how to integrate workers (and queues to an extent). There's
nothing wrong with this approach, however my position is that workers
!= queues, and I don't necessarily want to define my workers in the
context of Rails, yet I do want an abstraction layer for queues. The
current design of ActiveWorker has the queues essentially as adapters,
similar to how ActiveRecord works, so I can understand leaving this as
part of ActiveWorker, but I do wonder if it's a good idea to couple
these things together. Personally I don't think it is but then again
others may disagree.

Here's my proposal: there should be a queue abstraction layer (call it
ActiveQueue if you like) with the following high-level requirements:

* It should provide a generic interface to queues (messages queues and
publish/subscribe)
* It should provide a standard interface for drivers to implement and
should provide a few basic driver implementations
* It should allow other drivers to be added in through simple
configuration (config/queue.yml)
* It should define an interface for serializing messages (and provide
JSON and XML serialization as the default?)
* It should NOT define how to handle work units (i.e. this is not for
defining asynchronous workers)
* It should be used under the hood by ActiveWorker

I actually have a need for this right now and would be willing to
implement it to scratch my own itch, but I didn't want to do so
without first getting some feedback from the core community to see if
this is both interesting and useful.

Thoughts?

Sincerely,
Anthony Eden

--
GMU/IT d- s: a32 C++(++++)$ UL@ P--- L+(++) !E W+++$ !N o? K? w--- !O
M++ V PS+ PE Y PGP t+ !5 X- R tv b++ DI+ D++ G- e++ h---- r+++ y++++**

http://anthony.mp

--

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@....
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=.

Re: ActionMailer with Mail gem - It is here

2009-11-22T15:17:37Z

On Sun, Nov 22, 2009 at 5:48 AM, Mikel Lindsaar <raasdnil@...> wrote:
> So, I have integrated edge ActionMailer with the Mail gem, removing TMail in
> the process.
> Currently, ActionMailer is running with 131 tests, 309 assertions, 0
> failures, 0 errors
> This is using ActionMailer from http://github.com/mikel/rails as well as the
> Mail gem version 1.2.8

Which interpreters?

-- Chad

--

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@....
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=.

ActionMailer with Mail gem - It is here

2009-11-22T04:48:32Z

So, I have integrated edge ActionMailer with the Mail gem, removing TMail in the process.

Currently, ActionMailer is running with 131 tests, 309 assertions, 0 failures, 0 errors

This is using ActionMailer from http://github.com/mikel/rails as well as the Mail gem version 1.2.8

But mail is throwing a few warnings in the process and I would love more eyes on it. I've done it up to here, but now I need some sanity checks :)

To replicate:

sudo gem install mail

( should install at least Mail 1.2.8 )

git clone git://github.com/mikel/rails.git

cd rails/actionmailer

rake test

You should get 0 errors, 0 failures.

Please let me know what you get and patches welcome!!!

--
http://lindsaar.net/
Rails, RSpec and Life blog....

[PATCH] Autolinking non-http protocols doesn't work

2009-11-20T11:18:40Z

If you redefined the AUTO_LINK_RE to support protocols other than HTTP, bad links are generated. In the auto_link_urls code it checks if there is an http in the generated href and if there isn't it prepends one. If you're using auto_link_urls on, for example, ftp:// links, instead of <a href="ftp://example.com">ftp://example.com</a> , you get <a href="http:// ftp://example.com">ftp://example.com</a>. This patch adds a test and changes the code to check for any protocol instead of just http before prepending the default.

This patch is against the 2-3-stable branch.

Lighthouse ticket: https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/3494-patch-autolinking-non-http-protocols-doesnt-work

-Zach Brock

Re: Dirty Associations

2009-11-18T20:30:31Z

Poking around a little, it's completely an implementation side-effect,
and only appears in the exact case you've described. For instance,
assigning to a has_many doesn't show up in .changes either:

def test_changed_includes_new_record_assignments
album = Album.create! :title => "Give Up the Ghost"
album.artist = Artist.new :name => "Brandi Carlile"
assert album.changes.any?
end

In the belongs_to case in your example, note that the change does get
recorded fairly early (before the before_save callback is invoked), so
you're OK using the dirty tracking in callbacks / observers.

--Matt Jones

On Nov 18, 2009, at 4:47 PM, Chris O'Meara wrote:

> Hello,
>
> I found an area where I don't totally understand the behavior of the
> dirty tracking feature in Active Record. It appears as though
> changes are tracked when I assign a persistent object (already has
> an id) to the association but not tracked when I assign a new record
> to the association.
>
> Here's a test that highlights the difference:
>
> http://gist.github.com/238283
>
> Is the difference between the two usages intentional?
>
> Thanks,
> Chris
>
> --
>
> 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@....
> To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@...
> .
> For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=
> .

Re: Dirty Associations

2009-11-18T19:25:53Z

> Is the difference between the two usages intentional?

Nope, looks like a side-effect of the implementation to me.

--
Cheers

Koz

--

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@....
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=.

Re: AR Association Proxy prevents calling methods defined using method_missing on the target of the association

2009-11-18T19:24:39Z

> If I have a model like this:
>
> class User < ActiveRecord::Base
> # Provide is_admin?, is_guest? account type discovery methods def
> method_missing(method_id, *arguments)
> if match = /^is_(\w+)\?$/.match(method_id.to_s)
> self.account_type == match[1]
> else
> super
> end
>
> end end
>

If you override method_missing, you need to also override respond_to?

>
> I can't do Activity.first.user.is_guest? because it raises a
> NoMethodError. The problem is that the Association Proxy only allows
> calling methods on the target that respond_to?(method). It doesn't
> need to do this check, because if the method really doesn't exist, the
> call to target.send(method, args) will raise NoMethodError itself, so
> nothing is gained by doing that check in the proxy.

This is not quite right. send will also call private methods, the
proxy check prevents that.

> Regards,
> Karl
>
> --
>
> 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@....
> To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@....
> For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=.
>
>

--
Cheers

Koz

--

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@....
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=.

Re: Decrypt a admin password (with salt)

2009-11-18T19:15:20Z

On Nov 9, 2009, at 5:48 AM, madhuri godade wrote:

> Hello,
>
> I want decrypt a password which is encrypted by MD5.
> there are 4 functions which i am using :

[snip]

> please do tell me...

OK. First, it's not possible. The only reason you'd want to do this if
you have access to the DB is if you're a hacker.

Second, this isn't a list for this kind of question - that's what
rails-talk is for.

--Matt Jones

--

You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@....
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=.

Re: Decrypt a admin password (with salt)

2009-11-18T19:12:34Z

On Nov 9, 2009, at 4:18 PM, madhuri godade wrote:

> Hello,
>
> I want decrypt a password which is encrypted by MD5.
> there are 4 functions which i am using :
>
> # Encrypts some data with the salt.
> def self.encrypt(password, salt)
> Digest::SHA1.hexdigest("--#{salt}--#{password}--")
> end

* Chop *

Madhuri, this is list is called "Rails Core", meaning code, problems and issues
relating to Rails code itself. Perhaps, you should try some other lists for your code
which is unrelated to Rails itself in the future.

In any case, MD5 is a hashing algorithm and a one-way function. Meaning, once
you get a hash, there is no way to get the original data back.

Also, in the code snippets that you gave, you are using SHA1: which is completely
different from MD5.

Cheers,

Amol Hatwar

--

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@....
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=.

Dirty Associations

2009-11-18T13:47:21Z

Hello,

I found an area where I don't totally understand the behavior of the dirty tracking feature in Active Record. It appears as though changes are tracked when I assign a persistent object (already has an id) to the association but not tracked when I assign a new record to the association.

Here's a test that highlights the difference:

http://gist.github.com/238283

Is the difference between the two usages intentional?

Thanks,
Chris

Rubyconf 2009 ticket for sale

2009-11-18T10:56:38Z

Gotta bail due to family issues. Want my ticket?

ajaya

--

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@....
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.

Re: Preserving has_many :through ids assignment order

2009-11-17T22:07:29Z

Well, disturbingly my in-depth response I posted 12 hours ago has
seemingly vanished into thin air. I won't repeat the whole thing.
Essentially, my response was that, no Rick, I definitely want the
routes ordered by primary key, and depending on that order GREATLY
simplifies both my controller and my module (see http://www.theauteurs.com/lists
for an example). Acts_as_list is tremendous overkill in most
situations. Depending on insertion order simplifies a great many
things. With regards to ordering routes you can do so entirely at the
client level with something like Prototype's Sortable, and the
controller doesn't need to be aware of routes at all, it can use
purely desination ids which makes the resulting code extremely clean.

My patch is up on lighthouse, could use some reviewers:

https://rails.lighthouseapp.com/projects/8994/tickets/3491-assigning-to-has_many-through-using-the-generated-_ids-method-does-not-insert-in-the-same-order

On Nov 14, 8:50 am, Rick DeNatale <rick.denat...@...> wrote:

> It seem to me that ordering on id isn't what you really want here.
>
> What happens when you add the function to reorder the routes? If it
> were me I'd probably do something like adding a position attribute to
> route and use something like acts_as_list

--

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@....
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=.

Re: Preserving has_many :through ids assignment order

2009-11-14T08:50:58Z

On Thu, Nov 12, 2009 at 1:59 PM, dasil003 <gabriel.d@...> wrote:

>
> On Nov 12, 10:38 am, Matt Jones <al2o...@...> wrote:
>
>> For this to make sense as a Rails patch, there's got to be a reason
>> why this ordering should be preserved. What's the difference between
>> adding the records in the [5,8,3] order vs. some other order?
>
> The reason is because when you assign directly to a has_many :through,
> it's creating records, and the order they are created in is
> significant. Suppose this is populated by an javascript autocomplete
> where a user is picking a series of destinations. If the declaration
> is:
>
> has_many :routes, :order => 'id'
>
> Then the order that the routes are inserted is significant.
>
> Now it's true that you can control the order by creating routes
> manually, but being able to assign to the leaf association is
> incredibly useful in certain circumstances because it can remove a ton
> of boilerplate bookkeeping code. The view and controller don't even
> need to know about Routes at all, they just work with Destinations
> which is much cleaner.
>
> Finally, I the order should be preserved for @person.destination_ids=
> for simple symmetry with @person.destinations= and other iterating
> object creators which all seem to preserve order in my experience.

It seem to me that ordering on id isn't what you really want here.

What happens when you add the function to reorder the routes? If it
were me I'd probably do something like adding a position attribute to
route and use something like acts_as_list

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

template vs view

2009-11-13T08:21:26Z

I know there has been a lot of refactoring going on in the rendering
engine in Rails 3.0. I just hope we get a clear definition and usage
of "view" (instances of ActionView::Base) and "template" (instances of
ActionView::Template).

What is considered as "view" parameter in some places (template code)
is stored as @template in the controller.

And making it possible to access the view during template compilation
would be nice...

Gaspard

--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Validating models on destruction

2009-11-12T11:27:10Z

On Thu, Nov 12, 2009 at 2:10 PM, dasil003 <gabriel.d@...> wrote:

I understand where you're coming from here. I faced this issue just
last week. However I think it's a bit tricky to piggyback this onto
validations, because validations are conceptually designed around
record creation. It's all built to support the idea of showing errors
on specific fields in an edit form. When it comes to destroying
records I'm not sure it makes conceptual sense to flag individual
fields with errors. In some cases yes, but more often it seems like
it would be due to some combined state with other records and
associations and in general maps much less cleanly to fields.

Right, which is why in this case I wanted to use add_to_base

I would definitely support some infrastructure improvement here, but I
think we'd need to take a deep look at AR::Errors and figure out what
would be the useful part for destroy validations, and make sure to
keep the terminology clear... you wouldn't want valid? to return false

because a destroy validation failed for instance.

Agreed.

I'm not saying we should take all the current validations (uniqueness_of, presence_of, etc...) and give them the option to run on destruction. Because you're right that doesnt make any sense. But I can see adding two methods: AR::B#validate_on_destroy and AR::B#valid_for_destruction?. Then I'd modify the default scaffolding to check the return value of #destroy and conditionally display any errors that come back.

Any other thoughts? Want patch?

On Nov 12, 10:25 am, Ryan Angilly <angi...@...> wrote:
> Hey guys,
>
> Have you ever wanted to validate a record was valid for destruction? Does
> this make sense conceptually? Let me paint a picture of something I just
> ran into that makes me think I should be able to do this.
>
> I have a many to many polymorphic relationship between our Advertisement
> model and a bunch of other models in our app. One of these models is the
> User model. At any point I may want to find the ad for top_dashboard_ad_1
> for a given user, but if that user doesnt have an ad specified I want to
> fall back to our defaults:
>
> @user.ad_for('top_dashboard_ad_1')
>
> class User < AR::B
> def ad_for(type)
> advertisements.find_by_location(type) ||
> SiteSettings.instance.ad_for(type)
> end
> end
>
> SiteSettings is a singleton model that also has a polymorphic relationship
> with the Advertisement model. This is all CMS'd. A certain User can have
> special ads assigned, and the defaults can be changed at any time. Here's
> the kicker: If a certain advertisement is associated with the SiteSettings
> instance (meaning it is a default), I dont want it to allow it to be
> destroyed.
>
> I currently have this in my Advertisement model:
>
> class Advertisement < AR::B
> before_destroy :make_sure_not_default
>
> private
> def make_sure_not_default
> !(ad_zone_placements.map{|a| a.placement.class}.include? SiteSettings
> end
> end
>
> This does prevent the record from being destroyed, but doesnt provide any
> feedback to the user as to why.
>
> Seems like this should be a validation. I want to be able to use AR::Errors
> to send a message back to host explaining why it cannot be destroyed, but
> that behavior kind of flies in the face of the conventional restful
> controller generated in Rails scaffold (ie: in the destroy action, there is
> no 'check for errors and render the edit page'). I feel like I should be
> able to do:
>
> validates_on_destroy :make_sure_not_default
>
> def make_sure_not_default
> errors.add_to_base('Cannot destroy this AdZone while it is a default')
> if ad_zone_placements.map{|a| a.placement.class}.include? SiteSettings
> end
>
> Right? Has anyone else ever ran into this? Is there something built in I'm
> missing? Am I have a braindead moment like that time I forgot about
> "has_many :through" ?
>
> Thanks,
> Ryan

--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Validating models on destruction

2009-11-12T11:10:30Z

I understand where you're coming from here. I faced this issue just
last week. However I think it's a bit tricky to piggyback this onto
validations, because validations are conceptually designed around
record creation. It's all built to support the idea of showing errors
on specific fields in an edit form. When it comes to destroying
records I'm not sure it makes conceptual sense to flag individual
fields with errors. In some cases yes, but more often it seems like
it would be due to some combined state with other records and
associations and in general maps much less cleanly to fields.

I would definitely support some infrastructure improvement here, but I
think we'd need to take a deep look at AR::Errors and figure out what
would be the useful part for destroy validations, and make sure to
keep the terminology clear... you wouldn't want valid? to return false
because a destroy validation failed for instance.

On Nov 12, 10:25 am, Ryan Angilly <angi...@...> wrote:

> Hey guys,
>
> Have you ever wanted to validate a record was valid for destruction? Does
> this make sense conceptually? Let me paint a picture of something I just
> ran into that makes me think I should be able to do this.
>
> I have a many to many polymorphic relationship between our Advertisement
> model and a bunch of other models in our app. One of these models is the
> User model. At any point I may want to find the ad for top_dashboard_ad_1
> for a given user, but if that user doesnt have an ad specified I want to
> fall back to our defaults:
>
> @user.ad_for('top_dashboard_ad_1')
>
> class User < AR::B
> def ad_for(type)
> advertisements.find_by_location(type) ||
> SiteSettings.instance.ad_for(type)
> end
> end
>
> SiteSettings is a singleton model that also has a polymorphic relationship
> with the Advertisement model. This is all CMS'd. A certain User can have
> special ads assigned, and the defaults can be changed at any time. Here's
> the kicker: If a certain advertisement is associated with the SiteSettings
> instance (meaning it is a default), I dont want it to allow it to be
> destroyed.
>
> I currently have this in my Advertisement model:
>
> class Advertisement < AR::B
> before_destroy :make_sure_not_default
>
> private
> def make_sure_not_default
> !(ad_zone_placements.map{|a| a.placement.class}.include? SiteSettings
> end
> end
>
> This does prevent the record from being destroyed, but doesnt provide any
> feedback to the user as to why.
>
> Seems like this should be a validation. I want to be able to use AR::Errors
> to send a message back to host explaining why it cannot be destroyed, but
> that behavior kind of flies in the face of the conventional restful
> controller generated in Rails scaffold (ie: in the destroy action, there is
> no 'check for errors and render the edit page'). I feel like I should be
> able to do:
>
> validates_on_destroy :make_sure_not_default
>
> def make_sure_not_default
> errors.add_to_base('Cannot destroy this AdZone while it is a default')
> if ad_zone_placements.map{|a| a.placement.class}.include? SiteSettings
> end
>
> Right? Has anyone else ever ran into this? Is there something built in I'm
> missing? Am I have a braindead moment like that time I forgot about
> "has_many :through" ?
>
> Thanks,
> Ryan

Re: Preserving has_many :through ids assignment order

2009-11-12T10:59:33Z

On Nov 12, 10:38 am, Matt Jones <al2o...@...> wrote:

> For this to make sense as a Rails patch, there's got to be a reason
> why this ordering should be preserved. What's the difference between
> adding the records in the [5,8,3] order vs. some other order?

The reason is because when you assign directly to a has_many :through,
it's creating records, and the order they are created in is
significant. Suppose this is populated by an javascript autocomplete
where a user is picking a series of destinations. If the declaration
is:

has_many :routes, :order => 'id'

Then the order that the routes are inserted is significant.

Now it's true that you can control the order by creating routes
manually, but being able to assign to the leaf association is
incredibly useful in certain circumstances because it can remove a ton
of boilerplate bookkeeping code. The view and controller don't even
need to know about Routes at all, they just work with Destinations
which is much cleaner.

Finally, I the order should be preserved for @person.destination_ids=
for simple symmetry with @person.destinations= and other iterating
object creators which all seem to preserve order in my experience.

Patch forthcoming...

--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Preserving has_many :through ids assignment order

2009-11-12T10:38:38Z

On Nov 12, 2009, at 11:54 AM, dasil003 wrote:

>
> Matt, your comment doesn't make any sense. I'm not sure what you are
> thinking, but you are clearly not understanding the issue.

Whoops - looks like I was reading the question the other way around
(that you *wanted* the records to come back in order). Sorry about that!

> This is
> not my own method, it is a method generated by the has_many :through
> macro. Consider this concrete example:
>
> Person has_many :routes
> Person has_many :destinations, :through => :routes
>
> Now say I do, @person.desination_ids = [5, 8, 3]
>
> That is what the included method definition does. It's totally
> reasonable to expect the first route insertion to be for destination
> 5, the second insertion to be for destination 8 and the third
> insertion to be for desination 3. However it doesn't do this as you
> pointed out due to the fact that it finds all the destinations without
> any order. However as I tried to point out in the original post,
> there is NO WAY to maintain the order in the SQL because it's
> arbitrary, it's not sorted on any field.
>
> That is why I redefined the method so that it uses the original array
> to inform the final order of objects that get passed to the
> association method (ie. @person.destinations). As you can see, the
> ordering of my association is neither here nor there. It's the order
> of insertion that matters, and it's not controlled by an order clause.
>
> My question was not how do I solve this, my question was whether
> people think that this should be submitted as a Rails patch. Having
> thought about it further I'm convinced it should be.

For this to make sense as a Rails patch, there's got to be a reason
why this ordering should be preserved. What's the difference between
adding the records in the [5,8,3] order vs. some other order?

--Matt JOnes

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@...
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Validating models on destruction

2009-11-12T10:25:08Z

Hey guys,

Have you ever wanted to validate a record was valid for destruction? Does this make sense conceptually? Let me paint a picture of something I just ran into that makes me think I should be able to do this.

I have a many to many polymorphic relationship between our Advertisement model and a bunch of other models in our app. One of these models is the User model. At any point I may want to find the ad for top_dashboard_ad_1 for a given user, but if that user doesnt have an ad specified I want to fall back to our defaults:

@user.ad_for('top_dashboard_ad_1')

class User < AR::B
def ad_for(type)
    advertisements.find_by_location(type) || SiteSettings.instance.ad_for(type)
end
end

SiteSettings is a singleton model that also has a polymorphic relationship with the Advertisement model. This is all CMS'd. A certain User can have special ads assigned, and the defaults can be changed at any time. Here's the kicker: If a certain advertisement is associated with the SiteSettings instance (meaning it is a default), I dont want it to allow it to be destroyed.

I currently have this in my Advertisement model:

class Advertisement < AR::B
before_destroy :make_sure_not_default

private
def make_sure_not_default
    !(ad_zone_placements.map{|a| a.placement.class}.include? SiteSettings
end
end

This does prevent the record from being destroyed, but doesnt provide any feedback to the user as to why.

Seems like this should be a validation. I want to be able to use AR::Errors to send a message back to host explaining why it cannot be destroyed, but that behavior kind of flies in the face of the conventional restful controller generated in Rails scaffold (ie: in the destroy action, there is no 'check for errors and render the edit page'). I feel like I should be able to do:

validates_on_destroy :make_sure_not_default

def make_sure_not_default
    errors.add_to_base('Cannot destroy this AdZone while it is a default') if ad_zone_placements.map{|a| a.placement.class}.include? SiteSettings
end

Right? Has anyone else ever ran into this? Is there something built in I'm missing? Am I have a braindead moment like that time I forgot about "has_many :through" ?

Thanks,
Ryan

--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---