Replies: 4 comments
-
|
Makes complete sense. @malliaridis FYI, your thoughts please.
…On Wed, 23 Oct, 2024, 8:39 pm Helen, ***@***.***> wrote:
As you remember from Solr 8.x Data Import Handler had it's own UI
interface to communicate with functionality of the application feature,
starting from Solr 9.x, I don't remember that what version. It was removed
from the UI of the Solr and main application team refers to current team
for a UI feature.
What do you think about that to create an injectable UI module for new
interface, since current version of UI interface is outdated and no longer
supported, so for a future UI it will support UI modularization with Api
that allow extend with plugins/modules that has it.
—
Reply to this email directly, view it on GitHub
<#84>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABDCR5DOXJBYV4H2GJM2LYLZ4632ZAVCNFSM6AAAAABQPB2FP2VHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZXGM2TQMBQGA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
The packages framework actually supports arbitrary JS/HTML to work. Assuming your DIH UI was all self contained, then you could deploy it as part of the package. Here is an example of this in action. We take the entire JS/HTMl app that powers http://splainer.io, and package it up as a Solr specific package: https://github.com/o19s/splainer/tree/main/solr-splainer-package. Works GREAT. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the ping @chatman. Modularization in the current POC of the new Admin UI is one of the key features. However, when it comes to extendable UI applications via third-party modules, each target (currently wasm and jvm) in a multiplatform app may have its own constraints and challenges. Supporting dynamic loading of such "plugins" would not make it easier. A plugin architecture is quite an interesting and complex topic, and it would require a lot of research in case of the current stack of the new UI. I am less worried about whether it is possible or not, and more worried about the maintenance and complexity behind that. I believe that an approach similar to Splainer and YASA would be easier and quicker to implement. And since it is already spported, no action is necessary from Solr side. Additionally, if there is an API for these packages, the new UI could potentially include a reference section where these extensions are listed in the UI, improving the discoverability and accessibility for the user. |
Beta Was this translation helpful? Give feedback.
-
|
@Helen-JS if you go down the route of the packages the way Splainer does it, and need some review/help, please do ping me! |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
As you remember from Solr 8.x Data Import Handler had it's own UI interface to communicate with functionality of the application feature, starting from Solr 9.x, I don't remember that what version. It was removed from the UI of the Solr and main application team refers to current team for a UI feature.
What do you think about that to create an injectable UI module for new interface, since current version of UI interface is outdated and no longer supported, so for a future UI it will support UI modularization with Api that allow extend with plugins/modules that has it.
Beta Was this translation helpful? Give feedback.
All reactions