The changes that the SilverStripe team have been doing over the past few
months have been merged into branches/gsoc.
Markus: This includes the decorator role stuff that you need. Also note that I had to rename the XML.php file in Yadis - this was a situation that had the potential to mess up the manifest builder that is now explicitly checked for and warned against.
"I changed the name of add_extension to addExtension (to have consistent method names) and added the addRole() method to member in r38052. "
Markus - can you please change this back!
a) lowercase_with_underscores is our convention for static methods. It's not consistently applied for some historical stuff, but we're trying to set the standards going forward.
b) You're not the only person to use this code, you're not even the first. Your change will break other people's code, and so won't be able to be part of v2.1 when it comes to put the gsoc branch out as the "main version"
We can't just go around renaming the names of core functions!
I changed the name of DataObject::add_extension() previously because the only static method according to this style was NewsletterAdmin::template_path() and both the [url=http://doc.silverstripe.com/doku.php?id=coding-conventions&rev=1180033560&do=diff]coding-conventions site[/url] and the [url=http://doc.silverstripe.com/doku.php?id=member]member documentation site[/url] used addExtension().
Of course no one should change the name of core functions, but I really thought that this method isn't used yet (or at least only in the forum code).
Another point is that now there are at least 4 or 5 styles for methods which I think is quite confusing. It would be nice if someone could rewrite the coding conventions site so that it is up to date and then also really used for new code!
But no need for long discussions here, I reverted the change already. The method DataObject::addExtension() is now called again DataObject::add_extension() (r38129).
I think that calling ManifestBuilder::exclude() is not the best option since then one have to know already what to exclude before that code is added and the exclude() call can not really be embedded in the code to exclude.
> If we had an extra file, I would probably go for a more specific
> filename such as _manifest_exclude.php or something.
That's a good idea.
> Should it be a PHP file, or just some kind of text file format?
Why not just make a file _manifest_exclude which can also be a zero-byte file. There is no need for a specific file format since the file itself doesn't contains any information.