<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Creating a (Google Maps) ToscaWidget</title>
	<atom:link href="http://wyattbaldwin.com/2007/03/21/creating-a-google-maps-toscawidget/feed/" rel="self" type="application/rss+xml" />
	<link>http://wyattbaldwin.com/2007/03/21/creating-a-google-maps-toscawidget/</link>
	<description></description>
	<lastBuildDate>Tue, 17 Nov 2009 13:46:32 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
	<item>
		<title>By: Wyatt</title>
		<link>http://wyattbaldwin.com/2007/03/21/creating-a-google-maps-toscawidget/comment-page-1/#comment-67</link>
		<dc:creator>Wyatt</dc:creator>
		<pubDate>Thu, 29 Mar 2007 06:49:29 +0000</pubDate>
		<guid isPermaLink="false">http://wyattbaldwin.com/2007/03/21/creating-a-google-maps-toscawidget/#comment-67</guid>
		<description>@Alberto: Thanks for the feedback. I’ve updated the package and the post.</description>
		<content:encoded><![CDATA[<p>@Alberto: Thanks for the feedback. I’ve updated the package and the post.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alberto</title>
		<link>http://wyattbaldwin.com/2007/03/21/creating-a-google-maps-toscawidget/comment-page-1/#comment-66</link>
		<dc:creator>Alberto</dc:creator>
		<pubDate>Fri, 23 Mar 2007 09:51:19 +0000</pubDate>
		<guid isPermaLink="false">http://wyattbaldwin.com/2007/03/21/creating-a-google-maps-toscawidget/#comment-66</guid>
		<description>Hi Wyatt,

Very nice article! Just one little problem: You seem to have grokked TW way to well without decent docs, that takes much pressure away from me to write them! :P

Anyway, some comments/suggestions in random order:

&lt;ul&gt;
    	&lt;li&gt;Yes, you can pass variables to CSSSource/JSSources (not *Links) with the “source_vars” variables. They behave in a parallel way to “params”. I must admity I rarely use them though and have been tempted to remove them altogether and provide the same behavior with just “params” for consistency’s sake.&lt;/li&gt;

    	&lt;li&gt;You don’t need to manually create the directory structure for a widget egg, “paster create -t toscawidgets twGMap” will do it automatically.&lt;/li&gt;

    	&lt;li&gt;You can also “add_call”s inside init or post_init (in that case you won’t need the “include_dynamic_js_calls” attribute). The reason you might need to do it in “update_params” is if you want to override initial parameters when displaying the widget.&lt;/li&gt;
&lt;/ul&gt;

I’ll extend on this some more because it’s an important part of TW’s design:

Widgets are designed to be initialized once in the lifetime of your application (this is legacy behavior from TG widgets) and reused in every controller/template that needs them. To avoid creating dozens of very similar instances, most widgets allow you to override any (or most) params when displaying them. This is the reason you might want to add the calls at update params: so you can override variables sent to js when displaying the widget.

&lt;ul&gt;
    &lt;li&gt;You can let TW convert parameters from python to js for you (uses simplejson). To do that you’ll do:&lt;/li&gt;
&lt;/ul&gt;

&lt;pre&gt;from toscawidgets.api import js_function
init_map = js_function(“twGMap.create_map”)
&lt;/pre&gt;

and then in update_params:

&lt;pre&gt;self.add_call(init_map(d.map_options))
&lt;/pre&gt;

(To make default “map_options” you declare as a class attribute or when instantiating a widget available at “d” you should list it at “params”)

&lt;ul&gt;
    &lt;li&gt;Yes, that boiler-plate at (Pylons’) middleware.py will soon be incorporated at pylonshf.py…&lt;/li&gt;
&lt;/ul&gt;

Well, that’s all I can think of now… very nice article indeed! :) Hope I’m over a contract soon and get some docs out to save the trouble of chasing snippets of wisdom all around the net for others. :)

Alberto</description>
		<content:encoded><![CDATA[<p>Hi Wyatt,</p>
<p>Very nice article! Just one little problem: You seem to have grokked TW way to well without decent docs, that takes much pressure away from me to write them! <img src='http://wyattbaldwin.com/wp-includes/images/smilies/icon_razz.gif' alt=':P' class='wp-smiley' /> </p>
<p>Anyway, some comments/suggestions in random order:</p>
<ul>
<li>Yes, you can pass variables to CSSSource/JSSources (not *Links) with the “source_vars” variables. They behave in a parallel way to “params”. I must admity I rarely use them though and have been tempted to remove them altogether and provide the same behavior with just “params” for consistency’s sake.</li>
<li>You don’t need to manually create the directory structure for a widget egg, “paster create -t toscawidgets twGMap” will do it automatically.</li>
<li>You can also “add_call”s inside init or post_init (in that case you won’t need the “include_dynamic_js_calls” attribute). The reason you might need to do it in “update_params” is if you want to override initial parameters when displaying the widget.</li>
</ul>
<p>I’ll extend on this some more because it’s an important part of TW’s design:</p>
<p>Widgets are designed to be initialized once in the lifetime of your application (this is legacy behavior from TG widgets) and reused in every controller/template that needs them. To avoid creating dozens of very similar instances, most widgets allow you to override any (or most) params when displaying them. This is the reason you might want to add the calls at update params: so you can override variables sent to js when displaying the widget.</p>
<ul>
<li>You can let TW convert parameters from python to js for you (uses simplejson). To do that you’ll do:</li>
</ul>
<pre>from toscawidgets.api import js_function
init_map = js_function(“twGMap.create_map”)
</pre>
<p>and then in update_params:</p>
<pre>self.add_call(init_map(d.map_options))
</pre>
<p>(To make default “map_options” you declare as a class attribute or when instantiating a widget available at “d” you should list it at “params”)</p>
<ul>
<li>Yes, that boiler-plate at (Pylons’) middleware.py will soon be incorporated at pylonshf.py…</li>
</ul>
<p>Well, that’s all I can think of now… very nice article indeed! <img src='http://wyattbaldwin.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' />  Hope I’m over a contract soon and get some docs out to save the trouble of chasing snippets of wisdom all around the net for others. <img src='http://wyattbaldwin.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
<p>Alberto</p>
]]></content:encoded>
	</item>
</channel>
</rss>
