2

I'm still sort of new to CakePHP, and I've presently created and deployed one (rather complex) application using it. It has full user and group support and I took the time to get the access tables working and everything.

Now, I'm creating a separate application. I initially just created a brand new CakePHP installation, but I later realized that I wanted to authenticate users based on my first app. They currently use different data sources. I understand that there are a couple of ways this could be accomplished, with various pros and cons. Do I:

  1. Keep them separate, add a data source to my extension application, and port my user authentication code over?
  2. Keep them separate, process logins with the first application, and somehow share that data with the second using a communication protocol?
  3. Combine them into a single data source and accept the added complexity in my app?
  4. Something entirely different?

I'm using CakePHP to create both sites, which will be running on the same host/hostname, and connecting to the same MySQL server. Users are always stored/created on the main application, and just need to be passively accessed by the second app.

Blank
  • 7,088
  • 12
  • 49
  • 69
  • Can you give us a little more detail as to what each site is for, and why you think they should be separate. – Brandon Cordell Aug 31 '11 at 17:57
  • The sites store student data. There is a section of the site that is dedicated to registering students and allowing them to apply for one of our programs. This new site is for both students and faculty to use, and it's a global calendar of events. They're basically completely different functions except for the shared login credentials: the administrator for the program doesn't necessarily need to wade through the tables for appointments, which is why I want to separate them. But I don't suppose they technically need to be separate-- it would just expand an already complex codebase. – Blank Aug 31 '11 at 18:55

1 Answers1

-1

Honestly it sounds to me like you could bring them together with ease. Your reasons for keeping them separate sound to me like you could just keep them separate pieces of the one program.

For example the application I work on for a living does many of these things. Users can register, they also have access to a calendar of events, job postings, recent news, and about 25 other modules. They are just different parts of the program.

You could have one application that has a route like /users/register which the users controller takes care of registration. Then you can have another part of your application that routes to /calendar/.... where the calendar controller will take care of the calendar logic. If you need separate calendars for students and faculty you could have routes like /faculty/calendar/1 and /student/calendar/1 which would route to different parts of your calendar controller.

It's all about modularising your application, so that you can easily maintain code that is logically grouped together. You don't have to separate them so much so that they are two different applications.

I think you will avoid many headaches in the long run.

If it makes you feel better about my opinion the software I work on that I was talking about is an enterprise solution that deals with (literally) millions of documents per day, and hundreds of thousands of users per week on the government level.

Brandon Cordell
  • 1,308
  • 1
  • 9
  • 24