[stringtemplate-interest] Does StringTemplate support components?

[Bill Venners]

Hi Terence,

On Jan 2, 2007, at 3:25 PM, Terence Parr wrote:

>
> On Dec 27, 2006, at 4:45 PM, Bill Venners wrote:
>> So why not let each component keep track of its own data and
>> templates, and do the rendering of itself. What I'd need in ST is a
>> way to call render() on components I suppose, and I don't believe I
>> have a way to do that in ST, because it would open up the possibility
>> of calling any arbitrary Java code.
>
> Hi Bill, sorry for the delay, I have been working like mad to finish
> the new ANTLR V3 book.
>
No problem. I look forward to your book. I just migrated a code  
generator from JavaCC to ANTLR 3 this weekend, and am working on  
migration one right now. ANTLR 3 is very nice.

> Can you just make the component answer toString()?

Yes, I can, and that solves the problem. It is probably premature  
optimization but the difference between toString() and render is  
simply that render takes a "Writer out" parameter. You mentioned you  
don't buffer up Strings, but inside the component's toString method,  
that's what we'd have to do, because we have to return the view of  
the whole component as one String. What I figured would be the  
"efficient" design up front would be to have ST check each object to  
see if it implements View (or whatever interface has the render 
(Writer) method whose semantics say it renders an ST template), and  
if so passes the Writer on down instead of calling toString(). The  
only difference is efficiency, and right now I'm not that worried  
about it.

>
>> The other thing that bugs me a bit is that I can't know at compile
>> time if I'm using a parameter in a template that doesn't exist in the
>> data.
>
> Yeah, that is annoying.
>
>> I'm tempted towards the JSP approach of taking some template
>> and translating it into print statements that could be called by the
>> render method of component objects. These would not compile if there
>> were naming problems.
>
> I have thought about a mode where STs could be translated to pure
> Java or whatever language.
>
Actually, in truth I don't care about the potential efficiency boost  
of compiling templates to Java code, and frankly I'm not sure there  
would be one. What I miss is type checking, and I already deployed a  
(minor) bug using ST because of that. One nice thing you do get with  
pre-compiling JSPs is that you find out at compile time if you  
mistyped an attribute name. But in truth again, I don't think I  
really care about type checking. I just care about *name* checking,  
and it doesn't have to be at compile time. It could be a test. I am  
planning on specifying "view" components in a DSL, and I am going to  
explore to what extent I can automatically generate name check tests  
for the templates that render each particular view. (I'm worried  
about this in particular because we want each component to be able to  
have multiple templates for different themes and locales.)

>> I know that Terrence came to the design of ST while solving real
>> problems of web pages and code generation. Is there any reason why
>> doing such a component approach might be less useful in practice than
>> the ST approach?
>
> The only issue is that you're using real code, which opens up the
> potential for abuse.    Templates can't be extended with us all sorts
> of functionality whereas the component could be.  Further, components
> can't be used by graphics designers-- they have to be programmers to
> understand code.
>
Well, I think the crux of the difference in my mind is simply do I  
call ST once per page and ask it to render a template, or once per  
page plus let each component on the page call ST to render itself.  
You're right that you can't control what someone does inside the  
render(Writer out) method, but as you mention in one or two of your  
papers about ST, you really can't control what people do inside  
toString() either. I'm going to be generating these render methods,  
and the only thing they will be doing is creating a StringTemplate,  
setting its attributes, and rendering the template to the Writer  
passed to render. The toString method will call render with a  
StringWriter, and that will work for now. If I actually have a  
performance problem, I'll deal with it then.

Thanks.

Bill
----
Bill Venners
President
Artima, Inc.
http://www.artima.com