Enhance Realm Rendering in Gno by Supporting Multiple Render Methods

[gfanton]

In the current implementation, each realm possesses a Render method that returns a Markdown representation of the realm. While there are ongoing efforts to enhance this default rendering format (as discussed in issue #439), the current method is limited in scope, supporting only this single, default rendering format.

To extend the versatility and usability of realms, I propose introducing additional rendering methods. This enhancement would allow realms to support various formats like HTML, JSON, etc., akin to how structures in Go can implement custom MarshalJSON and UnmarshalJSON methods for JSON processing.

Implementation

• Multiple Render Methods: Each realm could implement multiple render methods such as RenderHTML, RenderJSON, RenderXXX, etc. This approach enables platforms, devices, or any other clients to request a specific render format as per their requirements. These methods could coexist with the existing Render method, providing developers with a suite of flexible rendering options.
• Default Render Method: To ensure consistency and backward compatibility, it is essential for every realm to implement the default Render method. This method would act as a fallback, guaranteeing that a basic and human readable Markdown rendering is always available, regardless of the additional formats supported.

This proposal, while introducing versatile rendering options like RenderHTML or RenderJSON complements the ongoing improvements to the default Render method discussed in issue #439. It aims to broaden the utility and adaptability of Gno realms without conflicting with existing enhancement efforts. By offering diverse rendering capabilities alongside a reliable Markdown fallback, this enhancement seeks to cater to a wider range of use cases, from web views to specific data representation.

[moul]

I'm not sure about making this a default on gno.land, but it's a good and simple idea.

If we do this, we could try having RenderJSON return an interface{} and do the marshaling from the VMKeeper. This could help since we don't have the reflect package, yet. Maybe RenderObject is a better name?

For RenderHTML, I think we shouldn't use it to avoid issues with XSS and cookies.

[moul]

Sure, here's an improved version of your comment:

---

New API I'm proposing for this:

// AnyHandler can be called by Gno import and "maketx q_eval --format=json".
// Depends on #1776.
// In the future, it could also be callable via a proxy server at api.gno.land to simulate a REST API.
func AnyHandler(input MyFirstType) MySecondType {
    // Implementation here
}

// Render returns Markdown content for the given path.
func Render(path string) string {
    // Implementation here
}

// RenderHTML returns HTML content for the given path.
// The HTML is published on a special permissionless playground server, like html.gno.land.
func RenderHTML(path string) string {
    // Implementation here
}

The goal is to avoid having MIME type support in Render() and to avoid any marshalling.

[grepsuzette]

To extend the versatility and usability of realms, I propose introducing additional rendering methods. This enhancement would allow realms to support various formats like HTML, JSON, etc., akin to how structures in Go can implement custom MarshalJSON and UnmarshalJSON methods for JSON processing.

Since realms can already export whatever function they want, perhaps we should try and turn the question upside down: which kind of consumer/client/device can we think of, which would need a such standardized function?