[antlr-interest] StringTemplate "reflection" enhancement

matthew ford Matthew.Ford at forward.com.au
Sat Sep 25 15:26:01 PDT 2004


WebStringTemplates Data Interface Defintion handles multi-valued attributes
and displays them as ordered lists.
The order number is for the reader's benifit only and in keeping with Ter's
philosophy the template can NOT reference items in
the list by index.
matthew

----- Original Message ----- 
From: "Terence Parr" <parrt at cs.usfca.edu>
To: <antlr-interest at yahoogroups.com>
Sent: Sunday, September 26, 2004 8:20 AM
Subject: Re: [antlr-interest] StringTemplate "reflection" enhancement


> Ok, I just found an objection.  $x.y$ currently looks up y in the
> attribute table of x if x is a ST.  This is consistent with the use of
> $super.attribute$ and $super.templateRef()$.  Hmm...so $self.name$
> doesn't work: it looks for attribute name in the attribute list not
> getName() in ST self.  Argh!!!!
>
> Any suggestions?  I don't want to make self special obviously and
> behave differently than any other reference to a template variable.
>
> Perhaps we throw out self and use just a plain attribute reference that
> is special like $attributes$, which you could then walk with ST.  The
> negative is that it would unnecessarily expensive to compute
> "attributes" and have it laying around all the time.   Perhaps it's
> only available in "lint mode", which already exists?
>
> $attributes:{Name: $it.name$ Type: $it.type.name$
> Properties:$it.properties$}$
>
> Also, what if a an attribute is multi-valued?  Before I had this:
>
> > Name: user
> > Type: org.foo.MyUser
> > Properties: name, email, address, phone
>
> but what if it's really say 2 users:
>
> Name: users
> Type: org.foo.MyUser
> Properties: name, email, address, phone
> Type: org.foo.MyUser
> Properties: name, email, address, phone
>
> oh, i guess ST would handle that automatically with template
> application.
>
> Now, what about properties that have properties.  For example,
>
> Name: student
> Type: org.foo.Student
> Properties: name, school, ID
>
> where school property is actually an aggregate with properties too or
> worse a ST itself?  You must recurse.  Since this could go 10 levels
> deep, I'm not sure if it's worth digging down into subproperties of
> subproperties etc...
>
> Ter
>
> On Sep 25, 2004, at 1:31 PM, Terence Parr wrote:
>
> > Howdy,
> >
> > When debugging templates particularly for web pages with lots of nested
> > templates, printing out the list of attributes you've set with
> > setAttribute() is pretty handy.  You could, for example, display the
> > contents of all attributes at the bottom of a web page if in "debug"
> > mode.  So if you had set two attributes title (a simple string) and
> > user (a user-defined object), you might want this info:
> >
> > Name: title
> > Type: java.lang.String
> >
> > Name: user
> > Type: org.foo.MyUser
> > Properties: name, email, address, phone
> >
> > It shows the incoming data not the references in the template.
> >
> > Seems like this can be easily had by allowing templates to access the
> > list of attribute name/value pairs via a reflection method.  We'd want
> > this to be on-demand rather than computing a set of reflection
> > descriptors each time.  Rather than make a special attribute, we should
> > make it something like <self.attributes> which will on demand (when
> > rendered) call getAttributes() on "self" (the template object).
> >
> > <self.attributes> would return not the raw attribute data, but a
> > reflection object that describes the key/value pair.  That reflection
> > object would let you say:
> >
> > <self.attributes:{Name: <it.name> Type: <it.type.name> Properties:
> > <it.properties>}>
> >
> > Further you want to be able to be able to recursively walk down to
> > embedded templates and get those attributes.  You'd probably want a
> > flattened list of all attributes for any particular page.  Perhaps that
> > requires <self.embedded> or <self.children> so you can use
> > StringTemplate to walk down to those templates. :)
> >
> > All I have to do is set "self" to be a predefined attribute pointing to
> > the surrounding template "this" pointer and all this will just work.
> > <self.name> etc... will just work as they are getXXX methods already
> > defined.
> >
> > Hmm...anybody have any suggestions or problems with this approach?
> >
> > Thanks,
> > Ter
> > --
> > CS Professor & Grad Director, University of San Francisco
> > Creator, ANTLR Parser Generator, http://www.antlr.org
> > Cofounder, http://www.jguru.com
> > Cofounder, http://www.knowspam.net enjoy email again!
> >
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> --
> CS Professor & Grad Director, University of San Francisco
> Creator, ANTLR Parser Generator, http://www.antlr.org
> Cofounder, http://www.jguru.com
> Cofounder, http://www.knowspam.net enjoy email again!
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>



 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/antlr-interest/

<*> To unsubscribe from this group, send an email to:
    antlr-interest-unsubscribe at yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 



More information about the antlr-interest mailing list