On Mar 15, 2010, at 2:24 PM, Susan Lau wrote:
> hi,
>
>
> > Why not make the models responsible for data validation? I've never
> > understood the desire to require the use of form objects.
>
>
> at least from my point of view, I would never want to allow the model do the
> validation. just because of the simple fact, that I might have different
> validation criterias for different user-groups but still for the same model.
>
> very simple example: an editor can add HTML to a text-field, a simple user
> not.
again, that is the controller's responsibility, and to some extent, the view.
if you really want to, you could add model methods like
updateHonoringAcl($user, $request) and have the model know which fields are
editable by each access level.
i don't see how strewing validation across multiple forms is in any way an
improvement. instead of editing the data validators in one place, i have to
edit it in 3 or 4. if i add a new field to the db, i have to find all of the
forms that aren't supposed to include that field, and unset the widgets and
validators or risk silently erasing data. when i edit a form, i have to have
at least from 3 files open, all in different locations in the file tree, just
to figure out what in the world is supposed to happen.
>
> I do have anyway two form-classes for this fact (one might extend the other
> one), because the editor is using more fields for the same model too.
mixing presentation with validation is probably the most annoying part of sf
forms. i'm glad to see it go away in 2.0.
>
> just my2Cents
>
>
> PS: for the main-topic of that thread:
> usually we extend our form-classes by setting the form.labels with a i18
> identifier, which again, is translated in a language file:
>
> $widget_schema->setLabel('username', __('form.username', array(), 'sf_guard')
> );
>
>
> and the helper is already loaded in the app-configuration.class
> public function configure()
> {
> ProjectConfiguration::getActive()->loadHelpers(array('I18N','Url'));
> }
>
> --
> 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
--
Jacob Coby
--
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
