Hi Marco,

> in the case of bibedit: there will be a "full" value in the field very

Maybe the author index toy-example already does something similar, if
you look at it closer, you will see that we are sending
'inappropriately big amounts of data' -- basically, all the author
names (limited . So, I think sending the full field value, even the
full record is possible

> often when the user enters the field. What's your idea of how the
> jQuery plugin should behave in such a situation?

I would think less data is better

>
> 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?

Yes, that can be done with the plugin.

Best,

roman

>
> 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
>>>
>>>
>>
>

Reply via email to