Jump to:

7940 Posts in 1543 Topics by 946 members

DataObjectManager Module

SilverStripe Forums » DataObjectManager Module » DataObjectManager vs ModelAdmin

Discuss the DataObjectManager module, and the related ImageGallery module.

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

Page: 1
Go to End
Author Topic: 2390 Views
  • socks
    Avatar
    Community Member
    190 Posts

    DataObjectManager vs ModelAdmin Link to this post

    If I'm understanding correctly, both DataObjectManager and ModelAdmin are used to work with Data Objects. Why would I use one over the other?

    thanks

  • UncleCheese
    Avatar
    4085 Posts

    Re: DataObjectManager vs ModelAdmin Link to this post

    They're very different things.

    DataObjectManager is a formfield, similar to ComplexTableField that administers the basic create, read, update, delete (CRUD) of records associated with a page or dataobject. In addition to that basic functionality, it has a whole host of other features to enhance that management including drag-and-drop sorting, search, etc.

    ModelAdmin is a CMS interface that is used to administer CRUD of generic data -- that is, data that is not necessarily associated with a page, as it must be in CMSMain. You can manage one or many different objects in any given ModelAdmin interface and search on them, export, them, and more.

    In a given ModelAdmin interface, you may want to employ a DataObjectManager in your fieldset to manage associations of one DataObject to another.

    If you're associating the objects with a page, you want to use a DataObjectManager in CMSMain in your getCMSFields() function that you're probably familiar with.

    An example of ModelAdmin might be an interface for StaffMembers. Each StaffMember may have an Education object associated with it, so you can create something like:

    Name: Jon Smith
    Title: CEO
    Education:
    - Boston University, 2001, Bachelor of Arts
    - Oxford, 2004, Masters in Basketweaving
    - UCLA, 2009, PhD.

    Where the school name, year, and degree are all properties of an Education object. You would add each of those objects to a StaffMember using a DataObjectManager as a formfield in your ModelAdmin interface. It would be in your fieldset along with Name and Title fields for the StaffMember.

    Make sense so far?

  • socks
    Avatar
    Community Member
    190 Posts

    Re: DataObjectManager vs ModelAdmin Link to this post

    Thanks Uncle C,

    That makes a little more sense to me. In a future project, there will be a Store Locations page that simply lists out all the stores (store id, address, city, state, zip code) grouped by state then city.

    1. Since the Locations dataobject is related to the Store Locations page, you would suggest using DOM over ModelAdmin?
    2. Does DOM have import/export of CSV files like ModelAdmin does?
    3. Do I put all fields (store id, address, city, state, zip code) in static $db or do I list City and State as static $has_many since both can have multiple stores?

  • UncleCheese
    Avatar
    4085 Posts

    Re: DataObjectManager vs ModelAdmin Link to this post

    1. Since the Locations dataobject is related to the Store Locations page, you would suggest using DOM over ModelAdmin?

    ===> Again, they're really not comparable tools. ModelAdmin is a content management interface that would hold one or many editing screens for any number of objects. DataObjectManager is a specific field you would use in those editing screens to manage the relationship of one object to many. If you are creating the StoreLocationsPage in CMSMain, then you should use a DataObjectManager in your fieldset to attach many locations to that Page object.

    2. Does DOM have import/export of CSV files like ModelAdmin does?

    ===> No, not yet. I keep meaning to add that. I can probably just piggyback off the CTF export features, but.. So little time.

    3. Do I put all fields (store id, address, city, state, zip code) in static $db or do I list City and State as static $has_many since both can have multiple stores?

    ===> You would set it up like this:

    StoreLocationsPage extends Page

    $has_many Locations => StoreLocation

    StoreLocation extends DataObject

    $has_one StoreLocationsPage => StoreLocationsPage

    $db City, State, etc..

    Please refer to tutorial #5 in the SS documentation on managing DataObject relationships.

  • socks
    Avatar
    Community Member
    190 Posts

    Re: DataObjectManager vs ModelAdmin Link to this post

    Sounds good, thank again.

    2390 Views
Page: 1
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.