[Neos] Typo3.Form Neos Question

[nikos]

Hi Bastian

Thanks for your detailed and very helpful reply. You have, as always, given me examples that I will use to move my project forward.

I think you are quite right that it would be best to store the form details in a db or cvs file since as you rightly point out with the use case that 
I mentioned re submitting the form would likely result in the same error.

I have also taken your point on board in respect to stateless nature of a form and although it would be helpful to know how to create a form from a 
finisher I dont want to trouble you with this at this time, I appreciate that this takes you away from your own work.

I will utilise your example of a fluid finisher, this is really helpful, as I think that would be a good and flexible way to go, it will enable a more 
elegant way of 'finishing', and report back on my progress. I am wondering if, with this approach, it is possible to access NodeType/Typoscript data 
eg a target node to be displayed when the form is completed.

With respect to the RedirectFinsher I am  still unsure how you would use this straight off in a Neos context using the yaml config : is this possible 
out of the box?

Thinking more generaly about forms and finishers I am wondering if it would be useful if it was possible to define an onError state, similar to the 
cancel method, that any finisher could flag and perhaps and also supply a message so that the fe users is helpfully informed that a problem occurred. 
That way one could chain a whole sequence of finishers where each finisher could perhaps vote for an error or success and then a relevant message  is 
displayed to the user eg success or failure. F.e. we may have a first DBFileFinisher which saves to file or db, 2nd EmailFinisher emails 3rd 
Confirmation and a 4th OnErrorFinisher. If 1st and 2nd fail then the submission is lost and user is informed, via OnErrorFinisher, but if 1st or 2nd 
succeeds its ok and normal chain proceeds. Not sure what you think?

Finally thank you again and bearing with my newness to Neos! Something I definitely want to persist with as I really respect the architecture and 
values it is based on and hope with time I will be able to helpful contribute to.

Warm regards

Nikos




On 21/05/2014 17:44, Bastian Waidelich wrote:
> nikos wrote:
>
> Hi Nikos,
>
>> [...] I am wondering what is the best way to display a link back to display the form again
>
> Just take a look at the provided finishers. The ConfirmationFinisher demonstrates how to return a custom message, the RedirectFinisher shows how to
> retrieve the current request (that you would need to create a proper link).
>
> If you combine this you can create a custom finisher and do s.th. like:
>
> $formRuntime = $this->finisherContext->getFormRuntime();
> $uriBuilder = new \TYPO3\Flow\Mvc\Routing\UriBuilder();
> $uriBuilder->setRequest($formRuntime->getRequest());
>
> $formUri = $uriBuilder->uriFor('index');
> $response = $formRuntime->getResponse();
> $response->setContent(sprintf('<a href="%s">Back</a>', $formUri));
>
> Better yet, use Fluid to render the message and link. I've created a simple "FluidFinisher" that you could use/adjust:
> https://gist.github.com/bwaidelich/cd696fb99c1882561e0b
>
>
> BUT: Because even multi-step forms work stateless (that means the values are not persisted in a session but always encoded in the so called "form
> state" that is passed on from page to page) the values will be gone if you only link to the first page.
>
> If you want to keep the values you should create a form instead. Let me know if you need help with that..
>
>
> I'm wondering though whether redisplaying the form is a good idea in your case:
>
>> The use case I am thinking of is when I am using an EmailFinisher and
>> there is an error  e.g. can't connect to the smtp email server.
>
> If it's really an unexpected error like this one, it's quite likely that the same error still occurs if you send the exact same data a few seconds
> later..
> Instead you could create a simple finisher that stores the form data in a more reliable backend (the database or some csv file for example). That way
> - even when sending the email fails - you can recover the form data and/or try resending it at a later time.
>
> HTH
>