17488 Posts in 4473 Topics by 1978 members
Page: 1 2
|Go to End||Next >|
6 July 2007 at 3:50pm
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.
Core Development Team
6 July 2007 at 4:20pm
6 July 2007 at 8:14pm Last edited: 6 July 2007 8:15pm
Is it really necessary to rename the XML.php file? Every change in a 3rd party library makes the update of it more difficult and leads to problem such as no one wants to update them anymore...
Would it not possible to let's say just include a _exclude.php (or whatever) file in a directory to prevent the manifest to traverse that directory and all subdirectories?
Another possibility would be to create a sapphire/3rd_party_libs directory which isn't included and the ini_set('include_path', $path) hack wouldn't be a hack anymore
6 July 2007 at 9:04pm
I changed the name of add_extension to addExtension (to have consistent method names) and added the addRole() method to member in r38052.
So now http://doc.silverstripe.com/doku.php?id=member#new_ideamember_role_decorator is implemented and the documentation page could be changed as soon as those changes are released.
8 July 2007 at 9:18pm Last edited: 8 July 2007 9:24pm
"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!
8 July 2007 at 9:23pm
"Is it really necessary to rename the XML.php file? Every change in a 3rd party library makes the update of it more difficult and leads to problem such as no one wants to update them anymore..."
Hmm... this is a good point. Currently we're using a _config.php in each module to decide which files get traversed.
One option would be to have a ManifestBuilder::exclude() call into the _config.php file, but they are getting quite cluttered.
If we had an extra file, I would probably go for a more specific filename such as _manifest_exclude.php or something.
Should it be a PHP file, or just some kind of text file format?
9 July 2007 at 8:50pm Last edited: 9 July 2007 8:51pm
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 coding-conventions site and the member documentation site 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).
9 July 2007 at 8:57pm
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.
Page: 1 2
|Go to Top||Next >|