Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

DataObjectManager Module /

Discuss the DataObjectManager module, and the related ImageGallery module.

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

DataObject, ManyMany, and inline tickboxes


Go to End
Reply


13 Posts   3501 Views

Avatar
Double-A-Ron

Community Member, 604 Posts

13 July 2009 at 9:05pm

Hiya, OK what I'm trying to do.

I have created a page type called TwoColumnPage. I have also created a class called SideBarBlock which extends DataObject. The idea is that for this site, my user can create as many side bar blocks as they like, have all previously build blocks accessable on every TwoColumnPage, and just select the ones they want for the current page.

These sidebar boxes consist of a Header (TextField) and Content (HTMLContent).

Easy enough for ManyManyComplexTableField, but I am interested in using DataObjectManager for two reasons:
1. The Drag and Drop ordering.
2. The SimpleHTMLContent field type for the popup.

I have tried this, and there are some issues:
1. Drag and Drop re-ordering isn't even an option for some reason. The tickbox is gone.
2. There is of-course no tick box to select which side bar block is active on each page.

Am I trying to use DataObjectManager for something it's not designed for (for starters, a many-many relationship)? Can anyone spot an easier way of doing what I am trying to do.

Avatar
UncleCheese

4085 Posts

14 July 2009 at 1:01am

Hi, Double-A (my nickname as as a kid, as well),

We have a very similar set up on all of our sites. By default all of our site installs get a page class with a many_many CalloutBox relation. In the near future, I want to add the ability to sort many_many items so that each page instance will show a unique sort order of those set of callout boxes. The problem is that by default, DOM will store the sort on the DataObject, when in actuality it belongs on the linking table because it's defined for every relationship. Every page should be able to have its sidebar blocks sorted uniquely. It's just a matter of making the controller a little more aware of the relation, and sniffing out belongs_many_many. If it finds a many_many_extrafields, then it should update that.

I'm surprised you haven't been able to get the checkbox to show up, though. You have this in your _config.php?

SortableDataObject::add_sortable_class('SideBarBlock');

I have seen some cases in 2.3.1 where it doesn't decorate the object properly, but that was rare.

Avatar
Double-A-Ron

Community Member, 604 Posts

14 July 2009 at 11:12am

Ha, my Pop thought "Double-A-Ron" was the funniest thing in the world.

No, I didn't have that Line in my _config so I will try that when I get home. So the only other thing that is missing for me is the inline checkboxes for each item in the grid so I can choose to include or not include a particular SideBarBlock on each page a-la ManyManyComplexTableField. Is this possible at all?

I understand that the sort order will be global across all pages. I felt that this is a live-able trade off for the benefits that your module provides in the sort order and popup editor with the SimpleHTMLEditor. It will allow my clients to make text changes to their own sidebar blocks without having me to change the templates at all. (which happens frequently)

I spent quite a bit of time last night (dumping the above idea) modeling a system on the Blog's widget model. I actually had this working very well with the major flaws being that it does not provide a way to:
a) Show data based information in the "Avaialable Widget" section. These appear to have to be subclasses of Widget (ie - a PHP class for every block I need). I'm sure this could be adapted.
b) Edit or enter text with HTML formatting. I can added a TextArea easy enough, but HTML tags are too much for my clients.

One thing I didn't test was using the WidgetEditorArea on more than one page and how this effects included Widgets and Sort Order on each page.

I will play with this more later, as I feel the administration interface is pretty close to perfect for this application.

This may also entail a new PageType for SideBoxes that are managed from the tree itself, with the new module (based on the Widget system) hacked to pull info from the site tree instead of looking for subclasses of "Widget".

I just thought your module was pretty darn close to be perfect for this application too. In fact it's probably closer to the above considering all it needs is selection tickboxes, and page-level ordering. I may have a go at hacking this instead.

Cheers
Aaron

Avatar
UncleCheese

4085 Posts

14 July 2009 at 1:06pm

Are you using ManyManyDataObjectManager? The checkboxes should be there.

Avatar
Double-A-Ron

Community Member, 604 Posts

14 July 2009 at 2:35pm

Sheesh,

I didn't even know there was one. No I was using DataObjectManager.

Cheers mate, I'll give it a run tonight.

Aaron

Avatar
UncleCheese

4085 Posts

14 July 2009 at 3:39pm

There is a DOM and FDOM counterpart for every CTF type.

DataObjectManager
HasOneDataObjectManager
HasManyDataObjectManager
ManyManyDataObjectManager

FileDataObjectManager
HasOneFileDataObjectManager
HasManyFileDataObjectManager
ManyManyDataObjectManager

ImageDataObjectManager

AssetManager

NestedDataObjectManager (coming soon)

Avatar
Double-A-Ron

Community Member, 604 Posts

14 July 2009 at 9:34pm

Edited: 14/07/2009 11:42pm

Thanks mate. I'm damn close now. However the sorting doesn't appear to work on the CMS side of things.

I can drag and drop, and when I check the table, the SortOrder field has been added and the numbering moves around when I do drag and drop operations. However, if I refresh the CMS, the order of the items appears to be based on ID.

I have even tried adding the Sort clause to the getCMSFields operation.

I also not that clicking on the header column to sort the table has no effect also. Firebug tells me that the params that are sent are all in the format "ctf[SideBarBlocks][filter]" etc. (note the 's' at the end of SideBarBlocks - the class is acutally called the singular "SideBarBlock".

SideBarBlock.php

class SideBarBlock extends DataObject {

static $db = array(
'Header' => 'Text',
    'Content' => 'HTMLText',
);

static $has_one = array (
);

static $belongs_many_many = array(
'TwoColumnPages' => 'TwoColumnPage'
);
   
public function getCMSFields_forPopup()
    {
      return new FieldSet(
         new TextField('Header', 'Block Header'),
         new SimpleHTMLEditorField('Content','Block Content', array (
         'css' => 'mysite/css/side-bar-blocks.css',
            'increaseFontSize' => false,
            'decreaseFontSize' => false,
            'justifyLeft' => false,
            'justifyRight' => false,
            'justifyFull' => false,
            'justifyCenter' => false
         ))
      );
   }

}

And TwoColumnPage.php

class TwoColumnPage extends Page {
   
   static $many_many = array(
      'SideBarBlocks' => 'SideBarBlock'
   );      
   
   public static $db = array(
   );
   
   public static $has_one = array(
   );
   
   public function getCMSFields()
   {
      $fields = parent::getCMSFields();

         $fields->addFieldToTab("Root.Content.Sidebar", new ManyManyDataObjectManager(
            $this,
            'SideBarBlocks',
            'SideBarBlock',
            array('Header' => 'Header'),
            'getCMSFields_forPopup',
            '',
            'SortOrder'
         ));
      
      return $fields;
      
   }
   
}

Any ideas what I've got wrong here? This just appears to be a CMS side thing. The actual sort order values look legit.

Cheers
Aaron

Avatar
UncleCheese

4085 Posts

15 July 2009 at 2:38am

I've tested your code and the only bug I found is that your file is named SidebarBlock.php but your class is SideBarBlock, so it wasn't getting pulled into the manifest and SortableDataObject wasn't able to find it. Other than that it's working as expected on my sandbox site, column sorting and all.

http://dataobjectmanager.carlinowebdesign.com/admin
u: admin
p: password

BTW, ComplexTableField and DataObjectManager use the named relation in lieu of the class name in almost all of their operations. Not sure why. I was just following CTF's lead. :)

Go to Top