These are some examples of problems that we have helped to solve or to create:
If most of the information for the presentation is in the lists theirselves, why to repeat it in
each one of the forms? On the same way as the out of the box forms know to present/display the fields,
forms can be generated that they themselves know what fields to present/display, even depending on the
current user, or being related to the rest of lists, presenting/displaying other controls, filtering or not
according to previous data, current user or his/her group, etc.
In order to organize better the information of the forms without needing a rich client specialized in
Tabs and subtabs that don't load or render their content if they are not active or, in the other way,
they load that in order to have the information available right away and/or to avoid postback.
That they remember which of them was active and with independent scroll.
To have the content in multiple languages or to presenting/displaying the interface in several languages
without replicate the pages.
To be able to use a unique dictionary or resources file for all the application and its assemblies.
To be able to have a system of exceptions to personalize the dictionary to the client without losing its
generic update (always there's some costumer that uses another word to name the same).
Not always the user arrives at a screen from the same place and therefore not always when finishing it
must return to the same origin point. Each screen must know from where has been called and when finalize
his functionality it must know to where the user must be redirected, conserving the view, filters, active
tab, etc. it has when he/she entered, but updating its content.