- This topic has 7 replies, 4 voices, and was last updated 20 years, 4 months ago by
.
-
Posts
-
I include functions/common.jsp, functions/header.jsp, functions/footer.jsp.
But when I try to do this in MyEclipse I get a lot of errors of this type:
DbBean cannot be resolved (or is not a valid type) for the parameter db of the method displayKampInfoBox
DbBean is a class name.
use the extends .jsf for included files.
=> functions/common.jsf, functions/header.jsf, functions/footer.jsf.
NOP
Thanks NOP.
For my interest is DbBean class imported by one of the included JSPs or in the main JSP? Also are there error markers on the included JSPs, i.e., JSP fragments? NOP’s suggestion will take care of the later type of problem since the suggested file extension for JSP fragments of *.jsf or *.jspf in the JSP spec are understood by the ME JSP Editor as incomplete JSPs and thus are not compiled.
I would encourage you to use .jspf for JSP Fragments, as in the Sun naming standard for JSP pages, “jsf” is potentially reserved for Java Server Faces pages, and suggests using jspf as well.
Thanks a lot for all the answers. I changed my included files from *.jsp to *.jspf, with success! BUT: changes in jspf files did not trigger the “Build Automatically”prosess. So it took a while to figure out that I had to do a clean build every time I wanted to see errors and changes in the jspf files. Is this a bug?
Btw when I use the “find and replace” command, the find keyword is remembered from my last search but, the replace keyword is lost. It would have been nice to remember both 🙂
Eclipse 3.0 RC2 and MyEclipse
MyEclipse 3.8 Beta-1 for Windows 98/2000/XP (6/1/2004)” fragments of *.jsf or *.jspf in the JSP spec are understood by the ME JSP Editor as incomplete JSPs and thus are not compiled”
🙂 So you know the jspf not is compiled, but why not?The DbBean is included in common.jsp(f)
So you know the jspf not is compiled, but why not?
The issue is that fragements are typically not compilable because they are not self contained JSPs. What I mean by this, is that a JSP fragment is similar to a macro that only makes sense within the context of JSP documents which includes it. Also there is many-one possibility between JSP docs and an included fragment. So the question is what do you do when a fragment changes? Should every jsp document that includes the fragment be revalidated or should the fragment be ignored. We currently take the latter approach. To compensate for this “no action policy” we will be adding the ability to manually validate a single JSP from the context-menu. This will enable you to manually validate any JSP document that contains a fragment of your interest. Ultimately we will hook into a new dependency framework that Eclipse3 will provide.
Thanks for the answer. You have the best support forum I’ve ever seen 🙂
“Should every jsp document that includes the fragment be revalidated or should the fragment be ignored.”
I think every jsp document that includes the jspf files should be compiled when the jspf files changes. I can’t seem to find a reason for not compiling jspf files. But, it’s good that you are working with this!
