Pyle

Mailables ​

Overview ​

Pyle framework mailables extend CBOX\Framework\Mail\BaseMail, which keeps Laravel's Mailable behavior and adds registry-backed override helpers. Applications can override framework mailables when they need app-specific subjects, views, attachments, queue settings, or build logic.

Framework mail overrides must preserve Laravel mailable behavior. Keep queues, serialization, attachments, envelopes, markdown views, and constructor payloads compatible with the framework mailable being replaced.

Registering an Override ​

Register mail overrides in config/pyle.php under pyle.overrides.mails:

php
return [
    'overrides' => [
        'mails' => [
            \CBOX\Framework\Mail\ForCustomer\OrderConfirmationEmail::class => \App\Mail\ForCustomer\OrderConfirmationEmail::class,
        ],
    ],
];

The application mailable must extend the framework mailable it replaces:

php
<?php

namespace App\Mail\ForCustomer;

use CBOX\Framework\Mail\ForCustomer\OrderConfirmationEmail as FrameworkOrderConfirmationEmail;

class OrderConfirmationEmail extends FrameworkOrderConfirmationEmail
{
    public function build()
    {
        return parent::build()
            ->subject(__('Your order is confirmed'));
    }
}

Mail overrides are resolved through pyle.overrides.mails and the mail registry. Generated mail bindings are no longer read.

Creating Framework Mailables ​

Use the framework mailable class and let the registry resolve the active application override:

php
use CBOX\Framework\Mail\ForCustomer\OrderConfirmationEmail;
use Illuminate\Support\Facades\Mail;

Mail::to($order->email)->queue(OrderConfirmationEmail::make($order, $locale));

Laravel's container also resolves the active override:

php
$mail = app(OrderConfirmationEmail::class, [
    'order' => $order,
    'locale' => $locale,
]);

The registry maps framework constructor parameters into the override constructor before Laravel resolves any extra dependencies. If an override renames framework parameters, keep compatible types so positional calls such as OrderConfirmationEmail::make($order, $locale) still map safely.

Class Strings ​

Most code should not need a mail class string. Use resolvedClass() only when Laravel or a package API specifically requires one:

php
$mailClass = OrderConfirmationEmail::resolvedClass();

Compatibility Helper ​

CBOX::mail(...) remains as a deprecated compatibility helper backed by the mail registry only. New code should not use generated mail bindings, CBOX::mail(...), or direct new FrameworkMail(...) construction. Use FrameworkMail::make(...) or app(FrameworkMail::class, [...]) instead.