Architecture and Entities: The guts of rh_mexico (Part 2)
In Chapter 1 I promised we'd talk about code, so let's get to it.
When I started designing the rh_mexico module for Drupal, the first thing that became clear was that using standard Nodes was going to be structural suicide. I needed custom Content Entities.
Entities: Modeling real life
Instead of messy database tables, I created specific entities for everything that happens in the agency. No patches here, just solid classes:
RegistroAsistencia: The core. It doesn't just save the time; it saves the location, the device, and the "operational motive" (office, event, scouting).EventoScoutingandRetardo: Because being late isn't the same as being at a festival setting up speakers since 6 AM.Vacacion,DiaDescontado, andPermisoConGoce: All tied to user profiles so HR doesn't have to do Excel math like idiots.
Services: Where the black magic happens
Having entities is like having bricks, but the cement is Drupal's Services. Dependency Injection is beautiful when you have interconnected logic.
AsistenciaProcessor: This guy takes the punch in/out, validates if you're in the allowed geo-fence or if you're justifying your presence for an event.DeviceFingerprint: Because there's always that one dude who tries to clock in for his buddy. This service cross-references browser and device data to ensure you are who you say you are.RetardoManagerandBusinessDaysCalculator: They handle all the stupid math for Mexican business days, holidays, and tardiness tolerance thresholds. Zero human intervention.
Doing this natively in Drupal with Symfony underneath gives you stupid scalability. I can punch in 10,000 records a month and the database doesn't even sweat because everything is indexed and loaded using the Entity Type Manager.
In Chapter 3, we're going to talk about my favorite toy: How I connected all this software with the physical world using Raspberry Pi for WiFi auto check-in.
Stay sharp.