tagName: 'img' produces `<img></img>`.
Is there a way to prevent this? I know I could just create a div and put the img inside, but creating the img right away is more convenient for me and I dont need to create any template for the component.
Thanks for any input.
I found this issue which indicates that the ember core team is aware of the behavior for self closing tags but probably will not change this behavior before Ember 2.0.
See the quote by #trek in the issue I've linked to:
The documentation is accurate. This is just a bug that hopefully we
can address in 2.0. I'm closing this particular issue since it was re:
docs. I know #mmun and #mixonic are aware of this general problem.
I wouldn't worry too much. I'll quote #mixonic from the same issue:
This is correct, a view that is based on a self-closing DOM node
cannot by definition contain more DOM
So it doesn't seem that anything will be accidentially inserted between the opening and closing tags.
Related
Doing a shallow rendering, I'm working with the following and trying to use the .get() function in order to check the text within the node. My page has multiples of the class tag-cloud__section. I've found that .html and .text returns an error that they are not a function. What am I misunderstanding here?
expect(wrapper.find('.tag-cloud__section').get(0).text()).toContain('these words');
The project I'm on is using 3.3, but I haven't seen anything mentioning in the docs that its a newer feature. Any tips, pointers or exposing of my ignorance is appreciated!
You are able to use both .first() and .at(0) to perform this action
I created a site with several lists and several CSR renderers for those lists. I applied the renderers to the forms via JSLink. Then I tried to save the site as template and create another one from this tempalte. All the JS links are now broken and lead nowhere.
Here is one of the JSLinks from the initial site:
<JSLink xmlns="http://schemas.microsoft.com/WebPart/v2/ListForm">~Site/SiteAssets/FormsManagement/Js/utils.js|~Site/SiteAssets/FormsManagement/Js/paymentsFormRenderer.js</JSLink>
</WebPart>
And here is what it changed to after the template creation:
<JSLink xmlns="http://schemas.microsoft.com/WebPart/v2/ListForm">/sites/home/test-subsite/SiteAssets/FormsManagement/Js/utils.js|/sites/home/test-subsite/SiteAssets/FormsManagement/Js/paymentsFormRenderer.js</JSLink>
These changes break all my CSR and I have no idea how to fix it. I am aware that these two links have to be equivalent, although on the recreated subsite, browser tries to load the javascript from a domain of cdn.sharepointonline.com which is wrong. (I suspect this is due to wrong relative addressing).
All the help is much appreciated! Thanks in advance.
So I figured it out. I am not sure what the problem was but I found the workaround that seems to work pretty good.
I scraped entirely the idea to use JSLink and instead I used <SharePoint:ScriptLink> tag and included the scripts that way. I wrapped my scripts so that they use ExecuteOrDelayUntilScriptLoaded([Script's closure here], 'clientForms.js');
This seems to yield the same result as using JSLink, but the tokens in JSLink are not expanded to relative urls and links are not broken. The only downside is that no one is able to modify the scripts without the Sharepoint Designer as they are no more listed in JSLink field.
As part of an attempt to port a fairly large/complex existing application to the Ember world, I'm generating and compiling named Handlebars templates dynamically, and associating views with them, using the technique:
var template = Ember.Handlebars.compile("some handlebars stuff");
Ember.TEMPLATES["myTemplate"] = template;
var view = Ember.View.create({
templateName: "myTemplate"
});
One of the things I'd like to do is be able to recompile new/different Handlebars template markup which overwrites the template named "myTemplate" and have it be accessible to views at that name.
I'm getting unexpected results trying to do this - a couple fiddles that illustrate the problems:
First fiddle - Shows what happens if you wait before rendering a view after the named template contents have changed.
Second fiddle - Shows what happens if there's no delay before rendering a view after the named template contents have changed.
There's obviously some magic under the hood that I'm not understanding. Can anyone shed some light on this?
UPDATE:
I went through the source code for Ember.View and the container module, and came to realize that I could solve the problem in the First fiddle by overriding the "template" computed property in a way that skips the container cache lookup. I've put up another fiddle here to demonstrate the solution I found.
This seems to be working the way I'd like it to - but - it feels like I might be fighting with the framework and "unhooking" from the container in a way that might bite me later. Is there a better, more Ember-esque way to accomplish what I'm trying to do? Will the hack I found break things?
UPDATE 2
I've also discovered that it's also possible to simply call
view2.get('container').reset();
before appending view2 in the First fiddle. Seems cleaner/safer, but is it "legal"? I've updated the First fiddle to illustrate this.
(in the second fiddle, both views show the second template)
This is because view1.appendTo($("#target")); just schedules the append, actual view rendering does not happen until end of the run loop. Before that happens, you've set Ember.TEMPLATES["myTemplate"] = template2;
(in the first fiddle, both views show the first template)
Pretty sure this is because ember container caches template fx, but not 100% on that. Checking...
I'm going to call this one answered. As I mentioned in my second comment, I'm using the solution shown in this fiddle in my project, along these lines:
mYiew.get('container').reset();
There's some discussion about the container not being intended to be used as an API here: https://github.com/emberjs/ember.js/commit/5becdc4467573f80a5c5dbb51d97c6b9239714a8 , but there doesn't seem to be any mention of using the container from Views for other use cases.
Also, a View's container can be accessed directly (at ".container") - meaning the devs haven't made it "hard" to get to the way they have for an Application's ".__ container __". This might suggest something about how they intend it to be used.
Since a View having the ability to clear its cache whenever it wants to doesn't seem to me to be unreasonable or a bad practice, I'm using the above mentioned solution...at least until someone sets me straight with a better idea (or a cache API).
After I call render on my jsRender template, it seems to be consumed, and thus is removed from the DOM. This is frustrating as I have a page where the template needs to be rendered several times depending on user interaction.
console.log($('#tpl'));
$('#container').html($('#tpl').render(json));
console.log($('#tpl'));
The second console.log is an empty array, and I can confirm the template no longer exists using the DOM inspector and the exception that jsRender throws: Uncaught JsRender Error: Unknown template: "#tpl" -- the page must be reloaded to re-inject the template into the DOM.
How can I persist the jsRender template between renderings?
I'm still not sure why it has to be consumed and simply can't stay in the DOM after rendering the first time, but I found a workaround. If anybody knows the reason for removing the template from the DOM, I'm still interested.
Update: Actual answer (Thanks, Boris)
My template was within my #container element, so the html() method was of course overwriting it. Silly me.
Workaround Neat little trick anyway
Using this 'variant' example, I saved the template in a local variable. Then I call render on the variable name instead of the jQuery selector:
var tpl = $.templates('#tpl');
.
.
.
console.log(tpl);
$('#container').html(tpl.render(json));
console.log(tpl);
This has also managed to preserve the template across renderings.
I also had a similar problem today where I had two target divs and two script block templates in the body. My problem was that I hadn't closed the div element tags correctly (too much xaml) and the result was the second template was never rendered as it couldn't be found.
Here's a JsFiddle showing the correct usage (rather than the /> self-closing syntax):
http://jsfiddle.net/jgoldsmith/XvvPC/
Hope that helps someone else.
i'm developing a site that must be as accessible as possible. While assigning the accesskeys to my form fields with
widget=FieldWidget(attrs={'accesskey':'A'})
i found out that the w3c validator won't validate an xhtml strict page with an accesskey in a select tag. Anyway i couldn't find a way to assign an accesskey to the label related to the select field (the right way to make the select accessible). Is there a way to do so?
Thanks
Interesting question. HTML 4.01 also prohibits accesskey in a select.
I believe the Short Answer is: Not in standard Django.
Much longer answer: I looked at the code in django/forms/fields.py and .../widgets.py and the label is handled strictly as a string (forced to smart_unicode()). Four possible solutions come to mind, the first three are not pretty:
Ignore the validation failure. I hate doing this, but sometimes it's a necessary kludge. Most browsers are much looser than the DTDs in what they allow. If you can get the accesskey to work even when it's technically in the wrong place, that might be the simplest way to go.
Catch the output of the template and do some sort of ugly search-and-replace. (Blech!)
Add new functionality to the widgets/forms code by MonkeyPatching it. MonkeyPatch django.forms.fields.Field to catch and save a new arg (label_attrs?). MonkeyPatch the label_tag() method of forms.forms.BoundField to deal with the new widget.label_attrs value.
I'm deliberately not going to give more details on this. If you understand the code well enough to MonkeyPatch it, then you are smart enough to know the dangers inherent in doing this.
Make the same functional changes as #3, but do it as a submitted patch to the Django code base. This is the best long-term answer for everyone, but it's also the most work for you.
Update: Yoni Samlan's link to a custom filter (http://www.djangosnippets.org/snippets/693/) works if you are generating the <label> tag yourself. My answers are directed toward still using the full power of Forms but trying to tweak the resultant <label>.