Re: Looking for contributors as part of Apache incubation

The contentType matter... thanks for looking after these! So then,
FreemarkerServlet surely should set the HttpServletResponse
contentType when it's still null. OTOH there should be an option to
only set it then (if it's not null), not always as it happens now. So
then the "ContetType" init-param remains as is, and we add a new
init-param, "OverrideResponseContentType" (better name?), whose
default is true for backward compatibility, but this default can be
changed to false by extending FreemarkerServlet. WDYT?

If the out-of-the-box default worth to be changed, then we can make
the default of "OverrideResponseContentType" be dependent on
cfg.incompatibleImprovements (IcI from now on). It's surely not a IcI
2.3.x thing though.

[snip]
>> Doesn't that just sets the locale in the RequestContext? That's a
>> Spring-specific object. Because then overriding deduceLocale(...) is
>> still the only option. If they were using FreemarkerSerlvet at all,
>> that is...
>
> Spring Framework primarily store request specific locale into its own
> RequestContext. However, it also falls back to
> ServletRequest#getLocale() if not set in its framework level
> (org.springframework.web.servlet.support.RequestContextUtils.getLocale(HttpServletRequest)).
> ServletRequest#getLocale() returns the preferred locale that the client
> will accept content in, based on the Accept-Language header, by default.
> However, many other frameworks can wrap servlet request to override this
> method. In our case, our HMVC framework (HST-2) supports URL prefix
> based locale setting feature and wraps request to support seamless JSTL
> tags integration for instance.
> In portal/portlet world, it's very common/crucial to see request
> wrappers for portlets where users are able to set locale preferences.
> Wicket also has wrappers to support this kind of things.
> In hierarchical aggregation frameworks (portal, HMVC, Wicket, etc), they
> have to wrap request/response objects anyway, and if they want to invoke
> controller and dispatch a view in a part of the page rendering, then
> they need to control #getLocale() somehow from the page request
> processing level, not from each part rendering level.
>
> So, if #deduceLocale() can somehow use either ServletRequest#getLocale()
> or global setting more intelligently (not sure how we can make it easier
> to config though), then it would be more ideal to me.

Then, I think, the default implementation of deduceLocale() should
take the a new init-param into account, let's call it
"LocaleFromRequest". The default of that should be false for backward
compatibility. But if someone sets that setting to true, and the
request locale isn't null, we use that instead of the Freemarker
Configuration setting. And here again, you could override what the
*default* is.

Just like with "OverrideResponseContentType", the default can depend
on the IcI on the long run.

-- 
Thanks,
 Daniel Dekany


------------------------------------------------------------------------------