Ideas for some more non-BC changes in 2.4

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Ideas for some more non-BC changes in 2.4

Daniel Dekany
Here is a list of ideas regarding further non-backward-compatible
changes that may should be done in FreeMarker 2.4.

Substantial changes:

- Static ObjectWrapper and Configuration instances should be removed,
  or it must be ensured that they are read-only (property setters
  throw exception).
 
- Remove #{exp}

- Change the default of the simpleMapWrapper bean property of BeansWrapper
  to true.

- Default XPath engine is Jaxen

- Default charset should be ISO-8859-1, not file.encoding.
  (Maybe, like in FMPP, the special "host" encoding should be added.)

- I'm not sure if this still stands since the whole object wrapping
  facility was improved by Attila since when I have written this:
  The DefaultObjectWrapper is a inconsistent monster born by
  backward-compatibility and the practical need for the more powerful
  default wrapper. It should gone. BeansWrapper should be the default.
  However it should automatically wrap XML nodes (and it is kind of
  dirty).
 
Boring/cosmetic changes:
 
- Move f.t.u.Constant-s into the corresponding TemplateModel interfaces.
  More precisely, just deprecate the Constants class, and left it there
  for BC.
 
- Change the type of TemplateScalarModel.EMPTY_STRING to TemplateScalarModel.
  (user code needs only recompilation)
 
- Change the return type of getSettins() to Properties.
  (user code needs only recompilation)

--
Best regards,
 Daniel Dekany


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ideas for some more non-BC changes in 2.4

Daniel Dekany
[snip]

I also wonder if the Rhyno support is still experimental. Attila, do
you think it is OK to remove that marking now?

--
Best regards,
 Daniel Dekany


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ideas for some more non-BC changes in 2.4

revusky
In reply to this post by Daniel Dekany
Daniel Dekany wrote:
> Here is a list of ideas regarding further non-backward-compatible
> changes that may should be done in FreeMarker 2.4.
>
> Substantial changes:
>
> - Static ObjectWrapper and Configuration instances should be removed,
>   or it must be ensured that they are read-only (property setters
>   throw exception).

If our preferred usage is that people new them rather than using a
static one, then we can just state that and also just use @deprecated on
these things. I don't see so much first order gain to actual removal.

To be clear, if there is a real need to cause potential breaking of code
moving from 2.3 to 2.4 to improve the product, we'll do it, but offhand
I don't see the gain as sufficient.

>  
> - Remove #{exp}

I don't frankly see this as very high priority or anything. I mean, it's
of debatable value to actually remove it. There are bound to be at least
some existing templates that use this. I agree that we aren't really
encouraging this any more.

The only immediate advantage I would see would be if somebody is writing
templates for some kind of output format that uses #{, but that is not
so many people. The other advantage would be that this would eventually
free us to use the #{...} notation ourselves for some purpose or other.

But offhand, it seems sufficient to just stop mentioning it in the docs,
and people just won't use it any more...


> - Change the default of the simpleMapWrapper bean property of BeansWrapper
>   to true.

I don't have an opinion about this, but it is probably a good idea.
(Attila's view carries more weight.)

>
> - Default XPath engine is Jaxen

Ditto on this one. I don't have a strong opinion but it's probably a
good idea if you say it is.

>
> - Default charset should be ISO-8859-1, not file.encoding.
>   (Maybe, like in FMPP, the special "host" encoding should be added.)

Same comment as last one. :-)

>
> - I'm not sure if this still stands since the whole object wrapping
>   facility was improved by Attila since when I have written this:
>   The DefaultObjectWrapper is a inconsistent monster born by
>   backward-compatibility and the practical need for the more powerful
>   default wrapper. It should gone. BeansWrapper should be the default.
>   However it should automatically wrap XML nodes (and it is kind of
>   dirty).

I may be the only crazy person who thinks that the current thing makes
any sense. (And I recognize I'm biased because the thing is largely my
fault. :-)) Even then I'm wondering about whether it does make sense,
since I guess nobody else thinks so -- and that is kind of a warning
signal...(Attila, you, Chris, are all on the other side on this.)

The origin of this is in the idea that exposing POJO's by java
reflection is, though highly useful in many cases, still not quite
the.... archetype of FreeMarker templating and should be avoided if you
can. The archetypal usage is that you expose a tree of lists, hashes,
and scalars, and you reference that tree in a read-only manner to
display the stuff you need to display. (And implicitly, rather than
using java methods like list.size() or list.get(n) you use the pure FTL
of list?size and list[n]. In passing, this has the purely theoretical
advantage that, following this usage archetype, your template would work
in a future FM port to other languages. I grant that this is very
theoretical at this point... :-))

The SimpleXXX wrappers are thus pure list/hash/scalar FTL
implementations that are not based on java reflection. The thing about
beanswrapping everything, including what one could think of as the core
FTL types, is that it potentially makes the thing much more complex --
your list is an FTL sequence, but it is also, say, a java.util.ArrayList
under that, so you can write myList[0] or you can write myList.get(0).
Or you can write myList?size or myList.size() and so on.

