Re: Looking for contributors as part of Apache incubation
Woonsan Ko <[email protected]> Tue, 02 Jun 2015 23:13:00 -0400
| Newsgroups | gmane.comp.web.freemarker.devel |
|---|---|
| Message-ID | <[email protected]> |
On 6/2/15 6:38 PM, Daniel Dekany wrote: > Tuesday, June 2, 2015, 3:31:39 PM, Woonsan Ko wrote: > >> Thank you very much, Daniel! >> >> I have been very happy with Freemarker personally and so it's very hard >> to find somethings I can hate, but I've just tried to list some wishes >> and improvement ideas from our experiences below: :-) >> >> >> FreemarkerServlet related improvements >> -------------------------------------- >> >> - TLD initializations can be done in #init() phase to avoid initial >> hiccups. We Hippo had to override the default servlet: >> https://issues.onehippo.com/browse/HSTTWO-3299 > > I don't see right now why's there a race condition; both TaglibFactory > initialization and TLD loading is synchronized (unless there's a bug > somewhere). Nor do I see how the hiccup can be worked around, because > creating the TaglibFactory is nothing, and loading the TLD-s (which is > the expensive step) will happen on demand regardless of when you are > initializing the TaglibFactory. Unless you are willing to specify a > manually assembled list of TLD-s in init-params, it can't happen > earlier, as we can't know ahead what TLD-s will be requested from the > templates. Hmm. Maybe I need to try to reproduce the problem with FreemarkerServlet instead of our custom servlet. I'll figure out what the root cause is and let you know again. Apologies if it's caused by a custom module here. > >> - #setContentType() invocation can check if it was already set before >> template execution. >> Currently, it invoked on #setContentType() every time regardless of >> the situation that (H)MVC framework sets it before executing the >> template. I'd like to have an option to not set if already existing at >> least. (ref: https://issues.onehippo.com/browse/HSTTWO-3012) > > Wouldn't that (the Content-type being set or not) be confusing and > fragile to build on? Is there a guarantee at all that the Servlet > container itself doesn't fill it with some default? > > Since FreemarkerServlet meant to be the only one who fiddles with the > response content (it's the View after all), it's naturally also > responsible for ensuring that the content type is consistently set. I think it's a good practice to ensure setting Content-Type in the view servlet. My point was if someone sets Content-Type in the controller before dispatching to the view then the view servlet might skip setting it again to a default value (unless developer sets in template again). Comparing with JSP, the current behavior seems okay, but I was thinking in line of flexibility in our HMVC framework. > So, maybe it would be better if we don't take away that duty from > FreemarkerServlet, instead it should be smarted about it: > > - You could just tell FreemarkerServlet explicitly to set a given > content type with a ServletRequest attribute. It's analogous to > specifying data-model variables to tell Freemarker what to show, > which you also do in the ServlerRequest via attributes. > > - Support a new init-param value: ContentType=dontSet > > - Adding a protected method where you can override how content type > detection happens, and if it happens (returning null means "don't > set"). I would like an init-param better than custom request attribute or protected method. Thanks for the suggestion! > >> - Configuration settings could be set through init parameters. >> Some servlet-related parameters are set through init parameters, but >> it could be even better if there's any specific init-param(s) to set >> Configuration settings without code changes. > > I'm not sure what you mean here. Pretty much all the Freemarker > settings can be set through the init-params, because the init-params > that are not recognized are feed to Configuration.setSetting(String, > String). Ah you're right. I was totally confused. I've just realized that even the following issue was about our misuse of the configuration parameter at the moment. Thanks for the pointer! > >> (ref: https://issues.onehippo.com/browse/HSTTWO-2525, > > If you want to specify a setting that doesn't exist in > FreemarkerServlet, then naturally you have to extends > FreemarkerServlet so that it can deal with that setting. > >> https://issues.onehippo.com/browse/HSTTWO-2460) > > Says "Errors in freemarker templates are logged on SEVERE level" (not > by FM). Is that what you meant to link? > > BTW, note that in 2.3.22 you can tell Freemarker not to log the > template errors which will cause Template.process to throw an > exception on you anyway. So then it's up to you if and how do you log > them. Ah this is also my mistake. We did override it there to ignore exception by default unless users sets TemplateExceptionHandler init parameter explicitly. Sorry for my misunderstanding. > >> - Locale issue. >> Currently templates are executed with a specific global locale all >> the time (FreemarkerServlet.deduceLocale() uses config.getLocale()). It >> can be overriden though. This can result in wrong date/currency >> formatting issue for instance (when using <@fmt.format* /> JSTL tags). >> It could have read HttpServletRequest#getLocale() by default. >> Normally (H)MVC frameworks sets the request locale before rendering a view. > > Is that default also desirable in other frameworks that use > FreemarkerServlet? It's a breaking change, so I don't think we can > change the default any time soon, but there could be an init-param for > this. (Though Hippo is perhaps not affected, as you already provide a > customized FreemarkerServler anyway.) I think so. For example, Spring Framework has a built-in component interface, LocaleResolver [1]. Depending on implementation component, it resolves the current request locale based on header, cookie, session, param, etc. So, even if they use the same component/template, they can change the locale and use different i18n resources dynamically. [1] http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#mvc-localeresolver > >> - More lightweight version. >> Sometimes our users want to use a more lightweight version instead >> of FreemarkerServlet. Especially people who are very familiar with >> Spring MVC Framework want that without having to set up a Freemarker >> servlet configuration in web.xml. One hurdle for them was they cannot >> easily take advantage of JSTL tag libraries if they don't use the >> servlet. I wish we could have more lightweight component support with >> which we can take advantage of JSTL tag support independently, without >> having to set up a servlet. >> By the way, this might be a byproduct of spring mvc framework >> integration probably. > > The JavaDoc of freemarker.ext.jsp.TaglibFactory says: "It can be added > to custom servlets as well to enable JSP taglib integration in them as > well." So at least at some point in the past that was an intent. It > should be piloted out if it indeed works, and maybe an example should > be added where it's applied. IIRC, it seemed difficult to do. But I can try it later again. I'll let you know later. > >> I think this is it for now. :-) > > So it seems, a good place for contributions for Hippo is all these JSP > integration stuff. This is where I'm weaker anyway... ;-) Yeah, and maybe (H)MVC integration things (Spring Framework, Struts2 for instance). > > And if someone at Hippo needs to do a hack to make FreemarkerServlet > behave better, always consider if it could be part of > FreemarkerServlet instead. Yeah, that's the right way to go. Agreed. Cheers, Woonsan > >> Thanks again! >> >> Cheers, >> >> Woonsan > -- [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 ------------------------------------------------------------------------------