Daniel Rall said: > Nathan Bubna wrote: > > Geir Magnusson Jr. said: > >>On Monday, October 6, 2003, at 01:37 AM, Nathan Bubna wrote: ... > I'm fine with deprecating VS, and am willing to modify Eyebrowse to use VVS. > Would it be possible (and backwards compatible) for VS to sub-class VVS > during VS's deprecation period?
hmm. well, VVS doesn't support the old init props key. also, it exposes the request and response as $request and $response instead of $req and $res. there have been various other improvements/changes (servlet logger, WebappLoader, toolbox support, not using getRealPath(), etc.), but i can't think of anything else that would break b.c.. > Regarding, use of getWriter(), I'm a strong +1. Use of getOutputStream() only > makes sense when dealing with binary data, which doesn't seem to fit with the > Velocity/Tools use model -- requiring some custom code here strikes me as just > fine. agreed. > >>>2. drop any explicit dealings with encoding in the VVS. note that we > >>>can do this only if we do #1. this is because according to > >>>http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/ > >>>ServletResponse.html#getWriter() > >>>determination of the PrintWriter's encoding is determined by > >>>response.setContentType(str) (as long as it's called before > >>>getWriter(), and > >>>it is). this should make the VVS's setContentType(req,res) > >>>sufficient, and we > >>>won't need to mess with encoding stuff during mergeTemplate() anymore. > >>>so, for those wanting to set the charset (character encoding) > >>>per-application, > >>>they then need only set it as part of their content-type in their > >>>velocity.properties. (i suppose we could also still accept an encoding > >>>separately in velocity.props and concat it to the content-type during > >>>servlet init) > > Examation of HTTP shows that the protocol is built to support content > negotiation. APIs to facilitate content negotiation are extremely important for > any I18N'd web application. I've made implementation of dynamic response > encoding selection trivial, why drop support for it? > > >>Won't that be confusing? > > > > i don't think so. as it is, they can already specify charset as part of their > > default.contentType in their velocity.properties. > > Uh oh. The charset portion default.contentType overlaps the output.encoding > property. That is badness. It must be very clear to the user which property to > use, and if they continue to overlap, which takes precedence. Is this > documented anywhere? doubt it. > > after all, it's the way the > > servlet API is set up; there's no setCharset() method for ServletResponse. > > also, if we take my parenthesized suggestion, then that should provide them a > > way to specify content-type and charset separately. would that be > > non-confusing enough? > > This is what I've done in VS. yes, but you do it for every request. i would only do it on init. > >>>for those wanting per-request configuration of the charset, they can > >>>override > >>>the VVS's setContentType(req, res) method to implement this as they > >>>please. > >>>(though i'm open to suggestions on ways to make this easier for them, > >>>if you like.) > >>> > >>>thoughts? > > This I introduced VS's chooseCharacterEncoding() method to provide easier access > to the response encoding. What you suggest here is effectively equivalent, but > requires more work on the extending developer's part. Why not leave it easy? it wouldn't be that much more work. i also just noticed in the servlet docs that response.setLocale() will set the charset automatically when appropriate. that's another tool that may make the extending developer's job easier. that said, i'm not deeply opposed to having a chooseCharacterEncoding() method, i just think it's unnecessary and could be done more efficiently. if you're sure you want it, then i'll implement it in VVS, and try to avoid some of that "ugliness" that bothers me. :) Nathan Bubna [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
