On Dec 7, 5:28 pm, Matteo Landi <[email protected]> wrote:
> > your definition of validate appears to differ from the frameworks. The
> > conclusion I was leading you towards was to always start with the code
> > bake gives you - and you are not.
>
> You are right, in the previous sentence with ``validate'' I meant I
> needed to make sure that given id points to a record of the database.
> I have not taken into account the possibility of using bake because
> I'm working on a REST application which has nothing to do with forms
> of flash messages, so I decided to create each controller from
> scratch; however I could give it a try and see how generated
> controllers look like.
Generally speaking controller code doesn't change whatever the means
of rendering results are. If it's purely for json/xml/whatever
consumption the only difference is likely to be no flash messages and
changing redirects to rendering confirmation messages/exceptions.
>
>
>
> >> I think
> >> I will put that logic inside the beforeSave callback in order to keep
> >> controllers as simple as possible.
>
> > Doing that doesn't make any sense, you're planning to put something in
> > a model that doesn't belong there.
>
> The only problem I see with what I proposed before, is that it would
> be not easy at all to distinguish between save operations trying to
> create a new record, and edit operations trying to edit an existing
> one; probably a new Model->update method would fix that: add
> controllers would invoke save to create a new object, while edit
> controllers would call the update method (which would fail if there is
> no record with given id). Do you think this solution is breaking the
> MVC paradigm?
Kind of depends.
if you wanted to explicitly create update and insert functions in your
models, or app model, which simply called save as appropriate (insert
prevented the id being set, update ensures it is and it exists),
that's ok I guess.
If your beforeValidate or beforeSave function runs if ($this->id && !
$this->exists()) { return false; } what that does is prevent creating
rows with a specific id. If all your tables are autoincrement you
won't find anything wrong with that, but as a one-size-fits-all
solution thats a bad idea - creating rows with a specific id is a
common use case.
However, I don't consider "does this row exist" data validation. it's
something the app controls. Just as "can user x edit this row" that's
not data validation either - it's something the app controls. trying
to edit something that doesn't exist is not a validation error - it
should be treated differently. Like $this->setFlash('Naughty naughty,
that dosen't exist and we're logging what you're doing"); $this-
>redirect('/terms+conditions');
All in all starting with baked code (putting if (!$this->Post-
>exists($id)) { throw new NotFoundException(); } in a controller edit
action) means you start with consistent functioning code, it is 100%
applicable whatever db scheme you've got, it'll work almost without
editing whatever type of app you're building and puts the logic check
in the right place IMO.
AD
--
Our newest site for the community: CakePHP Video Tutorials
http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others
with their CakePHP related questions.
To unsubscribe from this group, send email to
[email protected] For more options, visit this group at
http://groups.google.com/group/cake-php
