HTML/JSP editting

Since 5.0, the html/jsp inspecting/auto complete seems to slow down the editor to the point of not being useful. Is there any way to turn these off for all such files?

Manually turning off inspections does not seem to improve responsiveness. Thanks

8 comments

Generally, this happens when your JSPs are extremely heavy: there may be too many dependencies to resolve when IDEA reparses the file. (It might be an indication that your pages are not very well designed, sorry...Just something to consider.) One way to get around it is to change the time IDEA has to wait before it reparses the file on each edit operation. I think, by default, the auto-reparse delay is 300 msec, which means that the reparsing is done practically on every key stroke. If you change this delay to several seconds - in Settings/IDE/Editor/Error Highlighting - the IDEA will let you type freely and parse the text only after you stop typing for a few seconds.

0

wouldn't it make sense that IDEA considers the file size/complexity automatically somehow regarding the reparse delay settings? in my current project I do have 2-3 very complex and long JSP pages (heavy mix of JS, EL, lots of custom tags) but I don't want to bring up the reparse delay in general, cause it's fast enough in all other files..

0

I would be reluctant to leave it up to the IDE to decide when and how to change certain editor attributes. However it may be a good idea to have an option to set/disable the re-parsing parameter for each file individually - in addition to having the global value. That shouldn't be difficult to do. For examle, assuming that there is a class that represents a file in the editor, a new member attribute could be added, and its value defaulted to null (meaning that the global value will be used.) Once the user overrides this attribute, the new value is used. A negative value may be used to disable parsing for the given file completely. Then, of course, when the file is closed, this data should be persisted and looked up each time this file is opened again... Or something like that...

0

That would be very usefull (option to disable reparsing on individual files). Complex and large classes/pages are not always bad desing, there are always special cases.

But could reparsing happen in separate thread with lower priority then editor events? That would make IDEA much more responsive, especially as you are adding more and more inspections/intentions in every single release?

0

Complex and large
classes/pages are not always bad desing, there are
always special cases.

I beg to differ. There is practically never a valid reason to have a huge class or JSP with hundreds/thousands lines of code. You can always refactor some functionality into smaller separate modules. If one is trying too many things at the same time in a single JSP (like managing the layout, managing the presentation logic, and, God forbid, massaging some data with scriptlets, etc.) then there's a problem. For example, you may isolate your layout in a Tiles template. You could prepare all your data for rendering in your action classes and package the ready-to-render data in a single form bean. You could limit your JSP logic to basic presentation only (simple conditions and iteration) and import reusable/separatable components using import/inclusion tags. Even with the parser having to resolve the tags, it will still have to do much less work because it won't have to drill into the pages that implement the layout and imported components.

The only justification for overly complex classes/pages/etc. that may be acceptable is when yo uinherit that monster from some other developers... Unfortunately there's little you can do then.

0

+1

I spent 4 1/2 months rewriting a crappy written app. Now it is so much
easier to maintain, extend.

IJ shouldn't be specially written to support crap, that is a developer's
job to evolve the code base.

Constantine Vasilyev wrote:
>> Complex and large
>> classes/pages are not always bad desing, there are
>> always special cases.
>>
>>

I beg to differ. There is practically never a valid reason to have a huge class or JSP with hundreds/thousands lines of code. You can always refactor some functionality into smaller separate modules. If one is trying too many things at the same time in a single JSP (like managing the layout, managing the presentation logic, and, God forbid, massaging some data with scriptlets, etc.) then there's a problem. For example, you may isolate your layout in a Tiles template. You could prepare all your data for rendering in your action classes and package the ready-to-render data in a single form bean. You could limit your JSP logic to basic presentation only (simple conditions and iteration) and import reusable/separatable components using import/inclusion tags. Even with the parser having to resolve the tags, it will still have to do much less work because it won't have to drill into the pages that implement the layout and imported components.

>

The only justification for overly complex classes/pages/etc. that may be acceptable is when yo uinherit that monster from some other developers... Unfortunately there's little you can do then.

>
>

0

I agree about all that is said regarding big classes or large pages. BUT, never say never, there are always special cases when rules had to be broken. For example, imagine a big class represending a facade to the complex system. You can divide your complex facade into sub-system facades, but what if one subsystem must inherently have a lot of similar methods making a facade class big?

Also, imagine a complex page for manipulating data about complex financial insturmets (several tens of attributes, dozen of collections which themselfs have sub details and sub colletctions). And you have several different types of instruments to be managed in the same way. And managing only parts of instruments is out of question due to business and performance requirements. And the model for instruments is changing and evolving rapidly as the project is moving on. You opt for metadata based approach and get a complex monster page with a lot of smaller but also complex pages (for dealing with details, collections, etc...).

Although we should always try to find the simple(st) solution, complex problems cannot deliver simple solutions, sometimes complexity is inherent in the domain.

So, having an option to disable parsing of big/complex files is an important feature to me.



0

Remove the business logic from the page. Then you end up with several
tags that understand how to display their specific data.

Mileta Cekovic wrote:

I agree about all that is said regarding big classes or large pages. BUT, never say never, there are always special cases when rules had to be broken. For example, imagine a big class represending a facade to the complex system. You can divide your complex facade into sub-system facades, but what if one subsystem must inherently have a lot of similar methods making a facade class big?

>

Also, imagine a complex page for manipulating data about complex financial insturmets (several tens of attributes, dozen of collections which themselfs have sub details and sub colletctions). And you have several different types of instruments to be managed in the same way. And managing only parts of instruments is out of question due to business and performance requirements. And the model for instruments is changing and evolving rapidly as the project is moving on. You opt for metadata based approach and get a complex monster page with a lot of smaller but also complex pages (for dealing with details, collections, etc...).

>

Although we should always try to find the simple(st) solution, complex problems cannot deliver simple solutions, sometimes complexity is inherent in the domain.

>

So, having an option to disable parsing of big/complex files is an important feature to me.

>
>
>
>

0

Please sign in to leave a comment.