You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is potential to use atjson strictly as a document manipulation tool for any format for which we have a source defined. For example:
// Add target "_blank" to all links
let doc = HTMLSource.fromRaw(someHtmlString);
let links = doc.where({type: "-html-a"});
links.update(link => {
link.attributes.target = "_blank";
});
One thing that makes this difficult currently is that in order to render this back to HTML, we have to convert the document to a common format, which seems unnecessary. It would be nice if each source could define its own "natural" or "native" renderer which acts on the schema of the source rather than on a common format schema. We have currently only been writing renderers acting on a common format schema in order to avoid the temptation of writing converters between every pair of document formats, but it seems this proposed natural renderer still is in line with that philosophy since it only acts on the source schema.
Currently, there is nothing stopping users from adding these renderer definitions. I wonder if we would want to formalize it in the api somehow:
// Add target "_blank" to all links
let doc = HTMLSource.fromRaw(someHtmlString);
let links = doc.where({type: "-html-a"});
links.update(link => {
link.attributes.target = "_blank";
});
let newHtmlString = doc.render(); // calls the natural renderer of the source doc
It is possible that the natural rendering of a document produces different results than converting to a common format and using the existing renderers. I'm not sure if that is a problem or not.
Converter
Source ---> Common Format
\ |
\ |
\ | HTMLRenderer
Natural \ |
Renderer \ |
=== html?
What are the results of this discussion?
The text was updated successfully, but these errors were encountered:
There is potential to use atjson strictly as a document manipulation tool for any format for which we have a source defined. For example:
One thing that makes this difficult currently is that in order to render this back to HTML, we have to convert the document to a common format, which seems unnecessary. It would be nice if each source could define its own "natural" or "native" renderer which acts on the schema of the source rather than on a common format schema. We have currently only been writing renderers acting on a common format schema in order to avoid the temptation of writing converters between every pair of document formats, but it seems this proposed natural renderer still is in line with that philosophy since it only acts on the source schema.
Currently, there is nothing stopping users from adding these renderer definitions. I wonder if we would want to formalize it in the api somehow:
It is possible that the natural rendering of a document produces different results than converting to a common format and using the existing renderers. I'm not sure if that is a problem or not.
What are the results of this discussion?
The text was updated successfully, but these errors were encountered: