Dear Avi,

I wrote you below,

Sebastián Sastre ssastre@seaswork.com.ar www.seaswork.com.ar

-----Mensaje original----- De: seaside-bounces@lists.squeakfoundation.org [mailto:seaside-bounces@lists.squeakfoundation.org] En nombre de Avi Bryant Enviado el: Viernes, 27 de Agosto de 2004 19:13 Para: The Squeak Enterprise Aubergines Server - general discussion. Asunto: Re: [Seaside] MVP on Seaside

On Aug 27, 2004, at 7:56 PM, Sebastian Sastre wrote:

...

Hi all,       do you ever think about making an MVP framework on top

of seaside?

...

I mean, there is a presenter, obviously there are model (your objects), the only thing is missing here is something that

decouples

...

the view from the application-model.

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 think the basic problem is that web UIs are much less standardized than desktop UIs are.

I agree with the idea of the lack of standarization, but I don't see any relation with our problem. And that's because the basic widgets are esentially the same: trees, lists, tables (lists with several columns), icons, images, text imputs, text areas, radio buttons, buttons, progress bars, etc. In many web pages you can see a button made in flash, and it dances when you click on it. But it's a button.

...On any given

desktop platform, there's a fairly small number of widgets that get combined in predictable ways to build most applications, and so apart from the occasional custom view (one or two per app), all of the view classes can be provided by the framework and the application developer only has to worry about the model and maybe the controllers/presenters.

As I see this is exactly the same in web applications but with a strong artistic influence. 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.

On the web, there's a culture and aesthetic of building a unique look for each application,

I agree..

and so nearly every view class is going to be

specific to an application.

I disagree with this. You can have specific clases per each interface (GUI) the application uses (when is more than a messageBox), but not per view. In the long run, without MPV an application will have more clases than unsing MPV, with a lack of simplicity in every one of it (think in maintenance costs). As an example, the tree view class should be the same (WebTreeView for instance), but the TreePresenter (that also is the only one), can have 200 diferent views* for your 200 diferent sites/applications. *When telling view here, I mean the view as a resource (not as class), I mean, as a result of the instanciated objetc made with the view composer, and because of that, this view object has customized attributes, as font, color, etc, and css properties and is stored as another TreePresenter view.

Having a strict controller/view

separation here just seems to increase complexity and double the number of classes you have to manage.

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.

Having said this, I'd love to be proven wrong by someone coming up with a great MVP-style design for Seaside. CSS is a potential savior here, in that it allows a smaller number of view primitives to cover a much wider range of looks than would have previously been possible. But it's still a hard problem; much harder, I think, in the web context than on the desktop.

CSS is good, but as you say it's limited too. And because of this, I think is more intelligent to keep dependence to it as small as posible without abusing of this 'savior' effect that coul be tragical in the long run. Object Technology does not fail, so we can try to maximize (thanks to the seaside framework) the use of OT tools and solutions (homogenity). Because of this, I think it is possible and convinient to make a seaside application (a WebViewComposer) that allows the designer or any user, to 'draw' the widgets in some WebShell (a canvas) in almost the same way we make it in a desktop application. Then he/she can take advantage of the CSS to make final adjustments if necesary. As an additional benefit, you make the designers to work in the fashion they are used to, I mean they like to see what the will get (WHYSWYG) as they are making it. 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. So you will have only one treeview class, only one treepresenter class (to tell the view wich checkboxes or icons are in wich state), only one list view, with only one list presenter on many many views that you'll construct with them (like briks). To make your 200 "different" webmail applications.

About having done something with MVP.. well I made my own WebShell and WebDialog that are WAComponents subclasses, but I'm feeling the need to get the focus on the application model and not the way it renders on html to be more productive and to make the entire development to grow intelligiblely. So I want to share this ideas because I'm thinking they deserve to be tested.

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.

To see a little more on MPV I recomend you this paper: http://www.object-arts.com/Papers/TwistingTheTriad.pdf And if you like to see it working, you can make one or two dolphin smalltalk tutorials.

I think that using this mature framework, seaside users could have another strong benefit.

Best regards,

Sebastián Sastre ssastre@seaswork.com.ar www.seaswork.com.ar

Avi

---

Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/seaside

---

Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.745 / Virus Database: 497 - Release Date: 27/08/2004

--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.745 / Virus Database: 497 - Release Date: 27/08/2004

I answer below,

Sebastián Sastre ssastre@seaswork.com.ar www.seaswork.com.ar

-----Mensaje original----- De: seaside-bounces@lists.squeakfoundation.org [mailto:seaside-bounces@lists.squeakfoundation.org] En nombre de Avi Bryant Enviado el: Martes, 31 de Agosto de 2004 08:35 Para: The Squeak Enterprise Aubergines Server - general discussion. Asunto: Re: [Seaside] MVP on Seaside

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.

The association came to me because I use dolphin daily taking advantagge of this framework AND because you called the WAPresenter class in that way :)

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'll try to do my best, I think I could start making WebView and WebPresenter so then I can make the WebCanvas and WebShell subclasses respectively. Perhaps the ListPresentersPresenter (see below).

...

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.

