By default, the QForm engine will store the state of the actual QForm objects as a rather long Base64 encoded string. While this is a very simple, straightforward and very maintenance-free approach, it does cause some complications, especially for more enterprise-level application architectures:

• Performance: for really complex forms, formstate could account for as much as 10KB ~ 15KB or more of extra data being sent over the pipe. Especially for highly interactive AJAX-based applications, where you can have potentially multiple simultaneous operations, this can become a major performance bottleneck.
• Security: with just simple Base64 encoding, a hacker could alter their own formstate and modify private member variables in the form that you don't intend to have modified.

Qcodo resolves this by offering the ability to store/handle the formstate in various ways. You can store the formstate data in PHP Sessions or you can store the formstate data directly on the filesystem. For both methods, you end up only passing a small key back to the user. Moreover, the formstate, itself, or the key can even be encrypted, using the QCryptography class.

Finally, because the FormState handler is encapsulated in its own class, you can even define your own formstate handler, to store the formstate data on a shared server, in a database, or even in server memory.

In our example below, we use QSessionFormStateHandler to store the formstate data in PHP Session, and we will only store the session key (in this case, just a simple integer) on the page as a hidden form variable. For an added level of security, we will also encrypt the key.

If you use your browser's "View Source" functionality, you will see that the Qform__FormState hidden form variable is now a lot shorter (likely about 10 - 20 bytes). Compare this to the first example where the form state was easily over 1 KB. This is because the bulk of the form state is being stored as a PHP Session Variable, which is located on the server, itself.