User:Kuno/Templates

TL;DR, release editor templates are an absolute mess. It's all warp's fault, but he wants to fix it.

Problem

In the release editor we have various templates or bits of the DOM being used as templates. All of the template usage in the release editor is inconsistent, and because there is duplication between server-side and client side bugs have occured where a problem is fixed in the server-side templates but not in the equivalent javascript code / template.

When the release editor was created the assumption was that anything which needs to be rendered from javascript has already been rendered atleast once on that same page by the server -- that instance can then be cloned and used as a template for any further instances needed by javascript. This is no longer true, and various hacks are in place to work around it.

All edit pages

On a small scale this problem exists with the edit page for any entity using artist credits:

• server renders an artist credit, which is a list of one or more ArtistCreditNames (artist + credited name + join phrase).

• client can dynamically add more ArtistCreditNames, these are cloned from the first entry and then cleared. Some protections are in place to prevent the user from removing the last entry.

Or on even a smaller scale javascript has no access to any of the link_entity() and similar macros in compoments/common-macros.tt, this is a source of interface inconsistencies.

Tracklist (release editor)

The tracklist page on the release editor has several of these "templates":

tracks

• server: An empty track is rendered by the server, including a full artist credit template with details from the release artist. This template is part of the DOM, but hidden with css.

• client: Whenever a new track is rendered this track is cloned and filled in + displayed.

discs

• server: The release editor has hacks to ensure one disc is always rendered server side.

• client: There are protections against removing the last disc, any new disc added will clone the first available disc and clear out it's data.

Recordings (release editor)

The recording page has similar templates:

recording suggestions

• server: a "recording_suggestion" macro contains the template to both render recordings suggestions on the server, and to render the client-side template for recording suggestions. The client-side template is hidden with css as usual.

• client: It looks like the template version is only rendered when no other suggestions are rendered, so I expect the client clones the first recording suggestion and removes the template class + removes the "display: none" regardless of whether it was cloned from such a hidden template or not.

select recording

• server: The "select_recording" macro also renders both the server side instances of this bit of html and a template for use on the client.

• client: One template version of the "select_recording" macro is always rendered by the server, so is probably used by javascript code adding more "select_recording" bits.

disc-template

• server: A "disc-template" table is rendered by the server for use by the client -- this is rendered seperately from the disc tables already rendered by the server.

• client: Uses the template version, doesn't need the other server rendered versions.

Solution

I see three possible solutions here:

1. Standardize on a template language for which both server-side and client-sider render engines are available.
2. If javascript needs to render a template it sends the data for the template to the server and gets rendered html back.
3. Use separate server-side and client-side template languages, but standardize on their locations in such a way that a developer making changes to one if them is likely to notice the other and make the necessary changes there as well.

Client side rendering

PRO: The javascript code can load a template once and re-use it multiple times, avoiding a lot of roundtrips are bandwidth usage.

CON: Greatly limits our choice in which template language to use.

Server side rendering

PRO: We can pick a fast template engine for all server-side rendering (e.g. Xslate).

CON: Whenever the client needs to render something, a roundtrip to the server is necessary. Will also need logic to combine requests so the client can send the data for N tracks and have the server return N rendered versions, one for each track.

Keep templates separate

PRO: We can pick the best template language available on both sides, and no unnecessary roundtrips to the server.

CON: Maintenance nightmare.