AW: [stringtemplate-interest] Top-Down automatic attributeaggregation?

[Dreyer Ulf (CR/APA3)]

Hi!


I've encountered some more problems along the way.

First as always the facts:

> > Ulf replied:
> > I think, I've worked it out. After looking closely at 
> > StringTemplate.cs I now create a tree structure of 
> > alternating Hashtables and ArrayLists

Hashtable[Att-Name_1, Att-Name_2, Att-Name_3]

Att-Name_1 = ArrayList[1,2,3,4]

An Attribute can be:
   An ArrayList containing either more Hashtables(deeper nesting) 
                               or a single String 

> > and put them into the root-templaty via rootTemplate.Attributes=XYZ
> > (this is a public r/w property in the c# implementation - I haven't
> > testet in Java)
[...]
> I'd suggest the SetAttribute() option simply because 
> SetAttribute() does
> more than just hook up an attribute map.

Now I use SetAttribute() - I think somewhere during my futile tries 
it didn't work with SetAttribute - I tried with the r/w-Property (which
probably
didn't work either) and then left it that way.

WHAT WORKS:

   Calling strictly hirarchical templates does work with this structure.

   With a datastructure of    Foo.Bar
			               .FooBar

    TemplateA(Foo) ::= << $Foo:TemplateB$ >>
    TemplateB()    ::= << $it.Bar$ ; $it.FooBar$ >>

   evaluates correctly.

PROBLEM:
   
    I now can NOT access the deeper nestings of the structure.
    With above structure the following access

    TemplateA(Foo) ::= << $Foo.FooBar$ >>

    gives me a
    "Class System.Collections.ArrayList has no such attribute: 
     FooBar in template context [TemplateA]"
    
    When calling subtemplates with parameters ST seems to 
    'ignore' the additional ArrayList-layer (resolving it as expected)
    but when accessing Foo.FooBar the ArrayList gets in the way.
    A Call to Foo.attributeList.FooBar also fails 
    attributeList is my (for testing public) member which holds
    the ArrayList. (it involves wrapping ArrayList and giving it
    an accessor which (called with the string that designates
    the AL in the parent Hashtable) returns a reference to itself (the
AL).
    This would of course be extremely bad style and introduce cycles 
    into the graph.)

 My Ideas of solving this dilemma are all VERY messy and (due to
 time restrictions) only ideas at this point.

So I have to ask: Has anyone any experience with this problem?
 Or do you Terence or Kunle have an idea to how a suitable data
 structure has to look?

 I don't have enough understanding of how ST gets its attributes
 from a given datastructure to figure out something better.

I fear to ask how this would work out referencing PARENT attributes
from sub-templates.

Kunle wrote:
> PS    The issue you reported has been fixed in the depot. 
> Thanks. I'll try
> and get something out to you.
Thanks a lot!