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.

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?

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?

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 %>

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.

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.

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.

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?