5121 Posts in 1527 Topics by 1119 members
|
Page:
1
|
Go to End | |
| Author | Topic: | 1971 Views |
-
add_extension woes...

2 February 2009 at 7:37am
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 onlyAny ideas on why this is defaulting to the top parent extension? Or better yet, how to implement this sort of behavior?
Thanks!
John -
Re: add_extension woes...

9 February 2009 at 7:53am
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?).
| 1971 Views | ||
|
Page:
1
|
Go to Top |


