GUI Patterns

I've recently been working with Martin Fowler on documenting GUI patterns. Currently there are two pattern names that are prevalent in the development community, Model View Presenter (MVP) and Presentation Model (PM). The problem is, these names mean different things to different people.

Both MVP & PM are documented as rich client patterns on Martin Fowler's site. However, the patterns have also been successfully adapted for the web. Mike Mason has a wonderful write-up on this very subject. But, the real question is whether the pattern is abstract enough to be applied to either format. The answer to that question relies on what is the definition of MVP and PM.

The definitions on Martin's website state that the distinction between MVP and PM is where the state is maintained. For MVP the state is maintained in the View, but for PM the state is maintained in the PM. Based on this definition both MVP and PM could be easily adapted for the web. Unfortunately, not everyone agrees on this definition.

A common area of discussion is whether the view references the presenter/presentation model or if the presenter/presentation model references the view. In the past this implementation detail has been considered as orthogonal to the definition. However, due to the growing confusion over the relevance of this detail I believe it's worth exploring. Some definitions even describe the reference dependency as the central theme in the pattern.

I think the larger issue is that the goal has been slightly lost in the implementation details of these patterns. Martin has expressed to me that he may document a more abstract pattern that describes decoupling the view from it's behavior by introducing another class. This is the heart of both MVP and PM.

However, documenting the abstract pattern alone would be far less valuable than including the information about MVP and PM. Both MVP and PM have implementation trade-offs that have been discovered in use. Not documenting the issues with both patterns would be disappointing.

I'm hoping Martin can sort most of the issues out, but you can help also. Post comments with your opinions (and/or links to samples) and I will include these ideas in the book if they are relevant.