Rename OrchardCore.Liquid.Abstractions

[hishamco]

If we look closely into OrchardCore.Liquid.Abstractions it has a dependency on Fluid, which is one of the implementations for Liquid, I suggest to rename the project into OrchardCore.Liquid.Core or keep the intefaces that not have depedency on Fluid and move the others into core

@sebastienros your thought

[Skrypt]

Unless there is a need for that I would say it is not necessary but of course, that would be cleaner.

[hishamco]

What I see that OrchardCore.Liquid.Abstractions is tightly coupled on Fluid, similar to YesSQL at the past but we clean it up at least to extend Data APIs, samething should go here. Fluid is what we have for OC, but may be for a reason someone needs to use another Liquid implementation

[ns8482e]

@hishamco not sure I follow but I guess OrchardCore.Liquid.Abstractions is based on Fluid and It had nothing to do with other liquid implementation

If someone needs different implementation of liquid I don’t think they may be able to to use this abstraction

[hishamco]

That's why I suggested for the rename, at least we could separated Fluid specific types into another project say OrchardCore.Liquid.Abstractions OrchardCore.Liquid.Fluid or shorthand OrchardCore.Liquid.Core as we usual did

[Skrypt]

What I meant there is mostly that there is no need for a second Liquid parser as Fluid is the best. 😉
So, unless there is a need for a new Liquid parser then it is not necessary. But, of course if it is the goal you are trying to reach you will need to make the abstractions work.

[hishamco]

At least rename it to OC.Liquid.Core instead

[ns8482e]

@hishamco not sure if you observed but each module is basically following naming as like in Orion architecture guidance e.g.

XXX Module
XXX Core
XXX Abstractions

so here OrchardCore.Liquid.Abstraction represents abstractions required for OrchardCore.Liquid module and not necessarily an abstractions for Liquid implementation

[hishamco]

Ya, but it's a good practice to let the module depends on a default (core) implementation, so if someone doesn't like the implementation he can write his own

[hishamco]

If you notice that there several modules don't have a core implementation in the past, then we recieve many issues that the module SHOULD NOT depends on a default implementation without abstractions, because it avoid the extensibility point