Github user NightOwl888 commented on the issue:
https://github.com/apache/lucenenet/pull/209
> Happy to contribute if that'd help at all.
There are definitely [a lot of
things](https://github.com/apache/lucenenet/blob/master/CONTRIBUTING.md#other-ways-to-help)
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.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
