[Seaside] Brushes and state

Fri Jun 19 18:28:59 UTC 2009

Mario,

Comments below...

On Jun 18, 2009, at 5:57 PM, Mariano Montone wrote:

> James,
>
> Our intention is to use a map in a mobile application. That is to  
> say, both the smalltalk server and a browser are embedded in the  
> same device. In that context, having some markers and moving them  
> and receiving an update to the server whenever the marker moves,  
> makes sense. So, the state is the map I'm referring to (there may be  
> more than one map in the same page) and the markers of each map.
>
> This is what I have now, for example:
>
> 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?
>
> 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).

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.
>
> 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.
>
> Mariano

Of course, this is all mostly an interesting discussion based on your  
initial question. You started with a brush and are considering moving  
towards using a component to save state. I started with a component  
and moved to using a brush because I found that any state needed to be  
passed on to a domain-specific component. Your description so far  
doesn't suggest any reason I would reconsider my approach, though I  
certainly wouldn't mind being shown that my initial approach was better!

James

>
> On Thu, Jun 18, 2009 at 8:00 PM, James Foster  
> <Smalltalk at jgfoster.net> wrote:
> Mariano,
>
> I'll be interested to see how this comes out. As I mentioned  
> earlier, I started with a component and switched to a brush. I came  
> to view the GoogleMap as a browser widget, something like a listbox,  
> where you give it some data and let it draw itself. Yes, you can  
> configure callbacks, but that isn't really different from other  
> brushes. What sort of 'state' do you envision keeping with the map?  
> Might that be better in a domain-specific component that wraps a  
> map? I was able to implement over 40 examples and have not yet found  
> a need to get more complex.
>
> James
>
> On Jun 18, 2009, at 2:58 PM, Mariano Montone wrote:
>
>> Thanks Julian. I think a component will be ok.
>>
>> Mariano
>>
>> On Thu, Jun 18, 2009 at 1:22 PM, Julian Fitzell  
>> <jfitzell at gmail.com> wrote:
>> Hi Mariano,
>>
>> Off the top of my head, if I were implementing a google maps  
>> package, I would do it as a component or a painter (see below).  
>> Brushes certainly aren't intended to be kept around so if you have  
>> state to persist between requests that's not the way to go.
>>
>> There are people who like implementing everything as brushes but  
>> the main functionality of brushes is that they can be selected in  
>> arbitrary orders to nest content within each other, e.g.:
>>
>> html div: [ html span: [ html paragraph: 'foo' ] ].
>>
>> Unless you plan to do be able to do:
>>
>> html div: [ html googleMap: [ html paragraph: 'foo' ] ]
>>
>> (i.e. unless the thing you are creating allows content to be put  
>> inside it) I don't think there's much advantage in making your own  
>> brush. (The other reason to consider using brushes of course is  
>> that they have more direct access to the document).
>>
>> Even if you don't need the benefits of components (see http://blog.fitzell.ca/2009/05/when-to-use-seaside-component.html 
>>  ), you can just create a renderable object by implementing  
>> #renderOn: and do:
>>
>> html render: (GoogleMaps new configSomeStuff; yourself)
>>
>> This process is made much clearer in 2.9 where you can subclass  
>> WAPainter, implement #rendererClass to control what kind of  
>> renderer you get passed (you might possibly implement the google  
>> maps thing *using* one or more custom brushes and have your own  
>> renderer for them), and implement #renderContentOn: as you would  
>> for a component.
>>
>> Hopefully that makes things clearer and not muddier. :)
>>
>> Julian
>>
>> On Thu, Jun 18, 2009 at 5:51 AM, Mariano Montone <marianomontone at gmail.com 
>> > wrote:
>> Hello!,
>>            I'm implementing an API for rendering Google Maps. I've  
>> decided to implement it as a brush. That's because I'm just  
>> generating javascript code. But now I have a problem: when adding  
>> support for callbacks, I need to hold some state; for example, the  
>> map the callback refers to. But I think brushes are not meant to  
>> hold state, that is something left for the components mechanism,  
>> isn't it? So I would like to know what would be the correct way of  
>> implementing it in the framework. Should I implement maps as  
>> components, or should I add state to my brushes; I may hold a state  
>> in the callback block too, but I don't think that's good.
>>
>> Thanks!
>>
>> Mariano
>>
>>
>>
>> _______________________________________________
>> seaside mailing list
>> seaside at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>>
>>
>> _______________________________________________
>> seaside mailing list
>> seaside at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>>
>> _______________________________________________
>> seaside mailing list
>> seaside at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20090619/3068bbc2/attachment.htm