lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (LUCENENET-565) Port Lucene.Net.Replicator
Date Tue, 08 Aug 2017 17:04:00 GMT


ASF GitHub Bot commented on LUCENENET-565:

Github user NightOwl888 commented on the issue:
    > Happy to contribute if that'd help at all.
    There are definitely [a lot of things](
you could do to help and it would be much appreciated. Not just with `Lucene.Net.Replicator.AspNetCore`
when Jens completes his end, but there are a lot of new development tasks I would like to
do to make the API more palatable before calling this "released". It dawned on me that if
2 people create a folder with the same name (`src/dotnet/`) on 2 different branches, there
won't be a conflict since Git doesn't track folders anyway. So that is not a blocker for doing
this work.
    As I previously mentioned, I think we should have an integration package for each major
UI framework (both thick and thin client) so we can wire up the boilerplate stuff in "the
normal" way for that framework. Certainly, creating packages like `Lucene.Net.AspNetCore`
and `Lucene.Net.Owin` (or MVC?) are up for grabs, starting with creating a fluent way to setup
an index writer and/or reader at application startup, and working out what other stuff is
common boilerplate code that we could save others from having to research when setting it
up. There should also be some UI components to plug in to make adding the most common search
features to applications easier - I am being vague here, because this will take some discovery.
    Also, the most common 3rd party NuGet package is a Document - POCO mapper. This is high
on the list of things to create a built-in solution for that will ultimately find a place
in every one of the UI framework modules. It seems to me that taking a good hard look at the
MVC `ModelBinder` implementation would be a good place to start with this. We should make
it work by default with conventions like `ModelBinder`, but be able to override the defaults
using .NET Attributes (being that we have both a `TextField` and a `StringField` that could
map to a string property, etc.). Do note there is a `LazyDocument` implementation in `Lucene.Net.Misc`
that is read-only and we wouldn't want to block its use in any way.
    Then of course there are the fun ones - UI integrations with Highlighter, Suggest, and
Facet. At least the latter two may require some front-end JavaScript work for thin clients
to create the customizable boilerplate implementations so they don't have to be re-invented
by every consumer. Or, there may already be some great JS plugins we can use/recommend. Plus
we will need similar integration components with thick clients with similar goals. I'd like
to try to avoid the "experimental" JS frameworks that could evaporate tomorrow and use popular
frameworks like JQuery and Bootstrap (or others that most people have heard of), but we should
cater to the SPA crowd, too. It seems like this could be a very deep rabbit hole if we created
a package for each SPA framework, but if we do one I am sure that others might contribute
more for their framework of choice.
    BTW - when dealing with the DI stuff, there are a couple of great articles [here](
and [here]( which are helpful (plus
he wrote a great book, Dependency Injection in .NET). I'd like to try to avoid using statics
for this stuff if at all possible and allow for as much interop with DI containers as possible.
Coming up with a good solution for a singleton IndexWriter (which is Disposable) for some
of the older web frameworks when they are not using DI is a bit of a challenge.

> Port Lucene.Net.Replicator
> --------------------------
>                 Key: LUCENENET-565
>                 URL:
>             Project: Lucene.Net
>          Issue Type: Task
>          Components: Lucene.Net.Replicator
>    Affects Versions: Lucene.Net 4.8.0
>            Reporter: Shad Storhaug
>            Priority: Minor
>              Labels: features

This message was sent by Atlassian JIRA

View raw message