We have implemented checkbox in popover. There we are using checked.bind , but in the view model its not reflecting its value on change of the checkboxes.
Sample Gist Run Provided below:
Gist Run
Thanks in Advance
Programmatically injected HTML needs to be compiled manually
The integration with bootstrap I provided to you earlier cannot do this. The bootstrap plugin assigns the innerHTML property of the popover and it does this outside of aurelia's rendering pipeline. The HTML is therefore not compiled by aurelia, which is why bindings (and other aurelia behaviors) will not work.
The templating framework takes care of this for you automatically as long as you are following conventions (such as custom elements). In any other case you'll need to manually work with the ViewCompiler.
In case you're interested, you can see an example with programmatically generated HTML in this gist. Also see this question if you want to know more about it. I do not recommend it in this scenario however.
Use aurelia-dialog
A tooltip (or popover) is just that: a tip on how to use the tool. It should not need more than some plain markup, text and styling (of course this is subjective to some degree, and some people may disagree)
For collecting user input in-between pages or screens, I'd argue a modal dialog is a better fit because of its property to "pop out" more and to de-emphasize the rest of the screen until the user either proceeds or cancels.
More importantly, by using aurelia-dialog your bindings and behaviors will simply work because, well, it's an aurelia plugin :-)
Related
I'm trying to access the refresh button in react-admin project. I tried using getElementsbyClassName it returns HTMLComponents Object but it isn't accessible i.e I can see the component on printing it to console but isn't accessible by code. Is there a way for me to disable this refresh button wherever I want?
I'm not sure the exact use case here, but you can create your own custom AppBar that renders essentially whatever you want: https://marmelab.com/react-admin/Theming.html#replacing-the-appbar.
also see this GitHub issue that mentions removing it entirely: https://github.com/marmelab/react-admin/issues/3383
Within your custom AppBar you could have some logic checks within your custom AppBar if you know ahead of time when you'll want it disabled (like on a certain page/component).
If you need it to be more dyanimcally disabled, you could probably have a very high-level context/state to control that as well..
**NOTE: I have built a custom AppBar before, but I haven't done any selective rendering or disabling within it. So, I can't guarantee that this is exactly correct, but it fits with other custom components I've built.
I am trying to create some composition but I am not getting anything I'd expect. In almost every instance I've tried a similar setup I get something different which is wrong so this GistRun is representative only as far as it illustrates that at least "something" is wrong.
I've searched high and low for more information on the specific functionality and syntax of compose but I can't seem to solve the issues.
In the before mentioned GistRun you can see that the Container element is not rendered correctly, the h1 is not rendered and that #containerless is being ignored.
In similar scenarios I've had containerless ignored on the compose element resulting in the rendering being ignored and I've had the entire thing not working with named slots.
I have a feeling that I'm doing something wrong and I can't quite figure out what it is. If someone knows what I'm doing wrong or can point me to a solution I would be much obliged.
Part of the reason things aren't working as you expect is that your gist is based off of a very old version of the framework. I've updated your gist to the latest version of Jeremy Danyow's Aurelia bundle here: https://gist.run/?id=1b304bb0c6dc98b23f4a3994acc280e4 The old version of the framework you were using in your gist still used the content element for content projection.
There are a couple of reasons your gist wouldn't run (aside from what I mentioned above). First, the compose element (and any custom elements you create) are not self-closing. This is per the Custom Element spec. So <compose view="test.html" /> wont' work. Second, there is an existing issue regarding containerless elements being used with content projection. After talking with the team, this issue is unlikely to be resolved as containerless custom elements aren't really supported by the Shadow DOM v1 spec. If you remove the containerless attribute from the compose element, your demo works. Finally, you forgot to add <require from="container"></require> at the top of your app.html file. Thus Aurelia was unaware that <ck-container> is an Aurelia custom element. Unless you have globally registered a custom element (or any other view resource), you MUST require it in to any view where you wish to use it.
Now, let's discuss the use of containerless. The containerless decorator and attribute shouldn't be used simply to "clean up" your HTML. They should only be used when absolutely necessary to achieve your goals. "Making my HTML pretty" is never absolutely necessary. When you use containerless you are creating a custom element that likely cannot ever be used as a standard custom element. Again, the Aurelia team discourages you from using containerless elements unless necessary.
An example of a valid reason to use containerless is expained in our documentation here: http://aurelia.io/hub.html#/doc/article/aurelia/framework/latest/cheat-sheet/4
The code to embed the widget is nice and simple, but it includes javascript in tags.
Durandal appears to strip out such script tags.
How do I use the embed code in a Durandal view?
https://dev.twitter.com/web/embedded-timelines
<a class="twitter-timeline" href="https://twitter.com/XXX" data-widget-id="XXX">Tweets by #XXX</a>
<script>!function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0],p=/^http:/.test(d.location)?'http':'https';if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src=p+"://platform.twitter.com/widgets.js";fjs.parentNode.insertBefore(js,fjs);}}(document,"script","twitter-wjs");</script>
You would need to write a custom Knockout binding, or create a Durandal widget where the view is your tag, and the viewModel handles the JavaScript in your tag.
Some notes: In your widget's view model, you would avoid d.getElementsByTagName(s) in favor of simply referencing the view reference passed in to either the attached or compositionComplete handler that Durandal provides. In fact, you could pretty much eschew all direct DOM manipulation in favor of Durandal's imported view references and Knockout's/Durandal's templating/composition.
UPDATE
Take a look at this from the documentation you reference: "If you’re already including our ‘widgets.js’ JavaScript in your page to show embedded Tweets or Twitter buttons, you don’t need to include this script again; it updates automatically to support new features."
This could lead you down the path of simply referencing widgets.js in a script tag in your index.html or index.chtml file.
You cannot use script tags in Durandal views, but you can use them in your index page.
SECOND UPDATE
Once widget.js has been referenced in a script tag in the index.html or index.chtml (or perhaps even by using AMD), it becomes a matter of choosing the proper Durandal point at which to load the Twitter widget. This could be either in the attached handler or in the compositionComplete handler, as indicated above.
As the OP pointed out in his comments, a functional place to do this is compositionComplete, in the following manner:
var compositionComplete = function () {
twttr.widgets.load();
}
as documented here.
This assumes that twttr is either on the window or injected into the viewModel.
POSSIBLE MEMORY LEAK
It is equally important to note that unloading of widgets must take place in the Durandal's detached handler. Use Twitter's API to unload, and then be sure to nullify the windows reference.
I have a listener that is called when a tab is activated.
, listeners: {
activate: function(tab){
var first = tab.down('input'), // will be null
firstEl = tab.getEl().down('input'); // will contain first input element
I'm not having a lot of luck understanding the relationship between tab and tab.getEl(). If this was jquery, $(tab) would give me a jquery element which would largely expand on my set of options. extjs seems to be almost backwards in this regards, or at least more complicated.
I'm trying to understand when and why I need getEl() so that it is less of a development crapshoot about what will and won't work. In other places I do things like:
showFieldHelpOnBlur = function(ctrl) {
ctrl.up('form').down('#helptext').update("");
}
without the getEl(). In this case form is an element tag just like input (above), but I don't need the getEl() before I use it. In general the two sets of functionality that share the same names but don't work the same are frustrating, and the docs don't seem to give any clue as to why there are multiple methods with the same names that do different things, or do similar things in a different way.
Found some similar issues with focus(), but those might make more sense if I just understood why are there are 2 seemingly parallel sets of methods for what are essentially DOM elements wrapped in additional functionality.
I think at the core of your confusion is how you approach the development using ExtJS vs JQuery.
JQuery is all about DOM manipulation and low level API. ExtJS approach is very different, it wants you to think of your page structure as a hierarchy of ExtJS components that are responsible for rendering appropriate HTML. So ExtJS is essentially saying: "Don't worry about html, we'll take care of it - you focus on the larger components, layouts, events, etc. "
You will say "Whoa Nelly! What do you mean don't worry about html? I want control!" And ExtJS will respond OK - we have a wrapper object called Element (http://docs.sencha.com/extjs/4.1.3/#!/api/Ext.dom.Element) you can use it to do DOM manipulation just like you are used to with JQuery .. but be cautious. Because if you manage your own HTML we can't be responsible for what happens to your layouts and components that are not managed by the framework.
My advice is this - when in Rome do like Romans do :)
If you are going to be using ExtJS to build apps - embrace the way ExtJS is designed to work. Learn the different layout mechanics and numerous component types available to you out of the box. Use the MVC development pattern to beautifully organize your code. Use the examples to your advantage. Study the architecture and component guides - these are very useful. Understanding ComponentQuery class is a must (all those up/down methods and query).
At the end, when you have gained comfort using ExtJS components and their style of development you will be very efficient at building your UI compositions and can build much more complex applications than before.
Good Luck!
Pro Tip: Do yourself a favor and get Illuminations for Developers plugin for Firebug - it will open your eyes to see things using component structure rather than HTML elements.
In asp.net the DataGrid supports templates. You can provide your own template and have the grid fill the data in your template.
With Dojo Grid, it seems like I can't make my own template outside of the the rigid simplistic cell style grid that Dojo provides.
Does anyone know a way to use a custom template with Dojo Grid? Specifically, with Dojo you're forced to use a cell that corresponds to a data item. I'm looking to use a table as a template with any styling that I choose (rows,columns,rowspans,colspans, more than one data items in a single cell, etc).
Any clues please?
Thanks
Firstly, it sounds like everything you want is available by customizing the grid. You can do nesting of cells and even have things like Filtering Selects in rows. Unfortunately the docs on this are not awesome so it takes Googling and trial and error if you want very customized features.
Secondly, because of the OO nature of Dojo you can always use inheritance to create mixes of various widgets. Specifically the _templated class allows you to specify an HTML template for your widget, which themselves can included templated widgets.
If that sounds non-trivial, you're right, which is why I would suggest digging deeper into the Enhanced grid and probably open up the code before trying to write something yourself.
I can tell you that I struggled getting it working correctly, but I have hence been pleasantly surprised by features that I needed that I thought I would need to build myself but were built into the grid.