Jump to:

17452 Posts in 4473 Topics by 1971 members

Archive

SilverStripe Forums » Archive » branches/2.0 merged into branches/gsoc

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

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

Page: 1 2
Go to End
Author Topic: 2391 Views
  • Sam
    Avatar
    Administrator
    679 Posts

    branches/2.0 merged into branches/gsoc Link to this post

    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

  • Sigurd
    Avatar
    Forum Moderator
    628 Posts

    Re: branches/2.0 merged into branches/gsoc Link to this post

    Cheers Sam...

  • Markus
    Avatar
    Google Summer of Code Hacker
    152 Posts

    Re: branches/2.0 merged into branches/gsoc Link to this post

    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

  • Markus
    Avatar
    Google Summer of Code Hacker
    152 Posts

    Re: branches/2.0 merged into branches/gsoc Link to this post

    @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.

  • Sam
    Avatar
    Administrator
    679 Posts

    Re: branches/2.0 merged into branches/gsoc Link to this post

    "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!

  • Sam
    Avatar
    Administrator
    679 Posts

    Re: branches/2.0 merged into branches/gsoc Link to this post

    "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?

  • Markus
    Avatar
    Google Summer of Code Hacker
    152 Posts

    Re: branches/2.0 merged into branches/gsoc Link to this post

    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).

  • Markus
    Avatar
    Google Summer of Code Hacker
    152 Posts

    Re: branches/2.0 merged into branches/gsoc Link to this post

    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.

    2391 Views
Page: 1 2
Go to Top

Want to know more about the company that brought you SilverStripe? Then check out SilverStripe.com

Comments on this website? Please give feedback.