I have this array of rects using jQuery and Raphael:
squares = [];
for (i = 0; i < 2; ++i) {
var square = paper.rect(0 + 100*i, 0, 70, 70);
square.node.idx = i;
square.node.setAttribute('class', 'foo');
squares.push(square);
}
I can successfully query various attributes, like:
alert(squares[0].attr('x'));
or
alert(squares[0].attr('width'));
but not:
alert(squares[0].attr('class'));
Is there a special reason for which this is not valid?
Is there an (other) way to query the class attribute?
Thanks,
Adrian
Classes in SVG aren't quite the same as classes in everything else - and in Raphael, which deals with SVG and IE's VML, things get even more hairy.
First of all, they're on the page's DOM element (Raphael's output) not in the Raphael JS object itself. You'd use Raphael's .node to get the actual DOM path (e.g. with jQuery, $(squares[0].node).someJqueryFunction();) but this sort of thing is best avoided where possible for the above reasons. This related question has answers with more info.
If you want to use classes to store data (e.g. like using 'active', 'inactive' classes as switches), you're best off using Raphael's .data function which apparently is for storing arbitrary values. This related question has answers with more info.
Related
I'm trying to produce a runtime table. Below class and codes are simplified version of my final purpose.
class AppModel {
int appID;
String appName;
AppModel({this.appID, this.appName});
}
I'm calculating, fetching some another data and trying to fill the following object like this:
// _newApps value is between 1-30 mostly but not limited
List<AppModel> theList = [];
for (int i = 0; i < _newApps; i++) {
AppModel _newRecord = AppModel();
_newRecord.appID = _getNewAppID();
_newRecord.appName = _getNewAppName();
theList.add(_newRecord);
}
So the question is the code creates a new AppModel instance for only adding the element to the list for every iteration inside the for loop. According to my program logic, this event can be repeated 100-150 times sometimes.
Is it normal or is there any more memory efficient way to do so?
Thank you in advance.
I would like to point out (a better approach) that instead of for Loop you could have used the map method on the Apps List you have. And instead of creating a object every time in the Loop create a constructor for returning the object instance using the required details.
Hope you find it useful.
I want store the filters entered on the grid, is it possible to store the filters entered on filter pane of the grid.
I want to use those filters entered in my class, please help me in this regard.
No, form queries cannot be saved as code (but such functionality could be programmed).
A form query could be passed from the form to a class, using a parmQueryRun method or similar.
See:
How to Create Queries by using the AOT
How to Create Queries by Using X++
Yes you can retrieve the filters by getting the form's queryRun's query and packing that into a container to be stored/passed/unpacked.
The form has a query, that is passed to QueryRun, then the users puts filters/dynamic joins/etc on that query that belongs to the QueryRun. So you need the modified query to store what you want from it.
void clicked()
{
Query q = salestable_ds.queryRun().query();
int i;
container c;
for (i = 1; i <= q.queryFilterCount(); i++)
{
info(strFmt("%1: %2", q.queryFilter(i).field(), q.queryFilter(i).value()));
}
// If we want to store these we can do
c = q.pack();
}
See this post http://dynamicsuser.net/forums/t/63208.aspx
I'm trying to get my head around using CoffeeScript comprehensions as efficiently as possible. I think I have basic mapping down -- turning one list into another -- but searching still seems verbose to me.
Say I have a map of items to shops:
shopMap:
toyStore: ["games", "puzzles"]
bookStore: ["novels", "picture books"]
and, given an item, I want to find out which shop it's in. What's the best way of doing that in CoffeeScript?
Here's how I could do in in JavaScript:
var shop = findShop(item);
function findShop(item) {
for (shop in shopMap)
itemList = shopMap[shop]
for (i = 0, ii = itemList.length; i<ii; i++) {
if (itemList[i] === item) {
return shop;
}
}
}
}
I used a function to allow it to quickly break out of the loops with the return statement, instead of using breaks, but the function is kind of fugly as this is only being used once.
So is there a shorter CS equivalent preferably one that doesn't require creating a new function?
You can try this:
findShop = (item) ->
for shop, items of shopMap
return shop if item in items
If you really want to try with a list comprehension, this is equivalent:
findShop = (item) ->
(shop for shop, items of shopMap when item in items)[0]
But i think the first one reads better (and also doesn't need to generate an intermediate array for the results). This would be a better approach IMO if you wanted to find all shops for a given item:
findShops = (item) ->
shop for shop, items of shopMap when item in items
If this is a common operation, you might be better off creating an intermediate data structure up front and doing the lookup directly.
shopMap =
toyStore: ["games", "puzzles"]
bookStore: ["novels", "picture books"]
categoryMap = {}
for k, v of shopMap
for category in v
categoryMap[category] = k
alert(categoryMap['puzzles'])
Demo
With this implementation you need to loop through the structure only once up front (plus possibly update it if shopMap changes). With yours and epidemian's answer, you have to loop every time you need to do this particular type of lookup. If you do this operation a lot, it could make a difference. On the other hand, if your shopMap is really large (like thousands of entries), then my implementation will take up more memory.
Depending upon how robust you want to make this, you might want to turn it into a Class and have any operations on it occur through the Class' interface. You'd need addCategory and deleteCategory methods as well as a getStoreFromCategory method, which is essentially what we are implementing above. This object-oriented approach would hide the internal data-structure/implementation so you could later alter the implementation to optimize for memory or speed.
What would be the most efficient way to find all ExtJS components that are rendered as descendants of a given HTML Element? Note that this Element is not part of a component itself and is not managed by Ext in any way, it is just hardcoded raw HTML. And this Element may not only contain just ext components, it may have other non-ext managed html in it as well, and that html can also contain ext components. So that means that the solution must traverse all the way down the DOM, not just look at direct children.
My suggestion would be to walk the dom, checking the id of each element against Ext.getCmp, which is a hash-map lookup. You could then switch to walking through the Component methods, but I think it would be basically the same speed, and if you're already walking the dom to begin with you might as well keep at it:
var dom = ...;
var components = [];
Ext.Array.each(Ext.get(dom).query('*'), function(dom) {
var cmp = Ext.getCmp(dom.id);
if (cmp)
components.push(cmp);
});
Ext.get(dom).query('*') may do more work than you'd like, it might be more efficient to have your own walker, like this:
function walk(dom, callback) {
if (dom.nodeType === 1) {
callback(dom);
Ext.Array.each(dom.childNodes, function(child) {
walk(child, callback);
});
}
}
var dom = ...;
var components = [];
walk(dom, function(dom) {
var cmp = Ext.getCmp(dom.id);
if (cmp)
components.push(cmp);
});
All this assumes that the dom ids match the component ids, which I don't know if that is something you can rely on in future versions of Ext.
I have 2 main questions.
Does extending things like Object count?
What is DOM wrapping?
http://perfectionkills.com/whats-wrong-with-extending-the-dom/
After reading that article I couldn't find anything about DOM wrapping, and no specification and what exactly is and isn't DOM extension.
No, Object is specified as part of the Javascript language, while the DOM is an API only relevant in a browser environment and is used to "access and update the content, structure and style of documents" (W3C).
However, one of the reasons provided in that article arguing against the extension of DOM objects still applies to extending native types such as Object - namely the chance of collisions.
Wrapping an object refers to creating a new object that references the original, but providing additional functionality through the new, wrapper object.
For example, rather than extending a DOM Element object with a cross-browser addClass function like this:
var element = document.getElementById('someId');
element.addClass = function (className) {
...
};
You can instead define a wrapper function:
var ElementWrapper = function (element) {
this.element = element;
};
And add the function to its prototype:
ElementWrapper.prototype.addClass = function (className) {
...
};
And "wrap" elements like this:
var element = document.getElementById('someId');
var wrapped = new ElementWrapper(element);
wrapped.addClass('someClass');