Magery is designed around custom HTML5 template tags that called 'components' (though sometimes confusingly referred to as templates in our docs). On the server-side these need to be placed into a full HTML document to be useful, on the client-side only the components are used.
I'm proposing we call all current templates using custom tags 'components', and we introduce a concept of 'pages' for use with server-side implementations.
A page might look something like this:
<!DOCTYPE html>
<html>
<head>
<title>{{ page.title }}</title>
</head>
<body>
<h1>Profile</h1>
<my-component user="{{ user }}"></my-component>
</body>
</html>Which makes use of a component defined like this:
<template data-tagname="my-component">
Hello, {{ user.name }}!
</template>In the server-side library you would call separate functions/methods/whatever to load components and pages, for example:
magery.load_components("./templates/components")
magery.load_pages("./templates/pages")Components would be rendered using their tag name:
magery.render_component("my-component", data)And pages would be rendered using the path to the template file:
magery.render_page("project/example.html", data)Exactly how those server-side APIs look and how page paths are constructed will be up to server-side implementors - they can do whatever makes sense in their language.
Magery is designed around custom HTML5 template tags that called 'components' (though sometimes confusingly referred to as templates in our docs). On the server-side these need to be placed into a full HTML document to be useful, on the client-side only the components are used.
I'm proposing we call all current templates using custom tags 'components', and we introduce a concept of 'pages' for use with server-side implementations.
A page might look something like this:
Which makes use of a component defined like this:
In the server-side library you would call separate functions/methods/whatever to load components and pages, for example:
Components would be rendered using their tag name:
And pages would be rendered using the path to the template file:
Exactly how those server-side APIs look and how page paths are constructed will be up to server-side implementors - they can do whatever makes sense in their language.