How To Organize Login Forms In A Website With Different User Accounts?
I am developing a plain simple website using laravel 5 with different user accounts organized as follows:
Student and Admin inherit from User.
sample users table
- is_active /* Only needed when admin is deleted. Every student will definitely be active (1) */
sample students table
- Contain some more unique fields for student
I could have thousands of students but just a few admins. Currently, my approach is to have a login box on the home page where both users can login and depending on the user type, display the appropriate profile page. Are they any risks to this approach or is they some better way to tackle this?
- Students register and apply for internship
- Admin can do the following:
- Manage comments on website (publish, delete etc)
- Manage FAQ (Create questions and answers)
- Add another admin user
Well, you could go this way, i guess it's a matter of preference. I would use a different model.
On models: I like DDD (domain driven design) and event storming to get insight into the domain I'm solving a problem for. On DDD:
In order to create good software, you have to know what that software is all about. You cannot create a banking software system unless you have a good understanding of what banking is all about, one must understand the domain of banking.
From: Domain Driven Design by Eric Evans.
Event storming is a workshop format for quickly exploring complex business domains.
I don't know much about your domain, so my answer is based on many assumptions. Nevertheless, it might come in helpful to you.
In this case, I guess I would separate all three concepts (
User). Even though they might share some properties, in the real world they are involved in different domains. Ignore that fact and your code will soon cover annoying edge cases and contain unnecessary complexity.
So, two different classes for
Student. Both have a
User. In my case, that would result in three different tables aswell. It might be possible that a
Admin aswell (to ease administration, to filter overviews, and so on), but I'm just plainly guessing there.
In all three contexts, I would make use of immurable value objects, not just for code completion, but more importantly for encapsulating data, validation and exposing related behavior.
User logs in, and after successful validation is redirected to the view for either a
Student or an
Admin. You'll notice that separating these domains will be a huge advantage when your application grows and becomes more complex. You could consider having a separate administration backend on a different domain, but for now I'd say that it would only introduce complexity, and hardly any value.
Maybe it's valuable to model what one is allowed to do in your system with privileges. As in: an
Admin is allowed to do anything, a
Student has one or more
Privileges. This would create a flexible system in which some students can help with the administration. For example: maybe some students are in lead of some random study groups and need to be able to access study group administration. It might not be necessary now, so make sure your code is future friendly.
In any case: don't choose the newest acronym, always choose what best fits your domain (or context, or application).
- → "failed to open stream" error when executing "migrate:make"
- → October CMS Plugin Routes.php not registering
- → OctoberCMS Migrate Table
- → OctoberCMS Rain User plugin not working or redirecting
- → October CMS Custom Mail Layout
- → October CMS - How to correctly route
- → October CMS create a multi select Form field
- → October CMS - Conditionally Load a Different Page
- → How to disable assets combining on development in OctoberCMS
- → October CMS - Radio Button Ajax Click Twice in a Row Causes Content to disappear
- → OctoberCms component: How to display all ID(items) instead of sorting only one ID?
- → In OctoberCMS how do you find the hint path?
- → How to register middlewares in OctoberCMS plugin?