Whenever I add a node to my tree, through its XML data source, it expands all the closed branches.
The code for adding is pretty straight-forward:
AddNode(xmllTree:XMLList, xmlNew:XML):void {
xmllTree.appendChild(xmlNew);
}
And that's it. It does the same thing when I remove nodes.
Yes, I tried handling the mx.events.TreeEvent.ITEM_OPEN event, but despite the promises of Adobe's documentation, that event is not thrown under these circumstances >=/
Is there any other way to prevent this, short of going through the whole list, recording all the closed branches, then closing them again? (Which I'm not convinced would work anyway)
Flex 3.5 SDK here.
...actually, it was probably caused by this silly openItems="{objXML..node}" member of the mx:Tree that the original developers put in. I don't know what they were thinking.
Related
When writing code in cshtml files, sometimes intellisense goes haywire and starts writing text several lines above where I am actually typing. At the moment it seems to be limited to when I hit the tab key to let it finish a property name which isn't too bad because I can just not do that. However, it also seems to happen at other times like just when I type #Model and then press a period it might write the word Model in some other part of the code file.
Anyone know how to correct this?
This would probably fit better as a VS Feedback item, but since this is the only place I have found someone referencing the same issue, I thought I would add some confirmation. I do not have a solution, only more examples to add. This issue has been annoying me for months! It seems to happen most often when typing razor code inside of JavaScript, especially inside of a quoted string.
Here is an example from a test project, where I am attempting to put a reference to a model field into a JavaScript string. Notice that I click tab a couple times and it doesn't actually insert the intellisense result at the point I am typing. But when I scroll down you can see it inserted it randomly in another spot pretty far away!
I did also try to remove the hidden .vs folder, bin/, and obj/ and could still reliably reproduce the issue after restarting Visual Studio. Currently on 1 before the latest (16.9.4). I did notice that if I re-open this cshtml file, wait until the file seems to be fully loaded (all the red errors go away), I also reliably get an ArgumentException that occurs as I begin typing. Then when I scroll down I already see that Model has been randomly inserted in another spot in the code.
I'm going to try updating to latest (16.9.5), and starting in Safe Mode to skip loading all 3rd-party libraries, and see if the issue is still reproducible, in case it is caused by one of the handful of extensions I am currently using.
Edit: Well same issue with 16.9.5. Trying to use Safe Mode is a no go, it makes the intellisense and syntax coloring completely disabled for .cshtml files.
This is the first time I am trying to contribute to Mozilla. I went through several articles and documentation/resources to get a hang of what could be the best first steps to get started. I started off from this page http://whatcanidoformozilla.org1 and chose to start off with Java.
On initial tinkering I was taken to https://wiki.mozilla.org/Mobile/Get_Involved and eventually https://wiki.mozilla.org/Mobile/Fennec/Android/Suggested_workflow resource suggested that the best way to get started with it would be to pick up some simple bug and propose a patch for it.
So then I went to http://www.joshmatthews.net/bugsahoy/?java=1&simple=1 and this specific bug drew my attention. The description of the bug mentioned this :
There are some methods that we share (or can share) across our DB
implementations, like appending PARAM_SHOW_DELETED, PARAM_LIMIT, or
PARAM_PROFILE.
These are currently spread across LocalBrowserDB, TabsAccessor,
URLMetadata, and so on. It'd be nice to clean these up.
Question 1. Now how do I get some more context on what exactly is the bug and what is required to be done ?
As of now there seems to be 2 patches already submitted from what I understood (and please correct if my understanding is wrong here). So to get some context about the bug I went ahead and opened up the first patch submitted here.
It gave me some idea as to at least where exactly is the code itself that needs to be fixed. And I found it here
Question 2. Am I on the right track on how to figure out the code that needs to be fixed ?
Question 3. Even after reaching the DBUtils.java file I could not find any documentation about what the class basically does, or where does it fit into the whole picture. Could someone please help me with this, as to how do I figure out what a class is supposed to be doing etc. or at least some documentation around it?
You're on the right path. Basically, the What Can I Do For Mozilla website is a quick and easy way to let you discover projects you might be interested in, so it's the first gateway to the coding contributions.
That said, you did good in picking a bug to start off. However, as you saw the bug was already being worked on by somebody else (marked as Assigned). Your best bet is to find some new "good first bug" to work on. This might be a complicated task, as Bug's Ahoy shows only a few not owned good first bugs.
You should try to get in touch with the Fennec team, either via email or IRC (the latter for quicker responses).
Now, to answer your questions, in a more general way
Question 1. Now how do I get some more context on what exactly is the
bug and what is required to be done ?
Usually, this should be described in the first comment in the bug, on Bugzilla. If that's not the case, feel free to drop a message there and ask for more directions. You can also flag the reporter or the mentor of the bug using the needinfo functionality, as they are usually better shown.
As you can see, somebody asked for more info in comment 1 and some new directions were given.
In general, you won't find a patch with code on the bug itself, but you might find links to files and more precise directions on what to change and how. If not, again, feel free to ping the reporter and/or mentor.
Question 2. Am I on the right track on how to figure out the code that
needs to be fixed ?
You're on the right path. In general, if there are no links to files or DXR on the bug, but some code is mentioned, you can look it up using DXR, as you did.
Question 3. Even after reaching the DBUtils.java file I could not find
any documentation about what the class basically does, or where does
it fit into the whole picture. Could someone please help me with this,
as to how do I figure out what a class is supposed to be doing etc. or
at least some documentation around it?
What I usually do when navigating the Firefox code and need some more background on a not so well documented class, is browse the change log for that file, clicking on the Log button in the top-right panel on DXR (when displaying the file). It will show you a list of bugs that affected the file. You can even trace back the original file that implemented it, to get more context.
On the other hand, if you're only interested to the history of a single line of code within a file, then the blame tool is your friend. It tells you who last touched the line, the changeset and the related bug number. That is also accessible from where you can find the Log, here.
In the case of DBUtils.java, however, it looks like the class just holds some utility functions for database access.
To see how something is being used within the Firefox codebase, you can still use DXR. Here's a sample search for the DBUtils object.
Problem
So we have quite a big project with lots of different Partial Views and a client side data binding framework (Knockout.js in our case).
One of the more problemtic parts is that is getting harder and harder to figure out which partial view is rendering an element that I see on my page.
So I need to debug this particular DIV. Okay, where do I find it?
Usually I try to find a very specific class or ID close by this element and do a search through the whole platform - far from ideal.
Question
So I was thinking about the following; tagging all elements (in debug mode) with the source file where they have been generated.
Right now I'm thinking about something like a precompiler that adds a data-source="" to every element. I might refer to an ID within a dictionary to prevent repeating all the long filenames.
Before I'm reinventing the wheel:
is there already something similar?
are there better alternatives?
We're using ASP.NET MVC, but any hints to how other platforms do this are perfect too.
If you are using Visual Studio, I highly recommend the Web Essentials extension. Among many great features, it has one called "Inspect Mode", part of the larger "Browser Link" feature, that does exactly what you are looking for; it identifies the file that a particular DOM element came from. It might be worth a shot if that option is open to you.
#Dirk, as per my understanding your issue is to easily identify the element/view. Adding data-source can be an option but before that have a look at this link
Editing Styles and DOM - Chrome Dev Tools
This page has many demonstrations which might be helpful to your problem. Furthermore, I do agree with Kevin suggestion.
I need to place the toastr inside a specific container, but I can't find this concept represented in the API. I found an old question where it was mentioned that options has an undocumented property target that do seem to work properly, the question was closed, referenced generally to stackoverflow and the property is still undocumented.
I'm using typescript and the typings for toastr, so the fact that target does not exist in ToastrOptions becomes very explicit.
While it would be trivial to hack around this or just to get rid of the errors in typescript, I'd like to stay clean and would appreciate some clarity on the lack of this feature or the lack of documentation.
Is target supposed to be documented or is the lack of support for placing the toastr in a specific container a conscious design choice?
I've been working on the web for quite a long time and I saw the "best practices" evolve. I'm now fairly convinced separating HTML (Content), Javascript (Behavior) and CSS (UI) is the best thing to do.
A few months ago, I started using knockout.js . I did choose it among other similar frameworks like backbone or angular because a chapter in an MVC training I followed was about knockout, and the concept seduced me. Then after a quick comparison on the web it didn't look as a bad choice for my needs, and for a start.
But here's my problem : when I look at my HTML code now, after a few weeks of dev on a project, there's quite a lot of knockout bindings in it, and it makes me think a lot about the old times, when we (or at least I) used to put inline javascript event handling through onclick attribute and so on.
Therefore those 2 questions, which I'm not sure are 100% suited for SO, but I can't find any better StackExchange site to ask it :
Is using knockout (or the other frameworks as they all seem to basically work with the same pattern) contrary to the "separation rule" ? Or is it an acceptable small-step-out of this rule ? or is it even perfectly acceptable because it uses the "data-" attributes ?
In the case this would be a somehow bad practice, is there any possibility to do all the binding through a separate javascript file, using for example jQuery to select the controls and apply bindings to them ? If not possible in knockout, is it with another framework ? I must admit at the time I did my selection, I diddn't think about this kind of implications...
Thank you and sorry if this should be moved to another SE site.
I had the same initial reservations as you, but I have to say that having the bindings in the html and not hidden away in a JS file seems so much better to me, as the link between presentation and functionality is now completely obvious. It massively reduces the possibility of changing some HTML and breaking functionality because you weren't aware that someone had hooked up some javascript to an element using jQuery.
Also, as you point out, the use of the data-bind attribute does, I think, mean that it does adhere to the separation rule, though if you want to stick to it rigidly then make sure all bindings are to observables, computed or functions on your view model, don't use any code (i.e. a visible binding that checks the state of two observables). I'm not sure I'd take it that far though.
I guess everyone started to learn KnockoutJS have the same concerns.
IMHO, there must be some way that connects models(JS object) with views(HTML markup). Then we should have something that says:"When that button is clicked call this function with that arguments." or "Hide this element while you that JS array is empty" and so on. So how we can put/say/state that connection in a readable, reusable and clean way.
If you used another JS file to handle that connection, then you 'll have large lines of code just to put your connection logic and you need to know how to select the DOM element you are targeting. You 'll end up with massive code(probably lot of jQuery) just to make your HTML dynamic and alive(i bet most developers got into that many times). I haven't use other libraries or frameworks but i think they just make your massive code more organized.
On the other hand by KnockoutJS use Declarative Bindings, this is the link between models and views. It's more readable, easy to plug it in/out and it allow you to just focus on writing a good JS model object.
I guess to truly check separation think what if you sometime needed to change your model, how much changes you need to do to your view? and vice versa?
Adding to the rest of the answers, some tips:
Make sure there's no business logic in your bindings. Any logic (which should be minimal) should be "view logic": decisions that only affect how your view looks, not how it works. Deciding how many items to display per screen is view logic; deciding whether the user can add another item is business logic. It's perfectly OK to put view logic in your viewmodel rather than your view, and it's desirable if it involves lengthy expressions.
Keep "magic numbers" out of any view logic in your bindings. If it's a parameter that could be changed (e.g. number of weeks of results to show) as opposed to a true constant (e.g. number of days in a week), make it a property of your viewmodel and reference it in any expressions in your views.