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]>

Reply via email to