That was the reasoning.... it all originates there... but whether it's
worthwhile maintaining this, I don't really know. The fact of the matter
is that the ability to expose POJO's to the template layer is such a
typical usage in practice, that, to treat java.util.List, java.util.Map,
and so on specially (at least by default) may actually be what
complicates things for people.

And that said (in the foregoing, I'm saying I don't really know)
DefaultObjectWrapper would probably still remain, since basically it
still checks whether something is a Jython object, or an XML W3C DOM
Node, and so on, and if, failing that, it's actually just a POJO that we
don't deal with specially, then we go to the BeansWrapper.

Well, actually, I'm thinking about this out loud, and, you know, the
fact that we treat java.lang.String, java.util.List, and so on specially
in a default config seems roughly as justifiable logically as the fact
that we treat org.w3c.Node or org.python.PythonObject specially in a
default configuration.

I am not 100% sure that any change to this will result in a better,
simpler, more coherent situation for the typical user. The fact is that
all this stuff has enough nuance and complexity in it that
irrespectively of what we do (or if we do nothing with this) it's going
to be difficult for somebody to really understand it fully. (Of course,
not fully understanding all this ObjectWrapper stuff does not, as a
practical matter, prevent people from doing a lot of useful work with
FreeMarker... :-))

>  
> Boring/cosmetic changes:
>  
> - Move f.t.u.Constant-s into the corresponding TemplateModel interfaces.
>   More precisely, just deprecate the Constants class, and left it there
>   for BC.

I don't care about this. If you think that's an improvement, go ahead.

>  
> - Change the type of TemplateScalarModel.EMPTY_STRING to TemplateScalarModel.
>   (user code needs only recompilation)

I guess so.

>  
> - Change the return type of getSettins() to Properties.
>   (user code needs only recompilation)

I don't think I care about this either. Go ahead.

>

Thanks,

JR


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ideas for some more non-BC changes in 2.4

Daniel Dekany
Saturday, April 21, 2007, 10:11:41 PM, Jonathan Revusky wrote:

> Daniel Dekany wrote:
>> Here is a list of ideas regarding further non-backward-compatible
>> changes that may should be done in FreeMarker 2.4.
>>
>> Substantial changes:
>>
>> - Static ObjectWrapper and Configuration instances should be removed,
>>   or it must be ensured that they are read-only (property setters
>>   throw exception).
>
> If our preferred usage is that people new them rather than using a
> static one, then we can just state that and also just use @deprecated on
> these things. I don't see so much first order gain to actual removal.
>
> To be clear, if there is a real need to cause potential breaking of code
> moving from 2.3 to 2.4 to improve the product, we'll do it, but offhand
> I don't see the gain as sufficient.

The idea of static config and wrapper is plain wrong. More than
unprofessional. Lame. Pile of... whatever. Hence, it should gone.
Imagine an application where multiple independently developed
components use FreeMarker (like the e-mail generator and the Web pag
generator and etc). Now if the developers of two or more of them were
so fallible as the inventor of this FM feature was, and they want to
use different values of any of the setting, then there *will* be a
problem, and of the magical kind (that we all hate the most, right?).
So, really nobody should use these static things. So then just what is
the point in letting anyone using them? When it is just wrong? Note
that these static things are deprecated for a long time.

>> - Remove #{exp}
>
> I don't frankly see this as very high priority or anything. I mean, it's
> of debatable value to actually remove it. There are bound to be at least
> some existing templates that use this. I agree that we aren't really
> encouraging this any more.
>
> The only immediate advantage I would see would be if somebody is writing
> templates for some kind of output format that uses #{, but that is not
> so many people. The other advantage would be that this would eventually
> free us to use the #{...} notation ourselves for some purpose or other.
>
> But offhand, it seems sufficient to just stop mentioning it in the docs,
> and people just won't use it any more...

Whatever... OK.

>> - Change the default of the simpleMapWrapper bean property of BeansWrapper
>>   to true.
>
> I don't have an opinion about this, but it is probably a good idea.
> (Attila's view carries more weight.)
>
>>
>> - Default XPath engine is Jaxen
>
> Ditto on this one. I don't have a strong opinion but it's probably a
> good idea if you say it is.

As you may remember, with Xalan's published API some important things
couldn't be implemented. However Jaxen was overly buggy. But since
then it got lot of fixes. Oh, and Xalan is Apache... ;)

>> - Default charset should be ISO-8859-1, not file.encoding.
>>   (Maybe, like in FMPP, the special "host" encoding should be added.)
>
> Same comment as last one. :-)

Then better if you and other understand why. The problem is that if
you move your application between different computers, then the
platform default encoding may changes, and the results are
surprises... the app works in this machine, but not on the other. Most
people just don't realize that they are using the host's default
encoding (because for example most machines will use ISO-8859-1). So
the default shouldn't change.

[snip]

--
Best regards,
 Daniel Dekany


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ideas for some more non-BC changes in 2.4

Daniel Dekany
In reply to this post by Daniel Dekany
Friday, April 20, 2007, 12:29:39 PM, Daniel Dekany wrote:

