when i download some new plugins eg. jquery plugins i put them in js folder. and the same for css and img.
so all my different applications share them. but where do i put my js/img and css for specific application/website? every website?
and where should i put my ajaxcall-files.php?
EDIT: some guides that could give me a clean and neat file structure?
I normally keep a file structure for javascripts as follows:
- js
- jQuery
- flot
- chilli
- processing
- closure
- typical_library
- js
- css
- img
By keeping separate folders for each library/plugin (including the relevant css and images if it need be), the pain of maintenance during upgrades is less. There is one more advantage, predictable folder structures can help with autodiscovery of JavaScript base directories.
For ajaxcall files (since I mostly use an MVC pattern), I keep them in the controller files. (I mostly use CodeIgniter). Some people would keep them in views, however if the ajaxcall.php involve any business logic is best to stick them in the controller files.
In general minimize anything outside of folders.
It's entirely up to you. But what I do is put common resource files that get used by lots of pages in central locations, e.g. /js is where the javascript libraries go. My arrows go in /arrows.
But if a given resource is specific to only one page, e.g. foo_pic.png is only ever used by foo.php, then I keep the files together and name them so they list together alphabetically.
So, as you see, I don't prefer structuring only according to file type. But that's just me.
Outside of the DocumentRoot, I put my php include files under one directory and they are all suffixed .inc.php. HTML templates are organized under another dir.
Related
Including many javascript files on the same page can lead to low performance.
What I want to ask is:
Is it best to keep separate files or include all files in one javascript file?
And if it is better to include everything in the same file Javascript, how can I avoid conflicts between different scripts?
It is best to keep separate files or include all files in one file Javascript?
To avoid multiple server requests, it is better to group all your JavaScript files into only one.
If you're using C#.Net + ASP.Net, you can bundle your files — it is a very good way to compress your scripts.
how can I avoid conflicts between different scripts?
You can use RequireJS; different names it is a good idea too; and every time that a plug-in/script ends, use ; to determine its end.
Performatic consideration
To maintain the productivity of your scripts, you should minify them.
Solution for a single page application
After you have minified your scripts, then group them all — regardless if they are plugins or your own code — into a single file and call it in your application.
Solution for a multiple page application
In this case, you should call just the necessary JavaScript for each page. How can you do this?
After you minified all of your scripts, then separate them in categories. Take a look to get the idea:
/assets/js/core.js — here you put your JavaScript code that is necessary to all of your pages. It is your core; your kernel;
/assets/js/plugins.js — here you put all the plugins that runs with all of your pages (i.e. jquery, backbone, knockout, and so on.);
/assets/js/home/bootstrap.js — here is the magic: in this file you have to fill with the code that your home will call;
/assets/js/contact/bootstrap.js — the same as before: this file you should to place with the code that your contact page will call.
HINT: core.js and plugins.js can occupy the same file when you deploy your application. To better comprehension and developing, it is good to maintain them into separated files.
Third party plugins
To give you an idea, the file of your plugins should be like this:
/* PlaceHolder plugin | http://www.placeholderjs.com/ | by #phowner */
; $(function(){ /* the placeholder's plugin goes here. */ });
/* Masked Inputs plugin | http://www.maskedjs.com/ | by #maskedowner */
; $(function(){ /* the masked input's plugin goes here. */ });
/* Mousewheel plugin | http://www.mousewheeljs.com/ | by #mousewheelowner */
; $(function(){ /* the mousewheel's plugin goes here. */ });
Serving one large single vs serving multiple small files depends on quite a few factors:
do all clients require the exact same code base?
i.e. we probably don't need shim for modern browsers, so why serve it?
do we change those files regularly?
caching files that don't change often can be used to reduce traffic
do we want to use CDNs?
serving jQuery from New York to New York rather than shoving it around half the planet probably ammortizes an additional HTTP request (performance-wise at least)
Conflicts can be reduced/eliminated by introducing your own scope for each script. A common way is to use IIFEs/SIAFs and inject required variables.
A quick and simple example of an IIFE:
(function () { // IIFE
var undefined = true;
})();
if (document.querySelectorAll === undefined) {
// polyfill
}
If the content in the IIFE would execute in global scope, it would probably crash your polyfill. Since it is executed in a local (function) scope, you are pretty much safe from conflicts.
Note: usually, your polyfill should not be implemented in global scope as well.
Conflicting code has nothing to do with combining JavaScript or put it in separate files but it requires descent programming.
To combine or not to combine depends on multiple things like:
file size
how many changes are you expecting.
How many relevant code has to be loaded at once that it is useful to
put it in one file or separate files
one file keeps the number of file requests low
..
It's generally better to bundle. If you are using Visual Studio you can use the Web Essentials bundling for JS, CSS, and even image sprites.
http://vswebessentials.com/features/bundling
I have a background in coding in languages that have a concept of "classes". Now that I am coding JavaScript, I would like to code in a similar way so that each object oriented "class" I create is its own separate file.
see Accessing "Public" methods from "Private" methods in javascript class
see http://phrogz.net/JS/classes/OOPinJS.html
In other languages, I would create import statements at the top of the class file to ensure other custom classes that were used within a class file so that the other custom classes were compiled into the final binary.
Of course JavaScript is not a compiled language; however, I would still like to be able to be include some kind of "import" statement at the top of custom class files so I could ensure the imported JS "class" file was available for the user's browser to download.
It would be ideal if there were a 3rd party tool that combined all of my separate class files into one JS file so the browser only had to make one HTTP request for a single JS file instead of many calls for each indicidual JS "class". Does anyone know if such a tool exists where it would do the following:
allowed me to choose which JS files that I wanted to include in a single JS file
crawled thru the files I selected in step 1 and found all the "import" statements at the top of each custom "class" file. These "import" statements could simply be specially formatted comments in the code that the 3rd party recognizes as import statements.
The 3rd party would then create the single JS file with all of the files that were selected from step 1 and from all of the imported files that were found in step 2.
Some popular JavaScript frameworks seem to do just that. For example, jQueryUI allows you to customize the download of a single jQueryUI source file by allowing the user to check off which objects you want to use. If you uncheck an element that is needed for an item that you checked off, then the form tells you that there is a dependency you need to rectify before being able to proceed to download the file.
see http://jqueryui.com/download/
So is there a 3rd party tool that allows a developer to use some kind of "import" statement comment to ensure that many dependent JS files (and only the ones that the developer needs) to be combined into a single JS file?
RequireJS was built for exactly this purpose.
Have a look at Require.js. It lets you import various javascript files in a modularized fashion and add the required dependencies between them. Also at the end you can minify them all into one single JS file using r.js
A trivial batch file can do this for you:
#for %i in (classes/*.js) type %i >> build.js
This works best if your JS source files are all in one folder, and this example assumes that folder is named classes. It gets a bit more complicated if you have subfolders, but a similar principle can be applied.
Have a look at GruntJS, JQuery uses it for building. If you don't care for HTTP requests, you can use already mentioned RequireJS, which also has nice async methods to load files, which can improve perfomance in some situations.
Check out this class https://www.youtube.com/watch?v=KnQfGXrRoPM
This allows for importing on the fly within classes. also it allows
for importing all classes within an folder and all of its sub folders.
and its really simple because it is just a prototype function added to String.
just by adding the importer class you will call in classes like "com.project.Classfile.js".import();
or "com.project.*".import() to get all sub-classes.
fork on - https://github.com/jleelove/Utils
I am trying to reorganize my Javascript into JS files and clear out my js from my html... The way I see if is the following.... I would really like some input or any documentation/information confirming my plans - a little uncertain.
Basically if I have a Home.htm file then I will have a home.js file also, notice they are named the same. The home.js will be like the bootstrapper for that page and will assign events (onclick etc)...
I was planning on doing this with all files i.e. login.htm > login.js ...
I was also thinking about have a global.js file which will be included in EVERY page that contains items that are needed in every file..
I also plan on having other js files which I plan on producing in a namespace so that my bootstrapper files can call classes in that namespace to do things like date manipulation etc.. I know JS is not a true OOP language but i have some helper js which allow to create namespaces and better class structures.
Does anyone have a better idea? Am completely going in the wrong or right direction?
I would really like some input, I am trying to separate all my js into separate files but I don't want to repeat myself so I thought of creating those bootstrapper files to take care of everything for the page..
Depending on how you go about it, I think the idea itself is quite reasonable. Namespacing your JS code in an OOP-like fashion is a good idea, and many libraries such as YUI and Dojo already do it.
Using VS2008 and ASP.NET 3.5 (or VS 2010 / .NET 4.0?), how can I include a bit of dynamic ASP.NET server-side code in mostly-static JavaScript and CSS files?
I want to do this to avoid cloning entire JS or CSS files to vary just a small part of them multi-tenant sites. Later, I want to extend the solution to handle localization inside javascript/CSS, dynamic debugging/tracing support, and other cool things you can get by injecting stuff dynamically into JavaScript and CSS.
The hard part is that I don't want to lose all the cool things you get with static files, for example:
JS/CSS code coloring and intellisense
CSS-class "go to definition" support in the IDE
automatic HTTP caching headers based on date of underlying file
automatic compression by IIS
The server-side goodness of static files (e.g. headers/compression) can be faked via an HttpHandler, but retaining IDE goodness (intellisense/coloring/etc) has me stumped.
An ideal solution would meet the following requirements:
VS IDE provides JS/CSS intellisense and code coloring. Giving up server-code intellisense is OK since server code is usually simple in these files.
"go to defintion" still works for CSS classes (just like in static CSS files)
send HTTP caching headers, varying by modified date of the underlying file.
support HTTP compression like other static files
support <%= %> and <script runat=server> code blocks
URL paths (at least the ones that HTTP clients see) end with .JS or .CSS (not .ASPX). Optionally, I can use querystring or PathInfo to parameterize (e.g. choosing a locale), although in most cases I'll use vdirs for this. Caching should vary for different querystrings.
So far the best (hacky) solution I've come up with is this:
Switch the underlying CSS or JS files to be .ASPX files (e.g. foo.css.aspx or foo.js.aspx). Embed the underlying static content in a STYLE element (for CSS) or a SCRIPT element (for JS). This enables JS/CSS intellisense as well as allowing inline or runat=server code blocks.
Write an HttpHandler which:
looks at the URL and adds .aspx to know the right underlying ASPX to call
uses System.Net.HttpWebRequest to call that URL
strips out the containing STYLE or SCRIPT tags, leaving only the CSS or JS
adds the appropriate headers (caching, content type, etc.)
compresses the response if the client suports compression
Map *.CSS and *.JS to my handler.
(if IIS6) Ensure .JS and .CSS file extensions are mapped to ASP.NET
I'm already using a modified version of Darick_c's HttpCompression Module which handles almost all of above for me, so modifying it to support the solution above won't be too hard.
But my solution is hacky. I was wondering if anyone has a more lightweight approach for this problem which doesn't lose Visual Studio's static-file goodness.
I know I can also hack up a client-side-only solution where I split all JS and CSS into "vary" and "won't vary" files, but there's a performance and maintenance overhead to this kind of solution that I'd like to avoid. I really want a server-side solution here so I can maintain one file on the server, not N+1 files.
I've not tried VS10/.NET 4.0 yet, but I'm open to a Dev10/.net4 solution if that's the best way to make this scenario work.
Thanks!
I have handled a similar problem by having a master page output a dynamic generated JSON object in the footer of each page.
I needed to have my js popup login dialog box support localization. So using JSON.NET for serialization, I created a public key/value collection property of the master page that pages could access in order place key/values into such as phrase key/localized phrase pairs. The master page then renders a dynamic JSON object that holds these values so that static js files could reference these dynamic values.
For the js login box I have the masterpage set the localized values. This made sense because the masterpage also includes the login.js file.
I do commend you on your concern over the number of http requests being made from the client and the payload being returned. Too many people I know and work with overlook those easy optimizations. However, any time I run into the same issue you're having (which is actually quite often), I have found I've usually either taken a wrong turn somewhere or am trying to solve the problem the wrong way.
As far as your JS question goes, I think Frank Schwieterman in the comments above is correct. I'd be looking at ways to expose the dynamic parts of your JS through setters. A really basic example would be if you have want to display a customized welcome message to users on login. In your JS file, you can have a setMessage(message) method exposed. That method would then be called by the page including the script. As a result, you'd have something like:
<body onLoad="setMessage('Welcome' + <%= user.FirstName %>);">
This can obviously be expanded by passing objects or methods into the static JS file to allow you the functionality you desire.
In response to the CSS question, I think you can gain a lot from the approach Shawn Steward from the comments makes a good point. You can define certain static parts of your CSS in the base file and then redefine the parts you want to change in other files. As a result, you can then dictate the look of your website by which files you're including. Also, since you don't want to take the hit for extra http requests (keep in mind, if you set those files to be cached for a week, month, etc. it's a one time request), you can do something like combining the CSS files into a single file at compilation or runtime.
Something like the following links may be helpful in pointing you in the right direction:
http://geekswithblogs.net/rashid/archive/2007/07/25/Combine-Multiple-JavaScript-and-CSS-Files-and-Remove-Overheads.aspx
http://www.asp.net/learn/3.5-SP1/video-296.aspx?wwwaspnetrdirset=1
http://dimebrain.com/2008/04/resourceful-asp.html
By utilizing the combining at run or compile time you can gain the best of both world by allowing you to logically separate CSS and JS files, yet also gaining the reduction of payload and requests that comes with compressing and combining files.
I'd like to split my views in Grails into 2 files a .gsp file and a .js file so that I get a cleaner Javascript separation from my views. So here's an example:
views/index.gsp
views/index.js
views/home/index.jsp
views/home/index.js
But when I simply add the index.js script reference like this:
<script src="index.js" type="text/javascript"></script>
all I get is a 404.
Does anyone knows how to deal with this?
A great benefit would be to have the ability to use view data inside the index.js file to produce the desired content.
Matthias.
Actually, it should be perfectly possible to serve a JS file (or any other file type) as a GSP from your grails-app/views/ directory. The only thing you have to do, is define a suitable URL mapping for those GSPs, e.g.:
"/javascript/home/index"(view:'/home/index.js')
With this URL mapping, you can put your JS code into grails-app/views/home/index.js.gsp (note the trailing .gsp) and you can use any grails tags in your JS source. To ensure that your JS is delivered with the correct content type, you may want to place
<%# page contentType="text/javascript"%>
at the beginning of your GSP.
Unfortunately, the createLink tag doesn't support link rewriting to views, but it should be easy to write your own tag to create those links.
Anyways, keep in mind that this won't have a very positive impact on your app's performance. It's usually better to have static JS files (and also serve them as static resources) while passing dynamic stuff as parameters to JS functions for example. This will also keep you from some headaches wrt. caching etc.
The idea is good, but Grails has this directory structure for a reason. The view folder is intended for a certain artifact type (views)..
You could clone your view folder structure under web-inf, but that gives you more work as I guess the idea behind this is to keep related files close together for convenience reasons.
Even though I'm not to excited about storing Javascript together with the view I loved Robert's idea of hooking into the build process by using build events to copy javascript sources into the right directory! If you decide to go down that road you might as well compress the sources while you're at it. ShrinkSafe is popular library.
I don't think you are allowed to access js inside views/
if you need to do that ... here is the trick
create your js and rename it with myjs.gsp (use "")
iniside _myjs.gsp type you js
... write down you js in here ...
inside you gsp (for example: index.gsp, view.gsp, etc)
type this tag to upload you js
Update 2:
Grails offer the possibility of hooking into the build lifecycle using custom events.
An event handler can be written which synchronises all JavaScript files under grails-app/views with the target folder of web-app/js.
Place the custom code in $PROJECT/scripts/Events.groovy. The PackagingEnd is a good target for the invocation, since it happens right after web.xml is generated.
eventPackagingEnd = { ->
// for each js file under grails-app/views move to web-app/js
}
Update
If you'd like the JavaScript files simply 'meshed' together, you can do that using symlinks, e.g.:
grails-app/views/view1/index.js -> webapp/js/view1/index.js
As far as I know, there is no way of forcing grails to directly serve content which is outside of web-app.
Alternatively, you can inline your JavaScript, but that can have performance implications.
JavaScript files belong under web-app/js.
Then you can reference them using <g:javascript src="index.js" />.