That's no rush for this, so let's just find out the best option for 2.0 :)
Cristian
I
-- Cristian Bichis <contact@zftutorials.com> wrote (on Friday, 11 September 2009, 03:31 PM +0300):Thanks! How complicated is to chnage this into a derived class or something like that ? Any tips how to do it to avoid this design pattern ?It's not complicated at all -- override the filterName() method in your forms/elements/sub forms/display groups/etc, and either allow any value or provide a more lenient regular expression for filtering. While that part isn't complicated, the reason we can't just make this change at this time is because doing so breaks some of the overloading capabilities. For instance, right now, you can grab any element, sub form, or display group via property access: $element = $form->foo; $subform = $form->bar; $group = $form->baz; If we allow names other than valid PHP variable names, we can't offer overloading -- and that would be a BC break. At this point, I think it's worth doing, but it either needs to wait until 2.0, or we need to introduce an optional flag for "allow arbitrary names" that disables overloading.
-- Best regards, Cristian Bichis www.zftutorials.com | www.zfforums.com | www.zftalk.com | www.zflinks.com
没有评论:
发表评论