> - I'm not sure if this still stands since the whole object wrapping
>   facility was improved by Attila since when I have written this:
>   The DefaultObjectWrapper is a inconsistent monster born by
>   backward-compatibility and the practical need for the more powerful
>   default wrapper. It should gone. BeansWrapper should be the default.
>   However it should automatically wrap XML nodes (and it is kind of
>   dirty).

It seems I will have to eat my words on this. With BeansWrapper, a
String is wrapped as string+hash. Of course the hash part should not
be there for a plain string. And a List is wrapped as a string in
additional to as a sequence, etc.

BTW, I don't get this... why is List wrapped as string?

--
Best regards,
 Daniel Dekany


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ideas for some more non-BC changes in 2.4

Attila Szegedi
'Cause many folks wanted the ability to print them using ${list}...

Attila.

On Fri, 27 Apr 2007 12:59:55 +0200, Daniel Dekany <[hidden email]>  
wrote:

> Friday, April 20, 2007, 12:29:39 PM, Daniel Dekany wrote:
>
>> - I'm not sure if this still stands since the whole object wrapping
>>   facility was improved by Attila since when I have written this:
>>   The DefaultObjectWrapper is a inconsistent monster born by
>>   backward-compatibility and the practical need for the more powerful
>>   default wrapper. It should gone. BeansWrapper should be the default.
>>   However it should automatically wrap XML nodes (and it is kind of
>>   dirty).
>
> It seems I will have to eat my words on this. With BeansWrapper, a
> String is wrapped as string+hash. Of course the hash part should not
> be there for a plain string. And a List is wrapped as a string in
> additional to as a sequence, etc.
>
> BTW, I don't get this... why is List wrapped as string?
>

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Interpolation design doubts (Was: Re: Ideas for some more non-BC changes in 2.4)

Daniel Dekany
Friday, April 27, 2007, 6:52:43 PM, Attila Szegedi wrote:

> 'Cause many folks wanted the ability to print them using ${list}...

Well that's not enough in itself... like even more folks want
${nosuchvar} to silently print nothing, but they won't have that here.

Anyway, do people want the default formatting be for debugging?
Because something like "[1, 2, 3]" is very seldom useful for anything
else (assuming you seldom generate Python source code and like). This
indeed touches an interesting topic... basically all template
languages but FreeMarker uses "debug formatting" for interpolations
(like Object.toString()), and if you want to format something not like
that, then you have to specify the format explicitly, like
${format(var)} or something. I don't like this because I bet that most
template authors just print numbers and such like ${var}, so the
template output will be of lower typographical quality (like wrong
decimal point symbol used, no grouping, no rounding, etc), or in very
rare cases even misleading (like in Hungary 100.001 could be read as
hundred thousand one, rather than hundred and one thousandth). Now
unlike the other template engines, FreeMarker by default formats for
human audience (correct decimal point, grouping, rounding, etc). But
this creates another problem, that can be even more serious. If
somebody prints for "computer audience", like "var f = ${f}" (note the
comma instead of the dot), then the numbers can be malformed for that
audience. Like "var f = 3,14" (note the comma instead of the dot,
which is the format used in most European countries) is wrong, a
JavaScript syntax error. Other typical problem is the groupings
introduced in bigger integers, that also confuses parsers. And these
are now real functional problems, not just a typographical quality
problems like with the other template languages. I have added the ?c
built-in to address this problem, but I'm sure most people will forget
to use it. Everybody just writes ${var}, and then assumes that somehow
magically it will be formatter properly, but in fact only a human
being is able to tell what the proper formatting would be. So, what is
if someone goes fascist (and at this point me occurs for most readers
;)), and says that ${var} will print nothing but strings, others will
be "I can't decide alone how to format a <insertTypeNameHere>" error.
So for anything else, you must tell explicitly what format do you
want. I know it would be too radical for FreeMarker, but still, it's
an interesting template language design question. (Anyway, I think the
whole idea of interpolations in template languages doesn't make too
much of sense, but enough of my scandalous thoughts for this night.)

> Attila.
>
> On Fri, 27 Apr 2007 12:59:55 +0200, Daniel Dekany <[hidden email]>
> wrote:
>
>> Friday, April 20, 2007, 12:29:39 PM, Daniel Dekany wrote:
>>
>>> - I'm not sure if this still stands since the whole object wrapping
>>>   facility was improved by Attila since when I have written this:
>>>   The DefaultObjectWrapper is a inconsistent monster born by
>>>   backward-compatibility and the practical need for the more powerful
>>>   default wrapper. It should gone. BeansWrapper should be the default.
>>>   However it should automatically wrap XML nodes (and it is kind of
>>>   dirty).
>>
>> It seems I will have to eat my words on this. With BeansWrapper, a
>> String is wrapped as string+hash. Of course the hash part should not
>> be there for a plain string. And a List is wrapped as a string in
>> additional to as a sequence, etc.
>>
>> BTW, I don't get this... why is List wrapped as string?

--
Best regards,
 Daniel Dekany


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel