Dojo Grid Template - dojo

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.

Related

Aurelia popover checkbox checked.bind not reflecting on the view model

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 :-)

reusable components with bootstrap

Very new to bootstrap and it seems so cool, but as I look around at various templates, I feel I am missing the "template" nature of the code.
How does one build on the sample templates to have, for example, a master index page and reusable components (tabs, sidebars, menus, headers, footers) available to all "rendered" pages? It does not seem efficient to recode sidebar menus into every page but that's what the samples seem to show.
Perhaps there is a way to have a special div where the variable content can be loaded?
Or, perhaps there is a higher level framework I should be looking at and bootstrap is not the answer for what I need?

DNN - trying to insert background-image in .DnnModule HTML module, and then give client 3 choices to use as HTML modules

My first problem is that I can't even seem to get a full background image to work for individual modules of type "DnnModule DnnModule-DNN_HTML". Of course I could give them all the same background-image by targeting the DNN_HTML class, but I need to be able to use different background-images on different HTML modules (I need a green, a blue, and a tan). So I need a way to target the HTML modules being used individually? Is there a way to do that? (I am a newb, so please go easy)
Then, the ultimate goal is to have the client able to pick and choose which color module they want to use throughout the site.
Of course I could code an HTML module with the different backgrounds in-line, however, there are various other divs that surround that HTML module, and therefore, the background-image I set in the module using the editor is tiny, and does not cover the whole div.
I'm also not sure if its best to make the client a template with different colored backgrounds they can use already layed out in "bucket" containers for them, but I don't think they could switch the order around could they?
Is there any way at all to accomplish this? Any help would be really really appreciated.
This really would normally be handled by the Container system within DNN.
I would create 3 different Containers for the colors in question, and then instruct the customer how to choose the Container in the module settings for each of the modules that they want to change the BG for.

What is the point of getEl() in extjs4

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.

Dojo and Dijit reference for all properties

I was experimenting with Dojo and Dijit in the past days and I find it quite interesting. I was however trying to find a reference or an API doc that helps me understand all the properties I can assign to widgets and containers.
For example a Tab with a Save Icon will be like this:
<div data-dojo-type="dijit.layout.ContentPane" title="Group Two" data-dojo-props="iconClass: 'dijitEditorIcon dijitEditorIconSave'">
Now, where can I find what to put in the "data-dojo-props" property? Where can I find for example all the list of icons?
My main question would be for example on how to create a vertical menubar, but beyond odd examples scattered here and there, the api reference is not much helpful...
Any help? Am I missing something here?
For this kind of situation, the trick is learning how to convert between the programmatic Javascript style and the declarative HTML style (and sometimes also between the old declarative style, without data).
For the new declarative style, basically the only "real" argument now is data-dojo-props and it consists of an object that will be passed to the widget constructor.
//programatic style
new dijit.myWidget({foo:'a', bar:'b'});
//declarative style
<div data-dojo-type="dijit.myWidget" data-dojo-props="foo:'a', bar:'b'"></div>
You can find what properties an widget accepts by checking the corresponding widget documentation and looking for either declarative or programmatic examples (now that we know how to convert between them). If that is not enough, you can also check the source code - it is usually very well commented and is where api.dojotoolkit.org gets its data from anyway.