There are different ways you could do that.
Firstly I would duplicate the module and call it (say) checkoutpdfpayment - that means changing all references to checkoutpdfdownload in code and filenames paying particular attention to case (pdfinvoice vs. PDFInvoice etc) - and verify that it works.
Secondly you need to decide whether you want to email the pdf, or simply make it available to the customer to download via a button (from an email). The latter is easier, in the sense of a smaller change.
You'd want to change the test for adminstatus at the top of PDFOut.inc so that others apart from admins (i.e. your customers) can download it. I'd suggest adding the two-factor authentication system that's used in the checkout Status Page (you need to include two long secrets in the url which can't be guessed).
Then you'd need to make sure a link to the pdf is included in the relevant emails - with the new security factors. You can see how this is done already for the status-page link in existing emails. That's in the main checkout module, but it would be a parallel task for your module. To make your module include something in the emails (in this case a link or button) have a look at how checkoutemail (the module) uses the CheckoutEmailInterface_1_0 to include the extra payments detail text when a customer uses this method. Be aware also that there are two meanings of checkoutemail here - checkoutemail the module is a payment method but CheckoutEmailInterface_1_0 is an interface for *any* checkout modules to include content in emails to customers, *not* just for the checkoutemail module. both checkout and checkoutemail have an implementation of CheckoutEmailInterface_1_0, as does checkoutdownload, that can include download links in emails etc.
Also you'd want to make a button to the pdf appear on the status page for an order. To see how to make this happen, look at CheckoutPDFInvoiceStatusPagePlugin.class line 47, saying:
if ($form['formName'] == 'AdminOrder') {
return array(null,'modules/checkoutpdfinvoice/templates/StatusPagePDFInvoice.tpl','modules_checkoutpdfinvoice');
}
That means that the pdf download button (in the relevant template) is only included in the AdminOrder page, not the Status page. If you remove the conditional and always return that result you get the pdf button on the order-status page too. So your new module should remove this conditional. Then the button will appear where you want it.
You could also test for the order status, and only display the button when the status is unpaid. Then as soon as you (manually) update the status as paid the button disappears.
If you really want to email the form as an attachment to one of the existing emails, I think you could do this too, but it's more complicated. In your implementation of the getEmailTemplateAndVariables(...) as part of the CheckoutEmailInterface_1_0 you are already returning the name of a template file which gets included in the email (that's what the interface is for) but now, your template file has a callback to a callback function in your module that builds the actual pdf (either as file on disc returning the filename) or as the contents of a php/smarty variable, which you then write out to the browser after a)encoding it and b) including the 'here's an attachment' headers in the email.
I hope that gives you some ideas,
-Alec
ps. in answer to your direct question,
Quote:
Do you have an example of such a call to checkoutpdfinvoice from another module?
- the answer is no. Checkout modules can *only* use functions from the main checkout module, not from each other. So your new module should build and send the pdf itself, not rely on any other module. That's easy though, if you start by duplicating (and renaming) the existing checkoutpdfinvoice module.