This week's book giveaway is in the Agile and Other Processes forum. We're giving away four copies of Real-World Software Development: A Project-Driven Guide to Fundamentals in Java and have Dr. Raoul-Gabriel Urma & Richard Warburton on-line! See this thread for details.
OK, I'm trying to get my mind around what the spec refers to as the current JSP page and the current JSP file. I understand the difference between the page and the file parts of it (mostly from this thread and also from this one. The problem I'm having is in the examples in the JSP spec 1.2 page 78. I'll post them here so we are all on the same sheet of music:
For an example of a more complex set of inclusions, consider the following four situations built using four JSP files: A.jsp, C.jsp, dir/B.jsp and dir/C.jsp: � A.jsp says <%@ include file=�dir/B.jsp�%> and dir/B.jsp says <%@ include file=�C.jsp�%>. In this case the relative specification �C.jsp� resolves to �dir/ C.jsp� � A.jsp says <jsp:include page=�dir/B.jsp�/> and dir/B.jsp says <jsp:include page=�C.jsp� />. In this case the relative specification �C.jsp� resolves to �dir/C.jsp�. � A.jsp says <jsp:include page=�dir/B.jsp�/> and dir/B.jsp says <%@ include file=�C.jsp� %>. In this case the relative specification �C.jsp� resolves to �dir/C.jsp�. � A.jsp says <%@ include file=�dir/B.jsp�%> and dir/B.jsp says <jsp:include page=�C.jsp�/>. In this case the relative specification �C.jsp� resolves to �C.jsp�.
From the explanations that they give it seems to me that: In the 1st case A.jsp is using the include directive so it is relative to the current file which, at the time of that include, must be A.jsp. Then when B.jsp uses the include directive it must be the current file because the URL resolves to dir/C.jsp. In the 2nd case A.jsp is using the include action so it is relative to the current page, whcich must again be A.jps at the time the action is invoked. And again in B.jsp it must now be the current page because the relative url of maps to dir/C.jsp again. The 3rd case looks the same again A.jsp is the current page then B.jsp is the current file. The 4th case throws me, it looks like when A.jsp invokes the include directive it is the current file but when B.jsp uses the include action A.jsp must be the current page because the URL resolves to C.jsp not dir/C.jsp. I just want to make sure my train of thought is correct on this: When the include directive is performed, you are including a file so the included file becomes the current file while the current page remains the same. When the include action is used you are including a page so the both the current file and the current page change to the included resource. I can see that this is what's happening but just want to make sure my explanation is correct but I would like to know why? I guess the biggest question I've got is why doesn't the current page change when you do static include. Is it because the included resource becomes part of the resource that included it while in a dynamic include the included resource is still separate so both the current page and current file change? Any help is appreciated Thanks [ August 15, 2002: Message edited by: Dave Vick ]
Reading into it I can come up with a grid like this
jsp:include happens at runtime But @ include happens at compile time. I think I got that in the right direction and it isn't the other way around So in #4 your @ include includes the file at compile time, but the second jsp:include runs at runtime which is currently in the base directory. #1 works because c is added to B at compile time and therefore is in the correct directory. Hope that explains things better for you. But I know Madhav is much better at this stuff and explaining then I am. Mark
WOW!!! I just had one of those times when everything becomes clear and you really understand something - I love those moments, they are so cool. Is this an epiphany? Now, let me just make sure it is correct When we do a static include (@ include) there is no 'page' so everything is relative to the file. In the first case: A is including B at translation time then B includes C at translation time. Because they are both at translation time both includes are relative to whatever file is doing the including. In the second case: A is including B dynamically so it is relative to the page (in this case A), then B includes C (again dynamically) and so it is relative to the current page, which is now B, because it is happening at request time. Third case: A includes B at request time and then B includes C at translation time. Because B was included dynamically the inclusion of C is still done relative to B. Fourth case: A includes B at translation time. Then at request time B includes C, but becasue it is at request time and B is now already included in A is done relative to A not B. Thanks a lot Mark, it ws in reading your explanation that it came to me. I might have been making it harder than it needed to be and was overthinkng the whole thing. This is so cool!!!
Hi Dave, Another way of looking at it is this: think of <%@ include %> as a macro or a 'C' #include; it includes its target as if it had been typed directly into the page. (Formally, the two files on disk become part of the same 'translation unit'. At request time, they share a page scope since they are compiled into a single method in the back-end servlet that corresponds to your JSP page.) <jsp:include> simply passes control to a different page for a while. Under <jsp:include>, the two pages share 'request' scope but have a different 'page' scope.