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're retiring the forums!

The SilverStripe forums have passed their heyday. They'll stick around, but will be read only. We'd encourage you to get involved in the community via the following channels instead:

DataObjectManager Module /

Discuss the DataObjectManager module, and the related ImageGallery module.

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

Preview: DataObjectManager module

Go to End

379 Posts   75668 Views

Mr. Matt

Community Member, 5 Posts

9 April 2009 at 10:16am

Setting $var->setParentClass( 'Page' ); to the DataObjectManager fixes the issue, its when you try and use ImageDataObjectManager and FileDataObjectManager that it doesnt fix the problem any more.

Something is happening when the form is built that PageID is not being listened to in the FileDataObjectManager upon creation of new items.

Amir Mostofi

Community Member, 59 Posts

9 April 2009 at 10:37am

I have a basic question regarding the front-end templating and checking the extension of a file attachment to perform a certain function.

Imagine that we have a database file field $Attachment. $Attachment.Extension will return the extension. Now, assuming that $Attachment has both SWF and JPG files, I want to detect on the front-end template side that if extension is SWF, write the HTML code for displaying the flash file and if not, display $Attachment which will return the img tag.

I know that something like <% if $Attachment.Extension = SWF %>....<% else %>....<% end_if %> will naturally give parsing error. Then, how do you go about this?

Mr. Matt

Community Member, 5 Posts

9 April 2009 at 10:54am

Ok we think we have a fix for the problem.

From the current release of the module the method UploadForm on FileDataObjectManager does not have a hidden field to specify the DataObjects owner, e.g. the PageID.

We have commented out line 365 in FileDataObjectManager in method EditUploadedForm which does a loadDataFrom($dataObject) call. The hidden field is correctly added to this form (PageID) but the loadDataFrom method call overwrites the value in the Field as $dataObject, which is the record created from the UploadForm request (which didn't contain the PageID field).

Maybe it is that we haven't followed the documentation correctly, but the absense of the hidden field from the UploadForm suggests that something there has been over looked.

Will there we any effects from our change that will break other functionality?


Forum Moderator, 4102 Posts

9 April 2009 at 11:15am

I think I know the problem. Let me take a look and I'll issue a patch soon.

Amir, you can use <% if Attachment.Extension = SWF %>

or worst case,

<% control Attachment %><% if Extension = SWF %>

Amir Mostofi

Community Member, 59 Posts

9 April 2009 at 12:18pm

Mr. Matt, I believe you have got it!!!
Commenting out line 365 does the trick, provided you set a correct filter clause (e.g. "PageID = {$this->ID}") and setParentClass (e.g. $manager->setParentClass('Page');).

Thank you!

And much appreciation to UncleCheese and the rest of the helpful developers community! This is definitely the module with the greatest potential.


Forum Moderator, 4102 Posts

9 April 2009 at 12:20pm

I can see why you'd say the loadDataFrom method is not needed in this case because the objects are guaranteed to be new. However, I'm not sure I want to uphold that assumption. For instance, in ImageGalleryManager (an extension of ImageDataObjectManager), the albumID is set on the object before the EditUploadedForm is called. Without the loadDataFrom method, we would lose that information. In fact, at one time it was not there, and people were complaining that all of their photos got set to the first AlbumID in the dropdown list. The fix was to use loadDataFrom to ensure that the dropdown gets set to the correct value.

I'm really inclined to leave it in, in case anything ever changes. I'm looking for the most elegant way to force the relationship field in there. Good news, of course, is that we know the problem and it can be fixed easily.


Community Member, 49 Posts

9 April 2009 at 5:04pm

Ok, this is just a theory, but I am pretty sure it is why my code works with out setting the parent class, or any of the other hoops.

SortableDataObject::add_sortable_class('SomeDataObject'); (goes in your _config.php)

This insures you have IDs and maybe this is what make's mine work? I just know that I get all these things for free that people are saying don't work. Anyway, hope this helps someone.

Just a thought.


Community Member, 9 Posts

10 April 2009 at 7:51am

UncleCheese, first things first: dataobjectmanager is really nice work! thank you!

I'm probably doing something i'm not supposed to but i'm using the dataobjectmanager to make a searchable list of a pages children.
For a Page i have added a databjectmanager under a subpages tab. So if for example a newspage with a lot of children (> 50 for example) makes the sitetree impractical to use i can find underlying pages through this subpages tab.
Now i'm wondering: can i override the default behaviour of the edit icon for the items in the dataobjectmanager?
pseudo code: something like:
jump to childpage in sitetree and start editing this. instead of having all the fields in a popup?

basicly can i pass a custom javascript function name instead of the getCMSFields_forPopup?
i didn't seem to work but maybe i just did something wrong, wich is most likely.

Also maybe we could extend this to adding blanc underlying pages and then jump to them to edit?

Go to Top