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?
Related
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 have tried via some blogs, have joined mailing lists of W3C and WHATWG.
How should I proceed for writing spec for a new HTML tag and subsequently propose it to W3C?
My current employer is a member of W3C.
In literal terms, just write it and post it, and make it known via the mailing lists.
Writing the spec is the easy bit. Getting implementers to buy into it is the hard part. You have to convince them that putting the work into implementing and maintaining it will make for a better web, more so than the other things that they could be doing. That's a huge hurdle to overcome.
So it's actually more useful not to start by writing a spec. Instead post to the lists your description of the problem that you're aiming to solve and try to convince the others there that the problem is one worth solving. If you can do that, they will then be able to help you identify the best way to solve the problem, which may or may not involve the creation of a new element, and also help flesh out the use cases for the solution whatever it happens to be.
Will Polymer support Google Closure Compiler? What are the reasons why Polymer did not support Google Closure Compiler from the very beginning?
Well I can't answer why there wasn't support for the compiler from the beginning because I don't work on Polymer itself, but I do know that there are people working to make Polymer work better with the compiler now. In the short term, we're looking to add externs like these:
https://github.com/Polymer/paper-checkbox/tree/master/externs
for existing elements and are looking into adding an externs generator so that we don't have to manage these manually. Longer term, we are hoping to have full support for compiling Polymer elements and ensuring that they work well with other compiled code. Would externs address your use case in the short term? Maybe we can try to prioritize certain elements or at least give you some idea of when they'll be done.
A polymer-aware compiler pass looks like it's in the works: https://github.com/google/closure-compiler/wiki/Polymer-Pass
I have worked a few places which haven’t used source control. They seemed to get into the habit of putting comments around code they changed explaining the change so that things could be reverted.
I have found that this makes the code very difficult to read, and have been fairly adamant that such comments are not needed after introducing source control as the revision history will let you match up tickets with changes.
However now, I am not so sure, I think it may be good to document major revisions to a file in a file as well as in the commit messages. This should make the code more readable. Do people have a best practices way of documenting changes to code, so that it is not too cluttered but is still explanatory to someone trying to read it?
Just to be clear, I am not talking about a list of changes in the head of the file (which is a whole other argument) but comments in the code.
Most source control systems have an "Annotate" or "blame" command. It shows what code changed with each revision.
Since this information does not change the behavior of the program, or make it easier to understand the program, it doesn't belong in the program.
The documentation present in code should describe the code it is near. If the code changes, the documentation should also change accordingly. The version control system should take care of managing what changed and why it changed. Let the code and it's documentation do it's job (Doing things, and describing how/why those things are done), and let the version control system do it's job (controlling/documenting versions and changes).
Whenever you start indicating history in the present(current code), you are asking for trouble. Just think what a particularly change-heavy area of code would look like if it had a number of changes?!
If the comment is time sensitive don't do it it's a bad idea. Put a comment on the source file in the version control system instead.
I see this problem all the time at work. The code base I am currently working on extends back to 1979. You can imagine the difficulty with comments like the one below which have built up over that time:
"Line below seems to fix bug xyz, will revert if unforseen issues occur"
I realise it's not a very descriptive comment in the first place but that sort of thing in svn/cvs/etc. is actually very handy. A comment like that in the code sows the seeds of doubt. Can the comment be removed? Is the unforseen issue that has caused me to have to look back at the code related to this comment? etc.
I'm just wondering how knowing what the program USED to do helps understanding it now? You say it aids readability. How?
Now, when something is changed because the old way didn't work and the new way is counter-intuitive, I think that should be commented in code, because it's necessary to know for all time "This didn't work, don't do it again. I know it looks like it would make more sense. Still don't do it." Otherwise, I don't see that it helps.
Don't think that commenting changes inside a code is ever possible in a explanatory way.
But I'd like to say about "Modification history at the file begin". I doubt that this is useful at all. Unless I wanted to know which to versions of a file to compare to see the difference that were introduced with some "NNNN" task. In the file begin there is a line "NNNN date - small description". And our source control can "say" who and in which version this line was introduced.
So without this line I would look through all versions to find correct one.
I think it's good to document major changes or refactorings as comments in the code. I agree that it does get a little messy to read around copious amounts of comments, but I think it's easy enough to ignore the comments and try to just read the code. If anything is confusing, or you are tempted to change something, and there is a comment near by, you will be much more inclined to read the comment, as opposed to doing diffs with previous versions to see what had changed and why.
Each method in our codebase has its own change history. When the code of a method is changed its header gets a new entry. The code itself does not get cluttered with history comments, only the method header. Each change history entry consists of one or two lines briefly describing the reason for the code change in general terms. The entry also contains a number that refers to a change document, The change document also contains links to bug reports, development projects, design documents etc.
Such entries are invaluable, as they often give you an insight as to why the code is as it is. If you are there to fix a bug the history trace will invariably tell what code change introduced the bug, what the change was attempting to do, and therefore what else you need to be aware of when deciding on a fix.
OTOH - Reams of comments in the body of the code describing what it does and who changed it when are just noise.
Going to have a stab at answering this myself.
Documenting every change in the source makes it difficult to read, however if there is a particularly counterintuitive piece of code in there and it was introduced for a particular ticket put a note by it as to why the code is strange.
But the code should still be documented. So while you make not put in
/* ticket 101: add blink tag to headers, JF - 20010102 */
You may want to put in
/* make headers blink */
Quite often when people stop doing the former type of comments, they cut down massively on their comments and this is bad.