I'm not a developer so I'm not sure how to properly phrase my question.
As a graphic designer I work a lot on sorting through and processing batches of images through Photoshop to meet specific specs. I wrote/hacked together a short script (Javascript) that runs through Photoshop to accomplish the sorting part of this task.
Rather than opening the javascript file every time, is there a way I can turn it into a little standalone programme or Photoshop plug-in? I want people to be able to see a simple interface of some kind where they can choose certain options (like which folder to run the script on), and then just click "GO".
I'm not sure where to start so even just some links to resources would be great.
I think you have two options: a simple one and a difficult one.
A simple one would be adding an interface to you script via ScriptUI: this way your script can show UI. You'll still need to run the script manually (you can assign it to a hotkey or use in an Action tough) and this is going to block PS UI
A difficult one would be transforming your script to an extension panel: an entity that consists of HTML+JS for UI and JSX for your host app (your script). This way you can have ui for your script always opened and use any your favourite js framework
Note that plugins in Photoshop terminology are compiled C++ entities: believe me you don't want to go that way
i was wondering if there is a possibility to distribute my Custom Script to all the sheets in my workspace. I came upon different ways with libraries or Add-ons, but they all lack some points i want to accomplish.
I want it to be private only for my Google Account
I need it to run the onOpen(e) Trigger for every File on my Sheets Account
(So i can add a custom menu to all my Files)
I also need to set a time Trigger for each File so my main() Function runs every night (right now i always create a new trigger when i rerun my main Function)
So far i can use the Library Option and create a new Script for all my Files and call my Main Function out of that Library. This Workaround does not include an onOpen Trigger event. When i use the Ability of run->test as addon and manually add all new Files (which come up every new month) i also lack the possibility of trigger functions.
If you have Solution Ideas I'd be very happy.
BR NJ
An Add-on can be published privately. Private Add-ons
A Library is private by default - The only way that someone outside of your account can use your script as a library, is to set the file sharing to allow them to use it. Gaining access to a library
A Library can not run a simple trigger, but an Add-on can. The reserved function name onOpen() can't be triggered by a library. See Table - Resource Scoping
An Add-on can run the onOpen() function
An Add-on can create an add-on menu.
An Add-on can create one time-based trigger for each document it is installed in. Quote: "Each add-on can only have one trigger of each type, per user, per document" Add-on Restrictions
If you want to do something like overwrite an Apps Script file, that can be done with the Apps Script API. Even script projects that are bound to a document (Sheets, Forms, Docs) can be overwritten with the Apps Script API.
StackOverflow answer - Update an Apps Script file using Apps Script
You can also update the manifest file of an Apps Script file using the Apps Script API, and therefore, programmatically add a library, and the library version to an existing Apps Script File.
I'm working on a large web application which has about 10K lines of JavaScript code (without taking into account the third-party libraries). In order to speed up page loading it has been decided to automatically concatenate every script file into a large script that gets loaded (and cached) on the client the first time the application is accessed. This poses a problem due to the fact that each page had its own script which contained all JavaScript required in (essentially) the same function.
Now if an error occurs in one of the scripts it is really hard to tell where that error came from, since everything is rolled into the same script which is added to each page, as opposed to using explicit script declarations in each page as was done before.
Is there a JavaScript pattern for solving this issue? I'm thinking of something similar to the AngularJS modules that can be bound to certain containers inside a web application's pages.
However, I would like a simple, custom, solution, as we're short on time and we don't have time to implement a framework in our application. It should apply certain scripts (modules) only to their respective pages and it should allow developers to explicitly declare any other scripts (modules) that certain scripts rely on.
Also, implementing an exception handling system to notify users (in the Firebug console, for example) from which module an exception originated (if the page's module relies on other modules) would be great.
Is there a common means of solving such issues in JavaScript (without relying on frameworks)?
A possible solution to your problem could be the use of js source maps. Many concat/minify/uglify tools directly support this feature, while most modern browsers are capable of interpreting them.
You would still serve a single JS file containing all your code (even if this is most likely not the best idea to handle such large amounts of code - largely depending on your overall architecture)
But your browsers developer tools are now able to show you the original file name and line number of an error/console output/etc.
You might most probably not serve the source map file in production.
A good point to get into js source maps is this wiki.
Is it possible for the javascript you write for a XUL component to interact with the javascript defined in a webpage?
Eg, if a particular webpage has a dooSomethingNeat() function, can I have a button defined in a XUL overlay execute that function, or does it live in another namespace?
Put another way: if I'm looking to enhance the functionality of a website via my own code, does it make more sense to write a Firefox extension or use something like greasemonkey?
See my answer to another question here.
The webpage code does live in a 'namespace' separate from the scopes the browser code executes in.
It doesn't mean you can't access it from an extension, though.
On the other hand, running a function in a content page is not very easy to do securely at this moment.
Greasemonkey scripts (and ubiquity scripts, which can also interact with web pages) are somewhat easier to develop than extensions, and Greasemonkey already implements the required security precautions to allow you interact with web pages safely.
If you want others to use your script, packaging it as a standalone extension lowers the barrier to entry (on the other case, existing GM users may prefer simpler GM scripts to a separate extension).
So if you can implement what you need to do with a GM script or an ubiquity script, I'd say go with it. At least you can start with it, then convert to an extension when you find something you can't do with GM.
If you need features not supported by Greasemonkey or if you just want to try creating an extension, it is also a viable option.
There is a Greasemonkey-to-firefox-extension "compiler" available, but it isn't up-to-date with the latest GM changes.
However, it does have the basic GM framework for page interaction and security all wrapped up as a standalone extension, ready for you to modify and extend.
Wether to use standalone extension or GM-script depends upon who will be installing this. Will the user-base be willing to install GreaseMonkey, THEN the script? Or is the extension alone enough of an installation barrier?
The GM license does allow for repackaging it with pre-set scripts, I believe, but I can't find back citations for this, at the moment.
Do you localize your javascript to the page, or have a master "application.js" or similar?
If it's the latter, what is the best practice to make sure your .js isn't executing on the wrong pages?
EDIT: by javascript I mean custom javascript you write as a developer, not js libraries. I can't imagine anyone would copy/paste the jQuery source into their page but you never know.
Putting all your js in one file can help performance (only one request versus several). And if you're using a content distribution network like Akamai it improves your cache hit ratio. Also, always throw inline js at the very bottom of the page (just above the body tag) because that is executed synchronously and can delay your page from rendering.
And yes, if one of the js files you are using is also hosted at google, make sure to use that one.
Here's my "guidelines". Note that none of these are formal, they just seem like the right thing to do.
All shared JS code lives in the SITE/javascripts directory, but it's loaded in 'tiers'
For site-wide stuff (like jquery, or my site wide application.js), the site wide layout (this would be a master page in ASP.net) includes the file. The script tags go at the top of the page.
There's also 'region-wide' stuff (eg: js code which is only needed in the admin section of the site). These regions either have a common layout (which can then include the script tags) or will render a common partial, and that partial can include the script tags)
For less-shared stuff (say my library that's only needed in a few places) then I put a script tag in those HTML pages individually. The script tags go at the top of the page.
For stuff that's only relevant to the single page, I just write inline javascript. I try to keep it as close to it's "target" as possible. For example, if I have some onclick js for a button, the script tag will go below the button.
For inline JS that doesn't have a target (eg: onload events) it goes at the bottom of the page.
So, how does something get into a localised library, or a site-wide library?.
The first time you need it, write it inline
The next time you need it, pull the inline code up to a localised library
If you're referencing some code in a localized library from (approximately) 3 or more places, pull the code up to a region-wide library
If it's needed from more than one region, pull it up to a site-wide library.
A common complaint about a system such as this, is that you wind up with 10 or 20 small JS files, where 2 or 3 large JS files will perform better from a networking point of view.
However, both rails and ASP.NET have features which handle combining and caching multiple JS files into one or more 'super' js files for production situations.
I'd recommend using features like this rather than compromising the quality/readability of the actual source code.
Yahoo!'s Exceptional Performance Team has some great performance suggestions for JavaScript. Steve Souders used to be on that team (he's now at Google) and he's written some interesting tools that can help you decide where to put JavaScript.
I try to avoid putting javascript functions on the rendered page. In general, I have an application.js (or root.js) that has generic functionality like menu manipulation. If a given page has specific javascript functionality, I'll create a .js file to handle that code and mimic the dir structure on how to get to that file (also using the same name as the rendered file).
In other words, if the rendered page is in public/dir1/dir2/mypage.html, the js file would be in public/js/dir1/dir2/mypage.js. I've found this style works well for me, especially when doing templating on a site. I build the template engine to "autoload" my resources (css and js) by taking the request path and doing some checking for the css and js equivalents in the css and js directories on the root.
Personally, I try to include several Javascript files, sorted by module (like YUI does). But once in a while, when I'm writing essentially a one-liner, I'll put it on the page.
Best practice is probably to put it on Google's servers.
(Depends what you mean by "your" javascript though I suppose :)
This is something I've been wrestling with, too. I've ended up by using my back-end PHP script to intelligently build a list of required JS files based on the content requested by the user.
By organizing my JS files into a repository that contains multiple files organized by purpose (be they general use, focused for a single page, single section, etc) I can use the chain of events that builds the page on the back-end to selectively choose which JS files get included based on need (see example below).
This is after implementing my web app without giving this aspect of the code enough thought. Now, I should also add that the javascript I use enhances but does not form the foundation of my site. If you're using something like SproutCore or Ext I imagine the solution would be somewhat different.
Here's an example for a PHP-driven website:
If your site is divided into sections and one of those sections is calendar. The user navigates to "index.phhp?module=calendar&action=view". If the PHP code is class-based the routing algorithm instantiates the CalendarModule class which is based on 'Module' and has a virtual method 'getJavascript'. This will return those javascript classes that are required to perform the action 'view' on the 'calendar' module. It can also take into account any other special requirements and return js files for those as well. The rendering code can verify that there are no duplicates of js files when the javascript include list is built for the final page. So the getJavascript method returns an array like this
return array('prototype.js','mycalendar.js');
Note that this, or some form of this, is not a new idea. But it took me some time to think it important enough to go to the trouble.
If it's only a few hundred bytes or less, and doesn't need to be used anywhere else, I would probably inline it. The network overhead for another http request will likely outweigh any performance gains that you get by pulling it out of the page.
If it needs to be used in a few places, I would put the function(s) into a common external file, and call it from an inline script as needed.
If you are targeting an iphone, try to keep anything that you want cached under 25k.
No hard and fast rules really, every approach has pros and cons, would strongly recommend you check out the articles that can be found on yahoo's developer section, so you can make informed decisions on a case by case basis.