I'm working on a legacy ASP.NET project, which I'm trying to massage into shape slowly, but I can't make significant changes without it all collapsing like a chocolate finger house....
I've tried to find a solution for this, but failed miserably due to the specific mix of terminology ("javascript", "embedded" and/or "resource" just give me information as to how to embed a .js file...), and the fact that it's probably a weird way of doing things.
The project makes use of App_GlobalResources for translatable strings, which is used in C# code behind, the markup and in some of the JavaScript. For example:
HTML:
Text="<%$Resources: Resources, MeasuresLabel %>"
JS:
setDialogTitle('summaryDialog', physicalElementName, Resources.Resources.Summary);
This was all working fine, until we started using NUnit for some integration testing. To make the Resources.resx available to NUnit I've followed Scott Allen's suggestion, which works for NUnit but means that the above Resources.Resources is undefined.
So, my question is with this embedded file, how can I make it accessible to the JavaScript (or is there a better way I can make it available to NUnit)?
There's an the added complication due to the code I want to access it with being in separate .js files, rather than within script tags in the .aspx files.
EDIT
After looking at it some more, the real challenge is the properties that are accessed in the JS are static. Due to the number of places these are referenced, it's not practical to add a variable for each string that's being used.
I think that JS files aren't going through the ASP.NET engine and they are served as they are, that's why Resources.Resources.Summary isn't defined in your case, while it will work when embedded inside <script> tag in .aspx file.
The only way I know around this would be to store the used resource values in global javascript variables on the .aspx page and then use them in loaded JS files.
Related
I did find a very interesting tool for identify unused css definitions in a web project.
http://www.sitepoint.com/dustmeselectors/
Are there similar tools also for javascript projects?
P.S.
I know there is no program for deterministically finding unused code. But I am looking for a report to identify possible unused code. Then the last decision will always be your own.
Problem is there is no way to be really sure. Suppose the following:
The initial HTML site is practically empty. There is a lot of JS code though, which seems to be unused.
OnLoad, a function is called which launches an AJAX query to the server. The server returns a lot of HTML code, which is the body of the site. This body contains lots of JavaScript functions.
The initial body is replaced with the body received via AJAX. Suddenly, all code is used.
Static analysis utilities are therefore useless. I do not know whether there exists a browser extension that marks all JS usage from a running browser though.
You can try using tombstones to safely locate and remove dead code from your JavaScript.
https://blog.bugsnag.com/javascript-refactoring-with-bugsnag-and-tombstones/
In order to find the unused assets, to remove manually, you can use deadfile library:
https://m-izadmehr.github.io/deadfile/
It can simply find unused files, in any JS project.
Without any config, it supports ES6, JSX, and Vue files:
The one that comes to mind most quickly is Javascript LINT (http://www.javascriptlint.com/) and JSLint (http://www.jslint.com/).
Beware though: the latter hurts your feelings.
Every beginners guide to Javascript talks about the evils of embedded scripts.
And I get it: definitely good advice for novices who have no concept of modular design. But every rule has an exception, and since I'm fairly new at web development (but not development in general) I want to ask if the following is a good exception:
I'm building a web application using MVC on the server-side (Django, for the record), and Require.js on the client-side to manage application logic scripts. I'm careful to keep these scripts DOM-agnostic.
It makes sense to me to embed the remaining DOM-interacting code directly in the server-side HTML templates that are defining that DOM. Creating separate JS files that are so minimal and tightly coupled with the content of the templates just feels unnecessary. Am I wrong?
Assuming you've got all application logic tucked away nicely in external files, is it really so bad to sneak a few lines of jQuery in with your HTML to hook that logic up to the DOM?
If you've got JS that applies to only one page and there's not very much of it then yes, I would put it directly in the page rather than as a separate JS include.
If you have a lot of JS that applies to only one page then a separate JS include gives you the advantage that (after the first request) it will sit in the browser cache rather than being downloaded every time a user refreshes that page. So in that case I'd probably stick with the external JS file.
Having made the decision to include JS in a particular html page, I prefer to include it all as a single block either in the head or at the end of the body - I don't want to have to scan through the html looking for multiple small script blocks buried in the markup. Also if I later decide to move the script to an external file it is easy to do so.
See this on where it is going particularly comment around Angular js from google referred to
http://blog.stevensanderson.com/2012/08/01/rich-javascript-applications-the-seven-frameworks-throne-of-js-2012/
See this Comparison http://engineering.linkedin.com/frontend/client-side-templating-throwdown-mustache-handlebars-dustjs-and-more thorough test and comparison
It appears DOM Templates maybe the future. And for my mind better to deal with in terms of debugging.
I believe that this question has been asked in a few different forms, but I've read quite a few different responses.
At first, I had a web-application written with mostly jQuery that would make use of servlets to retrieve information from various locations JavaScript could not access (ie. Feeds, images from a server, etc.). Now, however, I've been told to do away with the servlets and application configuration classes so that this project of mine contains only HTML, CSS, and JavaScript/jQuery. Rather than pulling the images off of the server, I need to retrieve them from a local file on the computer. I know that allowing this might seem like terrible design, but it's what I've been asked to do. At any rate, what I really need to do is count the number of image files in a directory and then perhaps compile an array of the filenames themselves. I could do this fine in Java when using the servlets, but without them, I'm not sure how or even if this can be done.
I'm basically trying to use the jQuery Cycle plug-in to cycle through these images like a slideshow. I inject (or $("#div").append()) these images into the div by using a loop based on the number of images present.
So, is there a way I can do this with using JavaScript, HTML, jQuery plug-in, etc? I'd like to avoid using PHP and Java at this point...
You can't just read a directory with JavaScript; however, there appears to be a way to "exploit" how browsers function using http://www.irt.org/articles/js014/. It may not be pretty, but the demo works in the latest Chrome and IE7-9 for me. I'm sure some of the techniques could be updated to use cleaner code if you'd like to improve upon it.
EDIT:
Another technique you could use can be found in Javascript read files in folder
It definitely looks to be a cleaner solution. What I'd recommend is extracting the body contents to inject into a hidden div or using the path for an iframe that you can read from.
I am a javascript newbie. I am trying to write a requirements document, and need some help describing what I am looking for. We want our application to generate a javascript snippet like this:
<script src="http://www.jotform.com/jsform/10511502633"></script>
This will load a web form.
So my question is:
- How does a single script load an entire web form? Is this a JSON?
- What is this called? Is this a cross browser javascript?
- Can anyone point me in the direction of learning more about what this is?
Thank you for your help!
The javascript file is just hosted on an external site. It appears to be dynamically generated, so feel free to use some fancy words ;) But basically, you just include it here, as if it was on your own site.
You could say "The application will generate the required script-tags to include dynamically generated javascript file from an external, third-party site".
Offcourse you need to take special cautions for cases when the include won't work, because the other site is not reachable (site is down, DNS does not work, file is moved on other webserver, your application is on an intranet/behind a proxy/firewall...). Why can't you copy their file and mirror it locally? Or use a reliable Content Delivery Network, like Google or Amazon.
There are many names for this type of inclusion. The most common being widget.
What does it actually do:
take an id of some sort as parameter
use the id to fetch some specific data (most likely from a database)
generate some js and html based on the id/data
usually this involves iframes of some sort.
To use a script rather than an html iframe has multiple advantages
you can change what is actually delivered to the users browsers without changing the include
you can resize the iframe to fit certain predefined sizes
you can inject the necessary things into the page the widget is included (of course you need to make sure this is sanctioned)
We use this all the time and we never regreted it.
If you don't want to build the widget infrastructure yourself you can always use one of the widget providers like widgetbox:
http://www.widgetbox.com/widgets/make/
With those you are up and running in no time.
This is typically called a script include.
Google have lots of these types of items, and even they call them by many names,
widgets, custom javascript, snippets, custom code, etc. It really depending on who you are writing for... I would go with "cross platform embeddable javascript code" meaning that it would need to load all its dependancies. Also specify which browsers need to be supported and what should happen is the user has javascript turned off.
EDIT :
Actually since we are talking unique IDs, you will need 2 parts probably, the user/site unique "cross platform embeddable javascript code" and whatever serverside code to support it. Basically this is an API that is accessed using your own javascript widget. Feel free you point to examples in your requirements document, programmers love examples.
I left this question as generic as possible, but I do have a specific problem that I need to solve in my application and the answer to this would help.
The application I am working on uses PHP/MySQL as its backend, and is set up so that no text/words/phrases visible to the user are hardcoded in the HTML/JS that is output to the browser, rather they are stored in a database table associated with a language key that is used to fetch the correct translation of the word/phrase based on the user's language preference. Now this works great for text that exists inside the application's HTML, but in order for this system to work with the javascript files, all javascript must be placed in a .php file and wrapped in <script></script> tags and included inline with the HTML, CSS ect.
This creates some problems with the flexibility in the system's javascript, as it cannot be included as external scripts via <link> tags (I guess unless you set the .php file's headers manually), and perhaps more importantly it cannot be minified/packed etc. when served in the production environment.
My first thought of a solution to this problem is to have a php script that's placed before any other javascript which loops through every record in the language database table and creates an associative javascript array using the language key as the array keys and setting their value to the translated phrase according to the user's preference. So, in this way all javascript files could be made into actual .js files and link'ed, minified, packed, etc. as needed, and they would just reference the phrases they need from the master language array that was created (i.e. alert(LANGUAGE.some_text);)
Only problem is, the number of elements in this array could easily get into the thousands possibly even bigger. So back to my original question, what is an acceptable max size for a javascript array, based on the average PC? Or am I attacking this problem entirely wrong to begin with?
I think the problem has less to do with how much data javascript can theoretically handle and more to do with how your application is handling the data.
It sounds like you're returning all of the phrases for the user's language on every page, not just the phrases they need on that particular page. If that's the case, fixing it will be part of the solution to your problem.
The rest of the solution will be not using javascript for anything until the app is completely functional. Then go back and do progressive enhancement stuff with js.
Instead of generating javascript from those database queries, generate pages (server-side) in the user's natural language, and serve them from a separate subdomains/subdirectories. Have your web server load the appropriate config for the user's language based on subdomain/subdirectory.
It's not the answer you were looking for, but I hope it helps.
JavaScript is by its nature a scripting language. The interpreter is nestled inside the browser's kernel. Correct me if I'm wrong, but I don't believe there is a definitive upper limit. The only thing that constricts an unlimited upper bound are memory constraints.
You can house gigs of uncompressed data (more if you compress it).
You're more likely to get one of the top errors in the list here, before you'll see any "upper bound limit reached."
in order for this system to work with the javascript files, all javascript must be placed in a .php file and wrapped in tags and included inline with the HTML, CSS ect.
This creates some problems with the flexibility in the system's javascript, as it cannot be included as external scripts via tags
Actually, not necessarily true. You can serve javascript files (not html) using PHP. Of course doing this most likely mean that all your javascript file will have the extension .php but that is a small matter. If you don't care about being strictly correct you don't even have to set the Content-type to js since browsers will treat anything served by <script> tags as javascript anyway.
A lot of sites actually do this, though not necessarily in PHP. Google, Yahoo etc often serve javascript using a server side scripting language to enable them to do any or all of the following:
automatically concatenate javascript/css files into a single file
automatically minify the javascript/css files
automatically obfuscate the javascript files
automatically do dependency resolution to source needed javascript files
Some people use mod_rewrite to rename the .php (or .pl or .cgi) files to .js to hide the details of the implementation. But it's strictly not necessary.
Here's an example bookmarklet that I serve as a .php file.
I tried solving a similar problem as a non-web programmer before, and ended up hosting the language package as a separate XML which JS queries into. Bad idea, and I'll tell you why. Google can't see pages filled dynamically with JS. But if that's no issue to you, I would recommend that way, simply because I don't know any other. :)
The method Array.prototype.push , append arguments to the end of the array, and return the new length.
In some JavaScript engine such as v8, the length is bounded to 32bit unsigned integer, so this might be the limit you want to know.