Re: [Freemarker-devel] What is the most urgent?

[Jonathan R. <jre...@te...>]

On Friday 31 May 2002 06:24 pm, you wrote:
> Friday, May 31, 2002, 12:28:33 PM, Jonathan Revusky wrote:
>
> [snip]
>
> > In any case, I think we should exercise some self-control and get our
> > docs in shape and put out a 2.1 before we add more features.
>
> [snip]
>
> I feel that everybody proposes couple of new fancy things here, while
> there are very basic problems with FM. To prevent misunderstanding:
> the problem is not that people tell new ideas, it is good. The problem
> is that I can't see the prioritized list of TODO-s here. We should
> concentrate on a few top problems only. If I had to write then TODO
> list right now, then I would write this:
>
> 1.
> We have no documentation! This is a deadly mistake as we know.

I think this is the thing to address now and once we have docs that are 
fairly complete and that don't lie, we should put out a 2.1 preview. I think 
that soon we should resume a pretty aggressive policy of frequent releases.

>
> 2.
> We are still unable to bring FM API to a stable state. Every new
> release brings incompatibility with the previous release? This is a
> very big problem. So I think we should plan ahead, and try to release
> 2.1 with a stable API. And this goes for FTL too.

Well, most of the API changes have been in things like TemplateCache and 
introducing the Configuration object. I don't consider that stuff to be a big 
deal. Anyway, I don't see those things as having any need to change very much 
after 2.1 goes final. There is also the fact that in things like 
SimpleHash.put("key", object) the object can be the underlying object, as 
opposed to being a wrapper, so it gets wrapped as a TemplateModel in lazy 
evaluation fashion. However, code written against the older API will still 
work.

The FTL changes involve having much stricter semantics (by default) but we're 
leaving in a backward compatibility mode.

I think that the overall situation is not too bad. I mean, I do not think it 
was that hard for people to upgrade from 1.x to 2.0, and they got a lot of 
new functionality. There could be a bit of pain going from 2.0 to 2.1, 
but we're introducing the lazy wrapping and soon, we'll put in the date/time 
stuff.

I mean, people may suffer some inconvenience in upgrading, but these are not 
minor improvements. Really FM1 -> FM2 was pretty much a revolution. 
And given that, I don't think the level of backward incompatibility was too 
bad. I mean, if we were causing a hassle and the user wasn't getting hardly 
anything in return, it would be a different story...

Anyway, the cup is more than half full. In any case, we'll put out a few 
preview releases of FM 2.1 before we label it final and people will be given 
fair warning that stuff is more subject to change than if it was a release 
that is labelled "final".

>
> 3.
> The number formatting (#{... ;...}) thing is in a sorry state. Also
> we have no date support. How can you write templates without these
> basic things?

Well, people managed to write templates with FM 1. And people also are 
managing to write templates with Velocity and WebMacro, and those tools (the 
tweedledum and tweedledee of the java templating space) are in a much more 
sorry state on this stuff. (Well, basically, you can't even say they're in a 
sorry state. They're not in *any* state wrt these issues, since they just 
don't address any of it.... :-)) 

So anyway, we've got a clear path of improvement on this from our end. 
The number formatting in place is a stopgap measure. I think getting the full 
localized number formatting (with scientific notation and the grouping of 
digits etcetera) as well as introducing a fully localized time/date 
functionality will be key pieces for a 2.2.

>
> 4.
> We can't define "custom fm elements". The function thing does
> something similar, but since it can't have a body, and since it does
> not supports by-name parameter passing (e.g.: <myElement color="red"
> width="2">...</myElement>), it is not too useful on this field.

I think that, at some point, in the coming releases, the <function..> 
construct is going to be made more powerful. I actually have various ideas on 
this. But I don't consider that to be so very urgent.

>
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
> _______________________________________________
> Freemarker-devel mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemarker-devel

-- 
Jonathan Revusky
--
Lead developer of FreeMarker http://freemarker.sourceforge.net/
Build robust web applications with the 
Niggle Web Application Framework http://niggle.org/
Available for Java/Internet Consulting