Injector config does not influence Object::create()

29 views
Skip to first unread message

Fred Condo

unread,
Jan 12, 2016, 2:54:18 PM1/12/16
to SilverStripe Core Development
Is there an architectural reason why Injector config as documented in the Injector docs does not update Object::$custom_classes? Is this intentional or a bug? As things stand, developers have to know whether the framework calls Object::create() vs Injector::inst()->create before they can know how to override a core class (Injector config/YAML vs Object::useCustomClass()).

For instance the configuration below does nothing, contradicting the Injector docs:

Injector:
  MemberLoginForm:
    class: MyMemberLoginForm

If this can be fixed, it ought; if it can't for some reason above my head, at least the documentation ought to be clarified. I've checked the 3.3 and master branches, and it looks like nothing related to this issue has changed.

Loz Calver

unread,
Jan 12, 2016, 3:32:22 PM1/12/16
to SilverStripe Core Development
Setting a class name like that certainly should work, regardless of whether you’re using Object::create() or Injector::inst()->create(). Object::create() internally uses Injector::inst()->createWithArgs() anyway, so there should be no difference.

I’ve just tested your YAML example above and it does work for me (3.2.0)

Marcus Nyeholt

unread,
Jan 12, 2016, 3:38:03 PM1/12/16
to silverst...@googlegroups.com

One thing to be aware of though is that using the standard

$obj = new Type();

syntax will not trigger injection

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

Fred Condo

unread,
Jan 13, 2016, 12:17:38 PM1/13/16
to SilverStripe Core Development
Hi Loz,

Given that it worked for you, I re-tested it in a pristine installation (of 3.1), and it works as documented. This issue arose in the context of a complex site with a lot of modules, so something else must be going on. Sorry for the list noise!
Reply all
Reply to author
Forward
0 new messages