Properly instantiating a template instance so that everything is present (model data, filters, event handlers) - polymer

I'm a bit of trouble instantiating a custom template, and making all the bindings work. My custom element which has to do this is quite similar to polymer/core-list, with a few differences. Like core-list, the parent adds the element invokes my custom element, and adds a template as its content, as seen here.
Unlike core-list, the element adds an id to this template, and creates a few templates which refer to that one, as seen here. Finally, when the time comes, these new templates are used to create a few elements and add them in the dom.
That's all fine and good, and mostly, it works correctly. The model data is used to fill the resulting element correctly, and the default filters work, thanks to the PolymerExpressions used as a bindingDelegate. However, event handlers do not seem to work.
I don't know whether the handler function can't be found in whatever scope is used, or something else is at play here. The only thing I currently know is that the on-tap attribute value is empty when I look at the polymer-icon-button through the web inspector. With a very similar usage using the core-list, the event handler works. The web inspector there shows the polymer expression as the value of the on-tap attribute. And both handlers are defined in the parent element which contains the invokations of core-list and my element, and the templates which are passed to the corresponding contents.

Related

Dom-repeat and neon-animatable in Polymer

I have a same problem with use dom-repeat for neon-animatable in Polymer.
So, about my problem. When I dynamic building page, I use dom-repeat for building a certain number of pages. In code that look like
<neon-animated-pages id="views"
class="flex"
selected="[[selected]]"
entry-animation="[[entryAnimation]]"
exit-animation="[[exitAnimation]]">
<template is="dom-repeat" items="{{dataView}}">
<neon-animatable id="{{item.id}}">
<inner-content data="{{item.content}}"></inner-content>
</neon-animatable>
</template>
</neon-animated-pages>
After builded this page, I have a page which contains a certain numbe neon-animatable pages, but after first click on button for view next page , animation don't work, but if click on button more, animation work fine.
So, I can't understand why first animate don't work
If who have some mind about how resolve this problem, I will be grateful
P.S About my observations
When use in static code like this
<neon-animated-pages>
<neon-animatable>page 1</neon-animatable>
<neon-animatable>page 2</neon-animatable>
<neon-animatable>page 3</neon-animatable>
</neon-animated-pages>
Animation it is running the first time
This appears fixed for a future release: https://github.com/PolymerElements/neon-animation/issues/55
Details:
I ran into the same problem and it appears related to timing on when the light DOM children are created.
Short answer: on your custom element add an attached function that sets the selected page.
attached: function () {
this.async(function () {
this.$.pages.select(0);
});
}
Long Answer
When a template dom-repeat is used inside the neon-animated-pages, at the point the web component is initialized it is not able see the details of the light DOM children.
Using static code the tree is seen as:
neon-animated-pages
- neon-animatable
- neon-animatable
- neon-animatable
Using dom-repeat at initialization it looks like:
neon-animated-pages
- template
Because of this when the neon-animated-pages tries to set the selected page it get undefined because it is not able to see the neon-animatable components. These get created later. This behavior is described in the documentation https://www.polymer-project.org/1.0/docs/devguide/registering-elements.html which says
Note that initialization order of may vary depending on whether or not the browser includes native support for web components. In particular, there are no guarantees with regard to initialization timing between sibling elements or between parents and light DOM children. You should not rely on observed timing to be identical across browsers, except as noted below ... This means that an element’s light DOM children may be initialized before or after the parent element, and an element’s siblings may become ready in any order.
As the light DOM children starts getting filled in a call is made to the observer function "_updateSelected" on IronSelectableBehavior, which is the parent of NeonAnimatedPages, to update the selections based on the content updates.
However, NeonAnimatedPages also maintain internal references to identify selected items and uses the observer function "_selectedChanged" to setup references and control animations. Essentially it decides to display an animation based on whether a previous element is selected. Based on the tree above, when this method is called at initialization it cannot see the full tree and it sets previously selected to undefined. As the light DOM is getting populated, this handler is not getting called because the selected value is not changing only the content is changing. The consequence is that while IronSelectableBehavior correctly knows what is selected, NeonAnimatedPages still thinks nothing is selected, and as you make your initial screen change it treats it as an initial load because it thinks nothing is selected and suppresses the animation.
The solution essentially waits for the entire tree to be built and then sets the selected value so that all the event handlers are able to correctly see the light DOM children and set up internal references.
As Ade mentioned, this was a logged issue in neon-animation, but it has since been fixed. Update the component (bower update, if you're using bower) to resolve the issue. I would have added this as a comment to Ade's answer, but I don't have enough reputation yet

Connecting UI Elements in Google Apps Script (TabPanel - UiApp)

I've already asked a similar question, but I really can't figure out how to connect these elements together. I'm still not very good with Handlers, and I guess my question is:
How can I access UI Widgets (and their children) while outside of the doGet() function?
My use case is this: I have a list of projects/IDs. I have all the data I want based on the ID that will populate the Project Details tab of this application. I created 'unique' Buttons for each of these Projects, and threw them into a Grid. Now, I want to generate the Project Details (detailPanel) Widgets specifically for each Button if/when it is clicked.
I have the Project ID attached to each Button (uniquely) through a Hidden, but I can't seem to attach the Project Details tab (detailPanel) to the Button so that, when clicked, I can set the values for the TextBox, DateBox, ListBox, etc. Widgets of the detailPanel.
I think I'm missing something obvious about this. I want to avoid attaching each child Widget of the detailPanel as a callbackElement of the Button at all costs. There are around 40 elements (I've lost count), and it seems really inefficient. I'm almost sure that if I can add one Widget as a callback element, that I get access to all child Widgets. But I tried, and that doesn't seem to be the case.
Here is the link to the public UiApp, which shows the UI. And the sister Script Project (uneditable).
You dont need to add callback elements that you will write to, callback elements are only for reading their data. If the detailspanel id is dynamic have a hidden that has its id stored inside and pass it to the handler. from your handler you getelementbyid and set its data.

