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.

We've moved the forum!

Please use forum.silverstripe.org for any new questions (announcement).
The forum archive will stick around, but will be read only.

You can also use our Slack channel or StackOverflow to ask for help.
Check out our community overview for more options to contribute.

DataObjectManager Module /

Discuss the DataObjectManager module, and the related ImageGallery module.

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

DataObjectManager vs ModelAdmin


Go to End


5 Posts   2949 Views

Avatar
socks

Community Member, 191 Posts

4 September 2009 at 10:22am

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

Avatar
UncleCheese

Forum Moderator, 4102 Posts

4 September 2009 at 11:03am

Edited: 04/09/2009 11:05am

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?

Avatar
socks

Community Member, 191 Posts

7 September 2009 at 6:50pm

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?

Avatar
UncleCheese

Forum Moderator, 4102 Posts

8 September 2009 at 7:16am

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.

Avatar
socks

Community Member, 191 Posts

8 September 2009 at 2:37pm

Sounds good, thank again.