<?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"
	>
<channel>
	<title>Comments on: A9 and Google Local</title>
	<atom:link href="http://www.sitepoint.com/blogs/2004/09/20/a9-and-google-local/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.sitepoint.com/blogs/2004/09/20/a9-and-google-local/</link>
	<description>News, opinion, and fresh thinking for web developers and designers. The official podcast of sitepoint.com.</description>
	<pubDate>Tue, 02 Dec 2008 13:26:31 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5</generator>
		<item>
		<title>By: Adagio</title>
		<link>http://www.sitepoint.com/blogs/2004/09/20/a9-and-google-local/#comment-3560</link>
		<dc:creator>Adagio</dc:creator>
		<pubDate>Wed, 31 Dec 1969 19:00:00 +0000</pubDate>
		<guid isPermaLink="false">458677378#comment-3560</guid>
		<description>&lt;p&gt;Bah - just look at the code. No DOCTYPE, pure TABLE design. *sigh*&lt;/p&gt;

</description>
		<content:encoded><![CDATA[<p>Bah - just look at the code. No DOCTYPE, pure TABLE design. *sigh*</p>]]></content:encoded>
	</item>
	<item>
		<title>By: HarryF</title>
		<link>http://www.sitepoint.com/blogs/2004/09/20/a9-and-google-local/#comment-3561</link>
		<dc:creator>HarryF</dc:creator>
		<pubDate>Wed, 31 Dec 1969 19:00:00 +0000</pubDate>
		<guid isPermaLink="false">458677378#comment-3561</guid>
		<description>&lt;p&gt;&lt;blockquote&gt;&lt;p&gt;&lt;br /&gt;
I don't think we've even begun to scratch the surface of the possibilities that remote scripting opens up.&lt;br /&gt;
&lt;/p&gt;&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;Second that!&lt;/p&gt;

</description>
		<content:encoded><![CDATA[<p>
<blockquote>
<p>
I don&#8217;t think we&#8217;ve even begun to scratch the surface of the possibilities that remote scripting opens up.
</p>
</blockquote>
</p><p>Second that!</p>]]></content:encoded>
	</item>
	<item>
		<title>By: padders</title>
		<link>http://www.sitepoint.com/blogs/2004/09/20/a9-and-google-local/#comment-3562</link>
		<dc:creator>padders</dc:creator>
		<pubDate>Wed, 31 Dec 1969 19:00:00 +0000</pubDate>
		<guid isPermaLink="false">458677378#comment-3562</guid>
		<description>&lt;p&gt;&lt;blockquote&gt;&lt;p&gt;Once the iframe document has finished loading, it calls a function to copy its own innerHTML in to a div contained in the parent window that loaded it.&lt;br /&gt;
&lt;blockquote&gt;&lt;p&gt;&lt;/p&gt;&lt;/blockquote&gt;&lt;/p&gt;&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;&lt;blockquote&gt;&lt;p&gt;&lt;blockquote&gt;&lt;p&gt;I know that for my application I do something similair. What I generally do, is when the iframe loads, call a function on the main javascript window. This window can then access the data from the iframe that has now loaded.&lt;/p&gt;&lt;/blockquote&gt;&lt;/p&gt;&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;&lt;blockquote&gt;&lt;p&gt;&lt;blockquote&gt;&lt;p&gt;Part of the reason for doing this is I have a sort of switch back. I use the iframe for automatic checking, e.g. lets say checking for new emails to arrive so it reloads itself. When some remote server call is made, i reuse the iframe to call that page, and then reset it to the auto reload of the email check page, so far it works pretty well; I have functionalised it and linked into my html/content functions.&lt;/p&gt;&lt;/blockquote&gt;&lt;/p&gt;&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;&lt;blockquote&gt;&lt;p&gt;&lt;blockquote&gt;&lt;p&gt;I don't have  demo online but will currently; I have begun to realise how useful this is going to be for our app, unfortunatly that was a bit late in development stage so it is going to have to be next version to start fully using it, but the usefulness is so there.&lt;/p&gt;&lt;/blockquote&gt;&lt;/p&gt;&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;&lt;blockquote&gt;&lt;p&gt;&lt;blockquote&gt;&lt;p&gt;One major thing I have been considering is pre-form submit validation. You can now remove all that js validation; validate using the PHP you will do the validation with anyway and save the rewrite of validation code in two languages.&lt;/p&gt;&lt;/blockquote&gt;&lt;/p&gt;&lt;/blockquote&gt;&lt;/p&gt;

