Enhancement: Expose scope object

[ludwigschubert]

A acts_as_list object should expose its scope object/parent.

I'd love to patch and submit a pull request for this myself, but I'd like to discuss naming options, possible alternative solutions, and whether this is a sensible idea at all with you guys first.

Workaround

I #send a substring of the scope name to the object

object.send(object.scope_name[0..-3])

Why?

This would allow to create awesome nested paths without needing to know about the scope explicitly, such as this reusable navigation snippet:

link_to "Next Object", [:show, acts_as_list_object.scoped_to, acts_as_list_object.higher_item]

Naming

Here are some possible names, feel free to chime in on how you like them:

• scoped_to
• scope_object
• scope_parent
• parent imho ambiguous

[swanandp]

I've been meaning to do this for a while. The idea is to expose the list as an object, which can then act as a scope or whatever required.

Considering the object itself may or may not have the word list in it, the names that make more sense to me are list_scope or just plain list. e.g. todo_item.list. It could well be the name of the association, and the list object itself can leech off the parent association, thought that doesn't sound like a very good idea.

Thoughts?

[ludwigschubert]

List sounds fine to me, considering this gem is called acts_as_ list. 😅

Unfortunately I don't understand your second proposal:

and the list object itself can leech off the parent association

Which parent association do you mean?

The way I'd currently implement it is to save the passed :scope argument, and #send it to the acts_as_list object. So just like the workaround, minus the string subsetting.

[swanandp]

By parent association I meant the association reflected by the scope, but I realized that not all scopes would be associations.

[swanandp]

@ludwigschubert : If you got a chance to tackle this, do let me know. And don't worry about names to begin with, we can always rename them.

[ludwigschubert]

Unfortunately I don't feel confident I understand the entirety of of this gem's use cases well enough to provide a pull request.

Naive Implementation

What I did originally was a simple method on List::InstanceMethods that reads:

# Exposes the object the list is scoped to, see #97
def list
  self.send(self.scope_name[0..-3])
end

This only works when the scope is a parent association… an assumption I don't feel confident about in more general use cases of this gem.

Nicer Workaround

I simply went and created a path helper method on my actual list item that used the parent object. This feels a little safer to me, as it isn't using send and assuming a parent association implicitly.

Should this be closed?

I'm not sure. I don't think the enhancement request makes sense in all use cases of the gem. If there's a way to only add the list method when the scope is really a parent association, it might still be useful in certain scenarios. I feel like I was thinking in too abstract levels when I opened this enhancement request, and that more pragmatic approaches, like the one mentioned above, might actually lead to simpler code in many cases.

[brendon]

Hi @ludwigschubert, I'll close this off for now unless time has given you some new inspiration :)