Skip to content

Add plugin support for other templates languages #102

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 34 commits into from
Jan 22, 2025

Conversation

sarahelsaig
Copy link
Contributor

@sarahelsaig sarahelsaig commented Dec 7, 2024

I've thought this through, and I think Roslyn C# script plugins make the most sense. (also to make it work with DLLs you'd have to publish OrchardCoreContrib.PoExtractor.Abstractions to NuGet as a separate library package - probably not worth the effort) I've included a unit test and sample plugin that hopefully gets the point across without being too niche. (The important change is in the Program.ProcessPluginsAsync method, the rest is just plumbing.)

Fixes #101

@hishamco
Copy link
Member

hishamco commented Dec 7, 2024

I just looked into the PR and noticed a dependency on Program.cs which is wrong for me. IMHO exposing the IProjectProcessor will make the tool extendable. I am still thinking if we need the -p or if we can make the tool open some possibilities for the others to add their own options

Let me hear your feedback on this

@sarahelsaig
Copy link
Contributor Author

I just looked into the PR and noticed a dependency on Program.cs which is wrong for me.

If you mean the ScriptOptions.Default.AddReferences(typeof(Program).Assembly) here, I've only used Program to expose all the libraries to the script the tool has already loaded. As I see it, this is not a security application so we can be very permissive.
For example this way the script has access to OrchardCoreContrib.PoExtractor.DotNet.CS too, not just OrchardCoreContrib.PoExtractor.Abstractions. If someone wants to have a different take on one of the existing processors, this could be a way to have your own custom (more opinionated) solution without it affecting the main repo, while re-using the auxiliary classes that are already in those projects. I don't see the harm in it, so could you explain why it's wrong for you?

IMHO exposing the IProjectProcessor will make the tool extendable.

I think it's not possible to expose just one type, you have to expose its whole assembly. We can change the above linked code to only expose OrchardCoreContrib.PoExtractor.Abstractions instead of everything, but that feels unnecessarily restrictive.

I am still thinking if we need the -p or if we can make the tool open some possibilities for the others to add their own options.

Sorry, I don't really understand. This -p approach is the simplest way to add broad extensibility that I could think of, while being less maintenance in your code base. If you want something more elaborate without the need to use a command line switch we can discuss, but I'm not sure if it's really necessary.

@sarahelsaig
Copy link
Contributor Author

Also by importing Program's assembly the plugin developer will have access to all the of external dependencies PoExtractor has already loaded. For example if I only included the OrchardCoreContrib.PoExtractor.Abstractions, then the example plugin will fail with the following error:

error CS0234: The type or namespace name 'Json' does not exist in the namespace 'System.Text' (are you missing an assembly reference?)

So now I'd have to include #r "nuget: System.Text.Json, 9.0.0" at the start of the script, and NuGet may have to download this version if it gets out of sync from what the tool itself uses. This is annoying imo.

@sarahelsaig
Copy link
Contributor Author

@hishamco Have you seen my replies? This is not super urgent yet but it would be good if we could have a solution before year's end, because we might need it next month.

@hishamco
Copy link
Member

I didn't look into the last comment, but the PR is opened in one tab, so I need to revise it today or tomorrow to proceed

@sarahelsaig
Copy link
Contributor Author

Hi @hishamco , any news with this?

NuGet.config Outdated
<clear />
<add key="NuGet" value="https://api.nuget.org/v3/index.json" />
<add key="OrchardCore" value="https://nuget.cloudsmith.io/orchardcore/preview/v3/index.json" />
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The feed is already there?!!

Copy link
Contributor Author

@sarahelsaig sarahelsaig Dec 31, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ooops, I didn't notice. I've reverted the name.

My point was just to remove the OrchardCore source. It's not even used and because of the central package management this kept giving warning NU1507: There are 2 package sources defined in your configuration.

If you need the Orchard Core preview feed in the future, I suggest adding the full <packageSourceMapping> configuration, as you can see in OrchardCore.Commerce.

