Re: Best Practice Question - Components
I would say that calculations, and verification of amounts would be perfect functionality to place on the model. You wouldn't normally need a controller to determine the sum of items in an order, so why put it in a controller. For a shopping cart, you still might use a model to store the cart contents and cart items. You might query the cart to see what the total value is. This is not a calculation that the controller would need to make, so you wouldn't need to do it in a component either. All business logic for an entity should stay with the entity, and the model is the perfect place for that. What you might put in the component is functionality to load a cart that is attached to the session, or clear the cart from the session, if the user requests it, or save cart modifications to the session at the end the controller lifecycle. Interesting to note, in CakePHP 3.0, the model will be split between an Entity and a Table. The Table will take care of the schema, and typical database/CRUD operations, while the Entity will concentrate more on the business logic side of things. Regards Reuben Helms On Thu, Nov 7, 2013 at 10:08 AM, Kristen M wrote: > Yeah, the point of the exercise is to do things the "Cake Way" and take > advantage of all things automagical and Cake. ;) > > After puzzling over the docs for a bit and realizing it's not bad form to > have a controller use multiple models, I decided that splitting the > existing classes into a model and a component was probably the "correct" > solution. The model handles all the data, while the component contains > common functions all controllers that use the model will need, like > calculations and verification of amounts. > > > > > -- > Like Us on FaceBook https://www.facebook.com/CakePHP > Find us on Twitter http://twitter.com/CakePHP > > --- > You received this message because you are subscribed to a topic in the > Google Groups "CakePHP" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/cake-php/M6i0tin0b5Q/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > cake-php+unsubscr...@googlegroups.com. > To post to this group, send email to cake-php@googlegroups.com. > Visit this group at http://groups.google.com/group/cake-php. > For more options, visit https://groups.google.com/groups/opt_out. > -- Like Us on FaceBook https://www.facebook.com/CakePHP Find us on Twitter http://twitter.com/CakePHP --- You received this message because you are subscribed to the Google Groups "CakePHP" group. To unsubscribe from this group and stop receiving emails from it, send an email to cake-php+unsubscr...@googlegroups.com. To post to this group, send email to cake-php@googlegroups.com. Visit this group at http://groups.google.com/group/cake-php. For more options, visit https://groups.google.com/groups/opt_out.
Re: Best Practice Question - Components
Yeah, the point of the exercise is to do things the "Cake Way" and take advantage of all things automagical and Cake. ;) After puzzling over the docs for a bit and realizing it's not bad form to have a controller use multiple models, I decided that splitting the existing classes into a model and a component was probably the "correct" solution. The model handles all the data, while the component contains common functions all controllers that use the model will need, like calculations and verification of amounts. -- Like Us on FaceBook https://www.facebook.com/CakePHP Find us on Twitter http://twitter.com/CakePHP --- You received this message because you are subscribed to the Google Groups "CakePHP" group. To unsubscribe from this group and stop receiving emails from it, send an email to cake-php+unsubscr...@googlegroups.com. To post to this group, send email to cake-php@googlegroups.com. Visit this group at http://groups.google.com/group/cake-php. For more options, visit https://groups.google.com/groups/opt_out.
Re: Best Practice Question - Components
If you have existing class that work, then you could include them as Vendor code, and have your controllers call their find and save functions. However, doing things the CakePHP way, you'll probably want to convert those classes to Models, rather than Components. Models are where your business logic and validation rules go. I used to think that anything required by more than one controller should go into a component, but I'm thinking that components are for things that need to plug into the controller lifecycle. On Wednesday, 6 November 2013 06:03:19 UTC+10, Kristen M wrote: > > I'm not a new programmer (I'd say advanced beginner/intermediate) but I'm > quite new to Cake and MVC in general. > > I've decided best way to learn CakePHP and MVC is to take an existing > (functional, live) project and port it to Cake for kicks. Get the grand > tour of all the basics. > > In my existing project I have a number of utility classes that are used by > the other classes. 2 of them are an Item class and a Banking class. Item > obviously contains all the information about a user's inventory, plus > handles updating/deducting items, as well as using items. Banking does just > that- tracks a user's currency and handles transactions. Banking is used > between the Shop systems, Item is used by Shop and various action classes. > So I need a way to share their functionality between all the various other > controllers that require them. > > Simple example would be the user wants to buy an item from the shop, have > to verify the item is in stock, the item's price, that the player has the > currency to pay for it, deliver the item, deduct the payment and deduct the > item from shop inventory. While a different Controller (say, Toll Bridge) > needs the Banking functions to verify the user has the funds to pay the > toll, then debit the transaction. > > It SOUNDS like what I need to do is to create Banking & Item Components, > then the other controllers can make use of them as needed. However, this > would also require including various queries to chat with the database. The > CakePHP example on Components only shows a simple math operation with > passed params, and says nothing about if using Components as little > "bundles" of functionality that involve their own validations and database > interactions (although this is strongly implied) There is some conversation > on the 'net that what actually needs to happen is Banking and Item should > be controllers, and they get imported as needed. > > What's the best way to go about this? > -- Like Us on FaceBook https://www.facebook.com/CakePHP Find us on Twitter http://twitter.com/CakePHP --- You received this message because you are subscribed to the Google Groups "CakePHP" group. To unsubscribe from this group and stop receiving emails from it, send an email to cake-php+unsubscr...@googlegroups.com. To post to this group, send email to cake-php@googlegroups.com. Visit this group at http://groups.google.com/group/cake-php. For more options, visit https://groups.google.com/groups/opt_out.
Best Practice Question - Components
I'm not a new programmer (I'd say advanced beginner/intermediate) but I'm quite new to Cake and MVC in general. I've decided best way to learn CakePHP and MVC is to take an existing (functional, live) project and port it to Cake for kicks. Get the grand tour of all the basics. In my existing project I have a number of utility classes that are used by the other classes. 2 of them are an Item class and a Banking class. Item obviously contains all the information about a user's inventory, plus handles updating/deducting items, as well as using items. Banking does just that- tracks a user's currency and handles transactions. Banking is used between the Shop systems, Item is used by Shop and various action classes. So I need a way to share their functionality between all the various other controllers that require them. Simple example would be the user wants to buy an item from the shop, have to verify the item is in stock, the item's price, that the player has the currency to pay for it, deliver the item, deduct the payment and deduct the item from shop inventory. While a different Controller (say, Toll Bridge) needs the Banking functions to verify the user has the funds to pay the toll, then debit the transaction. It SOUNDS like what I need to do is to create Banking & Item Components, then the other controllers can make use of them as needed. However, this would also require including various queries to chat with the database. The CakePHP example on Components only shows a simple math operation with passed params, and says nothing about if using Components as little "bundles" of functionality that involve their own validations and database interactions (although this is strongly implied) There is some conversation on the 'net that what actually needs to happen is Banking and Item should be controllers, and they get imported as needed. What's the best way to go about this? -- Like Us on FaceBook https://www.facebook.com/CakePHP Find us on Twitter http://twitter.com/CakePHP --- You received this message because you are subscribed to the Google Groups "CakePHP" group. To unsubscribe from this group and stop receiving emails from it, send an email to cake-php+unsubscr...@googlegroups.com. To post to this group, send email to cake-php@googlegroups.com. Visit this group at http://groups.google.com/group/cake-php. For more options, visit https://groups.google.com/groups/opt_out.
