Hi Roman, in the case of bibedit: there will be a "full" value in the field very often when the user enters the field. What's your idea of how the jQuery plugin should behave in such a situation?
An unrelated note: we probably still need another module (already implemented in bibedit) for the "lookup" behaviour. This means: enter an acronym -> the value of the field becomes the words the acronym stands for. Or could this be done with your plugin, too? Yours, Marko On Tue, Jun 8, 2010 at 11:30 PM, Roman Chyla <[email protected]> wrote: > Hi Sam, > > I definitely agree on synchronizing our efforts - i checked some code > inside cds before starting, but i wanted more. Victor started his > autocomplete effort few days later after me, and we later discovered > we both were working on the same. > > I will reply, excuse me if I miss some questions > > > i checked other implementations: > http://www.google.com/search?q=jquery+autocomplete&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-GB:official&client=firefox-a > > my first go was with the first hit, but it while it worked, it was > harder to add more functionality to it > > i didn't like the 3 hit, and i thought the jQueryUI would be better as > there is wider community and newer version > > frontend is modified jQueryUI - autocomplete -- modified, because at > certain point i hit a wall - i was implemententing everything like > overrides (monkey-patching, i didn't want to touch the jQueryUi), but > it was very hard and as i said, at one point, it wasn't possible to > access certain objects without terrible hacks. so i rather forked the > whole thing > https://svnweb.cern.ch/trac/rcarepo/browser/newseman/trunk/tmp/dumean/jqueryui/ui/jquery.ui.autocomplete-rca.js > > you may see better ways, which i haven't seen > > as for the backend, it is NOT java, but python (even if we use lucene > - so yes, it is java, but inside python - that is important thing, and > should be kept in mind) > > there are several implementations - not only keywords, try the > fulltext, authors or display the index-6.html > https://svnweb.cern.ch/trac/rcarepo/browser/newseman/trunk/tmp/dumean/fulltext.py > > the communication is done via json, the structure is: > > [{'label': lepton, 'value': 'something=lepton', 'data': 'anything you > want...'}, {...}] > > the 'keyword:lepton' thing you mentioned is to show that we can build > a special query like: keyword:lepton OR abstract:lepton* -- just an > example, besides things are easily configurable through hooks. look > inside the html source and you will notice several functions and also > the several backen urls > > you can see for yourself the code, before i have time to describe the API: > > whisper.py -- this does the searching > keyword.py, fulltext.py.... - different adaptors of whisper.py for > specifi purposes > reindex.py - this builds the autocomple indexes > index-6.html -- example of the better autocomplete (different than the > previous) > js_included -- this is the part that is included by invenio into > template (at runtime) > > and yes, the UI has a few glitches still, but i haven't found any > jquery implementation of what was needed. but in my opinion, it is a > flexible solution > > Cheers, > > roman > > On Tue, Jun 8, 2010 at 10:44 PM, Samuele Kaplun <[email protected]> > wrote: >> Hi, >> >> Il giorno mar, 08/06/2010 alle 17.18 +0200, Marko Niinimaki ha scritto: >>> We discussed around noon that Roman will describe the API that his >>> system is using. The back-end is currently Java, but we may want to >>> interface it with Python in all the modules that you mentioned. >> >> OK I will wait to see the API. And hoping we can in the end agree on one >> javascript front-end to use. >> >> BTW have you checked, as I was mentioning, JQuery UI implementation? How >> do you compare it with the specific JS you decided to use? PROS? CONS? >> >> Cheers, >> Sam >> >> >
