<HTML>
<BODY>
Salvete!<br>

<br>

<br>

&gt;I find it totally undesirable to make or maintain any changes in the cataloging module for the purpose of <br>

&gt;going HTML-only.  <br>

<br>

<br>

            Forgive me if I'm wrong, but my sense was that a change or changes would be made with paucity of code and processing time in mind. It was an optimisation suggestion.<br>

<br>

<br>

&gt;<br>

 Your sense of server-side processing advantage may or may not translate to an <br>

&gt;advantage in actual environment constraints.   Consider that adding a repeatable field would have to <br>

&gt;constitute a new request and response for each element, parsing the marcxl each time, aggregating form <br>

&gt;state changes in some yet undefined table.  The server might validate the end results faster, but getting <br>

&gt;there just became 30 times as expensive and you still need to round trip to the server to get the results.<br>

&gt;<br>

<br>

             Is that 30 times rooted in fact? Also, from what is being described, it seems as though the long wait for the record's finalisation would be traded for a few shorter waits upon edit. Do I have that right Rick?<br>

<br>

<br>

&gt;I'd wager that exactly zero of our clients would prefer scriptless cataloguing, and would likewise be upset <br>

&gt;for Koha to sacrifice scripted features for it.<br>

<br>

<br>

             I'd reckon none of your clients would care if the job were done, and a whole bunch would be happier were the job done quicker. I don't think anyone was calling for a full sack of JS, just suggesting a well intended tinker to see if we can slim down an ugly just under a minute wait. Have you tried this your way Rick? I'd love to see side by side optimised versions to see what the pitfalls of both were.<br>

<br>

 <br>

&gt;Cataloging is already a huge amount of logic. Duplicating the plugins to operate cleanly as server-side <br>

&gt;validators would be a major undertaking in itself, and be more likely to introduce runtime warnings and <br>

&gt;fatals.<br>

<br>

<br>

             True, but I'm always all ears about making cataloguing better. What we have now is rather undesirable. I don't think anyone hinted that tinkering with or improving cataloguing was easy. :)<br>

             For pros, (and it's been a while since I looked, so maybe this is implemented, but I don't think so) would it save querying time if there were a simple text box where one edited an entire MARC compliant or single original record? I didn't have a text box for every field with III, just a big old text box with a record. It seems to me as though this would shift the processing burden to the server, as well, and probably save time in the end. I realise the initial outlay of coding time would be substantial, but the friendliness to experienced users would most likely be worth it. Usability would be oh so much better, too. (I still need to find the right star to wish on for guided cataloguing for non pros :) )<br>

<br>

Cheers,<br>

Brooke<br>

<br>


</BODY></HTML>