Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.help > #2487 > unrolled thread

LINTing Javascript in a Java WebApp

Back to article view | Back to comp.lang.java.help

Contents

  LINTing Javascript in a Java WebApp Steve <tinker123@gmail.com> - 2013-02-11 12:26 -0500
    Re: LINTing Javascript in a Java WebApp Roedy Green <see_website@mindprod.com.invalid> - 2013-02-11 11:42 -0800
      Re: LINTing Javascript in a Java WebApp Steve <tinker123@gmail.com> - 2013-02-12 08:40 -0500
    Re: LINTing Javascript in a Java WebApp Lew <lewbloch@gmail.com> - 2013-02-11 12:45 -0800
      Re: LINTing Javascript in a Java WebApp Steve <tinker123@gmail.com> - 2013-02-12 08:40 -0500
        Re: LINTing Javascript in a Java WebApp Lew <lewbloch@gmail.com> - 2013-02-12 09:45 -0800
          Re: LINTing Javascript in a Java WebApp Steve <tinker123@gmail.com> - 2013-02-13 14:26 -0500
            Re: LINTing Javascript in a Java WebApp Lew <lewbloch@gmail.com> - 2013-02-13 14:56 -0800
      Re: LINTing Javascript in a Java WebApp Roedy Green <see_website@mindprod.com.invalid> - 2013-02-13 18:43 -0800

#2487 — LINTing Javascript in a Java WebApp

Hi,

I have a number a Java webapp with a number of embedded ( in JSPs ) 
Javascripts and straight *.js files.

More than few times I've built the webapp and deployed it only to find 
I've made a trivial error, like forgetting a semicolon in the Javascript.

I've seen that there are some Javascript LINT tools out there.

Is there any particular tool or combination of tools that will highlight 
Javascript errors as I go ( similar to what spellchecks do these days by 
putting squiggly red line underneath ) or give me error messages at 
compile time ( for my Java webapp )?

Thanks either way

Steve

[toc] | [next] | [standalone]

#2488

On Mon, 11 Feb 2013 12:26:55 -0500, Steve <tinker123@gmail.com> wrote,
quoted or indirectly quoted someone who said :

>Hi,
>
>I have a number a Java webapp with a number of embedded ( in JSPs ) 
>Javascripts and straight *.js files.
>
>More than few times I've built the webapp and deployed it only to find 
>I've made a trivial error, like forgetting a semicolon in the Javascript.
>
>I've seen that there are some Javascript LINT tools out there.
>
>Is there any particular tool or combination of tools that will highlight 
>Javascript errors as I go ( similar to what spellchecks do these days by 
>putting squiggly red line underneath ) or give me error messages at 
>compile time ( for my Java webapp )?

I have not used it, but I have seen the JavaScript lint tools in
IntelliJ.
See http://mindprod.com/jgloss/intellij.html

There are also so primitive ones in
http://mindprod.com/jgloss/htmlvalidator that work on html with
embedded JavaScript.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
The first 90% of the code accounts for the first 90% of the development time.
The remaining 10% of the code accounts for the other 90% of the development 
time. 
~ Tom Cargill  Ninety-ninety Law 

[toc] | [prev] | [next] | [standalone]

#2493

On 2/11/2013 2:42 PM, Roedy Green wrote:
> I have not used it, but I have seen the JavaScript lint tools in
> IntelliJ.
> See http://mindprod.com/jgloss/intellij.html
>
> There are also so primitive ones in
> http://mindprod.com/jgloss/htmlvalidator that work on html with
> embedded JavaScript.

Thank you!

[toc] | [prev] | [next] | [standalone]

#2489

Steve wrote:
> I have a number a Java webapp with a number of embedded ( in JSPs ) 
> Javascripts and straight *.js files.

Hmm. Not a good clean separation there.

> More than few times I've built the webapp and deployed it only to find 
> I've made a trivial error, like forgetting a semicolon in the Javascript.

Why do you need so much Javascript?

> I've seen that there are some Javascript LINT tools out there.
> 
> Is there any particular tool or combination of tools that will highlight 
> Javascript errors as I go ( similar to what spellchecks do these days by 
> putting squiggly red line underneath ) or give me error messages at 
> compile time ( for my Java webapp )?

The Aptana plugin for Eclipse
www.aptana.org
provides more advance Javascript editing.

It seems wrong to put a lot of JS into a JSP. Or any, really.

I've seen it done in some projects and that consistently caused unholy messes.

But you might try using static pages with the same Javascript and debug the JS that way.
Freeze one possible output that the JSP might generate and try to use its Javascript.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#2492

On 2/11/2013 3:45 PM, Lew wrote:
> Steve wrote:
>> I have a number a Java webapp with a number of embedded ( in JSPs )
>> Javascripts and straight *.js files.
>
> Hmm. Not a good clean separation there.
>
>> More than few times I've built the webapp and deployed it only to find
>> I've made a trivial error, like forgetting a semicolon in the Javascript.
>
> Why do you need so much Javascript?

Some of it client side data validation that was done a long time ago 
before frameworks made server side data validation less of a PITA. 
Some of it is to enforce rules the users asked for ( example, if check 
box A is selected client side, disable textfield B, etc, etc ).  Some of 
it is AJAX used to decrease the number of screens the user has to 
submit.  Some of is gluing in various JQuery features, like a pop-up 
calendar for picking dates ( not something I asked for, the users love it ).



> The Aptana plugin for Eclipse
> www.aptana.org
> provides more advance Javascript editing.

Awesome, thank you.

