Formhandler

Hi Stefan,

the problem is: When you submit a form, the finishers are called, in your case Finisher_DB and then Finisher_SubmittedOK.
Finisher_DB stores some values in the internal GET/POST values ($this->gp). You can access these values later on using ###value_saveDB###.

In the SubmittedOK subpart you can use these markers too. But when pdf_generator2 calls the page again to render it, the form is not submitted, but the values are loaded from the log table. There is no call to Finisher_DB, so there is no ###value_saveDB###.

I think the workaround you suggest is in fact the only suitable way to make this possible.

Hello Reinhard,

what do you think about following?
Autogenerating markers like this when Finnisher_StoreGP is called: ###value_ses|saveDB|tx_sfoffer_domain_model_offer|type###?

Stefan

Hi Stefan,

Storing the data in the session and auto generating those markers isn't gonna cover all cases, I guess.
If you send the link to the PDF via email and another user opens the link, there is no session, so the values won't be available. Right?

I thought a bit more about the problem.
Here is a summary:

• The form is submitted without errors and it is the last step.
• The saveInterceptors are called
• The loggers are called. Logger_DB puts the form data into the log table
• The finishers are called. Finisher_DB stores values in the DB and stores the data in $this->gp['saveDB']. So the values are available in value-markers in SubmittedOK.

When the PDF is generated:

• The controller loads the data from the log table
• The Finisher_SubmittedOK is called and shows the view again. Problem: The saveDB values are not available.

Solution:

Use Finisher_DB as a saveInterceptor. This way it is called BEFORE the logger and the saveDB values are stored in the log table.

It might seems strange to configure Finisher_DB as a saveInterceptor, but the interface of the classes is the same, so it is possible.

Wouldn't that be a nice solution?