Setting (Bound) Model Object Properties from View in EmberJS...Programmatically?

QQ: How can I update an object's property to match the innerHtml of an element in a view when a button is clicked?
I am working on building a content editing interface using EmberJS and the HTML5 contenteditable attribute (via the Hallo editor). This means that valueBinding doesn't do the trick, since we're dealing with the actual page HTML, not input/textarea value attributes. I've built a similar app in Backbone, which lacks dynamic bindings but allows you to set the model object as a property of the view.
What's the best way to get this working with EmberJS? Should I set a property on the view to the entire model? Do I need to create some sort of innerHtml binding and view helper, modeled on valueBinding?
I've set up a fiddle with an example of what I'm trying to do (with basic jQuery handling of the contentEditable attribute, instead of hallo):
http://jsfiddle.net/W6gsW/2/
Thanks!
http://jsfiddle.net/ud3323/nXCvq/
I did change a few things with how you defined the bindings in App.docView to make things cleaner. My solution does feel a litte hackish, but it works with 1 line of code per property.

Binding to HTML elements in GWT

I'm trying to figure out how to bind a javascript event to a select element in GWT, however the select element isn't being built in GWT, but comes from HTML that I'm scraping from another site (a report site from a different department). First, a bit more detail:
I'm using GWT and on load, I make an ajax call to get some HTML which includes, among other things, a report that I want to put on my page. I'm able to get the HTML and parse out the div that I'm interested in. That's easy to display on my page.
Here's where I get stuck: On the portion of the page I'm using, there's a select element which I can easily locate (it has an id), but would like to capture event if my user changes that value (I want to capture changes to the select box so I can make another ajax call to replace the report, binding to the select on that page, and starting the whole process again).
So, I'm not sure how, once I get the HTML from a remote site, how to bind an event handler to an input on that fragment, and then insert the fragment into my target div. Any advice or pointers would be greatly appreciated!
How about this:
Element domSelect = DOM.getElementById("selectId");
ListBox listBox = ListBox.wrap(domSelect);
listBox.addChangeHandler(new ChangeHandler() {
void onChange(ChangeEvent event) {
// Some stuff, like checking the selected element
// via listBox.getSelectedIndex(), etc.
}
});
You should get the general idea - wrap the <select> element in a ListBox. From there, it's just a matter of adding a ChangeHandler via the addChangeHandler method.

'[Inspectable]' metadata tag

Anyone can explain briefly about the [Inspectable] metadata tag. I read and could not understand in live docs.
Please help me when we are going to use the [Inspectable] metadata tag?
Thanks,
ravi
The tag is used with properties to provide code hints for that property and to specify the possible list of values that property can take while using it in mxml. Unlike [Bindable] metadata, this tag doesn't have much effect on the working of the code (other than specifying a default value) - this is used mainly to give directions to Flex Builder regarding how to deal with a particular property.
[Inspectable] metadata tag
Defines an attribute exposed to component users in the attribute hints and Tag inspector of Flex Builder. Also limits allowable values of the property.
For example, the verticalScrollPolicy property of the mx.core.Container class has the following [Inspectable] tag with it.
[Inspectable(category="General", enumeration="off,on,auto", defaultValue="auto")]
public function get verticalScrollPolicy():String
{
return _verticalScrollPolicy;
}
This tells Flex Builder that this property should appear in the 'General' tab (it is 'Common' in my FB) of the Flex Builder's property inspector (open an mxml file, go to the Windows menu and select Flex Properties to open the property inspector - towards the upper side of inspector tab, near its title, you will find buttons to switch to standard view, category view, and alphabetical view). This property can take one of the three values off, on, auto and if none is specified it takes auto as its default value.
I've never used this tag and I believe you too won't be using it much unless you are writing a Flex API to be used by a bigger audience than your colleagues (or if you are a perfectionist).
This tag is useful for when you write your own custom components. While it does not interact with the actual code you write (unlike the [Bindable] tag, mentioned above), it does give the Flexbuilder environment a way of allowing the user to set properties of your component using the UI Designer.
Therefore, the tag is useful if you want to:
Write components that are to be used by other people (make only the publicly accessible properties Inspect'able)
You've written a custom component that is used multiple times in your UI (maybe an extended slider). You then write some Inspect'able getter/setter methods as the public API to your component, and then implement these getter/setter methods to do data validation and implement the internal logic of your component.
You can find more information and examples here. Some good info on writing custom components (using the code behind methodology, which I prefer) can be found here.
Note: When creating exposed properties using [Inspectable], they don't seem to show up in the Flexbuilder Flex-Properties panel (not in Standard view anyway, use Category view or Alphabetical view, instead)
Note: You can find an alternative method of adding public properties to your custom components using MXLM, like this.