Here is javascript code (jquery) for adding a row of images:
var tr = $('<tr>');
var td = '<td><img src="myimg.jpg"/></td>';
tr.append(td).append(td).append(td);
$('#mytable tbody tr:eq(0)').before(tr);
tr.empty(); //I really don't need this line...
Technically tr.empty() shouldn't have worked. It actually does the opposite of what I want. What is the techinical term for this behaviour - You've added tr to the DOM, but any jquery function calls to that object still works, where as you'd normally not expect it to work i.e. make changes to the DOM?
I think you have a case of a shared mutable object. You are modifying the object in one place and are surprised to see the changes visible in another place. It's not technically wrong; it's just what happens when you have multiple references to an object that can be modified.
If there is a particular term for this other than 'object reference', I don't know what it is. I'd suggest that your expectation:
any jquery function calls to that object still works, where as you'd normally not expect it to work i.e. make changes to the DOM?
should be adjusted - for object variables, one should expect that whichever particular reference a change is made through, all references see the updated object.
Related
Is there a way to execute a method exactly after the component has its properties available but before the first render?
I mean something between the class contructor() and firstUpdated().
It sounds trivial, maybe in fact I'm missing something trivial..
The element's constructor is called when the element is created, either through the HTML parser, or for example through document.createElement
The next callback is connectedCallback which is called when the DOM node is connected to the document. At this point, you have access to the element's light DOM. Make sure to call super.connectedCallback() before doing your own work, as the LitElement instance has some work to do here.
The next callback is shouldUpdate, which is an optional predicate that informs whether or not LitElement should run its render cycle. Useful if for example, you have a single observed data property and destructure deep properties of it in render. I've found that it's best to treat this one as a predicate, and not to add all sorts of lifecycle logic inside.
After that, update and render are called, then updated and firstUpdated. It's generally considered bad practice to perform side effects in render, and the occasions that you really need to override update are rare.
In your case, it sounds very much like you should do your work in connectedCallback, unless you are relying on LitElement's rendered shadow DOM, in which case, you might consider running your code in firstUpdated, then calling this.requestUpdate() to force a second update (or changing some observed property in firstUpdated)
More info: https://lit-element.polymer-project.org/guide/lifecycle
I'm using Coded UI Test to test a web application.
I have a class Locator that I use to stash the specifics needed for CUIT to find a control. To operate on a control, a page object specifies the locator, not the control, and lower-level functions find the control and perform the operation.
Right now, my class has:
Locator name.
One or more attrName/attrValue pairs that can locate the HTML element for the control.
An operator (Contains or EqualTo) that specifies the matching needed.
The problem: Some of the controls I need to operate on don't have enough unique attributes to allow them to be found. (Yes, I know the developers should improve their HTML, but I don't control that.) I have been using a locator to find a nearby element, then "walking" in the DOM to get to the element I want. I hate having this DOM-walking code in my page object, even factored into a function.
A possible solution: I'm considering enhancing class Locator so that it can have either the attrName/attrValue pairs or a reference to a function that has the DOM-walking code. One advantage of this is that the page objects would always use a locator object. Another is that when the HTML is improved, the locator could change from DOM-walking code to attrName/attrValue pairs, which would be transparent to the page object.
Still, I think this may be over-complicated.
Is there a better solution to this problem?
Not sure specifically how your locator works, but could you find the closest parent to that object, let's say an HTML Div with an id of "parent", and then count the tag instances underneath? For example:
HtmlDiv id="parent">
HtmlHyperlink>text1</
HtmlHyperlink>text2</
Would require the following code:
public HtmlHyperlink text2Link
{
get
{
HtmlDiv parentDiv = new HtmlDiv(browser);
parentDiv.SearchProperties["id"] = "parent";
HtmlHyperlink target = new HtmlHyperlink(parentDiv);
target.SearchProperties["TagInstance"] = "2";
}
}
This would find the 2nd hyperlink under the parent object. (Tag instances are not zero based).
Then, you'd just interact with your object as needed:
Mouse.Click(text2Link);
for example.
Is it possible to extend the addEvent function in mootools to do something and also calls the normal addEvent method? Or if someone has a better way to do what I need I'm all years.
I have different 'click' handlers depending on which page I'm on the site. Also, there might be more than one on each page. I want to have every click on the page execute a piece of code, besides doing whatever that click listener will do. Adding that two lines on each of the handlers, would be a PITA to say the least, so I thought about overriding the addEvent that every time I add a 'click' listener it will create a new function executing the code and then calling the function.
Any idea how I could do it?
Whereas this is not impossible, it's a questionable practice--changing mootools internal apis. Unless you are well versed with mootools and follow dev direction on github and know your change won't break future compatibility, I would recommend against it.
The way I see it, you have two routes:
make a new Element method via implement that does your logic. eg: Element.addMyEvent that does your thing, then calls the normal element.addEvent after. this is preferable and has no real adverse effects (see above)
change the prototype directly. means you don't get to refactor any code and it will just work. this can mean others that get to work with your code will have difficulties following it as well as difficulties tracing/troubleshooting- think, somebody who knows mootools and the standard addEvent behaviour won't even think to check the prototypes if they get problems.
mootools 2.0 coming will likely INVALIDATE method 2 above if mootools moves away from Element.prototype modification in favour of a wrapper (for compatibility with other frameworks). Go back to method 1 :)
I think solution 1 is better and obvious.
as for 2: http://jsfiddle.net/dimitar/aTukP/
(function() {
// setup a proxy via the Element prototype.
var oldProto = Element.prototype.addEvent;
// you really need [Element, Document, Window] but this is fine.
Element.prototype.addEvent = function(type, fn, internal){
console.log("added " + type, this); // add new logic here. 'this' == element.
oldProto.apply(this, arguments);
};
})();
document.id("foo").addEvent("click", function(e) {
e.stop();
console.log("clicked");
console.log(e);
});
it is that simple. keep in mind Element.events also should go to document and window. also, this won't change the Events class mixin, for that you need to refactor Events.addEvent instead.
I got a problem with processing an array in actionScript. I removed the last element of an array through array.pop(). After that I would like to put this removed display-object back to the beginning of the array: array.unshift(object). The object is now the first element of the array but it got still its old label (number of the last element). Therefor I can't update the position (graphically) of the display object. Is it possible to "reindex" the array?
A popped element will not keep it's index, since it will be taken out of the array. If you're trying to unshift(array[i]) after popping array[i], you get an error for referencing an index that no longer exists.
In order to do what you're describing, you can say array.unshift(array.pop()) and then reference the moved element at array[0].
I used the above method when I created an endlessly looping slideshow.
Edit.
It seems I misunderstood your problem slightly. IIRC it is not possible to manipulate an array you're traversing over.
Please post the snippet you're having trouble with for a more educated answer.
Explanation:
i have few objects and im declaring them inside $(document).ready(). WHY? because in thous objects i have many jquery methods $(..), obviously they can work outside too, but when i include mootool, then it stop working. i tried noConflict and some other things, nothing works, only if i change the $() to jQuery() or to $j().. and i dont want to change for my 20 files and more then 2000 lines for each file. anyway declaring my objects inside $(document).ready(). made them work just fine.
Now My Question is:
if i declare all these objects inside the $(document).ready() method, would it make my site slow? or would it make things slow from client side? thats the only concern in my mind.
I don't see how doing that would make your site slow. By declaring them within the $().ready you're simply restricting the scope of your declarations to that particular $().ready function, thus they won't be available from within the scopes of other ready functions on the same page - which should not really be a bother if your application is well-designed and you've stuck to one per page.
Oh, and your declarations certainly won't have been been parsed until the DOM is fully loaded, (as you know, $().ready only executes once the DOM has loaded), but that too should not be a problem as you're only utilizing them from within a ready function (at least I hope).
Do you really need two libraries? If it's just one or two little tidbits of functionality you are using from one of those libraries chances are you can mimic that behaviour using the one you're making the greatest use of. If you can possibly/feasibly do that it will make your life so much simpler.
Doing everything in jQuery.ready will not slow down your site.
As an alternative solution, you could replace $ with jQuery in all of your jQuery code, or you could wrap it in a function like this:
(function($) {
$('whatever').something();
})(jQuery);
This code makes a function that takes a paremeter called $, and calls that function with the jQuery object. The $ parameter will hide mootools' global $ object within the scope of the function, allowing you to write normal jQuery code inside the function.
Just declare
jQuery.noConflict before the document.ready request, then alias the jQuery method to $ within in the document.ready...
jQuery.noConflict();
jQuery(document).ready(function($){
});