All event names across the entire framework and application share a global namespace, right? If so, should we add “Form” to these event names? preSetFormData, etc... k On Thursday, April 14, 2011 at 3:03 AM, Victor Berchet wrote: About the event names, > > Maybe we can use something like: > - onBeforeSetDate, > - onSetData, > - onAfterSetDate > > This naming scheme is quite usual for people writing js, see: > http://flowplayer.org/tools/documentation/scripting.html#events > > Cheers, > Victor > > On Apr 14, 10:56 am, Fabien Potencier <fabien.potenc...@symfony- > project.com> wrote: > > On 4/14/11 10:48 AM, Bernhard Schussek wrote: > > > > > 2011/4/14 Miha Vrhovnik<[email protected]>: > > > > it would be onXXXXXX for everything as all would be prefixed. > > > > > onPreSetData then? Sounds silly to me - both "on" and "pre" are > > > prefixes that indicate the timing of the event. > > > > > Doctrine2 uses the "pre" and "post" prefixes too, so I really want to > > > remain close to their naming (preUpdate, preQuery etc.) > > > > I think the current names make sense. on, pre, and post are good > > prefixes. It just happens that the form framework is the first one to > > need pre and post. > > > > > > be biased as I also use Delphi and all the vents are prefixed with on > > > > there > > > > so It'+s immediately clear that it's an event. > > > > > We _could_ change "filter" to "on", then we'd only have "pre", "on" > > > and "post" as prefixes. But my above concerns still apply here. > > > > filter should probably be removed as it's not really a filter anymore > > with the new event dispatcher implementation. > > > > Fabien > > > > > > > > > > > > > > > > > > If I go and blindly cast to integer then the non numeric only string > > > > will be > > > > 0, or if i have a string starting with digits + some characters and cast > > > > I'll get only the numeric part and in both cases it will validate. I can > > > > also check if it's numeric and then cast, but in this case I'm doing > > > > the job > > > > of validator. > > > > > Validator != cleanup. The validator only checks your data, it doesn't > > > touch it in any way. So yes, if you do a constraint as strict as > > > @assert:Type("integer"), you have to convert it yourself. > > > > > The only possible solution I'd see is to add a "data_type" option to > > > Form that lets you choose the desired output data type. In this case, > > > the Form would try to convert the value as is and indicate an error > > > otherwise. > > > > > Do we want this? > > > > > Bernhard > > -- > 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
