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.
Related
The functionality I seek is very similar to the default ModelStructurePanel model browser, except that I need to list only a subset of elements, by passing a list of dbIds of the elements I want listed. By clicking on an element on that list, have the view focus on that element.
I figure there might be two ways of achieving this by using the ModelStructurePanel (although I'm open to using something else):
Creating a new instanceTree with only the specified elements, then doing something like viewer.modelstructure.setModel(newInstanceTree)
Overwriting the ModelStructurePanel.shouldInclude method to hide all elements but the specified ones.
I have googled for Viewer code boilerplate that would provide this functionality, but have not found it. Any help is very much appreciated.
There is a basic sample here very close to what you described, and I would go with customizing just one action instead create a new one, seems easier.
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.
First
It looks like it's possible to set custom validation rules, but I'm wondering if there is any way to customize the validation messages (I need them to be in Arabic).
Second
Is it possible to reverse the direction of paper-input floating label (place it at top right instead of top left).
First
paper-input exposes a error attribute you can use to declaratively set a custom message. If you want to use core-input directly, that element exposes a setCustomValidity(message) for setting it.
http://www.polymer-project.org/docs/elements/core-elements.html#core-input
Second
That would be a good feature request to file against paper-input. I was able to get something working using CSS overriding, but the internals of the API could change in the future.
http://jsbin.com/megafucuvapo/1/edit
I have this problem, in a form I have a list of customers that could be more than 300 and, for me, it isn't very simple find over there because I should scroll all results for find a single row!
On the old technology I had a button that opened a pop up where I should research which customer I should select and than I used a javascript for recording the selection on the first form, but It could be a good solution with new technology!
How can I resolve this doubt? What is the best solution for big <select> tag?
You basically want an autocomplete dropdown list. This does not exist in the standard JSF component set and it is also not exactly trivial to implement with JavaScript/jQuery on top of the standard JSF component set because the available values have to be present in the server side's state. You also basically want a dropdown list which is represented by a <div><input><ul><li> instead of a <select><option> because a normal <select> doesn't allow the enduser to type text in. The standard JSF component set does not have a component which renders the desired HTML markup. You'd basically need to create a custom JSF component.
There are 3rd party JSF component libraries which already offer a fullworthy JSF autocomplete dropdown list. It would be easier to use either of them instead of reinventing the wheel by a custom JSF component. Take your pick:
PrimeFaces - the <p:autoComplete> component
RichFaces - the <rich:autocomplete> component
OpenFaces - the <o:suggestionField> component
ICEfaces - the <ice:selectInputText> component
you can try jquery ajax autocomplete
Refer to:
http://docs.jquery.com/Plugins/Autocomplete
http://jqueryui.com/demos/autocomplete/
Yes, the jQuery autocomplete plugin is the best solution for you while you have a large number of items.
By the way, imagine that you would like to select an item with specific letters. While you are using drop down lists, you can point to your wanted items by typing their names from the first letter of each one. But using jQuery autocomplete, you can search a string or a group of letters in everywhere. it does not matter if are your inserted letters located at the first of your item names or in other places.
As ShantanuD said, you can find this plugin in http://jqueryui.com/demos/autocomplete/
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.