[OPEN-ILS-DEV] Rethinking "no Dojo" in TT OPAC

[Mike Rylander]

+1

That is all.

Thanks, Dan!

On Tue, Jun 14, 2011 at 10:09 AM, Dan Scott <dan at coffeecode.net> wrote:
> In going through the TT OPAC and seeing where JavaScript has been used,
> there's a statement in web/js/ui/default/opac/simple.js "/* Keep this
> dead simple. No dojo. */"
>
> Although I understand the desire to avoid the JavaScript monstrosity
> that our classic OPAC has turned into, I would like to reconsider the
> "No Dojo" policy in the TT OPAC.
>
> At 31 KB, Dojo base offers CSS3-based queries, DOM manipulation,
> an event framework, and more with routines optimized for each browser;
> and Dojo offers documentation and tests. (Yes, jQuery fans, jQuery is
> also 31 KB and offers pretty much identical functionality - the reason
> I'm not proposing it here is because we have an extensive existing
> amount of Dojo-based functionality and experience to build on).
>
> simple.js is currently 1.5 KB and doing raw DOM operations; staff.js is
> smaller at close to 1 KB but contains the seeds of a custom event
> framework. (Yes, I realize these are uncompressed sizes vs the Dojo base
> compressed size, but it's what we're currently serving up.) One could
> argue that simple.js and staff.js are self-documenting, because they're
> still relatively small -- but they're also still relatively young and
> seem likely to grow. There is also custom JavaScript sprinkled through
> the TT OPAC touching window.onload() and the like.
>
> With the TT OPAC, we could adopt a current version of Dojo (1.6, with
> 1.7 on its way) and move past some of the bugs we've had to work around
> with the 1.3 release to which we're currently tied in the rest of
> Evergreen.
>
> Again, the idea is not to build lots and lots of functionality into the
> TT OPAC using JavaScript. The goal of making everything work fast and
> light without JavaScript must continue to be the front and centre goal
> for the TT OPAC. Rather than rolling our own JavaScript framework, I
> would like to consider using a standard, optimized, cross-browser
> JavaScript framework for those times when we do want a JavaScript
> flourish (cursor focus set to the search text box, for example).
>
> (Aside: have we written down a set of design goals for the TT OPAC
> anywhere that contributors should try to adhere to? Is "all core
> functionality must be available with JavaScript disabled" an explicit
> goal, for example? One current issue is that the search textbox
> default text "Search keyword" gets in the way when JavaScript is
> disabled, for example, suggesting that the default text should also be
> added via JavaScript to avoid hampering usability in a non-JavaScript
> environment.)
>



-- 
Mike Rylander
 | VP, Research and Design
 | Equinox Software, Inc. / Your Library's Guide to Open Source
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker at esilibrary.com
 | web:  http://www.esilibrary.com