Hi,

I noticed AssetManager is an extension of FileDataObjectManager.
FileDataObjectManager has this cool feature in the popup that redirects one to a form with some other datafields (that are in the dataobject associated with the file (like title, description or whatever you want).

I also noticed there are some attributes associated with the file in the file-class (namely name, title, filename, content and sort).
I assume that's more or less the same as the associated data in the dataobject.

However: the AssetManager doesn't redirect by default. Is there a way to accomplish this?

It would be cool, because it would stimulate the users to set some proper names and titles for the file, so they can be used as name and alt-text in the template.

Yeah, i know what you mean. It's two different models, and therefore two different workflows. Remember, FileDataObjectManager is for managing dataobjects that contain a file relation. It is not for managing files directly. AssetManager is for managing the files directly.

Most of the attributes of a File object are set automatically by Silverstripe. Personally, I don't see much value in viewing or editing those attributes. I enjoy the streamlined process of a quick upload and being done with it.

I think maybe in the next version, a feature to consider for AssetManager is to have two upload buttons -- "Upload and close" and "Upload and edit"

Or something.. we'd have to clean up the language a bit.

Thanks for you're reply. I already was afraid of that :(
Maybe you (or someone else) can help me think of another solution for my problem? I'll try to explain the situation to make things clear.

I'm working on a site for a small low budget non-profit/volunteer organisation. They have just a small internet-budget and very little storage space. However they want to be able to have different headerimages on different pages and these images have to have some copyright-notices in the alt-tag (mostly creative commons). And of course: as soon as they get tired of one, they want to be able to trade a headerimage for another.

So I thought of the following set of solutions:
1) It seemed to be wise to add the copyright-notice to the image-table with dataobjectdecorator (at least: copyright and image belong together and this way the image with the (c)-notice can be reused in other situations on the same site). So I tried to make it possible to edit this db-field from within the dataobject-popup in de DOM, but didn't succeed yet.

2) The next thing that seemed handy was that if the connection of a page to the dataobject (connecting to an image) is deleted, the image will be deleted (this saves serverspace). I'm sure some severe coding will make this possible, but it's way over my head.

3) As the dataobject is only used for the link between page and image, why not cut it short and go directly from page to image. However: the user should be forced to see the add-copyright-notice-popup, instead of going the somewhat longer way through the files&images-tab (I'm always preparing for lazy users).

As point 3 is not possible (yet), I'm back to the 1+2 combination. But as said: that's the option that's beyond my capabilities. So any help is appreciated.

What you're trying to do is pretty simple. Just create a dataobject to contain your file relationship and whatever other fields you want to use. Because there's no such thing as a true one-to-one in Silverstripe, it doesn't cascade deletes down the has_one components, because those components may be associated with other parents. If your business logic says that the relationship is a true one-to-one, then you can handle the delete in your onAfterDelete() method.

class SomeHolderPage extends Page
{
static $has_many = array ('FileObjects' => 'FileObject');
public function getCMSFields()
{
$f = parent::getCMSFields();
$f->addFieldToTab("Root.Content.Files", new FileDataObjectManager($this));
return $f;
}
}

class FileObject extends DataObject
{
static $db = array ('Description');
static $has_one = array (
'SomeHolderPage' => 'SomeHolderPage', 
'File' => 'File'
);
static $summary_fields = array ('Description' => 'Description');
public function getCMSFields()
{
return new FieldSet(
new TextareaField('Description'),
new FileIFrameField('File')
);
}
public function onBeforeWrite()
{
parent::onAfterDelete();
$this->File()->delete();
}
}

Thanks,
You're raising a good point: they should by no means reuse a headerimage in another place... that's something to discuss...
I'm not sure if they're willing to give up that funcionality.

So all I have to do right now is he first task (no 1): make it possible to edit the db-fields of the file-class in the page or dataobject-popup... It appears a little bit more difficult than I supposed at first. Right now I'm trying to extend the FileField-class, but that's not going that smoothly... Do you have any suggestions ?

The code I gave you didn't work?

nope :(

After I changed some minor parts in it, because of errors (SomeHolderPage: new FileDataObjectManager($this,'FileObjects','FileObject','File') and FileObject: static $db = array ('Description' => 'Text')), I got these alert-messages while trying to upload a file:

An error occurred in the upload. Try again later.

And after clicking OK:

There was a problem with the upload.
The server did not accept it.

It's probably just something screwy in your model somewhere. Might have forgotten a has_one in one of your classes or something like that. Just go through and check everything. The Flash uploader can't report PHP errors -- only HTTP, so unfortunately, you don't have much to go on when the code errors out. You can also try the debugging tips in the SWFUploadField documentation. It's a tedious process, but you'll find out what's wrong.