Skip to content
This repository has been archived by the owner on Apr 12, 2024. It is now read-only.

feat($compile): support DOM nodes as template values #5508

Closed
wants to merge 1 commit into from

Conversation

caitp
Copy link
Contributor

@caitp caitp commented Dec 21, 2013

Special content types, such as SVG content or table content, can not be used in many cases due to generating a document fragment which does not support the particular template content type being used.

This patch enables special content such as SVG or table content to be used by making the template a DOM node or collection of DOM nodes, rather than strings.

The test demonstrates how this can be used to replace the directive node with SVG elements, or similar.

This could be considered an alternative solution to #5235, #2848, #1459, #3647, #3241 and others, with the benefit that it's less work to implement in the compiler, but slightly more work for the user, and doesn't support templateUrl templates.



it('should accept DOM nodes as a template', inject(function($compile, $rootScope) {
if (!(msie < 9)) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only testing this on browsers which are not IE8, due to IE8 apparently not supporting SVG nodes... but I don't actually know if it would really fail on ie8

Special content types, such as SVG content or table content, can not be
used in many cases due to generating a document fragment which does not
support the particular template content type being used.

This patch enables special content such as SVG or table content to be used
by making the template a DOM node or collection of DOM nodes, rather than
strings.

The test demonstrates how this can be used to replace the directive node
with SVG elements, or similar.

directiveValue = denormalizeTemplate(directiveValue);
if (!elementTemplate) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this means that DOM templates won't be denormalized. that's not good.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the individual nodes would end up denormalized later on though, no? Actually, I guess not.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

denormalization is about taking all {{ }} bindings and turning them into whatever the the interpolation start and stop symbols are.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this needs to happen so that reusable components can be built with the usual {{ }} bindings but then in the actual app we use whatever symbols the developer configured.

@IgorMinar
Copy link
Contributor

I think the issue with denormalization is an important one and I don't know how to solve that right now without traversing the whole dom fragment

@IgorMinar
Copy link
Contributor

otherwise this looks like an interesting feature

@caitp
Copy link
Contributor Author

caitp commented Feb 23, 2014

It would be easy to solve the denormalization problem by just having every node walked by the compiler denormalize its own text, that doesn't seem too bad.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants