Jump to:

7935 Posts in 1536 Topics by 943 members

DataObjectManager Module

SilverStripe Forums » DataObjectManager Module » Using ManyManyDataObjectManager on the belongs_many_many side

Discuss the DataObjectManager module, and the related ImageGallery module.

Moderators: martimiz, UncleCheese, Sean, biapar, Willr, Ingo, swaiba, simon_w

Page: 1 2 3 4
Go to End
Author Topic: 5287 Views
  • UncleCheese
    Avatar
    4085 Posts

    Re: Using ManyManyDataObjectManager on the belongs_many_many side Link to this post

    Umm, before I go any further, did you guys know that you don't have to define $belongs_many_many? I have at times mistakenly defined both as $many_many and it works fine.

    Maybe try that first?

    I never got the whole belongs_many_many thing, anyway.

  • MarcusDalgren
    Avatar
    Community Member
    288 Posts

    Re: Using ManyManyDataObjectManager on the belongs_many_many side Link to this post

    I have actually tried that and it kind of works.

    The problem with defining many_many on both sides is that you end up with two separate independent linking tables so the relationship ends up being one sided.

    The functionality I'm after is having a DataObjectManager on one side (the ProductPage) and then linking that to a SoftwarePage. When editing a SoftwarePage I might change my mind and want to change that relationship. As things are today you can either represent the relationship from the belongs_many_many side with a checkBoxSetField or you would have to save the SoftwarePage and then go to the ProductPage in question and change the relationship there.

    Looking at the code for ManyManyComplexTableField it looks like they planned on it working the way I have described but someone borked the code for finding the linking table from the belongs_many_many side.

    If you go for many_many on both sides relating a ProductPage to a SoftwarePage won't make a SoftwarePage related to a ProductPage since the relationships will be independent of eachother.

  • Chris Dangerfield
    Avatar
    Community Member
    8 Posts

    Re: Using ManyManyDataObjectManager on the belongs_many_many side Link to this post

    Hey guys,

    Really appreciate your work on this. I have been thinking, and I wondered if it was possible to NOT call 'getCMSFields_forPopup()' when the only permission that is set is 'show'. Because, if you have a page-to-page relationship you probably wouldn't need to add or edit the information from the dataobjectmanager. Let me know what you think.

  • MarijnKampf
    Avatar
    Community Member
    164 Posts

    Re: Using ManyManyDataObjectManager on the belongs_many_many side Link to this post

    UncleCheese will Smurkas code ( post268318 ) be included in the next version of ManyManyDataObjectManager? It solved the issue for me and allowed me to use ManyManyDataObjectManager at both sides of the relationship.

    Also in possibly an unrelated issue I found that using the name of the class as the array name brakes things:

    // This doesn't work
       static $belongs_many_many = array(
          'Species' => 'Species'
       );

    // This does work
       static $belongs_many_many = array(
          'ProjectSpecies' => 'Species'
       );

  • MarcusDalgren
    Avatar
    Community Member
    288 Posts

    Re: Using ManyManyDataObjectManager on the belongs_many_many side Link to this post

    Hi Martijn.

    I don't think that code is ready to be included partially since you seem to have found a bug I'll have to take a look at and because it kind of breaks the way things normally work.

    Fixing the bug is doable but I'm very unsure if there is a satisfactory solution to the infite loop since that's simply how DOM/Complextablefield is built. They all have the functionality of defaulting to getCMSFields() and this fix breaks that functionality in a pretty huge way.

    Since this seems to be a pretty rare scenario that break might be kind of acceptable but that decision is up to UncleCheese. IE we would have to inform people that using DOM on the belongs_many_many side means you have to setup separate popup-getters, otherwise everything explodes.

  • mattclegg
    Avatar
    Community Member
    56 Posts

    Re: Using ManyManyDataObjectManager on the belongs_many_many side Link to this post

    Thanks Marijn. This solved an issue I was having.

  • MarcusDalgren
    Avatar
    Community Member
    288 Posts

    Re: Using ManyManyDataObjectManager on the belongs_many_many side Link to this post

    Nice to see that the code is getting some use.

    I haven't had the time to look at the problem you reported Martijn but I'll hopefully get to it in the next couple of days and see if I can figure out what goes wrong when you use the same name as key/value.

    I just wanted to add that there is one more scenario where this will break rather messily and that is when you have several many_many relations to the same object, for example

    public static $many_many = array(
    "Scenes" => "Scene"
    "MoreScenes" => "Scene"
    );

    This is probably a pretty rare scenario but if it applies to anyone trying this fix then know that this will break it. The big problem here (which I don't think there is a real solution to within the boundaries of how this works today) is that there's no way for the belongs_many_many class to figure out which one of the two relations above is the one that applies and thus it can't reliably find the correct relationship table.

    If there's just one many_many relationship to a class then it works, if there's more it doesn't. I am going to have a look at how (or if) SilverStripe solves this with it's getters, if we're lucky there is actually a solution to this somewhere in the code.

  • mattclegg
    Avatar
    Community Member
    56 Posts

    Re: Using ManyManyDataObjectManager on the belongs_many_many side Link to this post

    Hey Smurkas,

    It looks like the 'belongs_many_many' is still a problem. Iv done a quick hack to stop FormScaffolder building anything on these types of relationships and submitted a patch here;

    [url=http://open.silverstripe.org/ticket/6395]http://open.silverstripe.org/ticket/6395

    Matt

    5287 Views
Page: 1 2 3 4
Go to Top

Want to know more about the company that brought you SilverStripe? Then check out SilverStripe.com

Comments on this website? Please give feedback.