[stringtemplate-interest] StringTemplate type proxies

[Rafael Chaves]

Just to be clear, I meant one would register the decorator factory,
not a single decorator.

In my implementation, it is up to the factory to decide whether to
wrap/decorate or not -  it may choose to return the object it got
"as-is" in some cases (i.e. not wrap it), for instance.

On Tue, Dec 14, 2010 at 12:22 PM, Rafael Chaves <rafael at alphasimple.com> wrote:
> Yeah, I'd rather register an instance instead of passing in a class
> and let ST instantiate it. That would address your concern about
> efficiency, but it is just better design IMO.
>
> On how to determine whether the wrapper should be activated, I'd hope
> it would be based on an "instanceOf" match instead of an exact class
> match (which is a grip I have with AttributeRenderer). I don't
> necessarily know the classes of the objects I am dealing with
> (implementation classes are often not exposed to clients of an API,
> but I will know some public class or interface), or may be interested
> in a hierarchy of classes. True, that leaves some room for multiple
> wrappers being interested in the same object, but you can decide based
> on order of registration (first or last to match wins) - for a single
> template, it is reasonable to assume there is only on party involved.
>
> Cheers,
>
> Rafael
>
> On Tue, Dec 14, 2010 at 12:06 PM, Terence Parr <parrt at cs.usfca.edu> wrote:
>> Ah! You are so correct! It only works on the values you pass through setAttribute. Ok, so the proposition is to simply add
>>
>> registerProxy(ModelType, MyProxyType)
>>
>> and have ST created new MyProxyType object with
>>
>> new MyProxyType(aModelTypeObjectAttribute)
>>
>> for each reference to a ModelType object? Won't that get inefficient? perhaps it should be like renderer and we  create a single object to wrap any object?
>>
>> $a.foo$ would invoke method MyProxyType.getFoo(a), right?
>>
>> Am  I going in the right direction?
>>
>> Ter
>>
>> On Dec 14, 2010, at 11:28 AM, Rafael Chaves wrote:
>>
>>> Yup, renderers translate from whatever values to String. The decorator
>>> (not a proxy, as it augments the shape of the target object) allows
>>> obtaining the values.
>>>
>>> This should apply at any level in the model graph, not only top level
>>> attributes. Does setAttribute handle that?
>>>
>>> For instance: Package has Classes with have Attributes. I set only one
>>> attribute on the top-level template, to be the root package object,
>>> and then navigate the graph with several templates (one for packages,
>>> one for classes, and another for attributes).
>>>
>>> Will overriding setAttribute allow me to intercept how any arbitrarily
>>> deep object is handled?
>>>
>>> Cheers,
>>>
>>> Rafael
>>>
>>> On Tue, Dec 14, 2010 at 11:16 AM, Terence Parr <parrt at cs.usfca.edu> wrote:
>>>> Very convincing argument, folks. thank you. 3rd party models.
>>>>
>>>> Ok, so how do they interact with renderers?  I guess the renderer is done *after* proxy stuff.
>>>>
>>>> Proxy: RandomModelObject -> MyWrapperForRandomModelObject, adds getFoo() or whatever.
>>>>
>>>> Then, if getFoo() returns type Date, renderer applies to that.  I like it.
>>>>
>>>> I remember mentioning how to do this manually. just override setAttribute() so that it traps RandomModelObject and wraps.
>>>>
>>>> Does this need to be formalized or can it simply be a FAQ entry?  it's a switch on type, look up in hashtable thing only right?
>>>>
>>>> Ter
>>> _______________________________________________
>>> stringtemplate-interest mailing list
>>> stringtemplate-interest at antlr.org
>>> http://www.antlr.org/mailman/listinfo/stringtemplate-interest
>>
>>
>