Re: Additional Forbidden Methods

On Tue, Jul 15, 2008 at 10:02 AM, Attila Szegedi <[email protected]> wrote:
> I can think of two approaches here:

You know, I was thinking about this sort of thing recently and
probably this kind of thing should ultimately be addressed by
optionally using annotations to label that a certain method should (or
not) be exposed to the template layer.

Actually, I was even half wondering whether the interface-based
approach that freemarker uses (it was originally developed in early
1999, I think) would be used if the tool had been developed more
recently against JDK 1.5. It might well be that one would just use
annotations to indicate how objects are exposed to the template layer
and dispense with interfaces. It seems that would provide more
flexibility for defining semantics than just a marker interface.

In general, in the 2.4 release cycle, we might well look at using
annotations more aggressively for things like this.

JR

>
> 1. FreeMarker uses java.beans.Introspector to discover the methods and
> properties of objects to expose. You can implement a custom
> java.beans.BeanInfo descriptor for your class that doesn't list the
> getPassword method as part of the public bean interface. You can do it
> by creating a class named AccountBeanInfo in the same package as
> Account, subclassing SimpleBeanInfo and overriding
> getMethodDescriptors() and getPropertyDescriptors().
>
> 2. Think whether you really need a public getPassword() method on the
> Account. Maybe you could rework your code so that you have a
> getPassword() on an internal AccountImpl class, but for all public
> facets of your system, you proxy it through a publicly visible Account
> instance that doesn't have the getPassword() method and proxies the
> rest of the methods to the AccountImpl. That way, you hide
> getPassword() not only from FreeMarker but also from other parts of
> your system (or its users) that shouldn't see it.
>
> Attila.
>
> On Jul 14, 2008, at 9:23 PM, Alan Gutierrez wrote:
>
>> Attila
>>
>> Sorry, off doing other things. I'm very fond of Freemarker now. It is
>> working out well as the templating engine for my application.
>>
>> I'd like to be able to hand over my data model, but not expose all
>> the methods.
>>
>> public class Account
>> {
>>    public void getName();
>>
>>    public void getContactEmail();
>>
>>    public void getPassword();
>> }
>>
>> For example, I'd like to prevent the getPassword method from being
>> called.
>>
>> As it stands, I've mirrored my data model using Map instances,
>> exclusing those properties that ought to be excluded. I'm content
>> with this approach. However, exposing a method that would allow a
>> user to feed the method exclusion method additional methods strikes
>> me as a good idea.
>>
>> Alan
>>
>> On Jul 11, 2008, at 4:49 AM, Attila Szegedi wrote:
>>
>>> That's true -- we didn't anticipate this list being expandable. What
>>> methods would you want to prohibit?
>>>
>>> Attila.
>>>
>>> On Jul 8, 2008, at 4:14 AM, Alan Gutierrez wrote:
>>>
>>>> Continuing to develop an application that allows for user defined
>>>> templating.
>>>>
>>>> How do I add additional methods to the list of unsafe methods
>>>> defined
>>>> in BeanWrapper?
>>>>
>>>> From what I can tell, it is not possible, unless I create my own
>>>> unsafeMethods.txt resource, which does not look like something that
>>>> I'm supposed to do.
>>
>> --
>> Alan Gutierrez | [email protected] | http://blogometer.com/ | 504
>> 717 1428
>> Think New Orleans | http://thinknola.com/
>
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> FreeMarker-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/freemarker-user
>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/