Brilliant guys - many thanks for your input. I'll remember to put the link to the file in future (should have thought of that).
As I don't know what cascading deletes/updates are (!) I'm going to go with standard cake functionality and do everything in the model. would anyone recommend OthAuth over the standard cake ACL? I'll be baking some more samples this weekend (in between 6 Nations games) so will let you know how I get on. thanks again, lukemack. On 2 Feb, 09:09, "AD7six" <[EMAIL PROTECTED]> wrote: > 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 cake-php@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
