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
