7913 Posts in 1355 Topics by 930 members
DataObjectManager Module
SilverStripe Forums » DataObjectManager Module » Preview: DataObjectManager module
Discuss the DataObjectManager module, and the related ImageGallery module.
Moderators: martimiz, UncleCheese, Howard, Sean, Ryan M., biapar, Willr, Ingo, swaiba, simon_w
| Go to End | Next > | |
| Author | Topic: | 54322 Views |
-
Re: Preview: DataObjectManager module
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?
-
Re: Preview: DataObjectManager module
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 %>
-
Re: Preview: DataObjectManager module
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.
-
Re: Preview: DataObjectManager module
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.
-
Re: Preview: DataObjectManager module
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.
-
Re: Preview: DataObjectManager module
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?
-
Re: Preview: DataObjectManager module
12 April 2009 at 10:33am
@mr_t - I see what you're getting at, but I think it's a little too far out of scope of the project for me to develop right now. DataObjectManager was built as an extension to the ComplexTableField, so I'd like the functionality to stay parallel for now.
@everyone who has been trying to fix the FileDataObjectManager on a page issue -- I'm having a hard time replicating this problem. Here's what I've done.
I've created a has_many relation on my Page class to the example Resource object. Resource has_one Page. In my Page class, I have a FileDataObjectManager for Resources, and I setParentClass("Page");
I'm able to get every page to have its own resources. What am I missing?
-
Re: Preview: DataObjectManager module
12 April 2009 at 10:52am Last edited: 12 April 2009 10:53am
@ UncleCheese I really can't say as I have been unable to reproduce the problem myself. But I did post a theory a few posts back. Do you have your DataObject sortable? That forces the ID into the DB and I believe solves any issues the others are mentioning. See my previous post here:
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.
| 54322 Views | ||
| Go to Top | Next > |
