Back-end > sends > the model > to > the presenter > which calls display method on > the view
Your model would be a POJO (typically a shared object retrieved from the back-end). The presenter would make and RPC call to retrieve it. Based on the model configuration the presenter will or will not call some "setAsEditable(Boolen editable)" method available on the view when receiving the model.
The view > sends events to > the presenter > which updates > the model > and sends it to > the back-end
When the user make some action on the view the presenter will receive a notice of it (through events or based on an interface) and update the model. Note the model update logic (like the display logic) is also meant to be in the presenter. The model would then be pushed back to the back-end by the presenter (via RPC). Business logic stays in the back-end.
Personal note:
Hardcore MVPers would enforce strict loose coupling between components, but it often involves writing lots of event classes and/or interfaces (some call it boilerplate). Be pragmatic. I sometimes avoid using this architecture when I know my components won't be reused, and wait until the need for reuse comes to me.
But if you can manage to stay pure, you're good !