</description>
		<content:encoded><![CDATA[<p>
<blockquote>
<p>Once the iframe document has finished loading, it calls a function to copy its own innerHTML in to a div contained in the parent window that loaded it.</p>
<blockquote>
</blockquote>
</blockquote>
</p><p>
<blockquote>
<blockquote>
<p>I know that for my application I do something similair. What I generally do, is when the iframe loads, call a function on the main javascript window. This window can then access the data from the iframe that has now loaded.</p>
</blockquote>
</blockquote>
</p><p>
<blockquote>
<blockquote>
<p>Part of the reason for doing this is I have a sort of switch back. I use the iframe for automatic checking, e.g. lets say checking for new emails to arrive so it reloads itself. When some remote server call is made, i reuse the iframe to call that page, and then reset it to the auto reload of the email check page, so far it works pretty well; I have functionalised it and linked into my html/content functions.</p>
</blockquote>
</blockquote>
</p><p>
<blockquote>
<blockquote>
<p>I don&#8217;t have  demo online but will currently; I have begun to realise how useful this is going to be for our app, unfortunatly that was a bit late in development stage so it is going to have to be next version to start fully using it, but the usefulness is so there.</p>
</blockquote>
</blockquote>
</p><p>
<blockquote>
<blockquote>
<p>One major thing I have been considering is pre-form submit validation. You can now remove all that js validation; validate using the PHP you will do the validation with anyway and save the rewrite of validation code in two languages.</p>
</blockquote>
</blockquote></p>]]></content:encoded>
	</item>
	<item>
		<title>By: padders</title>
		<link>http://www.sitepoint.com/blogs/2004/09/20/a9-and-google-local/#comment-3563</link>
		<dc:creator>padders</dc:creator>
		<pubDate>Wed, 31 Dec 1969 19:00:00 +0000</pubDate>
		<guid isPermaLink="false">458677378#comment-3563</guid>
		<description>&lt;p&gt;On that validation, I am wondering if you can:&lt;/p&gt;

&lt;p&gt;i) Someone enters form data. Press the Submit button&lt;br /&gt;
ii) Make a remote script call to server&lt;br /&gt;
iii) If not validated, some javascript wizadry to explain this to user. Page is already there etc.&lt;br /&gt;
iv) If validated, perhaps do whatever we where going to do, then send back a call to the browser to redirect to the page you where going to anyway.&lt;/p&gt;

&lt;p&gt;Advantages:&lt;/p&gt;

&lt;p&gt;i) no js validation functions&lt;br /&gt;
ii) no need to even consider writing the PHP to handle creating forms to handle a failed form submit, e.g. handling difference between editing a form and redoing a form etc.&lt;br /&gt;
iii) Much quicker, no browser reload for a failed form submit.&lt;/p&gt;

&lt;p&gt;Cearly, this would completly break the app if you disable javascript, but in apps where you have some control over the environment, that should not be a problem.&lt;/p&gt;

</description>
		<content:encoded><![CDATA[<p>On that validation, I am wondering if you can:</p>
<p>i) Someone enters form data. Press the Submit button<br />
ii) Make a remote script call to server<br />
iii) If not validated, some javascript wizadry to explain this to user. Page is already there etc.<br />
iv) If validated, perhaps do whatever we where going to do, then send back a call to the browser to redirect to the page you where going to anyway.</p>
<p>Advantages:</p>
<p>i) no js validation functions<br />
ii) no need to even consider writing the PHP to handle creating forms to handle a failed form submit, e.g. handling difference between editing a form and redoing a form etc.<br />
iii) Much quicker, no browser reload for a failed form submit.</p>
<p>Cearly, this would completly break the app if you disable javascript, but in apps where you have some control over the environment, that should not be a problem.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Skunk</title>
		<link>http://www.sitepoint.com/blogs/2004/09/20/a9-and-google-local/#comment-3564</link>
		<dc:creator>Skunk</dc:creator>
		<pubDate>Wed, 31 Dec 1969 19:00:00 +0000</pubDate>
		<guid isPermaLink="false">458677378#comment-3564</guid>
		<description>&lt;p&gt;padders: I love the idea of validation against your server-side PHP logic using remote scripting. I've implemented dual validation (client- and server-side) several times and the duplication of validation logic in two different languages has always bugged me.&lt;/p&gt;

