Dnn.platform: Prompt core classes are in the wrong place

[donker]

The feedback from my presentations about prompt highlighted one issue: since the PersonaBar is an optional component of DNN no module developer will ever make any Prompt commands as you're taking a dependency on something that might not be there.

The core mechanism of Prompt should not reside in an optional component. Instead, it should be part of the core library so that module developers can safely build on top of this.

[ohine]

I'm split on this. I like the separation between the core platform and the administration side of things.

I can see clients who would want the possibility of removing or replacing prompt with something else, or even the possibility of running dnn without any administration components loaded on a public webhead.

[erikvb]

I'd say there are 2 parts to this... Any part of prompt that is only used in the actual prompt component in the personabar should remain there. But the logic that other modules would need to also support prompt should be in a core library

[bdukes]

I agree with @erikvb, the commands should not live inside the PersonaBar, only the UI

[donker]

There are three parts to Prompt (currently):

1. The core classes needed to make commands (in the AdminExperience.Lib project)
2. The entrypoint for Command (WebAPI service) and logic to look up a command (AdminExperience.Ext Prompt project)
3. The various commands (e.g. List-Users). This is currently in AdminExperience.Ext solution and then the project for that item.

Ad 1: Any developer that wishes to include commands with their code will need to take a dependency on AdminExperience.Lib project which may not be there. So this won't work. My point above mainly concerns this.

Ad 2 and 3: It's not the end of the world that it is here. But I propose that one day we should be able to have a headless DNN. This means that the PersonaBar Prompt project should just be focused on UI. The WebAPI service would move closer to the framework itself. In line with this I'd also prefer to keep the command logic "closer" to the correct place in the framework. I.e. user commands in Entities.Users.

For me the latter discussion is tied to a rewrite and dotnetcore. The first is paramount to even kicking off Prompt, so it should be done asap.

[vmasanas]

I agree with you @donker and @erikvb on this. It doesn't feel rigth the current placement of classes for prompt commands

[ashishpd]

Any change in the namespace will result in breaking changes, which we don't want to do unless we want to have a forward from the current location to the new one while deprecating the current version.

[erikvb]

Well, we would copy, not move, and mark old classes deprecated

[donker]

@Ash: this stuff got introduced in 9.2. No one knows yet how to make commands (I am tasked with explaining this). But if the group feels necessary we'll just wire through. The fact is this was screwed up and needs to be repaired.

[mitchelsellers]

At this point, to meet the obligation that we made to the community we would need to flag the old stuff as deprecated in 9.2.x and to be removed in 11.x. But I agree, the current location doesn't make sense.

[donker]

I propose that we let this rest for now. It would create yet more code to maintain and migrate.

In a more distant future I believe we will be creating a new API from the ground up. So in that library I propose to follow a pattern where we keep all methods relating to aspect X of the platform in the same place. I.e. WebAPI, Prompt and API. And to have the core Prompt mechanism in that library as well.

[stale[bot]]

We have detected this issue has not had any activity during the last 90 days. That could mean this issue is no longer relevant and/or nobody has found the necessary time to address the issue. We are trying to keep the list of open issues limited to those issues that are relevant to the majority and to close the ones that have become 'stale' (inactive). If no further activity is detected within the next 14 days, the issue will be closed automatically.
If new comments are are posted and/or a solution (pull request) is submitted for review that references this issue, the issue will not be closed. Closed issues can be reopened at any time in the future. Please remember those participating in this open source project are volunteers trying to help others and creating a better DNN Platform for all. Thank you for your continued involvement and contributions!

[sleupold]

this still needs to be taken care of.