Cool. Thanks for that. There's a lot of new stuff coming down the pike. DOM 2.0 is well underway, and I'll be launching a blog soon that will document its progress with screenshots, etc. Lots of new stuff, and I'll be sure to roll this in.

Hi UncleCheese,
I have created a german translation for the ImageGallery module. Is there any standard way to submit this to you? I thought about posting it to the bug tracer or opening a new forum thread for it - do you have any preferences?

Speaking of translations:
1.) The german translation for the DataObjectManager Module does not work on my installation due to its filename - it works fine when the file in dataobject_manager/lang/ is renamed from deDe3.php to de_DE.php

2.) In the same translation there is an inconsistency: The translation for $lang['de_DE']['DataObjectManager']['DRAGDROP'] is different than the translation for $lang['de_DE']['CMSMain_left.ss']['ENABLEDRAGGING'].
In the short run this should be changed to 'Erlaube Neuordnen per Drag & Drop'.
In the long run perhaps it would be possible to change the DataObjectManager templates ([Data|FileData|ImageData|RelationData|RelationFileData]ObjectManager.ss) to use _t('CMSMAIN_left.ss.DRAGDROP',...) instead of _t('DataObjectManager.DRAGDROP',...).
In my opinion it would be even better to have a 'ENABLEDRAGGING' translation somewhere on a more global scope (CMSMain perhaps?) and refer this property in all other locations, since at the moment this same translation is in four different places: AssetAdmin_left.ss, CMSMain_left.ss, SecurityAdmin_left.ss and DataObjectManager.
This would of course introduce some cross dependencies in the translations, so this is not an option if the SilverStripe developers want to keep the translation files as independent as possible.

Hi UncleCheese

Great work on your modules! I've found them practically indispensable when developing sites with SilverStripe. I'm currently developing a module which uses the DataObjectManager and SWFUpload modules to create and manage categorized hCards for a site, and found that I needed a way to let the user know that a category could not be deleted (because it's tied to one or more hCards).

I found that if I patched dataobject_manager.js with the code below I can use the die() and echo functions in a onBeforeDelete() function in my class to notify the user that the item could not be deleted/was successfully deleted. I was wondering if you would be interested in including the patch in your module to make this a more permanent thing? I'd be happy to patch the file directly in the svn if I could have access. Anyway, here's the code:

The original code is found at two lines; 97 & 111 in /dataobject_manager/javascript/dataobject_manager.js

- ORIGINAL CODE - - - - - - - - - - - - - - - -
$.post($target.attr('href'),params,function() {$($target).parents('li:first').fadeOut();$(".ajax-loader").fadeOut("fast");});

- PATCHED CODE - - - - - - - - - - - - - - - - -
$.post($target.attr('href'),params,function($response) {
$type = 'unknown';
if($response != '') {
if($response.match(/^good:/i)) {
$type = 'good';
$response = $response.substring(5);
} else if($response.match(/^bad:/i)) {
$type = 'bad';
$response = $response.substring(4);
}
statusMessage($response,$type);
}
if($type != 'bad') {
$($target).parents('li:first').fadeOut();$(".ajax-loader").fadeOut("fast");
}
$div.fadeOut("fast");
});
- - - - - - - - - - - - - - - - - - - - - - - -

The messages can be prefixed with "good:" or "bad:" to display a success-style message or an error-style message.

Example:

class MyClass extends DataObject {
...
function onBeforeDelete()
{
// display error-style message
die("bad:Cannot delete this item");
parent::onBeforeDelete();
// display success-style message
echo "good:Item successfully deleted";
// display unstyled message
echo "This is a message";
}
}

Yeah, no doubt that functionality is extremely primitive -- assuming the user always has delete privs. However, returning "good" or bad" as a response is not exactly an elegant solution. Could you rewrite your patch using HTTPResponse codes instead? That way, you can take advantage of the "success" and "error" callbacks, which is a little cleaner than evaluating the contents of a text response, which will always trigger "success" no matter what its contents.

Keep in mind that 2.3 and 2.4 use different HTTPResponse objects. I think in 2.4 they renamed it SS_HTTPResponse.

Hi UncleCheese,

Here is something that I would find particularly useful - an option to show the related objects at the top of the list inside a ManyManyDOM by default. I imagine you would want it so that if a user then sorts by one of the columns this would revert to standard sorting.

What are your thoughts on that?

Cheers,
Howard

Hi UC,

It says in the docs that HasManyFileDataObjectManager & ManyManyFileDataObjectManager are coming soon. Both these would be awesome. A lot of my projects involve the picking of existing images from, say, the products section to be included in a homepage slideshow. A HasManyImageDOM would be perfect for this.

Thanks,
Tim

@UC: You are right, that sounds like a better solution. I've been looking through the code for SS_HTTPResponse, but I am not really sure about how to send the headers and interpret them in the javascript. Can you point me in a direction where to look?

I think it's just:

return new SS_HTTPResponse($code, $message);