[dev] [cvs] commit: imp/lib Compose.php imp/templates/prefs sourceselect.inc

[Michael M Slusarz]

Quoting Chuck Hagenbuch <chuck at horde.org>:

> Quoting Michael M Slusarz <slusarz at horde.org>:
>
>> Here's my thoughts after sleeping on this:
>> 1.) Non-AJAX expansion can only occur if search_fields is equal to  
>> 'name' and 'email'.  Any other search_fields requires AJAX  
>> expanstion.
>
> Why not just pull the fields that are set to be searched, either way?

Autocomplete.Local can only search the text it displays.  We need to  
display an RFC-822 compliant e-mail address on autocomplete, so the  
only data we can send locally.

>> 2.) Non-AJAX expansion would only occur if a user has below a  
>> certain threshold of entries in his addressbook (200?).  We could  
>> do this threshold check once per session and use the results for  
>> the rest of the session (ignoring any adds/deletes from the  
>> addressbook in that session).
>
> Ignoring adds/deletes during the course of a session seems very  
> counter-intuitive to me.

I guess I didn't make myself clear.  Ignoring adds/deletes only goes  
to whether you get a local (i.e. browser search) or you get AJAX  
searching.  Meaning if you login and do your first search when there  
are only 199 addresses in your book, you will get local searching  
until you logout, even if you add 300 subsequent addresses during the  
session.  Likewise, if you have 201 addresses on your first  
autocomplete load, then delete 50 addresses, you still will get AJAX  
searching the entire session even though it is technically below the  
threshold.  This just prevents us from having to do addressbook  
queries (typically SQL) just to get an address count, which might not  
be the lightest operation possible.

> 200 seems like a reasonable guess at a limit, though it's worth testing.

Agreed.

> I assume the issue here is bandwidth, not the backend search time?  
> In that case the ability to compress the list (gzip compression)  
> would be very helpful and might get the limit higher. The list could  
> also be served as a standalone json file with proper caching  
> headers, to allow not delaying the loading of the overall compose  
> screen.

The main gain is speed and responsiveness from the UI side.  And doing  
multiple AJAX requests to the server when autocompleting is definitely  
not a light operation server-side - each request requires us to  
set-up/tear-down a session, which is not cheap, in addition to the  
overhead of doing multiple searches that can easily be done using the  
user's CPU power instead.

>> 3.) Looking at scriptaculous' controls.js (the file that contains  
>> the Autocomplete code), about 60% of that file is dedicated to an  
>> AJAX in-place editor that we are not using.  It is a substantial  
>> bit of overhead that we don't need, so I think I am going to break  
>> out the autocomplete code into a separate file.  Considering a  
>> possible future goal is a rewrite of the autocomplete code anyway,  
>> this is something that would eventually happen anyway.
>
> That seems reasonable to me as long as the rewrite does happen; we  
> wouldn't want to distribute modified scriptaculous code in any case  
> (i.e, we shouldn't call either split-out version controls.js, I  
> think).

Well, I've already done the same for dragdrop and slider code in DIMP  
- they were originally based on scriptaculous but I broke them out  
into new include files (although with these, I heavily modified to  
remove a bunch of cruft).  The MIT-license is very nice in allowing  
this sort of rewrite to happen.  In the present case it is less  
removing cruft (the Autocomplete code is better written than the  
dragdrop code, for instance), but loading a file with 60% code that we  
don't use at all is enough of a waste that it does make sense to cut  
this extra code out (especially since it will affect runtime in slower  
running js virtual machines, such as IE 6/7).

My desire would be to move away from scriptaculous in general; I am  
not very impressed with either its coding style nor the ongoing  
support.  Once we start to deviate away from the stock autocomplete  
stuff (if we decide to go that way in the future), the only remaining  
part of scriptaculous we will be using is the effects stuff.  The  
effects stuff is universal enough, and stable enough, that I don't  
foresee a reason for jettisoning that code.

michael

-- 
___________________________________
Michael Slusarz [slusarz at horde.org]