Thanks for this module.

I would like to see support for farmville - I mean a simple way to use it standalone or as a substitute for model admin. That is not attached to a page.

Hi UncleCheese

I already own a SilverStripe Book, so you can exclude me from the competition.
Anyway... my top 3 wishes for the new DOM Release:
- Keep up the good work and awesome support!
- Add more comments to your code. This has several benefits: Automatic API Docs, Other users can figure out what's going on and eventually subclass the DOM for specialized needs... and all the other obvious advantages
- Bug-Tracking Software to report and track DOM bugs/issues/requests.

Best regards - Roman

Hey, guys, thanks! Here's what I can say so far..

- Validation for input

==> Coming very soon, as part of my jQueryValidator module. Won't be perfect, but will get the job done for the time being. The nice thing about this package is that it's super customizable, so any really specific validation needs will have the option of being handled, where as being locked into Silverstripe's own validation using the Behaviour class, our options are very limited, and customization is a PIA!

- Feedback hooks to the user (for example displaying a message in the case of a cascading delete)

==> Confirmed deletes are almost here. I'm struggling with the best way to implement i18n.

- Improve the re-usability of some parts (for example the modal windows can also be used for "normal" images in the rest of the website , inclusion of parts of a gallery in different pages etc. etc. ). This is , as Banal already states probably more of a documentation issue.

==> Frontend DOM has been on my mind for a long time. I'm not too keen on bundling up a lightbox module, however, because I think that the user should be able to choose and implement a lightbox of his/her choice. A frontend DOM as I see it right now, would be read-only.

- Keep up the good work and awesome support!

==> That's a given!

- Add more comments to your code. This has several benefits: Automatic API Docs, Other users can figure out what's going on and eventually subclass the DOM for specialized needs... and all the other obvious advantages

==> #1 priority right now. DOM suffers from the "broken window" principle -- that is, in neighborhoods where there is one or many broken windows, people tend to just trash the place and treat their environment disrespectfully. Why bother keeping it nice? It's already crappy. Code must adhere to the same logic, and DOM has not been. I created it basically in a weekend, and never estimated how popular it would become, so any bug fixes and add-ons have been fire drill code sprints that are documented poorly, implement hacks, etc. Whenever I think about doing it "the right way", I figure, well, the rest of it sucks, so why bother? So, like I say.. #1 priority in refactoring the code.

- Bug-Tracking Software to report and track DOM bugs/issues/requests.

==> In the works. I'm not nuts about Google code so far, and I'm really daunted by the idea of changing SVN channels, but at the same time, I hate the idea of paying for bug tracking, too.

hello
first of all like to thank you for your great modules,those has helped me a lot.
regarding the features i would like to see virus checking on upload and validation of input...