At 02:51 PM 12/8/01 -0800, you wrote: >I don't think the spec is that detailed -- I mean, it doesn't come out and >say the "page" attribute of jsp:include has to follow the requirements of >the JspWriter. So, I don't know the answer to that. > >Remember though, we're talking about included files -- by their very nature, >they don't necessarily represent *entire* files. They may only be pieces of >a bigger file that is ultimately displayed to the surfer. I can understand >that the file sent to the browser must have a sensible MIME type, but must >all the pieces that the file is built from also have registered MIME types? >I'm not sure that makes sense. > >Also, I always thought MIME types, in this context, were available so the >browser could decipher what kind of file was being retrieved and display >that file correctly. I never thought MIME types would be used to limit my >flexibility with JSPs in this way. > >Thanks, >--jeff
I understand what you are saying, Jeff. But the bottom line is that the JspWriter is the source of the out implicit object in this instance. Apparently your bottom line is that you want to use the extension to pass information, instead of an extension in any true sense. I think it is a little harsh to have them "expect" that use. That said, and I may be wrong, why not toss the '"dynamic" values in prior to the extension and trick the JspWriter, e.g. instead of com.site.123 us com.site.123.txt or com.site.123.jsp. You are going to have to have a class read the url in any event. The other way is to put your dynamic information inside the included tidbit. That seems more intuitive to me than using an extension for information anyway. Just a thought. -- micael -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>