[Seaside] MVP on Seaside

[Avi Bryant]

On Aug 31, 2004, at 2:25 AM, Sebastian Sastre wrote:

>> I've spent a lot of time thinking about how this might work and
>> building small experiments, but I've never come up with anything I'm
>> even remotely satisfied with.
> In those experiments do you ever tried this well proven framework 
> (MVP)?

I've never really used Dolphin, so I only know about MVP in theory, 
from reading the "twisting the triad" paper and so on.  I've certainly 
experimented with ideas from MVP, but it's not clear in my head what 
just "using" MVP directly would mean in a Seaside context.  If there's 
an obvious design you have in mind, I would definitely encourage you to 
implement it, at least to a proof-of-concept level, so that we can all 
better understand MVP and how it would apply here.

>  I also see that (in desktop developments) allways
> one have to deal, intensively, with model and presenters, rarely on
> views. I'm trying to get this benefit to the web applicatoin
> development, so we can get the energy only in model and application
> models (or presenters), and rarely on views.

This is what I'm disputing.  The aesthetic of the web is such that 
inevitably, any application that you write is going to have a large 
number of custom views.  It is also, hopefully, going to have a 
reasonable number of standard views (or the reusability claims for 
Seaside components would be much less interesting).  But take something 
like Google - how much of what you see would be included in a standard 
view library?  The text input and Search button, yes.  But the search 
results?  All the custom links that pop up (translate this page, 
cached, similar pages)?  The Goooogle pagination?  The AdWords on the 
side?

If you accept that a web application requires proportionally more 
custom views than a desktop application does, then the tradeoffs 
change.  There is almost certainly more total effort involved in 
writing a separable View/Presenter pair than in writing them in a more 
tightly coupled way.  In standard desktop MVP, that effort is 
worthwhile because the work to create the View is amortized over many 
Presenters.  If, as in the web, you are often writing a new View that 
will only be used by a single Presenter, that effort may no longer be 
worth it.

I say "may" because it's possible/likely that I just haven't found the 
right way to make View/Presenter pairs easy enough to write, or the 
right way to structure my code so that individual views (given the 
right CSS, say) can be used in a wider range of apps.  That's 
definitely a direction I'd like to move in, and I'm far from giving up. 
  But I do think it's a mistake to assume that just because a paradigm 
has been proven in the desktop arena, it is necessarily a good design 
for web apps.

> As you'll see all arround in many frameworks in smalltalk, more classes
> does not implies more complexity, when it's well designed, more classes
> implies simplification (of the ideas), specialization, decoupling and
> flexibility. So I don't see that as a barrier.

It's not so much the proliferation of classes that concerns me as the 
necessary decoupling.  Seaside relies heavily on lexical scope as a way 
to connect views to models.  This can simplify things immensely, but 
the only way I've managed to get it to work is by constructing views on 
the fly (if you consider what HtmlRenderer is doing to be "constructing 
views"), and so there's necessarily code to do this in the 
presenter/component.  This is coupling, but it's coupling that allows a 
valuable concision that I really don't think would be possible 
otherwise.  Let me give you an example: let's say have a collection of 
Person objects that I want to show in an unordered list, where each 
list item includes the person's name, a text input for editing some 
part of their address, and (if the person is removable) a link for 
deleting that person from the list.  In Seaside's current, "coupled" 
style, this might look like:

html list: persons do:
	[:ea |
	html text: ea name.
	html textInputOn: #street of: ea address.
	ea isRemovable ifTrue:
		[html anchorWithAction: [persons remove: ea] text: 'remove']].

Can you give me an example, assuming the existence of ListViews, 
TextInputViews, etc, and making up their API, of how this example would 
work in MVP?

>  Think about it, in the posibilities: a very very
> cool  ViewComposer, could generate the css automatically for you.
> Let's imagine an example: you want your application to have a tree
> presenter with a customized style, you can put the webTreeView on the
> shell with the composer, set some general properties like fixed or
> relative length, background color/image, etc, and specific properties
> like have checkboxes, getChecboxIconBlock, etc.
> To make this, all you have to do is choose your shell class, lets say
> for a webmail application you make your WebmailPresenter. Open the
> composer, you can divide it with two shells (proportionaly or 
> statically
> divided), put on the top of them a list view for the mail headers (in
> there you also can set wich columns it'll have, getInfoBlocks,
> sortBlocks etc.) and below a text view for the body.

This is a neat vision, and I would love to see how far an 
implementation of it could go.  You say elsewhere that you have started 
to implement WebShell; any code you can share with us for comments 
would be great.

> A more strong reason to use MPV, is that in the applications I want to
> make, I plan to use a Role Model that makes a model to be presented to
> the user in a way that is dependent on the rol he/she has configured.
> For instance an administrator will see all the presenters of any model.
> All posible cards on the web card container (WASimpleNavigation). A
> ManagerRole should see more 'cards' than the CashierRole and those
> knowledge could be given for some objects, colaborating with the role
> model, that says wich view of the presenter should be enabled for
> rendering on html.

Yes, I've done similar things myself, and it works well, but I don't 
see how it relies on MVP.  Each role/model pair simply needs to resolve 
(through double dispatch, say) to a particular component subclass.

Avi