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 
 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](http://blog.ploeh.dk/2014/05/19/di-friendly-library/) and 
[here](http://blog.ploeh.dk/2014/05/19/di-friendly-framework/) 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: https://issues.apache.org/jira/browse/LUCENENET-565
>             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

Reply via email to