you can write testsuites in JS to check the integrity and you can catch errors to generate automatic reports in error cases.

If it's a DHTML application you will need to automate a browser using selenium or imacros.

You can also send isolated JS-snippets from perl to the browser with mozrepl or WWW::Mechanize::Firefox.

As I said, it depends!

I am not talking about how to check JS.

I am asking about an efficient workflow to deal with JS-snippets (doing ajax-stuff with jquery) that are embedded in a Perl-module.

So mentioning mozrepl or Mech::FF is if no value to me (I know about these) unless there is a concrete way to incorporate them into a workflow.

Of course I could try to hack something together to extract the JS from my module, send it to a browser via mozrepl and so on but I am more hoping for tools I could just use (rather then develop myself).

A long shot, I know...

I would look at not generating Javascript at all. Consider having all JS code static and just sending JSON data from the server. That way you can decouple JS and the server. Personally, I write the tests for the Javascript parts in perl as well, as I can conveniently supply static JSON data to the JS handler with WWW::Mechanize::Firefox.

So I wonder is there a better way to do this?

Yes, seperate templates into seperate files, run tidyall/Code::TidyAll::Plugin::JSLint... on them, then when publishing, if you need to, incorporate into a single file/fatpack... whatever

I maintain the two files separately ... and for the Javascript portion of the system I now prefer to write in the haXe programming language, using it to generate Javascript.   The essential difference is that haXe is a strongly-typed language that can produce compile-time errors... and it is cross-platform.   Definitely something to keep on your radar...

All web-page outputs are generated by templates, and those (usually, the wrappers) deliver the JavaScript by script-reference tags to external files.   I basically do not use in-line (script-tag) JS content.

I use an editor (Eclipse) which is capable of both Perl and JavaScript syntax-checking ... JSLint and more ... but it cannot handle a file that consists of more-than-one language.

Do not generate your JavaScript from Perl. That's no different from generating HTML from Perl, which is very 1990'ish.

Very often JavaScript stays static and shouldn't be changed on each request (think of your functions/classes, they don't change). You can put such code into separate .js files and benefit from caching of static files. If you still need to conditionally generate JavaScript parts in your HTML output (such as variables interpolation) Template::Toolkit comes to the rescue the same way it helps to generate HTML.

Another suggestion, to reduce the number of typed characters and add more readability is to use CoffeScript or any similar language, which translates to more verbose JavaScript.

Hi,

I am writing web applications since several years now and I am used to the problem. There is no efficient was to debug JavaScript code. In my opinion the tips here are all valid. But as usual the solution is a mix between all suggestion.

Differentiate the scripts needing input from the PERL program and the other. Pack the script scripts which do not rely on PERL variables in libraries in a separate directory and include them at the start of the form:

print CGI::start_html( ...
        -script=>[
           {-type=>'JAVASCRIPT', -src=>'../js/utils.js'},
        ]
    ), "\n";
[download]

or

If your script relies on PERL output you have to place it in the code. Example:

print qq~
    <script type="text/javascript">
        function Whatsoever() {
            myElement = window.document.getElementById....
      …
            return true;
        }
    </script>
~;
[download]

Notice: if you write a multi language application most of your JavaScript will have to be included in the PERL code.

To debug the scripts I use Firefox and Firebug. It has an integrated console that is very useful remains open! Selenium is definitely what you want to test your forms. Easy to learn and to use.

The JavaScript debugging process is clumsy anyway. The alert() statement is very useful at this point in time.... If you designed your forms properly, meaning you thought about what is happening as the user reloads a form it resumes to:

• Start the form
• Check the error in Firebug console
• Correct the error
• Reload the form.
• Eventually write a test script for Selenium to improve the process

If you did not thought about the reload issue... I recommend you start thinking.

K