Using jQuery instead of Prototype (ESI Blocks)

[moofresh]

I'm using jQuery instead of Prototype in my Magento install.

Getting this error:

ReferenceError: Ajax is not defined

Which I think is related to the Prototype-looking js in this file:

app/design/frontend/base/default/template/turpentine/ajax.phtml

Which is this code specifically:

echo sprintf( '<div id="%s" style="display: none">
<script type="text/javascript">
new Ajax.Updater(
    "%s",
    "%s",
    {
        method: "get",
        evalScripts: true,
        %s: function(transport) {
            $("%s").appear({
                duration: 0.3
            });
        }
    }
);
</script>
</div>
',
    $blockTag,
    $blockTag,
    $this->getEsiUrl(),
    ( $debugEnabled ? 'onComplete' : 'onSuccess' ),
    $blockTag
);

Does anyone have a jQuery version of this file?

[steverice]

This is addressed in pull request https://github.com/nexcess/magento-turpentine/pull/324. Ideally this logic should be written in native JavaScript to eliminate the dependency on any one library — but it may be that replicating all of the XHR shim code provided by Prototype/jQuery makes this undesirable in terms of byte size.

Perhaps the solution is to provide separate templates — for Prototype, jQuery, other libraries, and native — and allow the store owner/developer to choose between them in layout xml / config.

[gondo]

personally im a big fan of jQuery over Prototype, but this should not be merged! Magneto is currently using only Prototype everywhere and this would cause overhead for many projects not using jQuery.

[moofresh]

Thanks Steve, this is great. I only use jQuery in my Magento install (I realise this is not default Magento practice) and this nicely replaces the ajax updater Prototype functions.

[steverice]

@gondo I made the overhead minimal while still keeping the code readable — having a build process produce a minified version should make the difference between the Prototype-only and Prototype/jQuery versions negligible. I agree in theory that it is wasted code, but I think the tradeoff for out-of-the-box compatibility is worth it.

[gondo]

@steverice i understand and in theory it sounds nice, but in real, not many ppl use or not even understand this. my point is, once you go down this path, whats stoping you from creating similar code for Dojo, YUI ... this can be great addition on a separate jQuery branch but not as part of the main code base.

[steverice]

Makes sense. As before, I think the best solution would be to have library-agnostic code (if its size is reasonable), or to have separate, configurable templates depending on the library you're using.