<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">>> there just became 30 times as expensive and you still need to round<br>
>> trip to the server to get the results.<br>><br>
> Is that 30 times rooted in fact? <br></div></blockquote><div><br>It isn't implemented, so it is hypothetical, but there isn't any way around *every* operation requiring a round trip to the server w/o js. Do some original cataloging, count how many times you change tabs, search for an authorized value, and add/remove fields. <br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">It is disingenuous to whine about return trips to the server when<br>
</div>
Koha is already littered with such in the form of Ajax calls, which<br>
sometimes for each keystroke invoke a return trip to the server.</blockquote><div><br>Uh, no. It's legit. Especially on the staff side, Koha would benefit from *more* ajax, not less. When the logic of a webapp can be broken into ajax-able atomic pieces, then each of those can execute and reply with very small updates without having to reparse everything else on the page that isn't changing. <br>
<br>As a simple (hypothetical) example, building a list gets really expensive if you have to read out the growing list AND all the other elements of the page to the client for every item loaded. With ajax you can get confirmation from server as terse as one line. The non-ajax method doesn't scale. It gets slower as the list gets bigger until the point where it is too slow to use. The ajax method can maintain the same performance at the 1000th request as the first, because it doesn't have to care about the last 999. <br>
<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Example: some of the Koha searches update a textbox / dropdown control with new search possibilities each time you hit a key on the keyboard.</blockquote>
</div><br>Those YUI autocomplete calls aren't parsing MARCXML into MARC::Record
objects like the cataloging editor must, and they can already be
disabled by syspref. YUI autocomplete performs reasonably well for us
and the thousands of other sites that use the package. And, lastly,
ajax has nothing to do with the cataloging editor anyway. It doesn't
use it. <br><br>You are comparing two clearly different entities. HTML-only cataloging with anything approaching the current features would require repeated expensive MARC parsing, aggregating the cataloger's manipulations in an unspecified location, all the existing permissions checking for toolbars and HTML::Template::Pro building, etc. That looks nothing like optional industry standard AJAX autocomplete that hits ysearch.pl, querying one table and running in 60 lines.<br>
<br>-- <br>Joe Atzberger<br>LibLime - Open Source Library Solutions<br>
<br>