DataManager doesn't give enough information

[Taras Voynarovsky]

The problem is in the limitations that the DataManager can do by adapting only context and field.
In my realization I NEED the state of the editform (Its an i18n realization, and I need the language of the current form). The Data manager is the best place to do my processing, but I can't even (without certain hacks) get the request. I think the manager lacks the ability to differ storage based on the request.

[Roger Ineichen (rogerineichen)]

I agree, it whould be a good idea to call a datamanager with more info e.g. the form and request etc. But on the other side almost anything works without the form itself. This means we probably need to make sure that we can use the widgets adapting a field without to require a form.

[Taras Voynarovsky (voyn1991)]

Well if we can more or less controll the read (by the converter), we have problems with the write. The save must be performed at the last place, becouse we need to let the form be aware of changes, that were made.
The proposition is to make the DataManager form aware (IFormAware). I think that it must not be aware of the widget, becouse its the Converter job to provide understandable data, but we must definetly have more space to manipulate the read/write operations

[Taras Voynarovsky (voyn1991)]

For example a situation:

We must save to the object if we have full access and to some temporary storage if we have limited access.

The problem is that we know if there were changes only at the last stage of the submit process. So we can create the temporary storage only at the last stage. So the place to apply changes will be the DataManager.

The other problem is the get operation. We must get data from another storage, but we can't. The adapter does not allow to find the current user or form.

[Stephan Richter (srichter)]

I am sure that the ``DataManager`` interface is not the right place for this. By design, it does not know about the view machinery.

That said, I know that there is sometimes a need for model and business logic code to know about the request. For those cases you always have the participations hooks, which any complex app uses anyways.