[Freemarker-devel] Looking for contributors as part of Apache incubation

[Daniel Dekany]

We are (or mostly, I'm) trying to move FreeMarker over to the Apache
Software Foundation. So far the reaction is mostly positive on
Apache's side, but, the major concern is the low number of active
contributors. If everything goes well, there will be a voting about
letting FreeMarker in into the Apache *Incubator*, where it will have
to build up some kind of community or else it will fail. OTOH the main
reason I want FM to be an Apache project is exactly to improve chances
of finding contributors, especially long term ones like myself.
Obviously, one man (me) is not very safe for the users (like what if
something happens with me, or I just move on).

So, I just wonder if I can expect anyone to join the incubation when
and if it will be started. There's lot of interesting but difficult
tasks to do. Like better automatic escaping, a new parser that's more
IDE friendly and faster and has better error messages, proper support
of Map-s with non-string keys, better null handling, advanced
white-space removal, better caching, better i18n, supporting custom
"dialects" (i.e., changing the set of built-ins and built-in
directives), public template introspection API, better debugging,
Android support, and many more. It was just a glimpse. There's a lot
of space for advancement.

[Woonsan Ko]

Sounds really cool!
I'd like to help anythings (code/doc contributions and incubation
related chores) with regard to moving to ASF. I have once helped Apache
Rave a bit in PPMC with my colleagues (one as ASF member as well). I'll
spread the word.
I'm sure this project will be really successful and gather big
participation soon in bigger communities with this move.

Kind regards,

Woonsan

Post by Daniel Dekany
We are (or mostly, I'm) trying to move FreeMarker over to the Apache
Software Foundation. So far the reaction is mostly positive on
Apache's side, but, the major concern is the low number of active
contributors. If everything goes well, there will be a voting about
letting FreeMarker in into the Apache *Incubator*, where it will have
to build up some kind of community or else it will fail. OTOH the main
reason I want FM to be an Apache project is exactly to improve chances
of finding contributors, especially long term ones like myself.
Obviously, one man (me) is not very safe for the users (like what if
something happens with me, or I just move on).
So, I just wonder if I can expect anyone to join the incubation when
and if it will be started. There's lot of interesting but difficult
tasks to do. Like better automatic escaping, a new parser that's more
IDE friendly and faster and has better error messages, proper support
of Map-s with non-string keys, better null handling, advanced
white-space removal, better caching, better i18n, supporting custom
"dialects" (i.e., changing the set of built-ins and built-in
directives), public template introspection API, better debugging,
Android support, and many more. It was just a glimpse. There's a lot
of space for advancement.

[Daniel Dekany]

Post by Woonsan Ko
Sounds really cool!
I'd like to help anythings (code/doc contributions and incubation
related chores) with regard to moving to ASF. I have once helped Apache
Rave a bit in PPMC with my colleagues (one as ASF member as well). I'll
spread the word.

Thanks! We will need the help during the incubation for sure!

Post by Woonsan Ko
I'm sure this project will be really successful and gather big
participation soon in bigger communities with this move.
Kind regards,
Woonsan

Post by Daniel Dekany
We are (or mostly, I'm) trying to move FreeMarker over to the Apache
Software Foundation. So far the reaction is mostly positive on
Apache's side, but, the major concern is the low number of active
contributors. If everything goes well, there will be a voting about
letting FreeMarker in into the Apache *Incubator*, where it will have
to build up some kind of community or else it will fail. OTOH the main
reason I want FM to be an Apache project is exactly to improve chances
of finding contributors, especially long term ones like myself.
Obviously, one man (me) is not very safe for the users (like what if
something happens with me, or I just move on).
So, I just wonder if I can expect anyone to join the incubation when
and if it will be started. There's lot of interesting but difficult
tasks to do. Like better automatic escaping, a new parser that's more
IDE friendly and faster and has better error messages, proper support
of Map-s with non-string keys, better null handling, advanced
white-space removal, better caching, better i18n, supporting custom
"dialects" (i.e., changing the set of built-ins and built-in
directives), public template introspection API, better debugging,
Android support, and many more. It was just a glimpse. There's a lot
of space for advancement.

[Daniel Dekany]

I forgot tell in the initial mail... This whole activity was started
by Jacopo Cappellato from Apache OFBiz, who has the "Champion" role in
this, as they call it at ASF. We also already have the required number
of Mentors BTW.

Post by Woonsan Ko
Sounds really cool!
I'd like to help anythings (code/doc contributions and incubation
related chores) with regard to moving to ASF. I have once helped Apache
Rave a bit in PPMC with my colleagues (one as ASF member as well). I'll
spread the word.
I'm sure this project will be really successful and gather big
participation soon in bigger communities with this move.
Kind regards,
Woonsan

Post by Daniel Dekany
We are (or mostly, I'm) trying to move FreeMarker over to the Apache
Software Foundation. So far the reaction is mostly positive on
Apache's side, but, the major concern is the low number of active
contributors. If everything goes well, there will be a voting about
letting FreeMarker in into the Apache *Incubator*, where it will have
to build up some kind of community or else it will fail. OTOH the main
reason I want FM to be an Apache project is exactly to improve chances
of finding contributors, especially long term ones like myself.
Obviously, one man (me) is not very safe for the users (like what if
something happens with me, or I just move on).
So, I just wonder if I can expect anyone to join the incubation when
and if it will be started. There's lot of interesting but difficult
tasks to do. Like better automatic escaping, a new parser that's more
IDE friendly and faster and has better error messages, proper support
of Map-s with non-string keys, better null handling, advanced
white-space removal, better caching, better i18n, supporting custom
"dialects" (i.e., changing the set of built-ins and built-in
directives), public template introspection API, better debugging,
Android support, and many more. It was just a glimpse. There's a lot
of space for advancement.

[Woonsan Ko]

Yeah, I noticed that in the ***@incubator today. That's really nice
to have enough mentors already!
Also, "Champion" will help you and others overcome any problems and find
proper resources, etc. [1]
In my experience with Rave incubation, those mentors and champion helped
a lot (including infra, branding, legal issues, etc) to establish a new
project and community until graduation.
I don't see any big differences between your way gardening in this
community and Apache Way. So, I'm really sure you'll be happily
organizing people and gardening in a bigger and more active community in
the near future. ;-)

