Non-persistable form element, multiple contexts per element

[Piotr Szymaszek]

Currently using either FormElement or GenericFormElement implicates that the underlying object is identifiable in one way or another and that this id can be accessed through the DataIndexer.

However, it may be the case that you are only using a DTO object to read the validated data from the form and then send it to an exterior service, be it in the application or as a cURL request. Neither of the provided form elements can handle this situation, since the FormElementContext (which is always used for both of them) will always try to find the object's id through the DataIndexer and in case of example Doctrine, will fail because it is an object not handled by the EntityManager.

If this situation is to be resolved, one of the following resolutions may be applied:

• Create a completely separate element for handling simple form submission and validation, which may or may not serve as a basis for the aforementioned elements.
• Remove the DataIndexerElement interface from the base FormElement interface and try to rework the relations between elements and contexts.
• Change the way element contexts are being assigned. Instead of applying all contexts to a supported element, have the ContextManager find the one with the highest priority and use it. That way you can override the base context, which may try to do something you would not want it to.

Thoughts?

[Łukasz Cybula]

I would add fourth option:

• Add generic implementation of DataIndexerInterface that would be used inside GenericFormElement