Re: Deprecation in data model

Thursday, December 31, 2009, 1:49:53 PM, Ista Pouss wrote:

> 2009/12/31 Daniel Dekany <[email protected]>:
>> Wednesday, December 30, 2009, 3:57:36 PM, Ista Pouss wrote:
>>
>> As far as FreeMarker is concerned, yes, but it's always a question if
>> the framework your are using gives sufficiently low-level access to
>> FreeMarker... Anyway, if it does, since "term" is a top-level data,
>> you could use a custom TemplateHashModel implementation that does
>> this. (If are using a java.util.Map as the data-model root, you could
>> wrap it into your TemplateHashModel implementation just before passing
>> to the template.process call)
>>
>
> Yes my root data model is a Map, so You say I do something like
>
> template.process(new CustomTemplateHashModel(map), output);
>
> and, in my Custom...
>
> TemplateModel get(String key)
> {
>  if (deprecated(key))
>    System.out.println("Damned! Deprecated!");
>  return super.get(key);
> }
>
> Is it OK ?

Yes, something like that.

> But what's append if the deprecated term is, from root, thing in
> "foo.bar.thing" ?

The basic idea is that the TemplateModel that you return with
get(String) must also be of a custom class so that it will be aware of
the name (path) of its parent and also of the whole deprecation
checking thing. More precisely, using a custom class for the return
value is only required if (a) the returned value itself is a hash (so
it can create further TemplateModel-s; you want to monitor that) (b)
you are still on a path that can lead to a deprecated object.

As of the implementation... I would write a custom ObjectWrapper by
extending BeansWrapper or DefaultObjectWrapper (whichever you plan to
use). Then I would configure FreeMarker to use that wrapper
(Configuration.setObjectWrapper or the "object_wrapper" property).

What should the custom implementation do? I would override the
wrap(Object) method, which would just call super.wrap, except if the
object to wrap is an instance of com.yourcompany.MapWithDeprecations,
in which case it would wrap it with
com.yourcompany.DeprecationAwareTemplateHashModel.
DeprecationAwareTemplateHashModel would be the extension of the class
that the ObjectWrapper you extended normally uses for maps (so if
those have any fancy extra features, yours will have them too).

MapWithDeprecations would be something that extends HashMap class. You
would instantiate it somehow like "new MapWithDeprecations(dataModel,
deprecations)", and that's what you pass to Template.process. So I
simply made the deprecations the part of the data-model, and made the
ObjectWrapper be aware of that information. If somewhere you just pass
in a plain HashMap as the data-model, it will still work, only without
the deprecation warnings. (Or if you pass in a MapWithDeprecations,
but you are using a standard ObjectWrapper, it will still work, just
again without deprecation warnings. Robust...)

> Thanks.

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