Full-text search in htdocs folder

[radelphe]

Hi there!

 

I have many text files (log files from another application which I want to link to some wiki pages) in my htdocs folder.

And now, I would like to do a full text search on that folder (htdcos).

I can't find any plugin that can do such search.

 

Could you give me a hint, how to do it please? It would be nice if it could be included on the "Search" box in trac.

 

Thanks,

radelphe

[Rajagopal Swaminathan]

Greetings,

On Fri, Oct 12, 2012 at 10:31 PM, radelphe <rade...@gmail.com> wrote:
> And now, I would like to do a full text search on that folder (htdcos).
> I can't find any plugin that can do such search.
>
> Could you give me a hint, how to do it please? It would be nice if it could
> be included on the "Search" box in trac.

Being a lurker, I am not sure.

But lucene seems an interesting option.

Of course, I realise it is Java based and all that.

Perhaps, other options:
http://codecanyon.net/item/gogoooose-superior-fulltext-search-engine-script/132942


http://devzone.zend.com/26/using-mysql-full-text-searching/

hth

--
Regards,

Rajagopal

[Steffen Hoffmann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think it's only one part, how to search through these files.
The other part is about proper integration with Trac search (not
TicketQuery).

For the latter, look at the ISearchSource extension point interface.

Steffen Hoffmann

[1]
http://trac.edgewall.org/wiki/TracDev/PluginDevelopment/ExtensionPoints/trac.search.api.ISearchSource
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlB5bboACgkQ31DJeiZFuHfeggCfQD0mOgP895JzCKIkHwYWEe/G
rS0AoIuXw0DNRP3Js6XQHeRgy9p3ZTwS
=KY/0
-----END PGP SIGNATURE-----

[Adelphe Rafanambinana]

Thanks for your replies

I really want to include it with Trac Search.

I read the doc about ISearchSource extension point interface, but I need your guidance to apply it.

In the meantime, just to get it working, I'm using Ksearch (http://www.kscripts.com/) to do the full text searching.

 

But as I said above, I'd like to have a solution integrated with Trac.

 

Steffen, could you be more specific please on how to do it?

 

Thank you, 

--
You received this message because you are subscribed to the Google Groups "Trac Users" group.
To post to this group, send email to trac-...@googlegroups.com.
To unsubscribe from this group, send email to trac-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.

--
Adelphe Rafanambinana

[Steffen Hoffmann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 13.10.2012 19:09, Adelphe Rafanambinana wrote:
> I really want to include it with Trac Search.
> I read the doc about

> /ISearchSource/<http://trac.edgewall.org/wiki/TracDev/PluginDevelopment/ExtensionPoints/trac.search.api.ISearchSource#ExtensionPoint:ISearchSource> extension

> point interface, but I need your guidance to apply it.
> In the meantime, just to get it working, I'm using Ksearch
> (http://www.kscripts.com/) to do the full text searching.
>
> But as I said above, I'd like to have a solution integrated with Trac.
>
> Steffen, could you be more specific please on how to do it?

You have some examples of ISearchSource implementations in existing code
at trac-hacks.org. I know, because I wrote one myself for
TracFormsPlugin. But sure, I may as well step you through the process of
an Trac extension point interface implementation. Be prepared to do some
coding work and testing on your own. Our help comes without payment, but
never for free. Rather see it as help to help yourself and others, ok?

Go back to the aforementioned wiki page about ISearchSource, please.
It's the second-best authoritative information you can get, only reading
the source itself could be more instructive. Trac source aims at being
self-documenting, quite instructive to developers.

The first method.

# ISearchSource methods

def get_search_filters(self, req):
yield ('usernames', 'User Names', False)

In wiki you read:
"The implementation reports the supported filters and whether they
should be enabled by default."

So you give an inplementation internal name, label and mandatory flag.
You can certainly do that now for your 'htdoc-files'.

The second method.

def get_search_results(self, req, terms, filters):
if not 'usernames' in filters:
return
with self.env.db_query as db:
sql_query, args = search_to_sql(db, ['sid'], terms)

for name, last_visit in db("""
SELECT sid, last_visit FROM session
WHERE authenticated=1 AND """ + sql_query, args):
dt = last_visit if last_visit else datetime.now(utc)
args = '?owner=%s&or&reporter=%s' % (name, name)
link = req.href.query() + args
yield (link, name, dt, '', '')

Sure, this is quite complex at first sight, but let's cut it into
pieces, and you'll see, how it works. Adoption for your resource should
be next to trivial then.

Initially it has a bypass for the 'not-selected' case. You'll want to do
similar for 'htdoc-files', or however you named your resource in the
first method.

Then the example implementation prepares a Trac db connection. This is
almost irrelevant, because your file search logic will probably not use
SQL instructions, right? This part is about returning
* a valid resource URL (in your case pointing to a file in your htdocs)
* resource name (the filename)
* some time stamp as timezone-aware datetime object, commonly used for
last-changed or similar information related to the resource (could be
changetime of the file, if you care)
* author information (file owner)
* excerpt with match and a bit or surrounding text

The example above doesn't tell you the last two points, but other
implementations could, if you looked at their code. Still there's
something to learn here: Things you can't provide or don't care, should
be replaced by the empty string. Be sure that your implementation still
yields exactly tuples of these five items.

Please note the hint on the wiki page about utility methods in
trac.search.api module, that provides helper functions often used to
implement the search itself and to format results appropriately.

Hint: The last should have explained, why you should include a line like
the following in your plugin source:

from trac.search.api import ISearchSource, shorten_result

Hope, that will get you started.

Steffen Hoffmann

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlB5voEACgkQ31DJeiZFuHezSQCfZtJ0l6SLsZKVF1XgilYid2Zf
gqcAnAzOvlRUIUHxE3I2PTC9MaidpHsN
=iljP
-----END PGP SIGNATURE-----