Community
Participate
Working Groups
This is a follow-up to bugs 87351, 149279 and 125877. Bug 125877 discusses the option to disable validation for certain directories or file types, when sometimes validation is not possible or not desired. This feature enhancement request addresses a separate concern: sometimes validation just depends on the context. Instead of tweaking "disable validation" options to avoid validation errors for JSPF fragments, a better solution would of course be that JSPF fragments _could_ in fact be validated (both HTML and JSP). This would require Eclipse to find the context in which the fragment is used, since only the whole of this context is possible to validate. The context should preferably be assigned when the user moves from the including JSP file the to fragment. If we want to assign a context when opening any arbitrary fragment, the workspace would need to be searched for JSP files including the fragment, and use one of them as the context. Something along these lines was already considered as a future enhancement in the discussion about bug 87351 (a "fragment properties page"), but it would be better if the context could be assigned automatically. Apparently the same fragment-and-its-context -problem exists for other types of files also, such as the XDoclet XML fragments mentioned in bug 125877 comment #1. Do any other similar cases come to mind? Should this bug be in component wst.validation instead of jst.jsp? I realize that this is a much more complex thing to ask for than a simple "disable validation" -option, but it would be immensely more valuable. Not being an Eclipse developer, I can't estimate the effort involved. Do you think it's a viable feature to implement, and in which timeframe?
(In reply to comment #0) > Apparently the same fragment-and-its-context -problem exists for other types of > files also, such as the XDoclet XML fragments mentioned in bug 125877 comment > #1. Do any other similar cases come to mind? Should this bug be in component > wst.validation instead of jst.jsp? If there are indeed other fragments that might benefit from this, it might be good to open a bug on wst.validation as well. I would keep this bug open too though and in each bug, reference the other one just for tracking purposes. Most likely, this will require a huge effort on both components. > I realize that this is a much more complex thing to ask for than a simple > "disable validation" -option, but it would be immensely more valuable. Not > being an Eclipse developer, I can't estimate the effort involved. Do you think > it's a viable feature to implement, and in which timeframe? I think it's a great idea, though also probably complex. I would say wtp 2.0 at the earliest, but might be later. You are always welcome to become an Eclipse developer/contributor :) Contributions will get the feature in quicker.
Related bugs: bug 147098 bug 155664 bug 157465 bug 155664
One idea about fragments: I think it would make sense to add a file specific setting "HTML/JSP/XML Headers/Footers" where pre-/post-JSP/HTML/XML can be entered which completes a HTML/JSP-fragment so that it is well formed and valid. The validator would have to merge header, fragment and footer and validate this file. It is probably a lot more work for the Eclipse user to maintain this information, but this way all kinds of fragments can be validated without WTP having to find the place where the fragment is included (or not).
That's a nice idea, but I'd be wary of allowing users to enter header/footer via a simple textbox control on a properties page. Encoding might be an issue. I'm still thinking more along the lines of bug 87351 comment #2 > 2. add something to the (future) "fragment properties" page to name > a "parent" file to use. This way, users could specify a generic parent file if they want, or they could specify a more specific/complicated parent.
Yes, that's a great idea ! Forget about my suggestion, the "Parent file" approach is the same thought but in a much more usable way ;-)
Just in case it is useful, I thought I would mention that Bea Workshop Studio seems to handle this well. Unfortunately, I have no idea how they do it, but maybe it will give someone some ideas. I know it creates some sort of internal database which it uses to validate the files, but I don't know how it handles fragments with multiple parents, etc. The user doesn't have to do anything, it is all automatic. As a side note, it also seems able to validate jsps quite a bit faster than Web Tools (I just started using eclipse europa, and it takes -ages- to validate everything). The cost seems to be that it uses more memory. I don't have much memory on my system, and using Workshop often causes a lot of paging, but even so, it still ends up being faster than europa. I also think that disabling validation for certain directories should be implemented, but not as a solution to this problem. They solve two different issues.
For me the main problem is that a fragment may have more than one parent. In my opinion the answer how to determine the "right" parent is easy: Just every possible parent (which includes the fragment) has to be treated as a parent and there should be no compilation problems in any of the cases. So as far I can see the best solution is that the validation process branches for each possible parent. If compilation errors occur, the error marker should contain the information in which case (parent) the compilation fails. (I posted this idea also to bug 123749)
Requesting that this anhancement would be treated as a hotbug and fixed as an update to WTP 2.0, on behalf of Patric Rufflar. Patric suggested a very simple and elegant solution in comment #7, which should not be very difficult to implement. Motivation: This bug makes JSP validation totally useless for projects that use JSPs with included JSP fragments. I belive this is an issue for many projects, which is indicated also by the high vote count (6 votes).
Determining a fragment's parent would require looking in every jsp file to see if it includes the fragment. If you have a project with lots of jsps, this would be a major performance hit. Things get even more complicated if you have JSPs that include fragments that include more fragments. To alleviate the performance hit, we could maybe keep a table somewhere mapping the fragment to all the parents that include it. But then this table would need to be updated with every resource change though if any files get renamed or deleted. Any changes to the parent jsp will also trigger an update to the table in case the jsp no long includes the fragment or includes a new fragment. The performance hit makes me hesitant to fix this bug since we already have complaints about our jsp validator being too slow. And a big reason for it being slow is the opening of the jsp files. So opening more files and making the jsp validator slower is not going to make people happy. I understand it's a pain not being able to make a change in a fragment and have jsp validation be able to tell you immediately that a parent doesn't like that change, but if you validate your project, the validation error should show up because we do validate the other way (when we validate a jsp, we validate the included files in the jsp) I'm not saying this bug is never going to be fixed, because I'd love to fix this bug in some way, but it's going to take some more investigation. As I mentioned before, if you, Peik or Patric would like to contribute a fix for this bug, I'd be more than happy to take a look, and it would speed up the process of getting this bug fixed.
(In reply to comment #8) Peik, "hotbug_requests" are for cases where a bug significantly inhibits adoption by an add-in provider or product for one of their releases. From my reading of these remarks, that's not the case here. So I've removed the flag. Greatest apologies if I've misunderstood, and invite you to explain. For "mere" pain-in-the-butt end-users bugs, we go by votes and the verbal comments to help determine priority, and the lack of handling fragments I think qualifies as "missing function" to allow it to be considered a major bug ... though, as noted, it's literally just missing, always has been, and not really a bug in existing code. I think the "examine all possible parents" approach would definitely take a whole new, and large, dependency caching mechanism, similar to the way Java (JDT) caches dependent classes for incremental builds -- and is definitely a "people years" sort of effot. That'd be great if someone wanted to contribute THAT, but I doubt the core team will be able to implement in 3.0 timeframe. The idea of specifying one parent file would at least be a start in the right direction, and probably improve 80% of the cases? My suggestion, for anyone thinking of taking this on, would be to allow a way that users could to it, but also allow programmatic ways to do it, since in some cases, other wizards and the like can set the parent of fragments it may be creating in the course of creating a specific "site" or similar.
reassigning to inbox
Resetting severity to enhancement. If we can avoid the huge performance hit anticipated in comment 9, this would be a good feature (even if that means not implementing the idea from comment 7).
*** Bug 391852 has been marked as a duplicate of this bug. ***
*** Bug 391341 has been marked as a duplicate of this bug. ***
