Looking for contributors as part of Apache incubation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Looking for contributors as part of Apache incubation

Woonsan Ko
On 6/3/15 2:50 AM, Daniel Dekany wrote:

> Wednesday, June 3, 2015, 5:13:00 AM, Woonsan Ko wrote:
>
> [snip]
>>>>  - #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.

>
>> Comparing with JSP, the current behavior seems okay, but I was thinking
>> in line of flexibility in our HMVC framework.
>>
>>> So, maybe it would be better if we don't take away that duty from
>>> FreemarkerServlet, instead it should be smarted about it:
>>>
>>> - You could just tell FreemarkerServlet explicitly to set a given
>>>   content type with a ServletRequest attribute. It's analogous to
>>>   specifying data-model variables to tell Freemarker what to show,
>>>   which you also do in the ServlerRequest via attributes.
>>>
>>> - Support a new init-param value: ContentType=dontSet
>>>
>>> - Adding a protected method where you can override how content type
>>>   detection happens, and if it happens (returning null means "don't
>>>   set").
>>
>> I would like an init-param better than custom request attribute or
>> protected method. Thanks for the suggestion!
>
> 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.

>
>>>>  - Configuration settings could be set through init parameters.
>>>>    Some servlet-related parameters are set through init parameters, but
>>>> it could be even better if there's any specific init-param(s) to set
>>>> Configuration settings without code changes.
>>>
>>> I'm not sure what you mean here. Pretty much all the Freemarker
>>> settings can be set through the init-params, because the init-params
>>> that are not recognized are feed to Configuration.setSetting(String,
>>> String).
>>
>> Ah you're right. I was totally confused. I've just realized that even
>> the following issue was about our misuse of the configuration parameter
>> at the moment. Thanks for the pointer!
>>
>>>
>>>>    (ref: https://issues.onehippo.com/browse/HSTTWO-2525,
>>>
>>> If you want to specify a setting that doesn't exist in
>>> FreemarkerServlet, then naturally you have to extends
>>> FreemarkerServlet so that it can deal with that setting.
>>>
>>>>          https://issues.onehippo.com/browse/HSTTWO-2460)
>>>
>>> Says "Errors in freemarker templates are logged on SEVERE level" (not
>>> by FM). Is that what you meant to link?
>>>
>>> BTW, note that in 2.3.22 you can tell Freemarker not to log the
>>> template errors which will cause Template.process to throw an
>>> exception on you anyway. So then it's up to you if and how do you log
>>> them.
>>
>> Ah this is also my mistake. We did override it there to ignore exception
>> by default unless users sets TemplateExceptionHandler init parameter
>> explicitly. Sorry for my misunderstanding.
>
> 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... (-;
>
>>>>  - Locale issue.
>>>>    Currently templates are executed with a specific global locale all
>>>> the time (FreemarkerServlet.deduceLocale() uses config.getLocale()). It
>>>> can be overriden though. This can result in wrong date/currency
>>>> formatting issue for instance (when using <@fmt.format* /> JSTL tags).
>>>>    It could have read HttpServletRequest#getLocale() by default.
>>>> Normally (H)MVC frameworks sets the request locale before rendering a view.
>>>
>>> Is that default also desirable in other frameworks that use
>>> FreemarkerServlet? It's a breaking change, so I don't think we can
>>> change the default any time soon, but there could be an init-param for
>>> this. (Though Hippo is perhaps not affected, as you already provide a
>>> customized FreemarkerServler anyway.)
>>
>> I think so. For example, Spring Framework has a built-in component
>> interface, LocaleResolver [1]. Depending on implementation component, it
>> resolves the current request locale based on header, cookie, session,
>> param, etc. So, even if they use the same component/template, they can
>> change the locale and use different i18n resources dynamically.
>
> 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.

>
>> [1]
>> http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#mvc-localeresolver
>>
>>>
>>>>  -  More lightweight version.
>>>>     Sometimes our users want to use a more lightweight version instead
>>>> of FreemarkerServlet. Especially people who are very familiar with
>>>> Spring MVC Framework want that without having to set up a Freemarker
>>>> servlet configuration in web.xml. One hurdle for them was they cannot
>>>> easily take advantage of JSTL tag libraries if they don't use the
>>>> servlet. I wish we could have more lightweight component support with
>>>> which we can take advantage of JSTL tag support independently, without
>>>> having to set up a servlet.
>>>>     By the way, this might be a byproduct of spring mvc framework
>>>> integration probably.
>>>
>>> The JavaDoc of freemarker.ext.jsp.TaglibFactory says: "It can be added
>>> to custom servlets as well to enable JSP taglib integration in them as
>>> well." So at least at some point in the past that was an intent. It
>>> should be piloted out if it indeed works, and maybe an example should
>>> be added where it's applied.
>>
>> IIRC, it seemed difficult to do. But I can try it later again. I'll let
>> you know later.
>
> 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

>
>>>> I think this is it for now. :-)
>>>
>>> So it seems, a good place for contributions for Hippo is all these JSP
>>> integration stuff. This is where I'm weaker anyway... ;-)
>>
>> Yeah, and maybe (H)MVC integration things (Spring Framework, Struts2 for
>> instance).
>>
>>>
>>> And if someone at Hippo needs to do a hack to make FreemarkerServlet
>>> behave better, always consider if it could be part of
>>> FreemarkerServlet instead.
>>
>> Yeah, that's the right way to go. Agreed.
>>
>> Cheers,
>>
>> Woonsan
>


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

------------------------------------------------------------------------------
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Looking for contributors as part of Apache incubation

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]

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

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

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

--
Thanks,
 Daniel Dekany


------------------------------------------------------------------------------
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Looking for contributors as part of Apache incubation

Daniel Dekany
In reply to this post by marijan milicevic
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


Wednesday, June 3, 2015, 10:46:01 AM, marijan milicevic wrote:

> Hi Daniel,
>
> On Mon, Jun 1, 2015 at 10:00 PM, Daniel Dekany <[hidden email]> wrote:
> 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
>
>
> Monday, June 1, 2015, 2:33:52 PM, marijan milicevic wrote:
>
>> 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.
>>
>> My apache "handle" is marijan (@apache.org) if you need more information.
>>
>> cheers
>> marijan
>>
>> PS:  I am one of the Woonasan colleagues
>>
>>
>> Daniel Dekany wrote
>>> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Looking for contributors as part of Apache incubation

Woonsan Ko
In reply to this post by Daniel Dekany
On 6/3/15 5:18 PM, Daniel Dekany wrote:
> The contentType matter... thanks for looking after these! So then,
> FreemarkerServlet surely should set the HttpServletResponse
> contentType when it's still null. OTOH there should be an option to
> only set it then (if it's not null), not always as it happens now. So
> then the "ContetType" init-param remains as is, and we add a new
> init-param, "OverrideResponseContentType" (better name?), whose
> default is true for backward compatibility, but this default can be
> changed to false by extending FreemarkerServlet. WDYT?

That sounds like a plan!

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

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

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

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

Cheers,

Woonsan

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


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

------------------------------------------------------------------------------
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Looking for contributors as part of Apache incubation

Daniel Dekany
In reply to this post by Wong, Christopher-2
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


Tuesday, June 2, 2015, 5:12:52 PM, Wong, Christopher wrote:

> 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:[hidden email]]
> Sent: Saturday, May 30, 2015 6:21 AM
> To: [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Looking for contributors as part of Apache incubation

Wong, Christopher-2
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:[hidden email]]
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


Tuesday, June 2, 2015, 5:12:52 PM, Wong, Christopher wrote:

> 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:[hidden email]]
> Sent: Saturday, May 30, 2015 6:21 AM
> To: [hidden email]
> 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.

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Looking for contributors as part of Apache incubation

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.


Wednesday, July 1, 2015, 10:25:34 PM, Wong, Christopher wrote:

> 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

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?

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

> - replace specific elements with something else (takes advantage of begin/end line/column properties)

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

> 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:[hidden email]]
> 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
>
>
> Tuesday, June 2, 2015, 5:12:52 PM, Wong, Christopher wrote:
>
>> 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:[hidden email]]
>> Sent: Saturday, May 30, 2015 6:21 AM
>> To: [hidden email]
>> 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

--
Thanks,
 Daniel Dekany


------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Looking for contributors as part of Apache incubation

pgachina.ibm@gmail.com
In reply to this post by Daniel Dekany
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Looking for contributors as part of Apache incubation

Daniel Dekany
Hello,

Please come over to [hidden email] 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


Friday, October 30, 2015, 2:26:58 PM, [hidden email] wrote:

> 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


------------------------------------------------------------------------------
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
12
Loading...