Thread

I have been using CakePHP and really do like it.  I had looked at CodeIgniter in the past and chose CakePHP, but recently have been asked to look into doing a site which alows the owner to manage the content.

I memory serves, CodeIgniter is similar to CakePHP in many ways (MVC).  I like that I can set up table associations and validation rules in my model etc…

I develop on the side for a design house.  They want to be able to manage several sites from one location (looks like EE can do this with an add on).  I like working with a framework which will do a lot of ‘Automagic’ for me and I get to write less code 😊.

In CakePHP, I would lay out my database using their conventions and create associations in the models so the joins just happen.  I would create my layout (the part of the view that is common to all pages - header, menu, footer etc.).

I am sure Code Igniter is similar.

I am not sure how all of this works with EE as opposed to Code Igniter.  Since it is a content management system, I assume some but not necessarily all pages can be edited in the back end, but I wonder if I still have complete control to make my own Models, Controllers and Views for other pages.  Things like custom registration forms, maybe pages that display a Google Map with a bunch of pins (pulling info from database to place them there).

I really want to recommend we use EE, but I want to be sure it allows me to do all the things I am accustomed to doing, while also allowing the content on certain pages to be edited using the admin tool.

Cake and CI are the same principle carried out differently. For example Cake makes things easy for you by connecting a lot of the dots and having things “on by default”. Whereas CI in simple terms for how i see it, assumes nothing and has things “off by default”. A recent article i read compared them for speed and CI won hands down on a simple hello world test - but as mentioned above, it would as with everything off compared to everything on, one is going to be faster than the other after a fresh install.

Moving on to EE. EE is a CMS re-built using CI. Therefore, you are buying EE as a CMS product, and have to adhere to their license rules. One of which means that the Multi Site Manager is only used for a single company entity. Basically this means if Joe Designs builds three sites for ABC construction - then this can use the multi site manager. If Joe Designs builds three sites for three separate clients (ABC, XYZ, 123) - then you cannot use multi site manager.
SO… from what i interpreted from above… this will not suit you.

Rolling your own code… In theory in EE, most of the time you would not create your own database and then script output, etc. You would build channels in the control panel, these channels would hold your fields (create the DB Table fields for you). These channels basically mean you never have to script and build databases - you just choose a field for date, file, text, etc.
If your wanting something really specialist, and channels don’t suit - then you can create your own modules for EE. These are coded as you would with CI, but are EE modules.
OR… you could create a completely separate application that sits alongside EE.

In short - CI is similar to Cake. I think your intended use of EE might fall foul of the licensing, and depending on your custom work needed you might want to create a full CI app, or an EE module, plugin, extension or accessory.

Hope that helps, others will correct me on some points i am sure! As these are just my experiences.

OK.  I am beginning to understand EE a bit better now.

I understand how the Multi Site Manager works now.  We would obviously not use that add on for our purposes.  I suppose we would just host EE for each site and each would have it’s own admin site where they can manage the content on some pages, and maybe not others.  I guess I need to explain to the designers that the control panel, while not a single address for all the sites, will still look and feel pretty much identical across the board.

I was not seeing anything in the documentation that resembled that which is in the CI documentation.  I guess I assumed that since it is CI, that under the hood it would be pretty much like working with CI.  I see the views look somewhat different (tags as opposed to inline php).

I think most of the projects we would use this for going forward would be from scratch, meaning we wouldn’t have an existing database.  I guess I have a bit of difficulty with their terminology.  From what I gather, channels are like tables or even views in a database?  How does it handle things like joining tables?  For instance, if I have a table for people who registered for an event, I would generally store CA or US in the country_id and use a join to look that display text up when I view their information.  How is this sort of thing handled in EE?

I have built a site where people register for a cycling event to raise money for a hospital.  On the main site I have riders, some of whom are on a team and some of whom are in families etc.. I have several tables for families, family_riders, teams, team_riders, riders and so on…. Is this the sort of thing I can expect to do with EE?

Sorry for all the questions, but some of the documentation seems like it is trying to make it simple to understand for non programmers maybe?  Or maybe it is just me 😊

Thanks for the assistance.

Hi, Conundrumb - welcome to the forums! It may be best for you to actually try out EE and look at how the database is structured.  Given your level of skill, that would likely give you the answers you’re seeking.

Depending on your needs - for instance, tracking teams of riders, that may be best as a custom add-on.  Or you could use a channel for that.  It really depends a lot on your project, workflow, and needs.  It’s not possible to go that in-depth in pre-sales, unfortunately. 

EE is geared at web designers that needs a flexible and powerful system to build sites for clients, but without programming knowledge.  EE is also a great application framework, built on CI, that gives you power to extend it to meet your needs.  Here is the development documentation, the rest of the user guide focuses on using ExpressionEngine’s feature-set.

Channels are collections of information.  You create custom fields that ultimately define the data-set.  But you could have a channel to store all the books in your library, for instance.  Or a channel that acts like an FAQ.  Or a channel that manages the items for your eCommerce store.  It’s really up to you.

Does that help?  Some of the learning resources listed on our community page might help you to jump in and get to grips with EE.

EDITed

The issue here is that you are approaching this from a programmers perspective and trying to understand it in pure code as opposed to a GUI.
You used to MVC basically data in a database, controllers to do the magic and views to show it all.
In EE the database is magic behind the scenes. Channels in EE are basically you creating your data entry forms (controllers) and they automagically create the database side of things for you (model). Views are templates.

So as an example in EE you create two channels:
1. Riders Channel
  name
  age
  sex
2. Teams Channel
  team name
  team photo, etc

The Channel holds the create and edit forms for those fields, and the database just happens. In the template you output the data from within one of those channels…

Now - you then mention joins to connect two entries in the database - i.e. put a rider in a team. In EE this is called relationships. There is default relationships within EE or as 99% of people do you get a Paid 3rd field type from “Pixel & Tonic” called “Playa”. Which basically makes the whole process of relating two (or more) entries in different channels easier (& prettier). In the template you then output the relevant Tags to display the related entries (or reverse relationships for the other way around).

So think of EE as this… a flexible CMS that lets designers create custom entry forms (channels) and display it without having to know PHP, MySQL, CI, etc…
In your case your advantage would be being a programmer that is able to create custom field types, special modules and extensions to make a designers life easier when using EE.

I am more of a designer than a programmer - but i know both sides. Often EE is quicker than building something custom, more flexible and some great extensions already exist (even if too many of these are paid). Whereas in other situations i get blocked by a CMS limitations and therefore think custom would be easier/cheaper…

EE will always say choose the right tool for the job… And often the right tool you know how to / are able to use!

Thanks very much for the replies and help.

The designer I work with wants to be able to always use the same solution so he knows that if I am not available another programmer could jump in I think.  I can certainly see his point.  I think it looks like EE would work for most of the things I do with him right out of the box, and in some cases where we want to do some more complex things, I can use add-ons like Playa (sounds pretty useful).  I like that there seem to be add ons for things like shopping cart systems and payment gateways (presumably I could extend that to support other payment gateways) etc… as this is something we want to do more of.

In instances where EE is the wrong tool, I could fall back to using CI or CakePHP.  I guess if I became more accustomed to CI by using EE, then I would shoose CI, but if working with EE is significantly different from working with CI then I would use CakePHP since I have become quite used to it.

Thanks again for your help.

I will dive into the developer documentation.

Very good. Please let us know if you have any more questions.