Re: Looking for contributors as part of Apache incubation

On 6/3/15 5:18 PM, Daniel Dekany wrote:
> 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?

That sounds like a plan!

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

I think we're fine with overriding the default value in our custom
FreemarkerServlet.

> 
> [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.

I like it!
Thank you so much for your considerations!

Cheers,

Woonsan

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


-- 
[email protected]     www.onehippo.com
Boston - 745 Atlantic Ave, 8th Floor, Boston MA 02111
Amsterdam - Oosteinde 11, 1017 WT Amsterdam
US +1 877 414 4776 (toll free)
Europe +31(0)20 522 4466

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