Enable custom renderers for specific filenames with fallback to default renderer #7911

New Issue

GiteaMirror · 2025-11-02T07:41:15-06:00

GiteaMirror commented

2025-11-02 07:41:15 -06:00

Originally created by @LugaMuga on GitHub (Sep 29, 2021).

Feature Description

We want to add a custom renderer for spring-configuration-metadata.json files. It's a file where you describe possible application properties. I've already written it, but I don't want to use it for all JSON files.

As I see a code, it's too hard to change property

FILE_EXTENSIONS = .json

to something like

FILE_REGEXP = spring-*.json

I think we can add two new properties:

GET_REAL_FILENAME = true/false - and if you are using IS_INPUT_FILE = true, the system will get your real name with some static prefix
FALLBACK_POLICY = default_renderer / error - if external renderer finished with error, the system can show file by default renderer or send an error to UI

These two properties will possible for us to resolve our task.
I can try to implement this logic but want to get approval from you for this solution.

Screenshots

No response

Originally created by @LugaMuga on GitHub (Sep 29, 2021). ### Feature Description We want to add a custom renderer for spring-configuration-metadata.json files. It's a file where you describe possible application properties. I've already written it, but I don't want to use it for all JSON files. As I see a code, it's too hard to change property > FILE_EXTENSIONS = .json to something like > FILE_REGEXP = spring-*.json I think we can add two new properties: 1. GET_REAL_FILENAME = true/false - and if you are using IS_INPUT_FILE = true, the system will get your real name with some static prefix 2. FALLBACK_POLICY = default_renderer / error - if external renderer finished with error, the system can show file by default renderer or send an error to UI These two properties will possible for us to resolve our task. I can try to implement this logic but want to get approval from you for this solution. ### Screenshots _No response_

GiteaMirror added the topic/content-rendering type/proposal labels 2025-11-02 07:41:16 -06:00

GiteaMirror commented

2025-11-02 07:41:16 -06:00

@wxiaoguang commented on GitHub (Sep 30, 2021):

Maybe we can make it without introducing too many settings.

eg:

.xxx starting with dot means extension
^spring-.*\.json$ starting with ^ and ending with $ means regex

This solution can express all situations.

Then introduce a FILE_PATTERN option and deprecate the FILE_EXTENSIONS. Make FILE_PATTERN default to FILE_EXTENSIONS if it doesn't exist.

@wxiaoguang commented on GitHub (Sep 30, 2021): Maybe we can make it without introducing too many settings. eg: * `.xxx` starting with dot means extension * `^spring-.*\.json$` starting with `^` and ending with `$` means regex This solution can express all situations. Then introduce a `FILE_PATTERN` option and deprecate the `FILE_EXTENSIONS`. Make `FILE_PATTERN` default to `FILE_EXTENSIONS` if it doesn't exist.

GiteaMirror commented

2025-11-02 07:41:16 -06:00

@delvh commented on GitHub (Sep 30, 2021):

At first, I was going to comment "Except file types starting with ^ and ending with $",
but then I noticed that even those can be displayed: ^\^…\$$.

@delvh commented on GitHub (Sep 30, 2021): At first, I was going to comment "Except file types starting with `^` and ending with `$`", but then I noticed that even those can be displayed: `^\^…\$$`.

GiteaMirror commented

2025-11-02 07:41:17 -06:00

@LugaMuga commented on GitHub (Sep 30, 2021):

Agree to use regex as I talked about it in the first part of message.
But looked to https://github.com/go-gitea/gitea/blob/main/modules/markup/renderer.go and think, that solution with regexp is too hard to implement.

@LugaMuga commented on GitHub (Sep 30, 2021): Agree to use regex as I talked about it in the first part of message. But looked to https://github.com/go-gitea/gitea/blob/main/modules/markup/renderer.go and think, that solution with regexp is too hard to implement.

GiteaMirror commented

2025-11-02 07:41:17 -06:00

@wxiaoguang commented on GitHub (Sep 30, 2021):

Oh yes ... it not easy to use a new mechanism without refactor.

So maybe your suggestion about "if external render exits with error code, then use fall-backed internal render" seems better, I think this can be the default behavior with a DEBUG log, no setting option is needed then.

@wxiaoguang commented on GitHub (Sep 30, 2021): Oh yes ... it not easy to use a new mechanism without refactor. So maybe your suggestion about "if external render exits with error code, then use fall-backed internal render" seems better, I think this can be the default behavior with a DEBUG log, no setting option is needed then.

GiteaMirror commented

2025-11-02 07:41:17 -06:00

@StrikerRUS commented on GitHub (May 14, 2022):

if external render exits with error code, then use fall-backed internal render

I strongly believe this behavioral improvement will be extremely valuable! In the case of our team we've just added the rendering of Jupyter Notebooks in our repo. However, some notebooks created at Google Colab cannot be processed via nbconvert due to the following issue: https://github.com/jupyter/nbconvert/issues/1731. So from the user side perspective, showing those problematic notebooks as a plain JSON will be a much better solution that failing with 500 error.

@StrikerRUS commented on GitHub (May 14, 2022): > if external render exits with error code, then use fall-backed internal render I strongly believe this behavioral improvement will be extremely valuable! In the case of our team we've just added the [rendering of Jupyter Notebooks](https://blog.gitea.io/2022/04/how-to-render-jupyter-notebooks-on-gitea/) in our repo. However, some notebooks created at Google Colab cannot be processed via `nbconvert` due to the following issue: https://github.com/jupyter/nbconvert/issues/1731. So from the user side perspective, showing those problematic notebooks as a plain JSON will be a much better solution that failing with 500 error.

GiteaMirror commented

2025-11-02 07:41:17 -06:00

@lunny commented on GitHub (May 15, 2022):

I think these are two problems.

One is should we support matching filename or even tree path and which matching method is better? Regex or Glob?

Another is if one file matched two or more rules, which one should I take at first and if it's failed should it fall back to another? And how should we define render failure?

@lunny commented on GitHub (May 15, 2022): I think these are two problems. One is should we support matching filename or even tree path and which matching method is better? Regex or Glob? Another is if one file matched two or more rules, which one should I take at first and if it's failed should it fall back to another? And how should we define render failure?

GiteaMirror commented

2025-11-02 07:41:17 -06:00

@lunny commented on GitHub (Jul 6, 2025):

This could be a plugin after #34917 is implemented.

@lunny commented on GitHub (Jul 6, 2025): This could be a plugin after #34917 is implemented.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#7911