6

I am about to extend my site quite extensively. At the moment I have a new channel and a walks channel (I list dog walks!)

I am opening up to creating a directory of dog services and amenities, hotels etc and was wondering what the best way to do this would be.

So far I will be offering listing for several different types of businesses, but although some of them will share certain types of data (i.e. name of business, address, contact details etc, there will be quite a few differences as well.

I was wondering what would generally be considered best practise.

For example,

Option one I have channels for: Dog Walkers - this will include name, address, telephone, rates, logo, and description fields. Dog Friendly Hotels - this will include name, address, telephone, logo, website link, gallery amenities and description fields. Pet Shop - this will include name, address, logo, and opening times fields.

Option two I create a single channel that includes all the above fields and they are just shown/not shown based on what type of business it is (defined by business type within the category)

My feeling is that its logical to break it down into seperate channels, however I do not really want to do this if its likely to have an adverse affect on performance.

I hope this question makes sense! Any thoughts, pros/cons appreciated.

**forgot to add that these entries will be added via a safecracker form, and not through the admin cp.

Improve this question
1
  • I'm going to go with separate Channels AND separate field groups (relevant to each channel). I think this will just be more logical, and will aid in more suitable server side validation of the fields. Thanks for the input!
    – shorn
    Commented Jan 9, 2013 at 12:56

2 Answers 2

Reset to default
6

If when you say "performance" you mean system performance the n it would probably be moot - as no matter what combination of channels and fields you put into EE at the EE database level you are just extending the same tables. In other words one EE channel does not equal one EE/MySQL table.

But by performance you could also mean Content Manager performance. If splitting it up makes the task of entering/managing the different content types more efficient then I'd worry about that more than system performance.

Then there is developer performance. If you have some field overlap across channels for the basics like address etc then one field group might save some setup time but cost you implementation time as you sort out the different validation and display requirements.

All in all I still prefer to split up different content types into their own channels and fields - it's how EE really "wants to work" and I'd rather play to the expectations of the CMS than work slightly at odds with them (in the form of one big field group etc).

Improve this answer
1
  • Thank you for your input. If system performance is not affected then that's great. I think i'm going to sit down and jot down all field/channel possibilities. This should give me a better idea of what channels will share the same fields, what is essential for validation, and I will probably then decide whether a full split is better or not. I am starting to feel that each content would be better separated into its own channel and field group. I think this will allow mean much easier validation and be more flexible should each content type evolve at all.
    – shorn
    Commented Jan 7, 2013 at 19:06
4

Personally, I would put those into their own channels.

You could certainly have 1 field group between 2 channels and then customise the form on the basis of what you need for that channel.

But I would recommend 1 channel for 1 field group.

Improve this answer
4
  • I'd second this approach. Further down the line, when the site expands or you need particular function in a particular area having content separated will make achieving it simpler.
    – stuartmcd69
    Commented Jan 6, 2013 at 22:50
  • That's great, and glad to hear I'm not alone in my thoughts of what might work best. I think it will also work out better in terms of implementing search functionality, as I'm using low search and I can make each channel its own search collection. Steven - in terms of "one field group" do you mean one field group (used in all the channels) that contains all the fields, and then only show the fields required in the safecracker/entry page?
    – shorn
    Commented Jan 7, 2013 at 0:24
  • yeah that's right, basically 1 big field group with every possible field you need. The downside to this though would be that required fields become a real pain and you could only really do JS validation for required fields.
    – Steven Grant
    Commented Jan 7, 2013 at 0:44
  • I understand. I guess server side validation might prove tricky. Hopefully there will be a standard set of fields that can be required. Any additional non-essential validation I could do via client side, but hopefully the core fields will still set if theres any js problems. Sounds good. Thanks for your input!
    – shorn
    Commented Jan 7, 2013 at 0:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.