views:

40

answers:

2

I'm developing a CakePHP application that we will provide as a white label for people to implement for their own companies, and they'll need to have certain customization capabilities for themselves.

For starters, they'll be able to do anything they want with the views, and they can add their own Controllers/Models if they need to add completely new stuff. However, I'd rather advise against touching my controllers and models, to make version upgrading easier.

Esentially, the customization capabilities I'm planning to give them are going to be quite basic, I just need to call "something" when certain things happen, so they can do things like update external systems, e-mail themselves/the clients, things like that.

I'm wondering what's the best way to do this?

My plan is to have a "file" (with one class) for each controller of mine, to keep things reasonably organized. This file will have a bunch of empty methods that my code will call, and they'll be able to add code inside those methods to do whatever they need to do.

The specific question is, should this class full of empty methods be a Component? A Controller? Just a regular plain PHP class?

I'll need to call methods in this class from my Controllers, so I'm guessing making it a Controller is out of the question (unless maybe it's a controller that inherits from mine? or mine inherits from theirs, probably). Also, I'd need the implementer of these methods to have access to my Models and Components, although I'm ok with making them use App::Import, I don't need to have the magic $this->ModelName members set.

Also, does this file I create (etiher Component or Controller) have to live in the app folder next to the other (my) controllers/components? Or can I throw it somewhere separate like the vendors folder?

Have you done something like this before?
Any tips/advice/pitfalls to avoid will be more than welcome.

I know this is kind of subjective, I'm looking to hear from your experience mostly, if you've done this before.

Thanks!

+1  A: 

Two ideas that spring to mind:

  • create abstract templates (controllers, models, whatever necessary) that your clients can extend
  • write your controllers/components/models as a plugin within their own namespace

Ultimately you seem to want to provide an "enhanced" Cake framework, that your clients still have to write their own Cake code in (I don't know how this goes together with your idea of "basic customization capabilities" though). As such, you should write your code in as much an "optional" manner as possible (namespaced plugins, components, AppModel enhancements, extra libs) and provide documentation on how to use these to help your clients speed up their work.

deceze
Thank you very much for your answer. The abstract controllers idea sounds interesting, I need to look further into it to make sure CakePHP won't choke on it.
Daniel Magliola
As for your other mention, I'm most definitely not extending CakePHP and then have my clients write their own code. I'm going to give them a fully functional application out of the box, but I know some of them will want to do some stuff when some things happen. Examples are things like updating an external CRM when an account gets created/modified, e-mailing people when certain things happen, stuff like that. It's not major modifications of the way the system works, it's just some hooks so they can do simple custom stuff that they may need.
Daniel Magliola
@Daniel You just kinda made it sound like you would... :) `abstract` classes work perfectly fine in Cake (it's all just PHP), I used them myself on occasion. You could also just provide empty classes with methods that get called on certain events that your clients can fill with code if needed. It really depends on the circumstances what the best method is.
deceze
Empty classes with methods: That's EXACTLY my idea, what I'm asking is "what those classes" should be (Components, Controllers, etc) so that, in those methods, they can use my Models/Components/etc. It looks like instead of having what I now have as "AccountsController", I'll have a "AccountsControllerBase", with the actual code, and the "AccountsController" will have the empty methods. That's what you're proposing, correct?
Daniel Magliola
@Daniel Well, that depends on how close you want to stick to Cake's structure and how your clients will feel about that. Remember, it's all just PHP, you don't have to use *controllers* or *models*. You could make a new class `EventHooks` in the `/lib` directory and call methods in it, passing relevant models or components as function parameters.
deceze
Passing the instanced models, interesting, I like that. Ok, i'll look into all this and experiment a bit. Thank you VERY much for your help!!!
Daniel Magliola
+1  A: 

I would setup a common set of events and use something like the linked to event system to handle this.

That lets the clients manage the event handler classes (read the readme to see what I mean) and subscribe to and broadcast events application-wide.

Also - if you want to have your users not muck about with your core functionality I recommend you package your main app as a plugin.

http://github.com/m3nt0r/eventful-cakephp

Abba Bryant
That events system sounds VERY interesting! I'll look more into it, it seems less destructive to my code than the abstract class idea, provided it gives me all the flexibility I need, I'll have to experiment. As for packaging, I'm going to be encoding most of my code with ionCube, or something like that. I know it's not perfect, but it lets me very clearly draw boundaries. If it's encoded, you're not supposed to touch it. Thank you!!
Daniel Magliola
Any update on whether or not this worked for you?
Abba Bryant