You might have noticed that in various sites if you give your UserID first time, the next time you come to fill your UserID, the browser auto-suggestions it.

Of course you can clear your browser's form data (in IE) or form & search history (in Firefox) but wouldn't it be better if we turn this feature off ? This especially becomes a necessity when inputing sensitive data such as bank account number, Debit/Credit Card number etc on a shared computer. In such cases, another user at a later time visiting the same site would be presented with your data through autocomplete suggestions.

So how do we prevent browsers from suggesting it ?

The solution is to add autocomplete="off" attribute to textbox tag, which will help to stop auto suggestion behaviour for that particular textbox.

And if you want to stop that behaviour for all the textboxes that are present inside a form then add autocomplete="off" attribute to form tag.

According to HTML specifications, autocomplete is an unrecognized attribute which was originally created by Microsoft (feature of remembering what you have entered in previous text fields with the same name, available first in Internet Explorer) and has adopted by all other major modern browsers (except Opera).

[link:www.mindfiresolutions.com]

By on 6/9/2010 2:14 AM ()

The only time I've done something similar was in C++ and I used a Patricia Tree. It worked fairly well. However, since in my application I didn't need to look up every possible prefix, just selected prefixes, I've since started using a hash map of the selected prefixes. (The performance is slightly better in my application, but mainly, the code maintenance is lower since I use the built-in .NET generic.)

I'm relatively new to F# (a few months) and I think that writing a Patricia Tree in F# would be a challenge but not at all unthinkable.

I'm just getting ready to start mingling F# and C# data structures for a proof-of-concept I'm doing, so I'm just about to learn whether that's painful or not, lol. (But I really suspect not.)

-Neil

By on 6/1/2010 7:54 AM ()

A very evil person was kind enough to share an implementation of tries in F#. I'm sure it works well for non-evil purposes too.

By on 6/5/2010 8:14 AM ()

I just started using F# classes from C#. For classes at least, if you keep in mind what things in F# are likely to translate well to the broader .NET world*, the process is absolutely painless. There is no discernable indication on the C# side that the F# classes are not simply .NET classes written in C# or any other .NET language.

-Neil

*See [i]Real-World Functional Programming[/i] by Tomas Petricek and Jon Skeet, pp.255ff.

By on 6/2/2010 8:09 AM ()

The solution is to add autocomplete="off" attribute to textbox tag, which will help to stop auto suggestion behaviour for that particular textbox.

And if you want to stop that behaviour for all the textboxes that are present inside a form then add autocomplete="off" attribute to form tag.

According to HTML specifications, autocomplete is an unrecognized attribute which was originally created by Microsoft (feature of remembering what you have entered in previous text fields with the same name, available first in Internet Explorer) and has adopted by all other major modern browsers (except Opera).

[link:www.mindfiresolutions.com]

By on 6/1/2010 4:07 AM ()

Hi Matt,

Interesting questions.

1. Is doing this in F# a good idea?

My gut reaction says no, put the data in a relational database slap some indexes on the apporiate columns and let the db take the strain. However if you really think a hand code solution would be better F# is generally good at tree mainipulations and that sort of thing.

2. Is doing this in F# a good idea?

Wouldn't have thought so. I suppose you may see a few more allocations and therefore objects that require collecting if you stick to a very pure functional apporach and use lots of immutable data structures, but the GC in .NET is self tuning and you should see that it handles this quite efficently. The preformance counters in .NET are very good so you can easily profile your app and using perfmon to see if there is too much time spent in GC and adjust the app accordingly. But I wouldn't think you'd need to.

3. Is using an F# data structure from C# painful?

It can be but doesn't have to be. The answer in a nut shell is, union types and tuples look a bit strange form C# records and basic types like strings look fine. I cover this in detail "Foundations of F#".

4. Anyone got an implementation they'd like to share?

No sorry.

Cheers,
Rob

By on 6/14/2007 10:43 PM ()

Rob,

The running the query in the database isn't really an option because of the usage model of auto-complete boxes. I'm going to need response times under 1/5th of a second for the textbox to seem "live" to the end user (excluding whatver the overhead of going over the wire is). Even if the database could query that quickly (and I don't think it can..read on for why), the overhead of a remote call with query hashing/parsing and marshalling the return results takes a fair bit of my time window.

I'll be firing a request for prefix matches ever 1/3 or a second or so so there will be a high volume of queries in short bursts. Additionally, I'm doing prefix matches (i.e. typing "M" will suggest "Matt", "Mike", "Mark", etc.), so my database indices won't be used (I'm not aware of a database that supports non-deterministic function indices - I'd be surprised if it were possible). Although, as I write this, it occurs to me that I should look at Oracle's full text indexing capabilities.

Thanks for the response, Rob. By the way, both of the APress F# books are on my Amazon wish list

Regards,
Matt.

By on 6/15/2007 6:44 AM ()

I'm pretty sure indices are taken into account when query char and varchar colomns using the like clause. Crucially your only ever searching form the begining of the string which is the way the index is order so the index can be helpful. The "example 1" shown on this page seems to agree with what I'm saying: [link:www.mssqltips.com]

However your right that all those queries to the database would not be a good thing. I might still be temped to query the database for the first or two characters then go on to sort though the returned list using F# for the rest. However this does run the risk of the same set of data being dragged into memory many times, say if lots of people start searching for a name that begins with M. You could use some sort of results caching mechanism, maybe using the caching block in enterprise library ([link:www.microsoft.com]), but that can quickly become complex engough so that it is of no benefit. So one big readonly data structure might be the way to go, though I think above a certain size of data structure it would probably become more practical to use a database.

It's an interesting problem so it would be interesting to code it up a few different ways and see which one worked best.

Cheers,
Rob

By on 6/15/2007 7:43 AM ()

Rob,

I apologize - it appears that I simplified my problem statement a bit too much. Your statement about index usage is correct but for several reasons (and by the way, this is Oracle), indices cannot be structured so as to avoid a full scan in all cases, even when taking multiple function indices into consideration. Suffice it to say that I need to match on strings from several columns and the characters are not always at the beginning of the string.

If I'm going to be caching on my app server and the volume of data is sufficiently small, I figured I might as well load the whole dataset into memory and rebuild it once in a while in the background. Additionally, the javascript in the browser uses an LRU cache so that pressing backspace doesn't trigger another search request.

Regards,
Matt.

By on 6/15/2007 8:48 AM ()
IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy
Built with WebSharper