Re: Dependeny on javax.swing

Sunday, January 3, 2010, 6:03:48 PM, Jeremy Chone wrote:

> Hi Daniel, 
>
> Ok, make sense for the 2.3/2.4. 
>
> About the (foo.bar)!null, I might have missed something in 2.3. Can
> I have (foo.bar.user.name)!null and if any property in the chain is
> undefined/null it will return null?

Yes. (Except that 2.3 doesn't have the null keyword...)

Look at "Missing value handler operators" here:
http://freemarker.org/docs/dgui_template_exp.html#exp_cheatsheet

> If yes, then, my bad, somehow I
> missed this very cool 2.3 feature. 
>
> Jeremy, 
>
> On Sun, Jan 3, 2010 at 3:16 AM, Daniel Dekany <[email protected]> wrote:
> Friday, January 1, 2010, 7:29:05 PM, Jeremy Chone wrote:
>
>> Hi Daniel,
>>
>> Yes, I was talking about the "old 2.4."
>> (http://freemarker.org/docs-24pre1/versions_2_4_pre1.html). These
>> features set are very appealing for me, and I would definitely be
>> open to go through some pain to port my code over.
>
> However, even if we release that as GAE compliant, we still have to
> address the same issue in something that is almost backward compatible
> with 2.3... because most can't afford a migration to "old 2.4".
>
>> The biggest feature that would simplify my template code would be
>> the null support (right now I do some workaround with -1 and
>> ?is_number which is not very clean).
>>
>> Also, another one that does not seem to be in the 24pre1 is the
>> null-safe operator (?. null-safe )
>
> Doesn't (foo.bar)!null cover that kind of issue?
>
>
>> http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000047.html
>
>> Jeremy,
>>
>>
>> On Mon, Dec 28, 2009 at 8:32 AM, Daniel Dekany <[email protected]> wrote:
>> Monday, December 28, 2009, 4:37:26 PM, Jeremy Chone wrote:
>>
>>> I have seen that 2.4 faith is uncertain, but this could be a good
>>> milestone to break backward compatibility.
>>
>> You mean we should introduce this BC breaking in what is now called
>> FreeMarker 2.4? Unfortunately 2.4 is non-BC on several other ways, so
>> even if it would be ready for release right now, we still had to
>> address the issue for the 2.3.x users.
>>
>>> About the contact in Google, I can definitely introduce someone
>>> from the freemarker team to them, but I do not think I can be an
>>> effective mediator (given my limited understanding of the
>>> internals). Let me know if someone wants an introduction.
>>
>> Certainly that will be Attila. He is the one who wrote all the
>> BeansWrapper (reflection) stuff.
>>
>>
>>> Jeremy,
>>>
>>>
>>> On Mon, Dec 28, 2009 at 4:30 AM, Daniel Dekany <[email protected]> wrote:
>>> Monday, December 28, 2009, 12:07:31 PM, Guo Du wrote:
>>>
>>>> 2009/12/28 Daniel Dekany <[email protected]>:
>>>>>> javax.swing.tree.*, that'd be a start. As I said, something similar
>>> [snip]
>>>>> So can that be worked around in FreeMarker (and of so, with how much
>>>>
>>>> I have two concern for work around javax.swing.tree.* package reference.
>>>
>>> Note that above I referred to the reflection issue.
>>>
>>>> 1. Backword compatibility, we don't want break the stable release
>>>> stream in 2.3.X. Even NORMAL freemarker usecase won't be involved with
>>>> the swing.
>>>
>>> Since Java language is quite static (which I like in general but these
>>> are the situations where it clearly backfires), the only
>>> backward-compatible work-around I can imagine is to create a separate
>>> release for each FreeMarker version that specifically targets GWE. But
>>> that's not that easy for the *users* as it may sound, as components
>>> that were not written specifically for GWE may pull in "plain"
>>> FreeMarker via automated dependency management (Maven, OSGi, etc.). I
>>> know, at least ideally that can be overridden, but I guess the way we
>>> upset the least number of users is by breaking the backward compatibly
>>> promise in this case, and blame Google.
>>>
>>>> 2. The simple/safe way to get away from javax.swing.tree.* is to
>>>> duplicate the used classes/interface insides freemarker such as
>>>> freemarker.core.tree. It may have copyright concern to the source
>>>> code.
>>>
>>> I didn't look into this, but most certainly we will have to re-write
>>> these from scratch, only by looking at the javax.swing Java docs.
>>>
>>>> P.S. There are only 4 direct reference in freemarker 2.3.15, so not a
>>>> big deal to just copy them to freemarker :)
>>>> ./freemarker/template/Template.java:57:      import javax.swing.tree.TreePath;
>>>> ./freemarker/core/FreeMarkerTree.java:56:   import javax.swing.JTree;
>>>> ./freemarker/core/FreeMarkerTree.java:57:   import
>>>> javax.swing.tree.DefaultTreeModel;
>>>> ./freemarker/core/TemplateElement.java:57: import javax.swing.tree.TreeNode;
>>>>
>>>> -Guo
>>>>
>>>> ------------------------------------------------------------------------------
>>>> This SF.Net email is sponsored by the Verizon Developer Community
>>>> Take advantage of Verizon's best-in-class app development support
>>>> A streamlined, 14 day to market process makes app distribution fast and easy
>>>> Join now and get one step closer to millions of Verizon customers
>>>> http://p.sf.net/sfu/verizon-dev2dev
>>>> _______________________________________________
>>>> FreeMarker-user mailing list
>>>> [email protected]
>>>> https://lists.sourceforge.net/lists/listinfo/freemarker-user
>>>>
>>>
>>> --
>>> Best regards,
>>>  Daniel Dekany
>>
>> --
>> Best regards,
>>  Daniel Dekany
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Verizon Developer Community
>> Take advantage of Verizon's best-in-class app development support
>> A streamlined, 14 day to market process makes app distribution fast and easy
>> Join now and get one step closer to millions of Verizon customers
>> http://p.sf.net/sfu/verizon-dev2dev
>> _______________________________________________
>> FreeMarker-user mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/freemarker-user
>>
>>
>>
>
> --
> Best regards,
>  Daniel Dekany
>
>
>
>

-- 
Best regards,
 Daniel Dekany


------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev