You might try updating the lighthouse ticket with this patch to try to drum up support. Seems quite useful.
+1 On Apr 22, 8:39 am, Chris Cruft <c...@hapgoods.com> wrote: > I've expanded my monkey patch (see it here:http://gist.github.com/88448) > to the point where I wouldn't call it proof of concept anymore. It > works very nicely in practice as well. The concept of scoped > associations and composing of scopes, regardless of my implementation, > seems strong. Luke, I would love your thoughts on this approach since > it's pretty close to your original syntax. > > The implementation has two major flaws/shortcomings: > > 1. No tests > 2. No proper patch (trivial) > 3. No support for procedural scopes (important, IMO) > > Anybody care to take a stab? > > On Mar 31, 6:37 pm, Chris Cruft <c...@hapgoods.com> wrote: > > > And here is the monkey patch for getting scoped join models (and > > targets): > > > http://gist.github.com/88448 > > > This is a "proof of concept" patch. It only scopes has_many > > associations (and has_many/has_one :through => <has_many> > > indirectly). Scoping has_one should be a trivial matter of > > adding :scope as a valid option. I don't think belongs_to would be > > hard either. HABTM, as usual, is a _special_ case and would probably > > explode on lift-off. > > > The second limitation is that "procedural" scopes (those that take > > parameters) are not supported. I could not think of a clean syntax to > > deal with the > > parameters and I wasn't (yet) prepared to support a proc/lambda as the > > param. As a side note, the chicken-and-egg problem of specifying > > association by having each end refer to the other frustrates clean > > syntax... > > > -Chris > > > On Mar 31, 12:24 pm, Chris Cruft <c...@hapgoods.com> wrote: > > > > The named_scope macro introduces a concise syntax for a complex set of > > > [:order, :conditions, :joins, :include, :offset, :limit, :readonly] > > > options for a model class. The options for the association macros use > > > most of those SAME OPTIONS. My first suggestion is that association > > > macros accept a :scope option, which is a symbol naming a named_scope: > > > > Replace this: > > > has_many :important_taggings, :class_name => > > > 'Tagging', :conditions => {:flag => :important} > > > With this: > > > has_many :important_taggings, :class_name => 'Tagging', :scope > > > => :important > > > > where the 'important' scope exists on the Tagging model as in Luke's > > > example. The scope option could also be used to replace many of the > > > other SQL-related options (e.g. :order, :include, :limit). And > > > eventually the scope could be extended to include a lambda for dynamic > > > construction of a scope. The essence of this suggestion is > > > that :scope can be used to simplify the options for association macros > > > AND introduce new, regular behavior (see below). > > > > Like Luke's original proposal, I'm suggesting that the macros accept > > > a :scope option. Unlike Luke, I am suggesting that, in the presence > > > of the :through option the :scope option NOT be treated as a special > > > case -let it scope the target, NOT the join model. So in this > > > example: > > > > has_many :important_tags, :through => :important_taggings, :source > > > => :tag, :scope => :g_rated > > > > the :g_rated scope is NOT coming from the JOIN table (Taggings) but > > > rather the target (Tags). > > > > The best news is that a trivial patch achieves this functionality AND > > > it provides the stupendously wonderful feature of scoping the creation > > > of join models. Following my example above: > > > > user.important_tags.create > > > > will create a Tag within the :g_rated scope AND create a Tagging > > > within the :important scope (:flag => 'important' to use Luke's > > > model.) No more extensions required to accomplish the obvious and > > > trivial setting of the :flag attribute. > > > > Here is the patch against 2.2.2:http://gist.github.com/88236 > > > > I'll post a monkey patch as well. > > > > One last comment: I started out liking Ryan's syntax. But I lost my > > > enthusiasm when I realized that the target class would need to be > > > decorated with a named_scope for each of the paths that associated > > > with it. It just doesn't seem like good encapsulation. In the > > > example, is it right that the Tag model need to know about the Tagging > > > class' scopes? In this example, it's a bit awkward. But in other use > > > cases, I think the target class will get pretty ugly with scopes > > > referring to the myriad ways in which it might be associated. And for > > > the case of a utility model provided by a plugin, the decoration of > > > the target is relatively expensive. > > > > On Feb 27, 1:37 pm, Luke Redpath <ljredp...@gmail.com> wrote: > > > > > In my current project, I have an association model that has various > > > > flags available. To keep the implementation of these flags > > > > encapsulated, I created named_scopes for each flag and use these > > > > scopes for finding and creating. > > > > > This model sits between two others as the join model in a > > > > has_many :through association. I actually wanted various > > > > has_many :through associations that use the same join model but > > > > different scopes. Unfortunately has_many :through doesn't have > > > > a :scope option; I could use :conditions to get it working but I've > > > > now broken the encapsulation I aimed for when I introduced the named > > > > scopes and created unnecessary duplication. > > > > > Hopefully this rather contrived example should make it clear what I'm > > > > aiming for. > > > > >http://gist.github.com/71585 > > > > > And my initial implementation, currently in use in our app (tries to > > > > extend ActiveRecord in the least-intrusive way): > > > > >https://gist.github.com/9d7f86e27014ef5df280 > > > > > And now, my attempt to do it properly as a patch to ActiveRecord, with > > > > a test. > > > > >http://gist.github.com/71587 > > > > > I don't expect this patch to be completely ready for inclusion; there > > > > are probably other things to consider such as, do you just want to > > > > pull the :conditions from the proxy? Is there anything else to pull > > > > in? Could this be written in a better way (probably, my knowledge if > > > > the AR internals is slim). > > > > > Any thoughts? --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
