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.

Customising the CMS

add_extension woes...


Reply

2 Posts   2162 Views

Avatar
BLU42 Media

2 February 2009 at 7:37am Community Member, 71 Posts

I'm trying to put together a USDatetime Module for future release and am using a series of Extensions to get the job done. I've run into a bit of a problem that I'm hoping someone can shed some light on.

When trying to add an extension to DMYDateField (which is a child of CalendarDateField, which is a child of DateField - both of which have extensions), I'm only getting one confirmed extension ... the DateField extension. If I comment out the DateField extension, then it defaults to the CalendarDateField extension. It's looking like this:

class A {}
class B extends A {}
class C extends B {}

A::add_extension()   //   no problems
B::add_extension()   //   A extension only
C::add_extension()   //   A extension only

Any ideas on why this is defaulting to the top parent extension? Or better yet, how to implement this sort of behavior?

Thanks!
John

Avatar
Ingo

9 February 2009 at 7:53am Forum Moderator, 801 Posts

First of all, we're planning a rewrite of the formfield API for better localization support, see http://open.silverstripe.com/ticket/2931
Its good to have extensions like USDateTime as short-term fixes though.

I'm assuming you're calling Object::add_extension('A','<your-ext-name>') instead of A::add_extension()? Static classes (currently) don't know about their classname, hence the two arguments for the method.
The static handling in SilverStripe needs some polish, it might well be the cause of this error. An abbreviated code example which we can fire up and debug would be ideal (perhaps even a unit test class?).