>
> It seems wrong to put a lot of JS into a JSP. Or any, really.

I've been hearing that since the year 2,000.  I would still love for it 
to be true :)


> But you might try using static pages with the same Javascript and debug the JS that way.
> Freeze one possible output that the JSP might generate and try to use its Javascript.

That is pretty much what I have been doing.  I was hoping for the 
convenience of type as you go error highlighting like I can get with Java.

Steve

[toc] | [prev] | [next] | [standalone]

#2494

Steve wrote:
> Lew wrote:
>> Steve wrote:
>>> I have a number a Java webapp with a number of embedded ( in JSPs )
>>> Javascripts and straight *.js files.
>
>> Hmm. Not a good clean separation there.
>
>>> More than few times I've built the webapp and deployed it only to find
>>> I've made a trivial error, like forgetting a semicolon in the Javascript.
>>
>> Why do you need so much Javascript?
>
> Some of it client side data validation that was done a long time ago 
> before frameworks made server side data validation less of a PITA. 
> Some of it is to enforce rules the users asked for ( example, if check 
> box A is selected client side, disable textfield B, etc, etc ).  Some of 
> it is AJAX used to decrease the number of screens the user has to 
> submit.  Some of is gluing in various JQuery features, like a pop-up 
> calendar for picking dates ( not something I asked for, the users love it ).

I've worked on projects like this. Never mind the JSP, all these Javascript 
frameworks tend to interfere with each other and cause more bugs than they 
help with.

Are you familiar with "technical debt"? It sounds like you're paying a lot just 
in interest.

I recommend that you gradually (since management won't buy in or give you time)
refactor the JS to make sense. Dump old, unsupported versions of any frameworks
you're using, and clean up the separation just between the JS parts.

Consider using Facelets/XHTML with new stuff. Make sure your changes remain 
compatible with existing code and you won't need to make sweeping, all-at-once
revolutionary upheavals.

But if you do nothing, this system will creak until it cracks. 

... [snip] ...

>> It seems wrong to put a lot of JS into a JSP. Or any, really.
> 
> I've been hearing that since the year 2,000.  I would still love for it 
> to be true :)

Congratulations. It is true. Sort of.

Hand-coded Javascript is what I was talking about. Even auto-generated 
Javascript can be dangerous, but not all APIs are equally guilty.

>> But you might try using static pages
>> with the same Javascript and debug the JS that way.
>> Freeze one possible output that the JSP
>> might generate and try to use its Javascript.
> 
> That is pretty much what I have been doing.  I was hoping for the 
> convenience of type as you go error highlighting like I can get with Java.

Hope away.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#2498

On 2/12/2013 12:45 PM, Lew wrote:
> Are you familiar with "technical debt"? It sounds like you're paying a lot just
> in interest.

I haven't heard the term before.  Does it mean a lot PITAs from legacy 
code?  The javascripts aren't bad.  My problem with them are my own 
typos when I get change requests.   I don't have a way to find out about 
them before I test the WAR that takes less time than doing just that.


> I recommend that you gradually (since management won't buy in or give you time)
> refactor the JS to make sense. Dump old, unsupported versions of any frameworks
> you're using, and clean up the separation just between the JS parts.
>
> Consider using Facelets/XHTML with new stuff. Make sure your changes remain
> compatible with existing code and you won't need to make sweeping, all-at-once
> revolutionary upheavals.

I have read those terms, haven't used them yet.  It didn't occur to me 
that those things could be used to reduce/eliminate javascript.   Can 
you check for simple syntax errors with these technologies before you 
run your app?  That is my problem with javascript so far.

Steve

[toc] | [prev] | [next] | [standalone]

#2499

Steve wrote:
> Lew wrote:
>> Are you familiar with "technical debt"? It sounds like you're paying a lot just
>> in interest.
> 
> 
> 
> I haven't heard the term before.  Does it mean a lot PITAs from legacy 

That's about the best definition I've ever heard.

> code?  The javascripts aren't bad.  My problem with them are my own 
> typos when I get change requests.   I don't have a way to find out about 
> them before I test the WAR that takes less time than doing just that.

If they can run standalone maybe you can run them on node.js. I'm reaching.

>> I recommend that you gradually (since management won't buy in or give you time)
>> refactor the JS to make sense. Dump old, unsupported versions of any frameworks
>> you're using, and clean up the separation just between the JS parts.
> 
>> Consider using Facelets/XHTML with new stuff. Make sure your changes remain
>> compatible with existing code and you won't need to make sweeping, all-at-once
>> revolutionary upheavals.
> 
> 
> I have read those terms, haven't used them yet.  It didn't occur to me 
> that those things could be used to reduce/eliminate javascript.   Can 

Not to reduce it, but to reduce your direct involvement with it. These things have JS 
already built in and you treat it like a black box.

> you check for simple syntax errors with these technologies before you 
> run your app?  That is my problem with javascript so far.

No.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#2500

On Mon, 11 Feb 2013 12:45:21 -0800 (PST), Lew <lewbloch@gmail.com>
wrote, quoted or indirectly quoted someone who said :

>I've seen it done in some projects and that consistently caused unholy messes.

The big problem is the code often works on only one browser.  It is
quite a trick to write code that works on even half a dozen browsers.

Dealing with those differences is largely what Ajax is for.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
The first 90% of the code accounts for the first 90% of the development time.
The remaining 10% of the code accounts for the other 90% of the development 
time. 
~ Tom Cargill  Ninety-ninety Law 

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.help

csiph-web