[Seaside] MVP on Seaside
avi at beta4.com
Tue Aug 31 13:34:59 CEST 2004
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
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
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
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:
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
> 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.
More information about the Seaside