Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Generic javascript template support design #7

Open
EntilZha opened this issue Apr 24, 2015 · 3 comments
Open

Generic javascript template support design #7

EntilZha opened this issue Apr 24, 2015 · 3 comments

Comments

@EntilZha
Copy link
Member

Documenting what we talked about yesterday (Dan) and what I plan on implementing.

Django Model: TaskType

Responsibility

Responsible for storing all information for a new task type. This will be exposed via a json api to support dynamic/runtime creation of new task types which are then stored in the database.

Fields

  • name: common string name of task type (eg. Image Recognition, Entity Resolution)
  • iterator_template: TemplateResource instance for point iterator, type=iterator_template
  • point_template: TemplateResource instance for a point, type=point_template
  • renderer: html/css/js code inserted into <body> which utilizes js variables to render the task
  • dependencies: alias for getting a list of dependencies from the prior three fields. The resources for iterator_template, point_template, and renderer are brought in as well

Django Model: TemplateResource

Responsibility

Contains html/css/js which is injected into the the template. The purpose is to have a set of composable resources representing javascript dependencies

Fields

  • name
  • content
  • type: value from [point_template, iterator_template, resource, renderer]
  • dependencies: List of TemplateResources this one needs and pulls these in
  • requirements: List of TemplateResources that must be present, but will not import if they don't exist, instead error out. This is helpful to enforce for example that a given "iterator_template" requires the renderer to support its assumed frontend framework (eg react)
  • Dependent on type, injects into: point_template -> js string variable in <head>, iterator_template -> js string variable in <head>, resource -> renders as html into <head>, renderer -> rendered as html into <body>

Django Template

  • Single template for all tasks
  • Parses content from Task and injects it as a javascript variable to the django template.
  • Injects iterator_template as a javascript string into <head>
  • Injects point_template as javascript string into <head>
  • Injects dependencies into <html> depending on its type.
  • Injects renderer into <body>

Features

  1. TaskType allows for creation of new task types dynamically which are stored in the database.
  2. TaskType defines fields for the basic abstraction boundaries: how to render a point given its data, how to render a list of points given its data. It further allows for those to be rendered in any container (via renderer)
  3. Supports any frontend javascript framework, or just plain old html. In the first case, different dependencies can be defined. In the second case renderer becomes just plain html code (perhaps with javascript injecting answers in to make it useful).
  4. Supports composition of resources in templates
  5. Supports enforcing requirements for a template

Template inheritance

For the first initial templates, I plan on making these based on ReactJS. Due to the implementation above, they are separate from implementation, so the ability to use inheritance is a function of being able to do that in React. This is fully supported and is a mean component of React so I don't see problems with this. The primary difference is that the responsibility to support inheritance is pushed from ampcrowd to the frontend user generated code and we provide reasonable default templates users can use or trash.
@EntilZha EntilZha mentioned this issue Apr 25, 2015
Open
@thisisdhaas
Copy link
Member

This looks great. A couple comments:

  • I don't understand the "renderer" field. Is it just the name of the JS template engine? The output of the template engine? The code for the template engine?
  • The resource type is confusing given the model name of TemplateResource. Maybe dependency or external_resource?
  • I'm not sure I understood the section on Template Inheritance, but I think it's worth making it easy for users to figure out what default templates are available, and which should be overriden. I don't know if that means an API call to get available template resources, or just detailed documentation, but there should be something.
  • This document doesn't mention it, but we obviously need API calls to manipulate these models. At a minimum, a call to get available TaskTypes and a call to add a new TaskType. Presumably we want the same for TemplateResources as well, though it seems less important.
  • Did you put more thought into where the default templates come from? Are they hard-coded? Are they fixtures in the file system?

@thisisdhaas
Copy link
Member

I'll take a look at your WIP PR tonight or tomorrow, which I'm sure will help answer some of these questions.

@EntilZha
Copy link
Member Author

EntilZha commented May 1, 2015

Answers to questions:

  1. At the most abstract level, it is html/css/js inserted into <body>. The intent is that this html/css/js code is responsible for using the other js variables (from the other fields) to render something on <body>. This makes renderer agnostic to how the final result is created (by jquery, react, ember...).
  2. Perhaps something more explicit like head_element would be good (since it is inserted into <head>.
  3. On the python/django side, the focus is on allowing composition of resources. Basically that paragraph is a convoluted way of saying that many clientside templating frameworks (like ReactJS), fully support template inheritance. I think on the second point, I (think) the current model makes it easy to see requirements/imports between TemplateResources, which could be used to construct an API/UI. It might be clearer if I can make a quick example of it soonish.
  4. Yes, those would be needed. I mostly wanted to tackle the data structures/model before implementing the specifics. That is one of the next things I will be working on.
  5. I think the default templates should be fixtures, but I don't have a strong opinion on it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@thisisdhaas @EntilZha