Generating a PDF from a FormIt submission

Development
,
1

I fear I may be out of my depth but the gist of the idea is:

A potential customer submits a form, the form is then saved with FormIt, the client then receives an email with a link like www.website.com/pdf-resource?h={hash} and when the page opens it is a PDF with all the values from the FormIt submission loaded in the right fields.

I saw PDFResource by Jako, but that seems to be about creating physical PDFs and saving them somewhere.

I have put together this much:

[[FormIt?
    &preHooks=`FormItLoadSavedForm`
    &savedFormHashKeyField=`h`
]]

[[+fi.partner_type]]

partner_type is a guaranteed input.

When I visit the page though the browser says “Failed to load PDF.” Am I missing something about how the PDF content type works?

2

I may have more issues with just loading a class as a service in a snippet.

The snippet I have so far is this:

<?php
if (!$generator = $modx->getService('pdfgenerator', 'Generator', MODX_CORE_PATH.'components/pdfgenerator/model/generator/')) {
    return "Not Found";
}

And the class is just this:

<?php

class Generator {
    function __construct() {
        
    }
}

And the page doesn’t load.

3

There is an option to create PDFs on the fly.

Is this MODX 2 or MODX 3 and what exactly are you trying to do here?

4

Interesting I’ll check that out. And this is MODX3, I was basing it on this from the docs modX.getService - Reference | MODX Documentation

5

The getService function is deprecated (in MODX 3). If you really need a service, then better use the new Dependency Injection Container.

In this case, the problem seems to be that you can’t create a class with the name “Generator”, as a class with the same name is already used by PHP → error message = The "Generator" class is reserved for internal use and cannot be manually instantiated.

6

Honestly, now that I’ve got PDFResource generating an on the fly pdf, I will be abandoning my own code.

PDFResource would still be able to run snippets inside of the tplPDF chunk? Or perhaps I’m misunderstanding how the FormItLoadSavedForm prehook works:

<!DOCTYPE html>
<html lang="[[++cultureKey:default=`en`]]">
<head>
    <meta charset="UTF-8">
    <title></title>
</head>
<body>
<h1>[[+pagetitle]]</h1>
[[+content]]
[[!FormIt?
    &preHooks=`FormItLoadSavedForm`
]]
[[+fi.partner_type]]
</body>
</html>
7

Try setting the property &updateSavedForm as well:

[[!FormIt?
    &preHooks=`FormItLoadSavedForm`
    &updateSavedForm=`1`
    &savedFormHashKeyField=`h`
]]
[[!+fi.partner_type]]
8

That did it.

Should the [[+fi.partner_type]] be uncached? Or does it matter?

9

Cached tags [[...]] are parsed before uncached tags [[!...]].

As the values of the [[+fi. ...]] placeholder tags are set by an uncached snippet call ([[!FormIt? ... ]]), the parser tries to parse the placeholder tags before they are set (if they are cached).

In this case it doesn’t really matter, because the MODX parser is somewhat tolerant and tries again (after the uncached snippet ran).

But it can create a problem if you (for example) use an output modifer.
Try [[+fi.partner_type:lowercase]] and [[!+fi.partner_type:lowercase]] and check the result.

So it’s best to use uncached placeholder tags, if they are set by an uncached snippet call.

10

Huh! Interesting!

Thank you for you help!