Html Common2 Laravel Package

Technical Evaluation

Architecture Fit

• Legacy PHP Monoliths: Ideal for PEAR-based legacy systems (e.g., pre-2015 PHP applications) where HTML_Common2 is already embedded in workflows (e.g., HTML_QuickForm2). Fits server-side HTML generation use cases like:
  • Dynamic email templates.
  • Legacy CMS backends.
  • Enterprise intranet portals.
• Laravel Misalignment: Poor fit for modern Laravel due to:
  • No PSR-15 middleware or Laravel service container integration.
  • PHP5-era design (no support for PHP 8+ features like attributes, enums, or typed properties).
  • Tight coupling with PEAR (assumes PEAR’s autoloader, dependency injection, and event system).
• Component Role: Could serve as a low-level utility in a hybrid architecture where:
  • Legacy PEAR components are gradually replaced with Laravel equivalents.
  • A custom facade abstracts HTML_Common2 for backward compatibility.

Integration Feasibility

• Laravel Service Provider:
  • Requires manual binding to Laravel’s container (no native support).
  • Example:

    $this->app->bind('html.common', function () {
        return new \HTML_Common2();
    });
    

  • Challenge: PEAR’s autoloader conflicts with Composer; may need custom include_path or vendor patching.
• Blade Integration:
  • Not natively supported; would need:
    • Custom Blade directives (e.g., @commonAttributes).
    • Helper functions (e.g., htmlCommonAttributes()).
  • Example Directive:

    Blade::directive('commonAttr', function ($expr) {
        $common = app('html.common');
        return "<?php echo \$common->parseAttributes({$expr}); ?>";
    });
    

• Dependency Conflicts:
  • PEAR packages often pull in outdated dependencies (e.g., PEAR/PEAR core).
  • Risk: Breaks Laravel’s dependency resolution (e.g., composer.lock conflicts).
• Alternatives in Laravel:
  • Built-in: Illuminate\Support\HtmlString, Str::of(), or Blade components.
  • Third-party: spatie/laravel-html (modern, actively maintained).

Technical Risk

Key Questions

1. Business Justification:
   • Why not use Laravel’s built-in Html facade or spatie/laravel-html?
     • Does this package enable legacy PEAR form compatibility or unique HTML attribute logic?
2. Migration Strategy:
   • Is this a short-term bridge for a legacy system, or a long-term dependency?
   • What’s the deprecation plan for existing PEAR components?
3. Security Compliance:
   • Are there compliance requirements (e.g., PCI, HIPAA) that mandate avoiding abandoned libraries?
4. Performance Impact:
   • Will PEAR’s autoloader degrade Laravel’s startup time in a high-traffic app?
5. Team Skills:
   • Does the team have PEAR/PHP5 expertise, or will this introduce technical debt?
6. Alternatives Assessment:
   • Has symfony/dom or league/html been evaluated as a modern replacement?

Integration Approach

Stack Fit

• Target Environments:
  • Legacy Laravel (≤5.8): Possible with custom service providers and Blade hacks.
  • Modern Laravel (8+): Not recommended—use illuminate/html or spatie/laravel-html.
  • Non-Laravel PHP: Better suited for plain PHP or Symfony (with PEAR bridge).
• Anti-Patterns:
  • Avoid in:
    • APIs (this is for server-side HTML, not JSON).
    • SPAs (no JavaScript/TypeScript support).
    • New Laravel projects (use built-in tools instead).

Migration Path

1. Assessment:
   • Audit all HTML generation points (e.g., Blade templates, form builders, PDF-to-HTML).
   • Identify specific use cases where HTML_Common2 adds value (e.g., legacy PEAR form attributes).
2. Isolation:
   • Install via Composer:

     composer require pear/html_common2 --ignore-platform-req=php
     

   • Patch composer.json to avoid PEAR autoloader conflicts:

     "autoload": {
         "psr-4": {
             "App\\": "app/",
             "HTML\\": "vendor/pear/html_common2"
         }
     }
     

3. Laravel Wrapping:
   • Create a service provider to bind HTML_Common2:

     // app/Providers/HtmlCommonServiceProvider.php
     public function register()
     {
         $this->app->singleton('html.common', function () {
             return new \HTML_Common2();
         });
     }
     

   • Test with a custom helper:

     // app/Helpers/HtmlCommonHelper.php
     function commonAttributes(array $attrs): string
     {
         return app('html.common')->parseAttributes($attrs);
     }
     

4. Blade Integration (Optional):
   • Add a Blade directive for dynamic usage:

     // app/Providers/BladeServiceProvider.php
     Blade::directive('commonAttr', function ($expr) {
         return "<?php echo commonAttributes({$expr}); ?>";
     });
     

   • Usage:

     <div @commonAttr(['class' => 'btn', 'data-id' => 1])>
         Click me
     </div>
     

5. Deprecation:
   • Replace legacy PEAR calls (e.g., HTML_QuickForm2) with the new service.
   • Document the migration path for other teams.

Compatibility

Sequencing

1. Phase 1: Proof of Concept
   • Install pear/html_common2 in a test Laravel project.
   • Verify basic functionality (e.g., parseAttributes, setOption).
2. Phase 2: Service Provider
   • Bind HTML_Common2 to Laravel’s container.
   • Write unit tests for critical methods.
3. Phase 3: Blade Integration
   • Develop custom directives or helpers for Blade.
4. Phase 4: Legacy Replacement
   • Replace one PEAR-dependent component at a time (e.g., a form builder).
5. Phase 5: Deprecation
   • Phase out direct PEAR usage in favor of the new service.
   • Document the migration path for other teams.

Operational Impact

Maintenance

• Short-Term:
  • High effort to integrate and test.
  • Manual dependency management (no Laravel-first tooling).
• Long-Term:
  • **