Cheers,

Woonsan

[1]
http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Champion

Post by Daniel Dekany
I forgot tell in the initial mail... This whole activity was started
by Jacopo Cappellato from Apache OFBiz, who has the "Champion" role in
this, as they call it at ASF. We also already have the required number
of Mentors BTW.

Post by Woonsan Ko
Sounds really cool!
I'd like to help anythings (code/doc contributions and incubation
related chores) with regard to moving to ASF. I have once helped Apache
Rave a bit in PPMC with my colleagues (one as ASF member as well). I'll
spread the word.
I'm sure this project will be really successful and gather big
participation soon in bigger communities with this move.
Kind regards,
Woonsan

Post by Daniel Dekany
We are (or mostly, I'm) trying to move FreeMarker over to the Apache
Software Foundation. So far the reaction is mostly positive on
Apache's side, but, the major concern is the low number of active
contributors. If everything goes well, there will be a voting about
letting FreeMarker in into the Apache *Incubator*, where it will have
to build up some kind of community or else it will fail. OTOH the main
reason I want FM to be an Apache project is exactly to improve chances
of finding contributors, especially long term ones like myself.
Obviously, one man (me) is not very safe for the users (like what if
something happens with me, or I just move on).
So, I just wonder if I can expect anyone to join the incubation when
and if it will be started. There's lot of interesting but difficult
tasks to do. Like better automatic escaping, a new parser that's more
IDE friendly and faster and has better error messages, proper support
of Map-s with non-string keys, better null handling, advanced
white-space removal, better caching, better i18n, supporting custom
"dialects" (i.e., changing the set of built-ins and built-in
directives), public template introspection API, better debugging,
Android support, and many more. It was just a glimpse. There's a lot
of space for advancement.

[marijan milicevic]

Hi Daniel,
I would also be interested in contributing..I am (we are) using freemarker
extensively and I would really like it to become an Apache project.
cheers
marijan
PS: I am one of the Woonasan colleagues

Post by Daniel Dekany
We are (or mostly, I'm) trying to move FreeMarker over to the Apache
Software Foundation. So far the reaction is mostly positive on
Apache's side, but, the major concern is the low number of active
contributors. If everything goes well, there will be a voting about
letting FreeMarker in into the Apache *Incubator*, where it will have
to build up some kind of community or else it will fail. OTOH the main
reason I want FM to be an Apache project is exactly to improve chances
of finding contributors, especially long term ones like myself.
Obviously, one man (me) is not very safe for the users (like what if
something happens with me, or I just move on).
So, I just wonder if I can expect anyone to join the incubation when
and if it will be started. There's lot of interesting but difficult
tasks to do. Like better automatic escaping, a new parser that's more
IDE friendly and faster and has better error messages, proper support
of Map-s with non-string keys, better null handling, advanced
white-space removal, better caching, better i18n, supporting custom
"dialects" (i.e., changing the set of built-ins and built-in
directives), public template introspection API, better debugging,
Android support, and many more. It was just a glimpse. There's a lot
of space for advancement.
--
Best regards,
Daniel Dekany
------------------------------------------------------------------------------
_______________________________________________
FreeMarker-devel mailing list
https://lists.sourceforge.net/lists/listinfo/freemarker-devel

--
View this message in context: http://freemarker.624813.n4.nabble.com/Looking-for-contributors-as-part-of-Apache-incubation-tp4655445p4655449.html
Sent from the freemarker-devel mailing list archive at Nabble.com.

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

[Pete Helgren]

I don't have the Java skills that a contributor ought to have but I am
willing to be included and if there is a "to-do" list I'll give it a
shot. My understanding of FM internals is pretty limited but again, as
a long time user of FM, I'll do what I can.

Pete Helgren
www.petesworkshop.com
GIAC Secure Software Programmer-Java

Post by Daniel Dekany
We are (or mostly, I'm) trying to move FreeMarker over to the Apache
Software Foundation. So far the reaction is mostly positive on
Apache's side, but, the major concern is the low number of active
contributors. If everything goes well, there will be a voting about
letting FreeMarker in into the Apache *Incubator*, where it will have
to build up some kind of community or else it will fail. OTOH the main
reason I want FM to be an Apache project is exactly to improve chances
of finding contributors, especially long term ones like myself.
Obviously, one man (me) is not very safe for the users (like what if
something happens with me, or I just move on).
So, I just wonder if I can expect anyone to join the incubation when
and if it will be started. There's lot of interesting but difficult
tasks to do. Like better automatic escaping, a new parser that's more
IDE friendly and faster and has better error messages, proper support
of Map-s with non-string keys, better null handling, advanced
white-space removal, better caching, better i18n, supporting custom
"dialects" (i.e., changing the set of built-ins and built-in
directives), public template introspection API, better debugging,
Android support, and many more. It was just a glimpse. There's a lot
of space for advancement.

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

[Daniel Dekany]

Thank you! And yes, there will be a TODO list, that I will assemble
with contributors is mind. BTW, just trying to make new features to
fail can be a big help, or participating in decision regarding FTL
language design decisions with a fresh eye.
--
Thanks,
Daniel Dekany

Post by Pete Helgren
I don't have the Java skills that a contributor ought to have but I am
willing to be included and if there is a "to-do" list I'll give it a
shot. My understanding of FM internals is pretty limited but again, as
a long time user of FM, I'll do what I can.
Pete Helgren
www.petesworkshop.com
GIAC Secure Software Programmer-Java

Post by Daniel Dekany
We are (or mostly, I'm) trying to move FreeMarker over to the Apache
Software Foundation. So far the reaction is mostly positive on
Apache's side, but, the major concern is the low number of active
contributors. If everything goes well, there will be a voting about
letting FreeMarker in into the Apache *Incubator*, where it will have
to build up some kind of community or else it will fail. OTOH the main
reason I want FM to be an Apache project is exactly to improve chances
of finding contributors, especially long term ones like myself.
Obviously, one man (me) is not very safe for the users (like what if
something happens with me, or I just move on).
So, I just wonder if I can expect anyone to join the incubation when
and if it will be started. There's lot of interesting but difficult
tasks to do. Like better automatic escaping, a new parser that's more
IDE friendly and faster and has better error messages, proper support
of Map-s with non-string keys, better null handling, advanced
white-space removal, better caching, better i18n, supporting custom
"dialects" (i.e., changing the set of built-ins and built-in
directives), public template introspection API, better debugging,
Android support, and many more. It was just a glimpse. There's a lot
of space for advancement.

------------------------------------------------------------------------------
_______________________________________________
FreeMarker-devel mailing list
https://lists.sourceforge.net/lists/listinfo/freemarker-devel

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

[Daniel Dekany]

So, Marijan and Woonasan. I'm especially interested in what Hippo
needs, what FM features you miss the most there, and what existing
"features" you hate the most.

Also, if in what topics you feel like contributing to. (Like Woonasan
has mentioned Spring MVC integration. That would be very useful to
improve.)

(And again, there will be a TODO list to pick from.)
--
Thanks,
Daniel Dekany

Hi Daniel,
I would also be interested in contributing..I am (we are) using freemarker
extensively and I would really like it to become an Apache project.
cheers
marijan
PS: I am one of the Woonasan colleagues

Post by Daniel Dekany
We are (or mostly, I'm) trying to move FreeMarker over to the Apache
Software Foundation. So far the reaction is mostly positive on
Apache's side, but, the major concern is the low number of active
contributors. If everything goes well, there will be a voting about
letting FreeMarker in into the Apache *Incubator*, where it will have
to build up some kind of community or else it will fail. OTOH the main
reason I want FM to be an Apache project is exactly to improve chances
of finding contributors, especially long term ones like myself.
Obviously, one man (me) is not very safe for the users (like what if
something happens with me, or I just move on).
So, I just wonder if I can expect anyone to join the incubation when
and if it will be started. There's lot of interesting but difficult
tasks to do. Like better automatic escaping, a new parser that's more
IDE friendly and faster and has better error messages, proper support
of Map-s with non-string keys, better null handling, advanced
white-space removal, better caching, better i18n, supporting custom
"dialects" (i.e., changing the set of built-ins and built-in
directives), public template introspection API, better debugging,
Android support, and many more. It was just a glimpse. There's a lot
of space for advancement.
--
Best regards,
Daniel Dekany
------------------------------------------------------------------------------
_______________________________________________
FreeMarker-devel mailing list
https://lists.sourceforge.net/lists/listinfo/freemarker-devel

--
http://freemarker.624813.n4.nabble.com/Looking-for-contributors-as-part-of-Apache-incubation-tp4655445p4655448.html
Sent from the freemarker-devel mailing list archive at Nabble.com.
------------------------------------------------------------------------------
_______________________________________________
FreeMarker-devel mailing list
https://lists.sourceforge.net/lists/listinfo/freemarker-devel

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

[Woonsan Ko]

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

- #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)

- 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.
(ref: https://issues.onehippo.com/browse/HSTTWO-2525,
https://issues.onehippo.com/browse/HSTTWO-2460)

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

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


I think this is it for now. :-)

Thanks again!

Cheers,

Woonsan

Post by Daniel Dekany
So, Marijan and Woonasan. I'm especially interested in what Hippo
needs, what FM features you miss the most there, and what existing
"features" you hate the most.
Also, if in what topics you feel like contributing to. (Like Woonasan
has mentioned Spring MVC integration. That would be very useful to
improve.)
(And again, there will be a TODO list to pick from.)

[Woonsan Ko]

Another complaint from one of our users was about the online
documentation. The site documentation looks good enough to me, but some
people might have felt a bit hard to find the proper info fast enough.

Regards,

Woonsan

Post by Woonsan Ko
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
https://issues.onehippo.com/browse/HSTTWO-3299
- #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)
- 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.
(ref: https://issues.onehippo.com/browse/HSTTWO-2525,
https://issues.onehippo.com/browse/HSTTWO-2460)
- 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
It could have read HttpServletRequest#getLocale() by default.
Normally (H)MVC frameworks sets the request locale before rendering a view.
- 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.
I think this is it for now. :-)
Thanks again!
Cheers,
Woonsan

Post by Daniel Dekany
So, Marijan and Woonasan. I'm especially interested in what Hippo
needs, what FM features you miss the most there, and what existing
"features" you hate the most.
Also, if in what topics you feel like contributing to. (Like Woonasan
has mentioned Spring MVC integration. That would be very useful to
improve.)
(And again, there will be a TODO list to pick from.)

[Daniel Dekany]

Post by Woonsan Ko
Another complaint from one of our users was about the online
documentation. The site documentation looks good enough to me, but some
people might have felt a bit hard to find the proper info fast enough.

Evangelia has added Google Search to the Manual with Docgen 2.0. I
hope it can be out in a few weeks. Also maybe I should make some good
cheat sheets...

Post by Woonsan Ko
Regards,
Woonsan

Post by Woonsan Ko
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
https://issues.onehippo.com/browse/HSTTWO-3299
- #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)
- 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.
(ref: https://issues.onehippo.com/browse/HSTTWO-2525,
https://issues.onehippo.com/browse/HSTTWO-2460)
- 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
It could have read HttpServletRequest#getLocale() by default.
Normally (H)MVC frameworks sets the request locale before rendering a view.
- 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.
I think this is it for now. :-)
Thanks again!
Cheers,
Woonsan

Post by Daniel Dekany
So, Marijan and Woonasan. I'm especially interested in what Hippo
needs, what FM features you miss the most there, and what existing
"features" you hate the most.
Also, if in what topics you feel like contributing to. (Like Woonasan
has mentioned Spring MVC integration. That would be very useful to
improve.)
(And again, there will be a TODO list to pick from.)

[Daniel Dekany]

Post by Woonsan Ko
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
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.

Post by Woonsan Ko
- #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.
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").

Post by Woonsan Ko
- 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).

Post by Woonsan Ko
(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.

Post by Woonsan Ko
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.

Post by Woonsan Ko
- 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
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.)

Post by Woonsan Ko
- 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.

Post by Woonsan Ko
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... ;-)

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.

Post by Woonsan Ko
Thanks again!
Cheers,
Woonsan

[Woonsan Ko]

Post by Daniel Dekany

Post by Woonsan Ko
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
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.

Post by Daniel Dekany

Post by Woonsan Ko
- #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.

Post by Daniel Dekany
So, maybe it would be better if we don't take away that duty from
- 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!

Post by Daniel Dekany

Post by Woonsan Ko
- 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!

Post by Daniel Dekany

Post by Woonsan Ko
(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.

Post by Woonsan Ko
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.

Post by Daniel Dekany

Post by Woonsan Ko
- 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
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

Post by Daniel Dekany

Post by Woonsan Ko
- 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.

Post by Daniel Dekany

Post by Woonsan Ko
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).

Post by Daniel Dekany
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

Post by Daniel Dekany

Post by Woonsan Ko
Thanks again!
Cheers,
Woonsan

[Daniel Dekany]

Wednesday, June 3, 2015, 5:13:00 AM, Woonsan Ko wrote:

[snip]

Post by Woonsan Ko

Post by Daniel Dekany

Post by Woonsan Ko
- #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).

So how reliable that is, detecting if it wasn't set? Does the Servlet
spec. say something about this?

Post by Woonsan Ko
Comparing with JSP, the current behavior seems okay, but I was thinking
in line of flexibility in our HMVC framework.

Post by Daniel Dekany
So, maybe it would be better if we don't take away that duty from
- 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!

So then, let's just extend the existing "ContentType" init-param to
support "dontSet"/"dont_set" value, or whatever it should be (and
indeed what should it be?). Then we will *never* set the content type,
not even if it wasn't set. Will the servlet container add a default
content type then? Had to check the specs and try it at least on
Tomcat and Jetty...

Post by Woonsan Ko

Post by Daniel Dekany

Post by Woonsan Ko
- 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!

Post by Daniel Dekany

Post by Woonsan Ko
(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.

Post by Woonsan Ko
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.

Things like this can cause confusion as they interfere with similar FM
features. It's better to figure out how to address the problem in
Freemarker itself and then contribute... (-;

Post by Woonsan Ko

Post by Daniel Dekany

Post by Woonsan Ko
- 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
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.

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

Post by Woonsan Ko
[1]
http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#mvc-localeresolver

Post by Daniel Dekany

Post by Woonsan Ko
- 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.

Well, it's entirely possible that it needs some substantial changes...
I don't know. The whole servlet/JSP integration stuff was always out
of my focus somehow.

Post by Woonsan Ko

Post by Daniel Dekany

Post by Woonsan Ko
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).

Post by Daniel Dekany
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

[Woonsan Ko]

Post by Daniel Dekany
[snip]

Post by Woonsan Ko

Post by Daniel Dekany

Post by Woonsan Ko
- #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).

So how reliable that is, detecting if it wasn't set? Does the Servlet
spec. say something about this?

According to Servlet Spec 2.4 (SRV.14.2.22.1),
ServletResponse#getContentType() should "Returns the content type used
for the MIME body sent in this response. The content type proper must
have been specified using setContentType(String) before the response is
committed. If no content type has been specified, this method returns
null. If a content type has been specified and a character encoding has
been explicitly or implicitly specified as described in
getCharacterEncoding() , the charset parameter is included in the string
returned. If no character encoding has been specified, the charset
parameter is omitted.
Returns: a String specifying the content type, for example, text/html;
charset=UTF-8, or null
Since: 2.4"

So, if #getContentType() returns null, then I think we can detect that
the Content-Type was never set before.

Post by Daniel Dekany

Post by Woonsan Ko
Comparing with JSP, the current behavior seems okay, but I was thinking
in line of flexibility in our HMVC framework.

Post by Daniel Dekany
So, maybe it would be better if we don't take away that duty from
- 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!

So then, let's just extend the existing "ContentType" init-param to
support "dontSet"/"dont_set" value, or whatever it should be (and
indeed what should it be?). Then we will *never* set the content type,
not even if it wasn't set. Will the servlet container add a default
content type then? Had to check the specs and try it at least on
Tomcat and Jetty...

According to SRV.5.2, "Servlet programmers are responsible for ensuring
that the Content-Type header is appropriately set in the response object
for the content the servlet is generating. The HTTP 1.1 specification
does not require that this header be set in an HTTP response. Servlet
containers must not set a default content type when the servlet
programmer does not set the type."

So, actually, frameworks or containers don't have to set Content-Type if
programmers don't. However, I have seen JSP compiler (of Tomcat)
generates source with #setContentType() before (maybe it's a legacy from
old spec?), so I still think setting Content-Type header in the
framework level (freemarker servlet in this case) to a reasonable
default value seems fine.

Regarding the special value to not set the default Content-Type, how
about an empty string for that? If I set ContentType="" in init param,
then it can skip setting the default Content-Type.

Post by Daniel Dekany

Post by Woonsan Ko

Post by Daniel Dekany

Post by Woonsan Ko
- 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!

Post by Daniel Dekany

Post by Woonsan Ko
(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.

Post by Woonsan Ko
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.

Things like this can cause confusion as they interfere with similar FM
features. It's better to figure out how to address the problem in
Freemarker itself and then contribute... (-;

Post by Woonsan Ko

Post by Daniel Dekany

Post by Woonsan Ko
- 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
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.

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.

Post by Daniel Dekany

Post by Woonsan Ko
[1]
http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#mvc-localeresolver

Post by Daniel Dekany

Post by Woonsan Ko
- 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.

Well, it's entirely possible that it needs some substantial changes...
I don't know. The whole servlet/JSP integration stuff was always out
of my focus somehow.

I'll give it a try soon.

Thanks for your remarks!

Cheers,

Woonsan

Post by Daniel Dekany

Post by Woonsan Ko

Post by Daniel Dekany

Post by Woonsan Ko
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).

Post by Daniel Dekany
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

[Daniel Dekany]

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]

Post by Woonsan Ko

Post by Daniel Dekany
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.

[Woonsan Ko]

Post by Daniel Dekany
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!

Post by Daniel Dekany
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.

Post by Daniel Dekany
[snip]

Post by Woonsan Ko

Post by Daniel Dekany
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

Post by Daniel Dekany
Just like with "OverrideResponseContentType", the default can depend
on the IcI on the long run.

[marijan milicevic]

Hi Daniel,

Post by Daniel Dekany
So, Marijan and Woonasan. I'm especially interested in what Hippo
needs, what FM features you miss the most there, and what existing
"features" you hate the most.
Also, if in what topics you feel like contributing to. (Like Woonasan
has mentioned Spring MVC integration. That would be very useful to
improve.)
(And again, there will be a TODO list to pick from.)

beside number of things Woonsan already mentioned,
I would also like to see better IDE support...
Currently I am quite familiar with Intellij plugin API and in the past I
built Eclipse plugin
for custom language so I have some experience with Eclipse plugin API,
although this was long ago...

Other than that, on a personal level, I would be interested to learn (and
do) more about grammar/parsers/AST building
(I see freemarker is using javacc, I have some experience with antlr),


cheers,
marijan

Post by Daniel Dekany
--
Thanks,
Daniel Dekany

Hi Daniel,
I would also be interested in contributing..I am (we are) using

freemarker

extensively and I would really like it to become an Apache project.

information.

cheers
marijan
PS: I am one of the Woonasan colleagues

Post by Daniel Dekany
We are (or mostly, I'm) trying to move FreeMarker over to the Apache
Software Foundation. So far the reaction is mostly positive on
Apache's side, but, the major concern is the low number of active
contributors. If everything goes well, there will be a voting about
letting FreeMarker in into the Apache *Incubator*, where it will have
to build up some kind of community or else it will fail. OTOH the main
reason I want FM to be an Apache project is exactly to improve chances
of finding contributors, especially long term ones like myself.
Obviously, one man (me) is not very safe for the users (like what if
something happens with me, or I just move on).
So, I just wonder if I can expect anyone to join the incubation when
and if it will be started. There's lot of interesting but difficult
tasks to do. Like better automatic escaping, a new parser that's more
IDE friendly and faster and has better error messages, proper support
of Map-s with non-string keys, better null handling, advanced
white-space removal, better caching, better i18n, supporting custom
"dialects" (i.e., changing the set of built-ins and built-in
directives), public template introspection API, better debugging,
Android support, and many more. It was just a glimpse. There's a lot
of space for advancement.
--
Best regards,
Daniel Dekany

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

Post by Daniel Dekany
_______________________________________________
FreeMarker-devel mailing list
https://lists.sourceforge.net/lists/listinfo/freemarker-devel

--

http://freemarker.624813.n4.nabble.com/Looking-for-contributors-as-part-of-Apache-incubation-tp4655445p4655448.html

Sent from the freemarker-devel mailing list archive at Nabble.com.

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

_______________________________________________
FreeMarker-devel mailing list
https://lists.sourceforge.net/lists/listinfo/freemarker-devel

[Daniel Dekany]

Improving IDE support is a very efficient way of making Freemarker a
better alternative for the users. It's possibly related to how
Freemarer parses for itself, because ideally, the IDE should just use
the real parser. I'm not sure if how feasible that is, though. An IDE
parser need to be incremental, be able to go on after errors to at
least continue syntax highlighting, etc. (Not to mention, that the IDE
should somehow mix an FTL parser with a HTML/CSS parser, or whatever
it is that you write a template for.) Even if it's not feasible to do
in a single parse, it would better if the IDE-centric parser is
maintained at the Freemarker project (in a separate artifact), rather
than each plugin tries to roll its own. (Especially as the FTL parser
has, well, quirks, if you look into the details...) So developing a
common IDE-centric parser would be a big help for plugin authors. And
indeed, I suspect that many other task could be implemented without
depending on a concrete IDE, like outline tree building or
auto-completion.

Seems you are an exceptionally good fit for this, as you have
experience with both major Java IDE-s, and also with parsers. So if
you feel like figuring these out... don't hold yourself back. (;

BTW, another long term goal with the parser is separating the
expression syntax from the "top-level syntax" (as I call it). Thus one
or the other could be replaced.
--
Thanks,
Daniel Dekany

Hi Daniel,
So, Marijan and Woonasan. I'm especially interested in what Hippo
needs, what FM features you miss the most there, and what existing
"features" you hate the most.
Also, if in what topics you feel like contributing to. (Like Woonasan
has mentioned Spring MVC integration. That would be very useful to
improve.)
(And again, there will be a TODO list to pick from.)
beside number of things Woonsan already mentioned,
I would also like to see better IDE support...
Currently I am quite familiar with Intellij plugin API and in the past I built Eclipse plugin
for custom language so I have some experience with Eclipse plugin
API, although this was long ago...
Other than that, on a personal level, I would be interested to
learn (and do) more about grammar/parsers/AST building
(I see freemarker is using javacc, I have some experience with antlr),
cheers,
marijan
--
Thanks,
Daniel Dekany

Hi Daniel,
I would also be interested in contributing..I am (we are) using freemarker
extensively and I would really like it to become an Apache project.
cheers
marijan
PS: I am one of the Woonasan colleagues

Post by Daniel Dekany
We are (or mostly, I'm) trying to move FreeMarker over to the Apache
Software Foundation. So far the reaction is mostly positive on
Apache's side, but, the major concern is the low number of active
contributors. If everything goes well, there will be a voting about
letting FreeMarker in into the Apache *Incubator*, where it will have
to build up some kind of community or else it will fail. OTOH the main
reason I want FM to be an Apache project is exactly to improve chances
of finding contributors, especially long term ones like myself.
Obviously, one man (me) is not very safe for the users (like what if
something happens with me, or I just move on).
So, I just wonder if I can expect anyone to join the incubation when
and if it will be started. There's lot of interesting but difficult
tasks to do. Like better automatic escaping, a new parser that's more
IDE friendly and faster and has better error messages, proper support
of Map-s with non-string keys, better null handling, advanced
white-space removal, better caching, better i18n, supporting custom
"dialects" (i.e., changing the set of built-ins and built-in
directives), public template introspection API, better debugging,
Android support, and many more. It was just a glimpse. There's a lot
of space for advancement.
--
Best regards,
Daniel Dekany

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

[Raymond Auge]

Liferay would enjoy if Freemarker (which Liferay uses extensively) were to
become an Apache project and would try to participate as much as we could.

Could you not provide to ASF the long list of "Powered by Freemarker" as
indicator that it's an active and viable project?

- Ray

Post by Daniel Dekany
We are (or mostly, I'm) trying to move FreeMarker over to the Apache
Software Foundation. So far the reaction is mostly positive on
Apache's side, but, the major concern is the low number of active
contributors. If everything goes well, there will be a voting about
letting FreeMarker in into the Apache *Incubator*, where it will have
to build up some kind of community or else it will fail. OTOH the main
reason I want FM to be an Apache project is exactly to improve chances
of finding contributors, especially long term ones like myself.
Obviously, one man (me) is not very safe for the users (like what if
something happens with me, or I just move on).
So, I just wonder if I can expect anyone to join the incubation when
and if it will be started. There's lot of interesting but difficult
tasks to do. Like better automatic escaping, a new parser that's more
IDE friendly and faster and has better error messages, proper support
of Map-s with non-string keys, better null handling, advanced
white-space removal, better caching, better i18n, supporting custom
"dialects" (i.e., changing the set of built-ins and built-in
directives), public template introspection API, better debugging,
Android support, and many more. It was just a glimpse. There's a lot
of space for advancement.
--
Best regards,
Daniel Dekany
------------------------------------------------------------------------------
_______________________________________________
FreeMarker-devel mailing list
https://lists.sourceforge.net/lists/listinfo/freemarker-devel

[Daniel Dekany]

Post by Raymond Auge
Liferay would enjoy if Freemarker (which Liferay uses extensively)
were to become an Apache project and would try to participate as much as we could.

Well, if Liferay needs some feature anyway, you know, that's the best place
to help maybe.

Also maybe Eclipse IDE development is a natural place where Liferay
could help out. It can either mean the improvement of the JBoss IDE,
or better yet, supporting Angelo Zerr in developing the plugin he has
started (hoping he still wants to do it). Other than it has more
potential for technical reasons, that could probably be done under the
Freemarker project, which means visible project activity. Or, working
on the FM core for better debugger support is also something that
Liferay may benefits from. Anyway, I ran ahead too much... we aren't
even in the Incubator yet.

Post by Raymond Auge
Could you not provide to ASF the long list of "Powered by
Freemarker" as indicator that it's an active and viable project?

They know that it's a widely used project, as far as I can tell. But
maybe it should be linked from the proposal, yes. The main concern
that was raised is that it has not much active contributors.
--
Thanks,
Daniel Dekany

Post by Raymond Auge
- Ray
We are (or mostly, I'm) trying to move FreeMarker over to the Apache
Software Foundation. So far the reaction is mostly positive on
Apache's side, but, the major concern is the low number of active
contributors. If everything goes well, there will be a voting about
letting FreeMarker in into the Apache *Incubator*, where it will have
to build up some kind of community or else it will fail. OTOH the main
reason I want FM to be an Apache project is exactly to improve chances
of finding contributors, especially long term ones like myself.
Obviously, one man (me) is not very safe for the users (like what if
something happens with me, or I just move on).
So, I just wonder if I can expect anyone to join the incubation when
and if it will be started. There's lot of interesting but difficult
tasks to do. Like better automatic escaping, a new parser that's more
IDE friendly and faster and has better error messages, proper support
of Map-s with non-string keys, better null handling, advanced
white-space removal, better caching, better i18n, supporting custom
"dialects" (i.e., changing the set of built-ins and built-in
directives), public template introspection API, better debugging,
Android support, and many more. It was just a glimpse. There's a lot
of space for advancement.
--
Best regards,
Daniel Dekany
------------------------------------------------------------------------------
_______________________________________________
FreeMarker-devel mailing list
https://lists.sourceforge.net/lists/listinfo/freemarker-devel

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

[Wong, Christopher]

Concerning the "public template introspection API", I'd like to provide an update on my freemarker-introspection project:

https://github.com/cwong15/freemarker-introspection

I've updated the code to support the latest Freemarker (2.3.22). To inspect the parsed Freemarker AST, it now uses package-local access instead of reflection for more robust Freemarker compatibility. I'm open to recommendations on how to progress towards making this part of the Freemarker project somehow.

Chris

-----Original Message-----
From: Daniel Dekany [mailto:***@freemail.hu]
Sent: Saturday, May 30, 2015 6:21 AM
To: freemarker-***@lists.sourceforge.net
Subject: [Freemarker-devel] Looking for contributors as part of Apache incubation

We are (or mostly, I'm) trying to move FreeMarker over to the Apache Software Foundation. So far the reaction is mostly positive on Apache's side, but, the major concern is the low number of active contributors. If everything goes well, there will be a voting about letting FreeMarker in into the Apache *Incubator*, where it will have to build up some kind of community or else it will fail. OTOH the main reason I want FM to be an Apache project is exactly to improve chances of finding contributors, especially long term ones like myself.
Obviously, one man (me) is not very safe for the users (like what if something happens with me, or I just move on).

So, I just wonder if I can expect anyone to join the incubation when and if it will be started. There's lot of interesting but difficult tasks to do. Like better automatic escaping, a new parser that's more IDE friendly and faster and has better error messages, proper support of Map-s with non-string keys, better null handling, advanced white-space removal, better caching, better i18n, supporting custom "dialects" (i.e., changing the set of built-ins and built-in directives), public template introspection API, better debugging, Android support, and many more. It was just a glimpse. There's a lot of space for advancement.

--
Best regards,
Daniel Dekany


------------------------------------------------------------------------------
_______________________________________________
FreeMarker-devel mailing list
FreeMarker-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freemarker-devel

________________________________

This e-mail and files transmitted with it are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you are not one of the named recipient(s) or otherwise have reason to believe that you received this message in error, please immediately notify sender by e-mail, and destroy the original message. Thank You.

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

[Daniel Dekany]

I'm still not sure what will be done about this (I mean whole topic of
detailed introspection). Right now, what I'm think of is that at some
point (even 2.3.24) I will add something like ParserPlugin, which is
something the user could specify on the Configuration level (maybe per
template name pattern). That means that a parser plugin can
participate in the parsing, because it was there before the template
parsing was started. This already eliminates some compatibility risks
(like what if Template-s won't contain an AST anymore, but generated
byte code for example - this can work even then). The plugin could
attach arbitrary attributes to the template (see custom attributes) to
store plugin output (if any), or even change the template.

So how does is make backward compatibility easier (apart from what was
already said above)? For now the user couldn't define custom
plugins... FM itself (or some additional optional artifacts) would,
define some plugins that cover the most frequent needs, and the user
only has the power to chose among these plugins. Two frequent things
that we could solve with a plugin are:

- Collecting the names of maybe-data-model variables used (to find out the
requires data-model variables for a template)

- Collecting the includes/imports (to analyze which template depends on
which)

So this hopefully somewhat alleviates the need for more detailed
template introspection (such as walking the AST), while we haven't
exposed much from the internals (and hence from the things that we may
want to change later).

What exactly was template introspection used for in your use case?

BTW, a plugin that I will make is the interruptible template plugin. A
template to which that plugin was associated will support
Thread.interrupt() on the running template. This functionality
(template interruptability) is already present in 2.3.22, but is only
accessibly through internal API-s, and is used on freemarker-online to
automatically abort long running templates.
--
Thanks,
Daniel Dekany

Post by Wong, Christopher
Concerning the "public template introspection API", I'd like to
https://github.com/cwong15/freemarker-introspection
I've updated the code to support the latest Freemarker (2.3.22). To
inspect the parsed Freemarker AST, it now uses package-local access
instead of reflection for more robust Freemarker compatibility. I'm
open to recommendations on how to progress towards making this part
of the Freemarker project somehow.
Chris
-----Original Message-----
Sent: Saturday, May 30, 2015 6:21 AM
Subject: [Freemarker-devel] Looking for contributors as part of Apache incubation
We are (or mostly, I'm) trying to move FreeMarker over to the
Apache Software Foundation. So far the reaction is mostly positive
on Apache's side, but, the major concern is the low number of active
contributors. If everything goes well, there will be a voting about
letting FreeMarker in into the Apache *Incubator*, where it will
have to build up some kind of community or else it will fail. OTOH
the main reason I want FM to be an Apache project is exactly to
improve chances of finding contributors, especially long term ones like myself.
Obviously, one man (me) is not very safe for the users (like what
if something happens with me, or I just move on).
So, I just wonder if I can expect anyone to join the incubation
when and if it will be started. There's lot of interesting but
difficult tasks to do. Like better automatic escaping, a new parser
that's more IDE friendly and faster and has better error messages,
proper support of Map-s with non-string keys, better null handling,
advanced white-space removal, better caching, better i18n,
supporting custom "dialects" (i.e., changing the set of built-ins
and built-in directives), public template introspection API, better
debugging, Android support, and many more. It was just a glimpse.
There's a lot of space for advancement.
--
Best regards,
Daniel Dekany

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

[Wong, Christopher]

I agree that introspection is a tricky business. So far, I have adopted your recommendation to use the package local TemplateObject.getParameterCount/getParameterValue accessors, but that works as long as Freemarker is kind enough to expose the AST.

These are the major things I'm doing with freemarker-introspection:
- identify custom directives (UnifiedCalls) and their params
- identify variables used
- replace specific elements with something else (takes advantage of begin/end line/column properties)

Your parser plugin proposal might work for me, if it supplies enough information. I could build my own AST as Freemarker does its thing. Of course, that pretty much means I'd have to rewrite freemarker-introspection. This will hopefully be a longer-term thing so I have time to do this. But there could be some uses of freemarker-introspection that I could reimplement using the ParserPlugin mechanism instead.

Chris

-----Original Message-----
From: Daniel Dekany [mailto:***@freemail.hu]
Sent: Saturday, June 06, 2015 8:26 PM
To: Wong, Christopher
Cc: Daniel Dekany
Subject: Re: [Freemarker-devel] Looking for contributors as part of Apache incubation

I'm still not sure what will be done about this (I mean whole topic of detailed introspection). Right now, what I'm think of is that at some point (even 2.3.24) I will add something like ParserPlugin, which is something the user could specify on the Configuration level (maybe per template name pattern). That means that a parser plugin can participate in the parsing, because it was there before the template parsing was started. This already eliminates some compatibility risks (like what if Template-s won't contain an AST anymore, but generated byte code for example - this can work even then). The plugin could attach arbitrary attributes to the template (see custom attributes) to store plugin output (if any), or even change the template.

So how does is make backward compatibility easier (apart from what was already said above)? For now the user couldn't define custom plugins... FM itself (or some additional optional artifacts) would, define some plugins that cover the most frequent needs, and the user only has the power to chose among these plugins. Two frequent things that we could solve with a plugin are:

- Collecting the names of maybe-data-model variables used (to find out the
requires data-model variables for a template)

- Collecting the includes/imports (to analyze which template depends on
which)

So this hopefully somewhat alleviates the need for more detailed template introspection (such as walking the AST), while we haven't exposed much from the internals (and hence from the things that we may want to change later).

What exactly was template introspection used for in your use case?

BTW, a plugin that I will make is the interruptible template plugin. A template to which that plugin was associated will support
Thread.interrupt() on the running template. This functionality (template interruptability) is already present in 2.3.22, but is only accessibly through internal API-s, and is used on freemarker-online to automatically abort long running templates.

--
Thanks,
Daniel Dekany

Post by Wong, Christopher
Concerning the "public template introspection API", I'd like to
https://github.com/cwong15/freemarker-introspection
I've updated the code to support the latest Freemarker (2.3.22). To
inspect the parsed Freemarker AST, it now uses package-local access
instead of reflection for more robust Freemarker compatibility. I'm
open to recommendations on how to progress towards making this part
of the Freemarker project somehow.
Chris
-----Original Message-----
Sent: Saturday, May 30, 2015 6:21 AM
Subject: [Freemarker-devel] Looking for contributors as part of Apache incubation
We are (or mostly, I'm) trying to move FreeMarker over to the
Apache Software Foundation. So far the reaction is mostly positive
on Apache's side, but, the major concern is the low number of active
contributors. If everything goes well, there will be a voting about
letting FreeMarker in into the Apache *Incubator*, where it will
have to build up some kind of community or else it will fail. OTOH
the main reason I want FM to be an Apache project is exactly to
improve chances of finding contributors, especially long term ones like myself.
Obviously, one man (me) is not very safe for the users (like what
if something happens with me, or I just move on).
So, I just wonder if I can expect anyone to join the incubation
when and if it will be started. There's lot of interesting but
difficult tasks to do. Like better automatic escaping, a new parser
that's more IDE friendly and faster and has better error messages,
proper support of Map-s with non-string keys, better null handling,
advanced white-space removal, better caching, better i18n,
supporting custom "dialects" (i.e., changing the set of built-ins
and built-in directives), public template introspection API, better
debugging, Android support, and many more. It was just a glimpse.
There's a lot of space for advancement.
--
Best regards,
Daniel Dekany

________________________________

This e-mail and files transmitted with it are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you are not one of the named recipient(s) or otherwise have reason to believe that you received this message in error, please immediately notify sender by e-mail, and destroy the original message. Thank You.

[Daniel Dekany]

I try to avoid changing the existing public AST API-s (as far as it's
possible when new features are added...) until there's no viable
published API for introspection/modification. For now, the purpose of
the ParserPlugins would be that less users will be forced to depend on
the AST API, because they get the functionality as a ParserPlugin
written by us.

Post by Wong, Christopher
I agree that introspection is a tricky business. So far, I have
adopted your recommendation to use the package local
TemplateObject.getParameterCount/getParameterValue accessors, but
that works as long as Freemarker is kind enough to expose the AST.
- identify custom directives (UnifiedCalls) and their params

For many that would be #import and #include and its *constant*
template name parameter. That information could be given back to the
user through a published API, as it's just Strings. Problems start
when the parameter of interest has some more generic expression as
it's value...

Anyway, can you tell me about the concrete use case in your case?

Post by Wong, Christopher
- identify variables used

That's possible as we can again just give back a bunch of strings...
or a chains of strings (like ["foo", "bar"] for foo.bar).

Post by Wong, Christopher
- replace specific elements with something else (takes advantage of begin/end line/column properties)

Here again, the concrete use case might would be interesting.

Post by Wong, Christopher
Your parser plugin proposal might work for me, if it supplies
enough information. I could build my own AST as Freemarker does its
thing. Of course, that pretty much means I'd have to rewrite
freemarker-introspection. This will hopefully be a longer-term thing
so I have time to do this. But there could be some uses of
freemarker-introspection that I could reimplement using the ParserPlugin mechanism instead.
Chris
-----Original Message-----
Sent: Saturday, June 06, 2015 8:26 PM
To: Wong, Christopher
Cc: Daniel Dekany
Subject: Re: [Freemarker-devel] Looking for contributors as part of Apache incubation
I'm still not sure what will be done about this (I mean whole topic
of detailed introspection). Right now, what I'm think of is that at
some point (even 2.3.24) I will add something like ParserPlugin,
which is something the user could specify on the Configuration level
(maybe per template name pattern). That means that a parser plugin
can participate in the parsing, because it was there before the
template parsing was started. This already eliminates some
compatibility risks (like what if Template-s won't contain an AST
anymore, but generated byte code for example - this can work even
then). The plugin could attach arbitrary attributes to the template
(see custom attributes) to store plugin output (if any), or even change the template.
So how does is make backward compatibility easier (apart from what
was already said above)? For now the user couldn't define custom
plugins... FM itself (or some additional optional artifacts) would,
define some plugins that cover the most frequent needs, and the user
only has the power to chose among these plugins. Two frequent things
- Collecting the names of maybe-data-model variables used (to find out the
requires data-model variables for a template)
- Collecting the includes/imports (to analyze which template depends on
which)
So this hopefully somewhat alleviates the need for more detailed
template introspection (such as walking the AST), while we haven't
exposed much from the internals (and hence from the things that we may want to change later).
What exactly was template introspection used for in your use case?
BTW, a plugin that I will make is the interruptible template
plugin. A template to which that plugin was associated will support
Thread.interrupt() on the running template. This functionality
(template interruptability) is already present in 2.3.22, but is
only accessibly through internal API-s, and is used on
freemarker-online to automatically abort long running templates.
--
Thanks,
Daniel Dekany

Post by Wong, Christopher
Concerning the "public template introspection API", I'd like to
https://github.com/cwong15/freemarker-introspection
I've updated the code to support the latest Freemarker (2.3.22). To
inspect the parsed Freemarker AST, it now uses package-local access
instead of reflection for more robust Freemarker compatibility. I'm
open to recommendations on how to progress towards making this part
of the Freemarker project somehow.
Chris
-----Original Message-----
Sent: Saturday, May 30, 2015 6:21 AM
Subject: [Freemarker-devel] Looking for contributors as part of Apache incubation
We are (or mostly, I'm) trying to move FreeMarker over to the
Apache Software Foundation. So far the reaction is mostly positive
on Apache's side, but, the major concern is the low number of active
contributors. If everything goes well, there will be a voting about
letting FreeMarker in into the Apache *Incubator*, where it will
have to build up some kind of community or else it will fail. OTOH
the main reason I want FM to be an Apache project is exactly to
improve chances of finding contributors, especially long term ones like myself.
Obviously, one man (me) is not very safe for the users (like what
if something happens with me, or I just move on).
So, I just wonder if I can expect anyone to join the incubation
when and if it will be started. There's lot of interesting but
difficult tasks to do. Like better automatic escaping, a new parser
that's more IDE friendly and faster and has better error messages,
proper support of Map-s with non-string keys, better null handling,
advanced white-space removal, better caching, better i18n,
supporting custom "dialects" (i.e., changing the set of built-ins
and built-in directives), public template introspection API, better
debugging, Android support, and many more. It was just a glimpse.
There's a lot of space for advancement.
--
Best regards,
Daniel Dekany

[p***@gmail.com]

Hello,

I would like to contribute to this project. I am a software developer,
primarily working with Java/J2EE technologies. Will be really interested in
helping with development activities towards the success of this project.
Looking forward to hearing from you asap.

Thanks and regards,
Priya



--
View this message in context: http://freemarker.624813.n4.nabble.com/Looking-for-contributors-as-part-of-Apache-incubation-tp4655445p4655588.html
Sent from the freemarker-devel mailing list archive at Nabble.com.

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

[Daniel Dekany]

Hello,

Please come over to ***@freemarker.incubator.apache.org and let's
discuss what you would like to work on. If you aren't sure, there's a
list of tasks on http://freemarker.org/contribute.html (though at the
moment we have a DNS problem... hopefully it will go away soon).
--
Thanks,
Daniel Dekany

Post by p***@gmail.com
Hello,
I would like to contribute to this project. I am a software developer,
primarily working with Java/J2EE technologies. Will be really interested in
helping with development activities towards the success of this project.
Looking forward to hearing from you asap.
Thanks and regards,
Priya

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