Hi lukemack,

On Jan 31, 5:10 pm, "lukemack" <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I'm looking for some help regarding a new cake project. I'm new to
> cake but not to php and am planning on using it for a project I'm
> working on in the hope that it will allow me to develop it reasonably
> quickly.
>
> What I'm after is some advice. I have attached a database diagram with
> some notes to the cake google group which should you a good idea of
> what I am trying to achieve. My main concerns are:
>
> Do I need to worry about the relationships between tables in database
> design terms i.e. one-to-many etc. or do I take care of that in the
> Model/Controller?  Or does cake take care of that as long as I name my
> keys / foreign keys correctly?

You can if you want :). If you are careful with the restrictions it's
a good idea, means looking at the db alone you can understand the app.

Specifically: Were you meaning regarding cascading deletes/updates
etc? If you define the foreign keys with conditions you may find that
you have some problems, but only because of the order things (may)
happen. If you do define cascading deletes (for example) don't define
your cake hasMany relationships as dependent - i.e. do things once.
Generally pushing/keeping the logic in the db will be more efficient
but be aware that your app won't know what the db is doing, so no
beforeDelete, afterDelete stuff will get triggered etc.

>
> Does my ACL apply to users of the CMS i.e. staff entering data, or the
> end-users, or both?

The cake ACL component is completely abstract, so it can be used any
way you want. That said, probably: yes. You would have an ARO for each
entry in the user table unless you derive the ARO based on a
membership of a group (but as the diagram doesnt have groups I mention
this just for info). If you define ACLs for ARO 'groups' just put an
ARO for each user under the correct parent so they inherit the rights
you want them to have.

>
> Taking reviews as an example, how would i go about managing the
> relationship between the user and review controllers and ensuring that
> users can only edit their own reviews?

Normally ACL rules are not so well suited to such a rule. However on
my site ACLPart1 blog there is an AC component which permits you to
*automatically* check for owner_edit, owner_view, owner_delete etc.
ACL rights whenever an edit, view or delete etc. method is called. It
even takes care of slugged urls if you set it up so. The ACL admin
plugin on cakeforge doesn't have this functionality in the download
(yet).

So you would setup ACL rules such that the top most ARO group (or
whatever is appropriate) can app::review::owner_edit and with that
single rule any user can edit their own reviews. If you want to do
this you need to create the ACO for the owner_edit action manually
(via the acl admin plugin this means using the "quick create" form,
specifying the correct parent, typing the full ACO name and submitting
the form).

>
> Just ignore the incorrectly named keys in the diagram - DBDesigner
> added these automatically.
>
> Many thanks for any input. This post will only make sense if you can
> see the diagram!

Now we know where they go.

HTH,

AD7six
Please note:
The manual/bakery is a good place to start any quest for info.
You may get your answer quicker by asking on
the IRC Channel (you can access it with just a browser
here:http://irc.cakephp.org).


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cake 
PHP" 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/cake-php?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to