foreach (var plugin in plugins)
{
var code = await File.ReadAllTextAsync(plugin);
await CSharpScript.EvaluateAsync(code, options, new PluginContext(projectProcessors, projectFiles));
Copy link
Member

@hishamco hishamco Dec 31, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure why this is in Abstractions while it relies heavily on CSharpScript

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where should it be then?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason is that this class only relies on IProjectProcessor from this project, which is in OrchardCoreContrib.PoExtractor.Abstractions, so I imported CSharpScript's package there as well. I think it's appropriate, because this helper is related to extensibility. We can move it into OrchardCoreContrib.PoExtractor if you prefer.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've moved it to OrchardCoreContrib.PoExtractor.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not familiar with POe but anything that is related to c# plugins should be in a separate project or in the main assembly, not abstraction. No reference, no class.

@hishamco
Copy link
Member

@sarahelsaig Sorry for the late, I revised the code one more time still worried about the impact of dynamic linking, so I'm thinking for two simple approaches:

  1. Creating OrchardCoreContrib.PoExtractor.VueJs directly in the repo
  2. Reference Lombiq.VueJs to OrchardCoreContrib.PoExtractor

While this repo is Orchard Core Contrib it SHOULD help any OC project, I might think the first option is better, but I need to hear your feedback. Also, I will think for the last time about dynamic linking and its drawbacks

@sarahelsaig
Copy link
Contributor Author

Can you explain what is your worry about dynamic linking? What are the drawabacks? I don't see any impact unless you manually opt-in by using the command line switch. Otherwise I think it's safe with only very minimal overhead. I see it as a transparent improvement.

this repo is Orchard Core Contrib it SHOULD help any OC project

I fully agree with this sentiment. Note that since my original PR, I have seen other highly project-specific opportunities where this feature could be useful. In both of the cases below I could use a PoExtractor plugin to centralize other localization tech so OC can manage the actual localization and then serve it back to the associated tech. This will reduce the number of tools for the staff to learn to do the translations, and make complete translation management easier and safer.

  • We have a client project that uses OC as a headless server with a complementing node.js frontend. We could harvest the english l18n JSON files used by the frontend (similarly to the example plugin in this PR) and then serve back the other languages.
  • In the same project we also have to use a XSLT to generate some visualizations (it's a legal requirement). For now we manually maintain XML translation files for the languages we need in the MVP, but having a third localization tech in the project just for one small feature is very annoying.

I don't think we should create OrchardCoreContrib.PoExtractor.VueJs, not other OrchardCoreContrib.PoExtractor projects for the use-cases I mentioned above. This would quickly bloat your repo.

Reference Lombiq.VueJs to OrchardCoreContrib.PoExtractor

I'm not sure if I understand. If you mean using OrchardCoreContrib.PoExtractor as a library inside Lombiq.VueJs, your existing NuGet tool package doesn't make it possible. Even if you released a NuGet library package it would be pointlessly cumbersome to use in my opinion.

@sarahelsaig
Copy link
Contributor Author

@hishamco Happy New Year! Have seen my last comment?

Even if you don't want to go forward with this PR I'd like to understand what's your concern about using C# scripts in this project. Maybe you are right and I should avoid using it in my own projects too.

Also just to clear things up, since you mentioned "dynamic linking" in your previous comment. The topic came up in the issue, but in this PR I did not implement dynamic linking. What we have here is just scripting. Similar to using Jint in OrchardCore, except the script language is also C#.

@hishamco
Copy link
Member

Happy New Year!

Let us finalize the PR this week, it would be nice to demo it in the upcoming meeting if it's possible I need to have @sebastienros feedback

@hishamco
Copy link
Member

I'm planning to use CLI parsing package to make things easier, let me create a quick PR to use https://github.com/natemcmaster/CommandLineUtils the you can react to the changes, then we could merge

Hope the recording for yesterday's meeting will be published ASAP, I need to have a look before we merge this. No worry we will try to merge this PR this week

@hishamco hishamco mentioned this pull request Jan 15, 2025
@sarahelsaig
Copy link
Contributor Author

I have rewritten Program to work with your new command line argument system. I have also found and fixed a bug that we missed in the previous PR.

About the recording, maybe it will be faster if you ask for a direct link from someone who is part of the main Orchard org.

@hishamco
Copy link
Member

I have rewritten Program to work with your new command line argument system. I have also found and fixed a bug that we missed in the previous PR.

I'm suggesting a new PR for it or I will do it so quick, we need to focus on what it's related to the plugin support

Thanks again

@sarahelsaig
Copy link
Contributor Author

I'm suggesting a new PR for it or I will do it so quick, we need to focus on what it's related to the plugin support

Thanks again

Sure, here is the PR: #104

@hishamco
Copy link
Member

I'm still waiting for Gabor to check the recording, but I will do one more review tonight

@hishamco
Copy link
Member

I just saw the recording and heard @sebastienros feedback:

  • Shall we need to support absolute & relative URLs for plugins
  • @sebastienros from a security perspective do you think this is safe, especially if someone wrote a C# plugin

Last not Liquid is already supported and the tool is able to extract the strings https://github.com/OrchardCoreContrib/OrchardCoreContrib.PoExtractor/tree/main/src/OrchardCoreContrib.PoExtractor.Liquid

@sarahelsaig
Copy link
Contributor Author

sarahelsaig commented Jan 21, 2025

Shall we need to support absolute & relative URLs for plugins

Can you elaborate, what relative URL means here? I just use HttpClient without any custom configuration for loading remote plugins, so I think we always need absolute URLs.

Last not Liquid is already supported and the tool is able to extract the strings

Sorry for the confusion, that part is not related to this PR. Just a sudden though I had at the moment. I have created a separate issue to discuss: #105

@hishamco
Copy link
Member

I did a last review, please check and let merge then

@hishamco
Copy link
Member

Please comment on #102 (comment) then we can merge so quick

@sarahelsaig sarahelsaig requested a review from hishamco January 22, 2025 15:15
@hishamco hishamco merged commit f799acb into OrchardCoreContrib:main Jan 22, 2025
1 check passed
@hishamco
Copy link
Member

Thanks so much @sarahelsaig, I think the next step is to publish the abstractions project

@hishamco
Copy link
Member

BTW did you start a VueJS localization extractor, or it's something private for Lombiq

@sarahelsaig
Copy link
Contributor Author

I will start working on it soon (Lombiq/Orchard-Vue.js#152).
It will be open source in the https://github.com/Lombiq/Orchard-Vue.js/ repo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add plugin support for other templates languages
3 participants