[Seaside] Brushes and state

Mariano Montone marianomontone at gmail.com
Sat Jun 20 15:24:32 UTC 2009


James,

On Fri, Jun 19, 2009 at 3:28 PM, James Foster <Smalltalk at jgfoster.net>wrote:

> renderContentOn: html
>     |marker|
>     self map
>         center: 45.5267 @ -122.8390 zoom: 11;
>         setUIToDefault.
>
>     marker := (GMarker overlayAt: 45.5267 @ -122.8390)
>                           draggable: true.
>     self map addOverlay: marker.
>     marker onDrag: ( html gmrequest callback: [:latlng | self lat: latlng
> lat lng: latlng lng ]).
>
> That places a marker and callbacks whenever the user moves the marker
> across the map.
>
>
> This seems quite similar to my current implementation, though my examples
> put the marker above the map creation to encapsulate the rendering. In the
> above, does 'self map' return a Brush or a WAComponent subclass?
>

It returns the brush and that's the problem. I'm just generating the code to
bind the callback at the moment, but it's meaningless to store the marker in
an instance variable in the brush. That's why I'm considering separating
static and dynamic behavior.  I may use brushes for rendering static parts
and a component to hold markers and the like.

>
> I'm using callbacks, but that has some limitations if I want to hold the
> markers, so I'll be moving the callbacks and markers to a component.
>
>
> I agree that the callbacks need to call a component and a component is
> needed to save state. What I don't see is that the map itself should be a
> component rather than a brush. Do you envision adding the marker list to
> your base GoogleMap component? Do you expect the markers to also be known to
> your domain logic? If so, then it seems that the information is in three
> places: (1) on the map in the browser; (2) on the map component; and (3) in
> the domain. I don't see the benefit of (2).
>

I think they should be part of your domain model, but that doesn't mean you
can get rid of every logic that belongs to the Controller (in MVC).

>
> If you wanted to capture
> the current selection from a drop-down list, would you create a component to wrap the drop-down list or would you have the drop-down list notify the component of its current value. I don't see any substantive distinction between a GoogleMap and a drop-down list. They each have state and can notify the server when that state changes. Yes, the map has more states
> (multiple markers) and the states are
> more complex (two floating-point numbers for the location of a marker instead of an integer for the current selection). But, fundamentally, the concept is the same. Something changed in the browser and we want to record that in the server.
>
>
> I could easily imagine that you would create a reusable component that includes a map, but the map itself does not need to be a component any more than a drop-down list needs to be a component.
>

Maybe, but the drop down list has to handle your domain model list somehow.
For example, this is what I would expect from a good drop down list
"component": I would serve my domain model list to it and register a
callback whenever the selected object changes. Something like:

(DropDownList on: myList) onChange: [:selectedItem | self doSomethingWith:
selectedItem ]

Or better, with something like value models:

selectedItemHolder := ValueHolder on: myList first.
DropDownList on: myList selectedItem: selectedItemHolder

This would not make sense in a traditional client/server application, that's
why you haven't found a need for something like this, I think.


I don't understand this distinction. Are you implying that event-based
> updates are not useful if the web server is remote from the client? It seems
> to me that most of AJAX is useful in just this case. I assume that when I'm
> using http://maps.google.com to get directions and I drag a marker on the
> map, it sends an event back to the server and recalculates the route, the
> time, and the distance, and renders new information to the client. I don't
> see that your use case is any different. Having a shorter network time is
> nice, but doesn't change the basic
> design or usefulness of being notified of events.
>

Ok

Cheers, Mariano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20090620/34fa2233/attachment.htm


More information about the seaside mailing list