-1(00) If you wan't to extend a widget, just extend it and configure it in your form. In my opinion this adds a lot of extra files for functionality that will not be used a lot...
On Aug 27, 2:24 am, Kris Wallsmith <kris.wallsm...@symfony- project.com> wrote: > Hi guys, > > I think the correct approach here is to create a custom form generator, > right? We won't be creating all these base classes in the core. > > Unless I'm not understanding correctly? > > Thanks, > Kris > > -- > > Kris Wallsmith | Release Manager > [email protected] > Portland, Oregon USA > > http://twitter.com/kriswallsmith > > On Aug 26, 2010, at 2:13 PM, Gustavo Adrian wrote: > > > > > +1. Nice idea. > > > On Thu, Aug 26, 2010 at 6:06 PM, Daniel Lohse > > <[email protected]> wrote: > > +1 > > > Kris is probably the right person to ask? > > > Cheers, Daniel > > > Sent from my iPhone4 > > > On Aug 26, 2010, at 9:11 PM, Tom Boutell <[email protected]> wrote: > > > > Shouldn't these have Base classes so we can override at project level > > > and have that automatically respected by doctrine and propel forms? > > > > That is: > > > > sfWidgetFormInputText -> BasesfWidgetFormInputText, with > > > sfWidgetFormInputText an empty wrapper extending that > > > > Then if you define sfWidgetFormInputText at the project level, also > > > subclassing the Base class but also adding functionality, that wins. > > > Just like BaseForm. > > > > Makes it drastically easier to enhance the widgets especially those > > > that don't have any outer wrapper element to hang your CSS and JS on > > > (time and date especially). > > > > Also you can choose to extend some other subclass that's in a plugin, > > > so it's easy to reuse other people's enhancements to the stock > > > widgets. > > > > The base classes can autoload, so no need for crazy require statements. > > > > Should be a backwards compatible change. > > > > This compares favorably with the complexity of configuring the > > > doctrine factories to use different widgets, plus that wouldn't help > > > with any instances not created by Doctrine. > > > > -- > > > Tom Boutell > > > P'unk Avenue > > > 215 755 1330 > > > punkave.com > > > window.punkave.com > > > > -- > > > If you want to report a vulnerability issue on symfony, please send it to > > > security at symfony-project.com > > > > You received this message because you are subscribed to the Google > > > Groups "symfony developers" group. > > > To post to this group, send email to [email protected] > > > To unsubscribe from this group, send email to > > > [email protected] > > > For more options, visit this group at > > >http://groups.google.com/group/symfony-devs?hl=en > > > -- > > If you want to report a vulnerability issue on symfony, please send it to > > security at symfony-project.com > > > You received this message because you are subscribed to the Google > > Groups "symfony developers" group. > > To post to this group, send email to [email protected] > > To unsubscribe from this group, send email to > > [email protected] > > For more options, visit this group at > >http://groups.google.com/group/symfony-devs?hl=en > > > -- > > If you want to report a vulnerability issue on symfony, please send it to > > security at symfony-project.com > > > You received this message because you are subscribed to the Google > > Groups "symfony developers" group. > > To post to this group, send email to [email protected] > > To unsubscribe from this group, send email to > > [email protected] > > For more options, visit this group at > >http://groups.google.com/group/symfony-devs?hl=en -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
