James,<br><br><div class="gmail_quote">On Fri, Jun 19, 2009 at 3:28 PM, James Foster <span dir="ltr">&lt;<a href="mailto:Smalltalk@jgfoster.net">Smalltalk@jgfoster.net</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style=""><div><div><div><div class="im"><blockquote type="cite">renderContentOn: html<br>    |marker|<br>    self map<br>        center: 45.5267 @ -122.8390 zoom: 11;<br>        setUIToDefault.<br>    <br>    marker := (GMarker overlayAt: 45.5267 @ -122.8390)<br>
                           draggable: true.<br>    self map addOverlay: marker.<br>    marker onDrag: ( html gmrequest callback: [:latlng | self lat: latlng lat lng: latlng lng ]).<br><br>That places a marker and callbacks whenever the user moves the marker across the map.<br>
</blockquote><div><br></div></div>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 &#39;self map&#39; return a Brush or a WAComponent subclass? </div>
</div></div></div></blockquote><div> </div><div>It returns the brush and that&#39;s the problem. I&#39;m just generating the code to bind the callback at the moment, but it&#39;s meaningless to store the marker in an instance variable in the brush. That&#39;s why I&#39;m considering separating static and dynamic behavior.  I may use brushes for rendering static parts and a component to hold markers and the like.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style=""><div><div><div><div class="im"><br><blockquote type="cite"> I&#39;m using callbacks, but that has some limitations if I want to hold the markers, so I&#39;ll be moving the callbacks and markers to a component.<br>
</blockquote><div><br></div></div>I agree that the callbacks need to call a component and a component is needed to save state. What I don&#39;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&#39;t see the benefit of (2). </div>
</div></div></div></blockquote><div> </div><div>I think they should be part of your domain model, but that doesn&#39;t mean you can get rid of every logic that belongs to the Controller (in MVC).  <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style=""><div><div><div></div><div><br></div><div>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&#39;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. </div>
<div><br></div><div>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.</div></div>
</div></div></blockquote><div> </div><div class="im">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 &quot;component&quot;: I would serve my domain model list to it and register a callback whenever the selected object changes. Something like:<br>
<br>(DropDownList on: myList) onChange: [:selectedItem | self doSomethingWith: selectedItem ]<br><br>Or better, with something like value models:<br><br>selectedItemHolder := ValueHolder on: myList first.<br>DropDownList on: myList selectedItem: selectedItemHolder<br>
<blockquote type="cite">This would not make sense in a traditional client/server application, that&#39;s why you haven&#39;t found a need for something like this, I think.<br></blockquote><div><br></div></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style=""><div><div><div>I don&#39;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&#39;m using <a href="http://maps.google.com" target="_blank">http://maps.google.com</a> 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&#39;t see that your use case is any different. Having a shorter network time is nice, but doesn&#39;t change the basic design or usefulness of being notified of events.</div>
</div></div></div></blockquote><div><br>Ok <br></div></div><br>Cheers, Mariano<br>