# Arquitectura de Vistas Base — Analisis y Definicion

> Fecha: 2026-03-31
> Contexto: Definir como deben funcionar las vistas welcome/about/contact
> para que el sistema sea escalable, mantenible y eventualmente self-service.

---

## El problema

Los 17 demos tienen welcome/about/contact con 2 patrones incompatibles:

```
PATRON A: "Config-driven" (accounting-2, insurance, construction...)
  ┌─────────────────────────────────────────┐
  │ Hero: config('site.welcome.hero_title')  │
  │ About: config('site.welcome.about_text') │
  │ CTA: config('site.welcome.cta_label')    │
  │ ... 10-55 keys por demo, todos distintos │
  └─────────────────────────────────────────┘
  Problema: cada demo inventa sus propios keys.
  accounting-2 tiene 55 keys, insurance tiene 9, construction 8.
  Solo 3 keys se comparten entre demos (4.6% overlap).

PATRON B: "Data-driven" (digital-agency-2, restaurant)
  ┌─────────────────────────────────────────┐
  │ Hero: config('site.name/tagline/desc')   │
  │ Secciones: $services, $featuredPosts...  │
  │ Headings: get_module_page_header_config()│
  │ 0 keys de site.welcome.* necesarios      │
  └─────────────────────────────────────────┘
  Ventaja: todo viene de datos existentes.
  No necesita keys custom. Funciona con cualquier demo.
```

## Datos del analisis

| Demo | Welcome keys propios | Patron |
|------|---------------------|--------|
| demo-accounting-2 | **55** | A (config-heavy) |
| demo-insurance | 9 | A (config-light) |
| demo-construction | 8 | A (config-light) |
| demo-digital-agency-2 | **0** | B (data-driven) |
| demo-restaurant | **0** | B (data-driven) |

**Overlap entre demos:** 3 keys de 65 totales = **4.6%**

---

## Definicion: El patron correcto es B (data-driven)

### Principio

Las vistas base NO deben depender de keys de config inventados por cada demo.
Deben construirse a partir de datos que YA EXISTEN en el sistema:

```
FUENTE DE DATOS            QUE ALIMENTA
─────────────────          ──────────────
site.name                  → Hero titulo
site.tagline               → Hero subtitulo
site.description           → Hero descripcion
site.assets.welcome_hero_image → Hero background

$services (DB)             → Seccion servicios
$featuredPosts (DB)        → Seccion blog
$featuredFaqs (DB)         → Seccion FAQs
$galleryImages (DB)        → Seccion galeria
$featuredProjects (DB)     → Seccion proyectos
$teamMembers (DB)          → Seccion equipo
$featuredReferences (DB)   → Seccion testimonios
$menuSections (DB)         → Seccion menu

get_module_page_header_config('services') → Titulo de seccion
is_module_active('services')              → Mostrar/ocultar seccion
```

### Que debe manejar el admin panel

**7 campos universales (site identity):**
1. `site.name` — Nombre del sitio
2. `site.tagline` — Tagline/slogan
3. `site.description` — Descripcion general
4. `site.assets.welcome_hero_image` — Imagen hero (upload)
5. `site.welcome.cta_label` — Texto del boton CTA principal
6. `site.about.main_title` — Titulo pagina about
7. `site.about.main_subtitle` — Subtitulo/descripcion about

**Titulos de secciones (ya existen via page_header_config):**
- `site.modules.services.page_header.title` — "Nuestros Servicios"
- `site.modules.blog.page_header.title` — "Blog"
- `site.modules.gallery.page_header.title` — "Galeria"
- etc.

**Todo el contenido de secciones viene de los modulos (DB):**
- Servicios → tabla `services`
- Blog → tabla `posts`
- FAQs → tabla `faqs`
- Galeria → tabla `gallery`
- Proyectos → tabla `projects`
- Equipo → tabla `team_members`
- Referencias → tabla `references`

### Que NO debe estar en config

- Textos de marketing especificos ("Invertir nunca fue tan facil")
- Stats/KPIs (deberian ser un modulo o tabla)
- Testimonios (ya existen en `references`)
- FAQs inline (ya existen en `faqs`)
- Skills/expertise (deberia ser parte del about o un modulo)

---

## Impacto en los demos

### Demos que ya siguen el patron B (no necesitan cambios):
- demo-digital-agency-2 ✓
- demo-restaurant ✓

### Demos que necesitan migracion de A → B:
- demo-accounting-2 → Reducir de 55 keys a ~7
- demo-insurance → Reducir de 9 keys a ~3
- demo-construction → Reducir de 8 keys a ~3
- Y los demas demos que usan keys custom

### Que significa migrar:
1. Los textos de marketing hardcoded → se reemplazan con `config('site.tagline')`, `config('site.description')`
2. Los headings de secciones → se reemplazan con `get_module_page_header_config()`
3. Los contenidos de secciones → vienen de las variables del controller ($services, $featuredPosts, etc.)
4. Si una seccion no tiene modulo correspondiente → se puede mantener con un config key generico pero compartido entre demos

---

## Implicaciones para el admin panel

### Lo que ya es editable desde admin:
- Modulos: services, blog, faqs, gallery, projects, team, references, menu, products
- Branding: logo, assets (BrandingController)
- General: site_name, description (GeneralController)
- Pages: meta tags (PageController)

### Lo que falta agregar:

**Prioridad 1: Identidad del sitio (admin/settings/identity)**
- site.name, site.tagline, site.description
- site.welcome.cta_label
- site.about.main_title, site.about.main_subtitle
- site.contact info (phone, email, address, hours)
- Social media URLs + active toggles

**Prioridad 2: Branding visual (admin/settings/branding)**
- Upload hero image
- Selector de colores (genera skin CSS on-the-fly)
- Selector de fonts (Google Fonts)

**Prioridad 3: Template selector (admin/settings/template)**
- Cambiar demo activo (requiere que todos los demos sigan patron B)
- Preview antes de aplicar

---

## Esto es CORE o no?

### ES CORE (dentro del sistema base):
- Los 7 campos universales de identidad → ya estan en la tabla settings
- El HomepageController que pasa datos → ya existe
- El patron B (data-driven) → ya funciona en 2 demos
- Los Blade components compartidos → ya creados (header-nav, footer-nav, etc.)
- get_module_page_header_config() → ya existe

### NO ES CORE (desarrollo adicional):
- Admin UI para editar los 7 campos → requiere vistas admin nuevas
- Color picker con generacion de skin CSS → requiere JS + backend
- Font selector → requiere UI + Google Fonts API
- Template selector → requiere UI + preview system
- Migracion de demos patron A → B → refactoring de vistas

### Orden de ejecucion recomendado:
1. **Migrar todos los demos a patron B** (eliminar keys custom, usar datos existentes)
2. **Expandir admin settings** con los 7 campos universales
3. **Color picker** con bewpro:skin integrado al admin
4. **Font selector**
5. **Template selector** (ultimo — requiere que todos los demos esten en patron B)

---

## Para CD (ahora):
Los datos se personalizan via provision JSON o tinker. No necesita admin UI.

## Para BewPro self-service (futuro):
El admin panel necesita los items 2-5 de arriba. Pero el paso 1 (migrar a patron B) es prerequisito y es trabajo de desarrollo, no de UI.