</description>
		<content:encoded><![CDATA[<p>padders: I love the idea of validation against your server-side PHP logic using remote scripting. I&#8217;ve implemented dual validation (client- and server-side) several times and the duplication of validation logic in two different languages has always bugged me.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: illuminosity</title>
		<link>http://www.sitepoint.com/blogs/2004/09/20/a9-and-google-local/#comment-3565</link>
		<dc:creator>illuminosity</dc:creator>
		<pubDate>Wed, 31 Dec 1969 19:00:00 +0000</pubDate>
		<guid isPermaLink="false">458677378#comment-3565</guid>
		<description>&lt;p&gt;Tooting my own horn though it may be, this is sort of what I was trying to get at in http://www.sitepoint.com/article/practical-xml-form-validation&lt;/p&gt;

&lt;p&gt;For full-strength validation, the technique would need to be taken further, but there's no reason you can't specify your validation in one xml document residing on your server, and have both your javascript and server side language reference that file to validate forms.&lt;/p&gt;

</description>
		<content:encoded><![CDATA[<p>Tooting my own horn though it may be, this is sort of what I was trying to get at in <a href="http://www.sitepoint.com/article/practical-xml-form-validation" rel="nofollow">http://www.sitepoint.com/article/practical-xml-form-validation</a></p>
<p>For full-strength validation, the technique would need to be taken further, but there&#8217;s no reason you can&#8217;t specify your validation in one xml document residing on your server, and have both your javascript and server side language reference that file to validate forms.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: MH</title>
		<link>http://www.sitepoint.com/blogs/2004/09/20/a9-and-google-local/#comment-3566</link>
		<dc:creator>MH</dc:creator>
		<pubDate>Wed, 31 Dec 1969 19:00:00 +0000</pubDate>
		<guid isPermaLink="false">458677378#comment-3566</guid>
		<description>&lt;p&gt;Gmail seems to be doing something similar, though their code is quite obfuscated.&lt;/p&gt;

&lt;p&gt;The question I have is, does this scripted switching of content sit well with screen readers? Do they somehow get notified of the change?&lt;/p&gt;

</description>
		<content:encoded><![CDATA[<p>Gmail seems to be doing something similar, though their code is quite obfuscated.</p>
<p>The question I have is, does this scripted switching of content sit well with screen readers? Do they somehow get notified of the change?</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Skunk</title>
		<link>http://www.sitepoint.com/blogs/2004/09/20/a9-and-google-local/#comment-3567</link>
		<dc:creator>Skunk</dc:creator>
		<pubDate>Wed, 31 Dec 1969 19:00:00 +0000</pubDate>
		<guid isPermaLink="false">458677378#comment-3567</guid>
		<description>&lt;p&gt;I doubt screen readers cope very well with remote scripting - it relies on JavaScript support for one thing, and I doubt that the hooks for understanding that new content has been loaded are particularly useful even in screen readers that have JavaScript support. Creating accessible tools with remote scripting is definitely an interesting challenge, as it requires a "fall back" mode for non-JavaScript browsers.&lt;/p&gt;

</description>
		<content:encoded><![CDATA[<p>I doubt screen readers cope very well with remote scripting - it relies on JavaScript support for one thing, and I doubt that the hooks for understanding that new content has been loaded are particularly useful even in screen readers that have JavaScript support. Creating accessible tools with remote scripting is definitely an interesting challenge, as it requires a &#8220;fall back&#8221; mode for non-JavaScript browsers.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: omnicity</title>
		<link>http://www.sitepoint.com/blogs/2004/09/20/a9-and-google-local/#comment-3568</link>
		<dc:creator>omnicity</dc:creator>
		<pubDate>Wed, 31 Dec 1969 19:00:00 +0000</pubDate>
		<guid isPermaLink="false">458677378#comment-3568</guid>
		<description>&lt;p&gt;Surely posting an entire form back to the server for validation is giong to take just as long whether done via a hidden iFrame or with an old-fashioned POST/GET of the entire page. If all of the elements of the page have been cached by the browser where is the advantage (especially if you have to write in extra code to handle accessibility)?&lt;/p&gt;

</description>
		<content:encoded><![CDATA[<p>Surely posting an entire form back to the server for validation is giong to take just as long whether done via a hidden iFrame or with an old-fashioned POST/GET of the entire page. If all of the elements of the page have been cached by the browser where is the advantage (especially if you have to write in extra code to handle accessibility)?</p>]]></content:encoded>
	</item>
	<item>
		<title>By: awasson</title>
		<link>http://www.sitepoint.com/blogs/2004/09/20/a9-and-google-local/#comment-3569</link>
		<dc:creator>awasson</dc:creator>
		<pubDate>Wed, 31 Dec 1969 19:00:00 +0000</pubDate>
		<guid isPermaLink="false">458677378#comment-3569</guid>
		<description>&lt;p&gt;omnicity,&lt;br /&gt;
Posting the entire form isn't really as huge a concept as it sounds, because all you're sending is a bunch of string data. Then if we're doing validation you can load the results into the page elements that display your message or reload the form fields etc...&lt;/p&gt;

&lt;p&gt;This is great. I'm more partial to the XML HTTP Request method becasue it seems a whole lot cleaner, but either way it's so much better without a full page refresh.&lt;/p&gt;

</description>
		<content:encoded><![CDATA[<p>omnicity,<br />
Posting the entire form isn&#8217;t really as huge a concept as it sounds, because all you&#8217;re sending is a bunch of string data. Then if we&#8217;re doing validation you can load the results into the page elements that display your message or reload the form fields etc&#8230;</p>
<p>This is great. I&#8217;m more partial to the XML HTTP Request method becasue it seems a whole lot cleaner, but either way it&#8217;s so much better without a full page refresh.</p>]]></content:encoded>
	</item>
</channel>
</rss>
