[Seaside] MVP on Seaside

Tue Aug 31 02:25:50 CEST 2004

Dear Avi,

	I wrote you below,

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

> -----Mensaje original-----
> De: seaside-bounces at lists.squeakfoundation.org
> [mailto:seaside-bounces at 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 at seaswork.com.ar
www.seaswork.com.ar

> 
> Avi
> 
> _______________________________________________
> Seaside mailing list
> Seaside at 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