Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

We've moved the forum!

Please use forum.silverstripe.org for any new questions (announcement).
The forum archive will stick around, but will be read only.

You can also use our Slack channel or StackOverflow to ask for help.
Check out our community overview for more options to contribute.

Archive /

Our old forums are still available as a read-only archive.

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo

branches/2.0 merged into branches/gsoc


Go to End


13 Posts   3433 Views

Avatar
Sam

Administrator, 690 Posts

6 July 2007 at 3:50pm

Hi everyone,

The changes that the SilverStripe team have been doing over the past few
months have been merged into branches/gsoc.

http://trac.silverstripe.com/gsoc/changeset/38014

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.

http://trac.silverstripe.com/gsoc/changeset/38013

Avatar
Sigurd

Forum Moderator, 628 Posts

6 July 2007 at 4:20pm

Cheers Sam...

Avatar
Markus

Google Summer of Code Hacker, 152 Posts

6 July 2007 at 8:14pm

Edited: 06/07/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 :-)

Avatar
Markus

Google Summer of Code Hacker, 152 Posts

6 July 2007 at 9:04pm

@Sam:

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.

Avatar
Sam

Administrator, 690 Posts

8 July 2007 at 9:18pm

Edited: 08/07/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!

Avatar
Sam

Administrator, 690 Posts

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?

Avatar
Markus

Google Summer of Code Hacker, 152 Posts

9 July 2007 at 8:50pm

Edited: 09/07/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).

Avatar
Markus

Google Summer of Code Hacker, 152 Posts

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.

Go to Top