implement << operator on collections about hydra-pcdm HOT 11 CLOSED

Is it a common use case to want the collections separate from the objects?

from hydra-pcdm.

I'll have to let others speak to this. I could see an app that wants to display collections grouped at the top of a list and objects grouped at the bottom of the list. With the code as it currently exists, the app could either request...

• colls = coll1.collections # just get collections in order
• objs = coll1.objects # just get objects in order
• members = coll1.members # get collections and objects intermixed in order

This ticket has to do with appending collections and objects.

from hydra-pcdm.

There are several tests in collection_spec that attempt to use << to add collections and objects. The test may need to be adjusted depending on the implementation approach. They are all currently marked xit to skip them since they are known failures.

from hydra-pcdm.

I don't think we should do this. The << operator would imply that a collection is the sum of its contained items (e.g. like an Array), but a collection is more than that, it has descriptions too.

from hydra-pcdm.

I agree with @jcoyne about putting the operator directly on instances of a collection. It should be coll1.members << obj1, not coll1 << obj1. See how this is handled by ActiveFedora::Associations (digging up links. one sec)

from hydra-pcdm.

I suspect that you will have to do something like ActiveFedora::Associations::CollectionAssociation

from hydra-pcdm.

Question: Is it the case that this is NOT a problem with .members << and is only a problem with .collections << and .objects <<?

If it's a problem with all three, then the underlying code (in AF::Aggregation) needs to do something like ActiveFedora::Associations, which adds the necessary methods to Collection and makes those methods return something like ActiveFedora::Associations::CollectionAssociation instead of an Array.

If, on the other hand, .members<< already works fine (meaning the underlying code is doing the right thing), then I would have different ideas about how to make .collections<< or .objects<< work.

from hydra-pcdm.

#members << doesn't work, but there's a ticket for it. It -should-.

from hydra-pcdm.

samvera-deprecated/activefedora-aggregation#22

from hydra-pcdm.

I'd want something like this...

def collections
  AssociationTypeFilter.new(members, PCDM::Collection)
end

class AssociationTypeFilter < SimpleDelegator
  attr_reader :type
  def initialize(members, type)
    @type = type
    super(members)
  end
  def to_a
    __getobj__.to_a.select{|x| x.rdf_type == type}
  end
end

Note that #to_a won't work, because I don't know the API for getting an AF::Base's type, but yeah.

from hydra-pcdm.

I've added some implementation suggestions to samvera-deprecated/activefedora-aggregation#22.

Note that with regular ActiveModel Associations you can simply add a second has_many (or has_and_belongs_to_many association and make it filter the objects differently, expect different classes, etc. Obviously, you can't to allow people to call aggregates multiple times, but maybe that's just a matter of having a second method like filters_aggregation

from hydra-pcdm.