The ${ } syntax used by the templates hinder with the expression evaluator syntax of the JSP 2.0 specification

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a simple JSP with the example shown in the trimpath homepage
2. Run the JSP on the server 
3. The data for the template elements will not be filled with the data

What is the expected output? What do you see instead?
The expected output should be as specified by the trimpath homepage.
Instead you will just see the regulat DOM elements and the data will be
truncated.

What version of the product are you using? On what operating system?
OS: Windows XP
JDK; 1.5
App Server: Sun App Server v9.1 (GlassFish V2 J2EE 5 
JSP Specification: 2.0

Please provide any additional information below.
Using HTML escape codes or the "\" seems to work for now in the JSP 2.0
specification.  Is there any effort to change this in the future as we are
planning to use JavaScript Templates in production shortly.

Original issue reported on code.google.com by mahi.set...@gmail.com on 4 Jan 2008 at 11:29

Attachments:

• index.jsp

[GoogleCodeExporter]

I got this too...

perhaps provide an alternate option for the $, maybe %,@, or #

Original comment by carlemueller on 25 Apr 2008 at 12:09

[GoogleCodeExporter]

I found a workaround, it was JSP-EL 2.0 f'ing with me. Do this in JSPs:

$<%="{x.output}"%>

Mwahahahahah. Scriptlets to the rescue!

Original comment by carlemueller on 25 Apr 2008 at 12:16

[GoogleCodeExporter]

Actually, $<%%>{x.output} would probably work too. 

Original comment by carlemueller on 28 May 2008 at 9:26

[GoogleCodeExporter]

Those are all clever workarounds.

Through luck I use '\' within view JSPs for java portlet development (jboss).

It looks pretty clean:
<!-- Define template partials for view -->
<textarea id="some_listing_jst" style="display:none;">
    <table>
     <tr><td>Some ID</td><td>Status</td></tr>
     {for m in matters}
         <tr><td> \${m.matter_id}</td>
         <td>\${m.status} <a href="#" id="some_detail_link\${m.id}"
class="some_detail_link">detail</a>
           <div id="some_detail_area\${m.id}">
           </div>
         </td></tr>
     {forelse}
         <tr><td colspan="2">No matters on record.</tr>
     {/for}
    </table>    
</textarea>

This is documented nowhere for JSP.  I believe it's commonly accepted escaping 
for
Java language itself.  I just tried it.

Original comment by kucerari...@gmail.com on 13 May 2009 at 2:54

[GoogleCodeExporter]

You're also better off developing in a SPADE-ish setup with a static 
representative
page --  Notepad++ editing the index.html and js source files,  reload page,  
etc. 
Then copy the JSTs to a temporary buffer for the global search and replace of 
"${"
with "\${",   then copying the stuff to the real application context,  into the 
JSP
for example.

That way you're in a fast lightweight dev loop most of the time,  and the 
temporary
buffer for replacement makes sure you don't confuse any JST syntax with the 
trimpath
templates.

For semi-round-trip:  if you do a lot of tweaks in the JSP and you want to take 
them
back the the SPADE env,  browser VIEW SOURCE will remove all the backslashes 
'\',  so
you can just copy/paste back into the SPADE env.

In practice when transitioning back into eclipse environment,  it'll will pick 
out
unbalanced tags in your templates,  if they crept in while in notepad++,   so 
that's
one of the things you may end up fixing in eclipse env.

Original comment by kucerari...@gmail.com on 16 May 2009 at 6:23

[GoogleCodeExporter]

If you need to make a case for your use of trimpath components in enterprise 
work...

Current JSP/Java/Spring/Portal dev is on the map here--jquery jettison:

http://www.infoq.com/articles/First-Cup-Web-2.0-Joel-Confino

Trimpath jst/query offer great drop-in support for their advanced dev model (the
optimized flow #2).   They are just nibbling on the edges,  whereas JST/query 
takes
you directly into LAMP-like programming right in the browser.  (Of course 
Javascript
is nicer and more versatile than PHP ;-)  They are still messing with DOM 
directly, 
no dom templates,  no SQL.   They also miss the further dev model of 
spade-like, 
where you can do most of your UI work in a single page with notepad++,  simply
refreshing a page in a local file.  Then later move your JST and other JS 
pieces into
slower less-interactive eclipse environment.

I intend to use perhaps the latest version of junction one step further,  to 
quickly
model a complex and custom enterprise provisioning app.

Original comment by kucerari...@gmail.com on 19 May 2009 at 1:30

[GoogleCodeExporter]

Just in case anyone runs into this post, a simple solution for this problem is 
to put your templates in a separate file (myTemplate.jst or whatever) and use 
the jsp:include standard action to include them in your main jsp. When you use 
jsp:include to load non-jsp content into a jsp it isn't evaluated by the JSP 
processor so your Trimpath expressions remain untouched.

Original comment by chad.lav...@gmail.com on 15 Jun 2012 at 2:18