I am in the same situation as glastoveteran (I am a Cake noob as well). I am building a content management system which posts various types of content (articles, bulletins, press releases, etc.). They all have some common characteristics, but also differ greatly. This is a typical is-a relationship. It would be tempted to create separate models for each item without a common base table, except I have one special condition.
** All content items must be able to have one or more tags associated with them. My thought is to create a tags table, and then a common base table for all content types. I could then use as associative table to hold content id, tag id pairs. How would I do this in cake without throwing out all of the built-in model functionality that cake offers. For example, when I create, delete, or edit a new article, how do get the base model and the article model to work together? How about when I add tags to my article, how do I get the Article model to pull from the associative table I've created? Am I thinking about this in the wrong way, or am I on the right track? Thank you for any advice anyone has to offer. On Feb 15, 11:37 am, Adam Royle <[EMAIL PROTECTED]> wrote: > To keep it simple with cake I have separate tables & models, but if I > need to share functionality between models, I use a behaviour. > > What you're saying about using a custom base class for your models/ > behaviours works well also. > > Ultimately it depends on your data. eg. in my scenario I was going to > have a generic "media" table, which would hold videos, images, > documents (pdfs), etc, but I eventually moved each type into its own > tables, which made much more sense and a heck of a lot easier to > manage. I created a generic FileBehaviour which handles the handling > of files in general. Then as necessary I created an ImageBehaviour > extends FileBehaviour, which added code to deal with images, etc. > > Hope that helps. > > Cheers, > Adam > > On Feb 16, 12:08 am, glastoveteran <[EMAIL PROTECTED]> wrote: > > > Hi all, > > > I'm building a content managed site with several slightly different > > types of record, but all of which feature a common set of fields e.g. > > title, summary, description, start_date, end_date, notes, etc. Some > > types of record have one or two extra fields, e.g. location, price, > > etc. > > > I've always wondered what's the best way of approaching this with > > cake, or indeed any framework? To have a single database table, > > model, controller etc with a field and logic indicating the record > > type? Or to implement each record type with a different table, model, > > controller etc? > > > I guess the first option of one model involves less repetition, but > > how would you handle different record types having a slightly > > different validation rules based on the fact that sopme have extra > > fields that need to be validated? Presumably you'd need to use a > > model beforeValidate() function instead of the standard validation > > array? > > > The second option would seem to follow the MVC convention a little > > better and validation would be easier but seems to have more > > repetition. > > > Looking at this in an object oriented way with classes you would I > > guess define a base class with the common characteristics and then > > extend / specialise this for other models. How does that work with > > cake? > > > Thanks all, > > > Alex --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