I understand your point but I also think that that inevitability could not imply a view classes proliferation. In other words, web views can also be factorized. In this case we have to figure out, how we can factorize well enough the WebView hierarchy to have detailed basic views, so it can be "customized" in innumerable ways. This large number of customized views will be stored in the presenter and that don't implies to have that (the same) large number of view subclasses. May be one or two with a diferent specialized behavior like this example: BasicListAbstract class has 2 subclasses: ComboBox and ListBox, and ListBox has MultipleSelectionListBox subclass. This classes should keep all the knowledge about drawing a list (using the renderer) in every possible way for them, and to reflect the changes of it's model.

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?

I see them all as presenters. Presenters could be composed one into each other, so I'll make an hipotesis of how all this could be made ok?

Pagination of results:

The BatchSelectionPresenter is a presenter, the BatchSelectionFooter is another

BatchSelectionFooterPresenter 0. It's model is the collection, so it can calculate the ammount of pages. 1. Some static texts, and anchors. 2. has images presenters (of each letter of Goooooogle) with it's links. 3. the right blue arrow is an static image that triggers an event when it's clicked, because it was configured to do so. The BatchSelectionFooterPresenter hooked this event so it can trigger:#nextPageRequested 4. The number of result pages is it's made with anchors that when clicked simply trigger:#pageRequested: with: pageNumber. 5. When changing the page, this presenter draws the left image and link as it needs. 6. It also remember the current page.

BatchSelectionPresenter 1. The BatchSelection presenter, when instantiated, adds a subpresenter: a BatchSelectionFooterPresenter, hooks it's interest in some events: #nextPage, #previousPage, #pageRequested: 2. Implements the methods onPageRequested:, onNextPage, onPreviousPage, 3. It has as model the collection of results so it can pass this items as model of a ListPresentersPresenter 4. This ListPresentersPresenter, knows how to draw presenters one below each other, and ties the events of this instanciated presenter so it can re-trigger them saying who was the originator (aResult). 5. So this presenter instanciates the 4, 8 (or whatever the batch say) ResultPresenter one below eah other. This specialized presenter already know what to do when are clicked (somethig concrete or just trigger that that happens).

Perhaps the a code example could tell you in some other way. The GoogleBatchSelectionPresenter inicialization could look like this:

GoogleBatchSelectionPresenter>>createComponents footerPresenter := self add: BatchSelectionFooterPresenter new name:'footer'. listPresenter := self add: ListPresentersPresenter new name:'results'. listPresenter whenPresenters:#translateRequired: send:#onTranslateResult: to:self; whenPresenters:#cacheRequired: send:#onCachedRequired: to:self; whenPresenters:#similarRequired: send:#onSimilarPagesRequired: to:self.

"I'm thinking how to solve the EventRouter needed to implement the routing of hooked events to implement the method #whenPresenters... but we'll see."

GoogleBatchSelectionPresenter>>createSchematicWiring super createSchematicWiring. footerPresenter when:#nextPage send:#onNetxPageRequired to: self; when:#previousPage send:#onPreviousPageRequired to: self; when:#pageRequested: send:#onPageRequested: to: self.

GoogleBatchSelectionPresenter>>onNetxPageRequired listPresenter model: self nextPage.

Publicity in the results page: A vertical shaped shell (presenter) that has a GoogleAddPresenter, etc

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.

Perhaps, but at the price of loosing flexibility and extensibility. Every time you want to do somethig, you'll have to deal with html forms and tables. I dont like to deal with html tables, tags, etc. Maybe it just a price too high for some developers.

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.

That's very good! :)

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.

Well, in one hand, until we see it very clear why not, we can assume that the paradigm is valid, and in the other hand, I think is desirable to heredates a mature framework to this new domain. All that I'm proposing here is that if we can make the domain transformations well enough, we can make this heritage to pass from the desktop to the web.

...

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")

Yes I think a renderer is a great specialized tool. It's our pen to the html. Our benefactor from the html jungle.

, 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?

Yes, I can, lets say is not modal:

WebPersonShell>>createComponents personsPresenter := self add: WebListPresenter new name:'persons'. personsPresenter when:#itemClicked: send:#onPersonRemoved: to: self.

WebPersonShell>>model: somePersons personsPresenter model: (ListModel on: somePersons).

WebPersonShell>>onPersonRemoved: aPerson personPresenter model remove: aPerson.

If you want it modal then WebPersonShell should be WebPersonDialog (a WebDialog sobclass instead of WebShell). Note that in the example I give you, I don't have to deal with wich attribute of person is editable or wich has to be shown. That's because I asume the existance of the WebViewComposer tool where you put all that view information (guidelines to the renderer). I hasn't care about html, tables, divs, etc. At least in this case you can't say if it's for web or for a desktop application except by the name of the class. Nice, isn't it?

...

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.

I'll do my best to have something more testeable and share it at once.

...

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.

Yes, you're right it can be resolved having MPV or not. I wrote that because the first time I think of it, I was thinking on how the subpresenters could be programatically added, but you inspired me with the google example: the ListPresentersPresenter that I'm working on.

Best regards,

Sebastián Sastre ssastre@seaswork.com.ar www.seaswork.com.ar

Avi

---

Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/seaside

---

Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.745 / Virus Database: 497 - Release Date: 27/08/2004

--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.745 / Virus Database: 497 - Release Date: 27/08/2004