<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/">
    <channel>
        <title>DOM Scripting comments: Spryjax</title>
        <link>http://domscripting.com/blog/display/93</link>
        <description>Another day, another library.</description>
        <language>en</language>
        <item>
            <title>HoWolker</title>
            <link>http://domscripting.com/blog/display.php/93#comment725</link>
            <content:encoded><![CDATA[<p>To press, that has not got in peak of news</p>
]]></content:encoded>
            <pubDate>Fri, 05 Jan 2007 15:15:36 GMT</pubDate>
        </item>
        <item>
            <title>baston</title>
            <link>http://domscripting.com/blog/display.php/93#comment724</link>
            <content:encoded><![CDATA[<p>Spry is far from just a marketing thing. Even though it is still in development it is being used in production sites already.</p>
]]></content:encoded>
            <pubDate>Wed, 03 Jan 2007 14:27:21 GMT</pubDate>
        </item>
        <item>
            <title>Andy Hume</title>
            <link>http://domscripting.com/blog/display.php/93#comment721</link>
            <content:encoded><![CDATA[<p>I think one of Jeremy&#8217;s main points is that it&#8217;s insisting on XML as the data format, and then parsing that into some serialised notation on the client. That&#8217;s far from ideal in every situtation except one where you&#8217;re forced into using an XML data format ( why would this be? ).</p>

<p>Google&#8217;s JavaScript XPath implementation teriffies me, and I notice they&#8217;ve taken it out of their maps API, along with the JavaScript XSL piece. I believe it&#8217;s some 60K before compression.</p>

<p>As people get more and more excited about the possibilities of client-side scripting, lets make sure there some that keep their feet on the ground and remember that some processes are far better suited to being run on the server and some suited to the client. Just because you can, doesn&#8217;t mean you should.</p>
]]></content:encoded>
            <pubDate>Tue, 26 Dec 2006 23:48:18 GMT</pubDate>
        </item>
        <item>
            <title>Raymond Camden</title>
            <link>http://domscripting.com/blog/display.php/93#comment720</link>
            <content:encoded><![CDATA[<p>Yes, I think it is. You can have one line pointing to the XML and then your HTML which uses the dataset. No need for creating a callback (although you can use one if you want one), no need to make a HTTP object (Spry does it all for you). Spry is <em>far</em> from just a marketing thing. Even though it is still in development it is being used in production sites already. I&#8217;m probably pretty biased as a Spry user (been using it since the first release), but I truly think is a great framework.</p>
]]></content:encoded>
            <pubDate>Mon, 25 Dec 2006 05:18:51 GMT</pubDate>
        </item>
        <item>
            <title>Colin</title>
            <link>http://domscripting.com/blog/display.php/93#comment719</link>
            <content:encoded><![CDATA[<p>Is it simpler than a request object and a callback? And, I don&#8217;t mean &#8216;complex&#8217; as &#8216;difficult.&#8217; I think Spry is purely a marketing thing. I don&#8217;t yet see it&#8217;s value over the basics. Just get &#8216;spry&#8217; all over the source code and it&#8217;s like viral marketing.</p>
]]></content:encoded>
            <pubDate>Mon, 25 Dec 2006 01:19:56 GMT</pubDate>
        </item>
        <item>
            <title>Raymond Camden</title>
            <link>http://domscripting.com/blog/display.php/93#comment718</link>
            <content:encoded><![CDATA[<p>Some comments to both the post and to the last comment.</p>

<p>Spry does not force you to use XML for data. In the latest release you can load HTML just as easy. However, if you want to use datasets, then yes, it requires XML. I&#8217;m not sure why someone would want to use HTML for data as XML seems to be a much better fit. It also allows you to do some nice manipulation of the data on the client side - for example, flagging rows of data where some condition is met.</p>

<p>As for the 404 for the namespace - do remember Spry is still in development so that is just a temporary problem. This hasn&#8217;t stopped me from using the code successfully on a few sites already.</p>

<p>Colin - I&#8217;m not sure why you think Spry is complex. I&#8217;ve taught Spry classes a few times now - and time and time again folks tell me they are amazed at how easy it is to use.  It certainly seems a lot easier than Prototype, although I&#8217;ll admit to not looking at Prototype quite closely yet. </p>
]]></content:encoded>
            <pubDate>Sun, 24 Dec 2006 20:35:22 GMT</pubDate>
        </item>
        <item>
            <title>Colin</title>
            <link>http://domscripting.com/blog/display.php/93#comment717</link>
            <content:encoded><![CDATA[<p>I think we might be in for a wave of this stuff. I remember the very first article/tutorial I read on Ajax, maybe a year ago, provided a very simple request object that ran a callback to parse the response. That&#8217;s the heart of Ajax. &quot;Hijax,&quot; or progressive enhancement, should be a given.</p>

<p>Now we have an onslaught of &#8216;frameworks&#8217; that attempt to make something very simple even simpler, which just makes it more complex. The &#8216;spry&#8217; namespace just seems to be more about Adobe marketing than having any real practical benefits. I think Adobe said, &quot;How can we &#8216;brand&#8217; a framework and get some sort of ROI?&quot; and ended up with Spry.</p>
]]></content:encoded>
            <pubDate>Sun, 24 Dec 2006 01:49:44 GMT</pubDate>
        </item>
   </channel>
</rss>