Re: Tapestry and inline Handlebars.js
Thanks for the info on the parser. I'd be thrilled with that element for 5.4, because Client Side Templating is becoming more prevalent and I think it's something client developers will run into consistently. -- View this message in context: http://tapestry.1045711.n5.nabble.com/Tapestry-and-inline-Handlebars-js-tp5660756p5678532.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Tapestry and inline Handlebars.js
Agree that micro templating is getting more popular but the space is also evolving rapidly which makes it difficult to pick winners at the moment. Check out LinkedIn's take on this: http://engineering.linkedin.com/frontend/client-side-templating-throwdown-mustache-handlebars-dustjs-and-more and a very cool performance study comparing various Javascript templating systems: http://jsperf.com/dom-vs-innerhtml-based-templating. Kalle On Tue, May 1, 2012 at 10:27 AM, yazdog8 j...@paulsenweb.com wrote: Thanks for the info on the parser. I'd be thrilled with that element for 5.4, because Client Side Templating is becoming more prevalent and I think it's something client developers will run into consistently. -- View this message in context: http://tapestry.1045711.n5.nabble.com/Tapestry-and-inline-Handlebars-js-tp5660756p5678532.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Tapestry and inline Handlebars.js
fyi, on a similar topic In this month's linux journal digital magazine there's a wanky write up about blueprint, cass, scss - it's a poor write up, i wouldn't recommend buying the one issue for it. there will be a write up in that series next month on bootstrap - hopefully it is more enlightening. On 02/05/2012, at 4:20 AM, Kalle Korhonen wrote: Agree that micro templating is getting more popular but the space is also evolving rapidly which makes it difficult to pick winners at the moment. Check out LinkedIn's take on this: http://engineering.linkedin.com/frontend/client-side-templating-throwdown-mustache-handlebars-dustjs-and-more and a very cool performance study comparing various Javascript templating systems: http://jsperf.com/dom-vs-innerhtml-based-templating. Kalle On Tue, May 1, 2012 at 10:27 AM, yazdog8 j...@paulsenweb.com wrote: Thanks for the info on the parser. I'd be thrilled with that element for 5.4, because Client Side Templating is becoming more prevalent and I think it's something client developers will run into consistently. -- View this message in context: http://tapestry.1045711.n5.nabble.com/Tapestry-and-inline-Handlebars-js-tp5660756p5678532.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Tapestry and inline Handlebars.js
trsvax, Trying to implement this, but I'm getting an error along the lines of: Parameter(s) 'template' are required for com.beckon.app.components.widgets.script.ClientHtmlTemplate, but have not been bound. My java is limited, but it looks like it's expecting us to pass in a template? Should this be something along of the lines of @SupportInformalParameters so that if you pass in p:script/ it will take that as its template parameter? Also, it looks like this is just designed to not have a .tml? Not sure what I'm missing here. Thanks! -- View this message in context: http://tapestry.1045711.n5.nabble.com/Tapestry-and-inline-Handlebars-js-tp5660756p5677007.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Tapestry and inline Handlebars.js
Here's what I'm trying to pass in: t:widgets.script.clienthtmltemplate t:id=testTemplate p:script /p:script /t:widgets.script.clienthtmltemplate -- View this message in context: http://tapestry.1045711.n5.nabble.com/Tapestry-and-inline-Handlebars-js-tp5660756p5677026.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Tapestry and inline Handlebars.js
So DUHuser error! I was passing in a p:script and it was looking for p:template. Thanks for the help! -- View this message in context: http://tapestry.1045711.n5.nabble.com/Tapestry-and-inline-Handlebars-js-tp5660756p5677055.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Tapestry and inline Handlebars.js
The issue here is that Tapestry uses an off-the-shelf XML parser for
the templates. That affects how HTML-ish content is going to be
parsed and interpreted, and also affects who content that looks like a
Tapestry expansion (${ }) will be interpreted.
I can see adding a new special Tapestry element that is used to
delimit a portion of the template where expansions should by treated
as literal text. That could be added to 5.4.
I think a better interrum solution would be to create a component that
renders out the script type=text/template tag, and reads the
contents of a file to provide the inside content, using
MarkupWriter.writeRaw().
You could easily establish a naming convention so that the component
would automatically read the correct file by default, and perhaps add
some caching to ensure things are performant.
In other words, move the content that is not working properly inside a
Tapestry template outside of the template.
On Tue, Apr 24, 2012 at 11:44 AM, yazdog8 j...@paulsenweb.com wrote:
So...been experimenting more...and from the fine folks at Stack
Overflow...this solution for pulling HTML out of CDATA. Fine point, it has
to be CDATA and not the JS/CSS commented CDATA.
You will then have to unescape the content before compiling with
Handlebars.compile.
var
template=Handlebars.compile($(div/).html($('#entry-template').html()).text())
template({'title': 'New Title', 'body' : 'New Body'})
This actually seems to work, and the TML doesn't force validation.
One question though...as micro templating on the client side grows in
popularity, are we going to seriously have client side developers
consistently jump through this hoop to use Mustache, Handlebars, icanhaz,
etc? It seems like there's a better, more direct way, and one that doesn't
put the onus on the FE developer to find a way around rigid Tapestry
convention in order to do so.
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/Tapestry-and-inline-Handlebars-js-tp5660756p5662963.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Tapestry and inline Handlebars.js
Ah ... kind of looks like you figured this out a couple of hours ago.
Long day for me.
On Mon, Apr 30, 2012 at 5:33 PM, Howard Lewis Ship hls...@gmail.com wrote:
The issue here is that Tapestry uses an off-the-shelf XML parser for
the templates. That affects how HTML-ish content is going to be
parsed and interpreted, and also affects who content that looks like a
Tapestry expansion (${ }) will be interpreted.
I can see adding a new special Tapestry element that is used to
delimit a portion of the template where expansions should by treated
as literal text. That could be added to 5.4.
I think a better interrum solution would be to create a component that
renders out the script type=text/template tag, and reads the
contents of a file to provide the inside content, using
MarkupWriter.writeRaw().
You could easily establish a naming convention so that the component
would automatically read the correct file by default, and perhaps add
some caching to ensure things are performant.
In other words, move the content that is not working properly inside a
Tapestry template outside of the template.
On Tue, Apr 24, 2012 at 11:44 AM, yazdog8 j...@paulsenweb.com wrote:
So...been experimenting more...and from the fine folks at Stack
Overflow...this solution for pulling HTML out of CDATA. Fine point, it has
to be CDATA and not the JS/CSS commented CDATA.
You will then have to unescape the content before compiling with
Handlebars.compile.
var
template=Handlebars.compile($(div/).html($('#entry-template').html()).text())
template({'title': 'New Title', 'body' : 'New Body'})
This actually seems to work, and the TML doesn't force validation.
One question though...as micro templating on the client side grows in
popularity, are we going to seriously have client side developers
consistently jump through this hoop to use Mustache, Handlebars, icanhaz,
etc? It seems like there's a better, more direct way, and one that doesn't
put the onus on the FE developer to find a way around rigid Tapestry
convention in order to do so.
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/Tapestry-and-inline-Handlebars-js-tp5660756p5662963.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Tapestry and inline Handlebars.js
While I agree with you in spirit here my opinion. Sending not well formed XML to any web client is a bad idea and if you do it even by accident you are just asking for hours of grief. Using CDATA to work around this when needed is a small price to pay. Being able to use existing parsers is just icing on the cake. As far as supporting this out of the box I'd say it does a pretty good job there also. While I had to write a component it's only about 20 lines of code, easily reusable and hardly a workaround. The success of a framework should be judged on how easily is supports new features not by what's supported in the core. So others may disagree but I'd say valid XML .tml files is a feature that I would not be willing to give up and components were designed to solve exactly the problem you are having and do it quite well. BTW: thanks for posting this problem so I finally got around to solving mine. -- View this message in context: http://tapestry.1045711.n5.nabble.com/Tapestry-and-inline-Handlebars-js-tp5660756p5664686.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Tapestry and inline Handlebars.js
Tried several pre-compilation tricks as well, and it still renders things out as text, and I think that's a result of the CDATA being XML whereas that data is rendered and read differently in the browser. I have read Mr. Shipp's blog about JS and the 5.4 release. I would love to know more about his plans for HTML/JS templating and where HTML5 support is heading. Having everything rendered out as perfectly formed XML is great for tag completion and validation, but I think takes away some fundamental tool sets and uniqueness that HTML5 brings. And one of those is the ability to throw in content in a script tag that ignored by the browser. John Resig, the creator of jQuery covers it wonderfully here: http://ejohn.org/blog/javascript-micro-templating/ I'll quote this phase: /Quick tip: Embedding scripts in your page that have a unknown content-type (such is the case here - the browser doesn't know how to execute a text/html script) are simply ignored by the browser - and by search engines and screenreaders. It's a perfect cloaking device for sneaking templates into your page. I like to use this technique for quick-and-dirty cases where I just need a little template or two on the page and want something light and fast./ If the goal is to move to a more modern JS architecture, I would pose that having micro templating is crucial, and needs to be accounted for in Tapestry. Quite simply, forcing the client side developer into an XML style validation for this shouldn't be necessary. I'd love to see an option to flag the t:content as some type of script/other so that validation is turned off. -- View this message in context: http://tapestry.1045711.n5.nabble.com/Tapestry-and-inline-Handlebars-js-tp5660756p5662818.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Tapestry and inline Handlebars.js
So...been experimenting more...and from the fine folks at Stack
Overflow...this solution for pulling HTML out of CDATA. Fine point, it has
to be CDATA and not the JS/CSS commented CDATA.
You will then have to unescape the content before compiling with
Handlebars.compile.
var
template=Handlebars.compile($(div/).html($('#entry-template').html()).text())
template({'title': 'New Title', 'body' : 'New Body'})
This actually seems to work, and the TML doesn't force validation.
One question though...as micro templating on the client side grows in
popularity, are we going to seriously have client side developers
consistently jump through this hoop to use Mustache, Handlebars, icanhaz,
etc? It seems like there's a better, more direct way, and one that doesn't
put the onus on the FE developer to find a way around rigid Tapestry
convention in order to do so.
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/Tapestry-and-inline-Handlebars-js-tp5660756p5662963.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Tapestry and inline Handlebars.js
I'd create a component so you can do something like this t:handlebars id=entry-template p:template /p:template /t:handlebars Then use something like this to write out the script tag http://tapestry.1045711.n5.nabble.com/Getting-the-HTML-markup-string-from-a-RenderCommand-td5564418.html#a5565449 You still need the CDATA but I'd say the benefits of tml files being valid XML easily out weight the drawbacks. This way the tml file has more or less what you want and the client side should work just fine because you remove the CDATA on the server. -- View this message in context: http://tapestry.1045711.n5.nabble.com/Tapestry-and-inline-Handlebars-js-tp5660756p5663235.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Tapestry and inline Handlebars.js
On Tue, 24 Apr 2012 17:26:09 -0300, trsvax trs...@gmail.com wrote: You still need the CDATA but I'd say the benefits of tml files being valid XML easily out weight the drawbacks. Agreed. In addition, to support other formats besides XML, we would need to write a parser for it. Not easy, not quick. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Tapestry and inline Handlebars.js
Something like this was on my TODO list. I wanted to pass scripts via
p:script
/p:script
So here it is.
public class Handlebars {
@Parameter(required = true)
private RenderCommand template;
@Parameter(defaultPrefix = literal)
private String id;
@Parameter(defaultPrefix = literal)
private String type;
private Element wrappingDiv;
@BeginRender
RenderCommand beginRender() {
return new RenderCommand() {
public void render(MarkupWriter writer, RenderQueue
queue) {
wrappingDiv = writer.element(div);
RenderCommand renderCommand = new
RenderCommand() {
public void render(MarkupWriter
writer2, RenderQueue queue2) {
queue2.push(template);
}
};
queue.push(renderCommand);
}
};
}
@AfterRender
void afterRender(MarkupWriter writer) {
writer.end();
String html = wrappingDiv.getChildMarkup().
replaceAll(lt;, ).replaceAll(gt;,
).replaceAll(amp;,);
wrappingDiv.remove();
writer.element(script, type, type, id, id);
writer.writeRaw(html);
writer.end();
}
}
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/Tapestry-and-inline-Handlebars-js-tp5660756p5663469.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Tapestry and inline Handlebars.js
Thanks. I'll give it a shot and report back. I still think there has to be a better way to handle client side templating, and one that should be baked into the system. If 5.4 is going to support more MVC style JavaScript, this is going to get a lot of use. -- View this message in context: http://tapestry.1045711.n5.nabble.com/Tapestry-and-inline-Handlebars-js-tp5660756p5663478.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Tapestry and inline Handlebars.js
I'm trying to use handlebars.js to generate some DOM code on a file upload widget (so there is no going to the server for a generated TML file...just no need). There are two ways to do this...you can include the handlebars template on the page (faster, easier and non cacheable) as opposed to including a JS file (cacheable, you have to wait to download it). Here's my code: It sits inside a TML file that is called into the page as a component. My problem is this...Tapestry is validating this file, or at least attempting to validate this as a valid TML file. It has a problem with the line that has the TD tag with the #unless. Failure parsing template classpath:com/beckon/app/components/widgets/form/FileUploadQueue.tml: Element type td must be followed by either attribute specifications, or /. This is valid as far as handlebars is concerned. And in a script tag. I just can't for the life of me understand why it's exceptionally difficult to do modern JS like this in Tapestry without jumping through hoops to do something that conceptually should be fairly simple in any other environment. Am I being forced to move this into a JS file and include it because of this? Seems somewhat silly to me. Is there a parameter I can pass the t:content to not parse this? Has anyone encountered this problem before? Sorry to seem somewhat cranky, I just run into these problems frequently and it gets very frustrating. It would be nice if JS wasn't treated as such a second class citizen in this framework. -- View this message in context: http://tapestry.1045711.n5.nabble.com/Tapestry-and-inline-Handlebars-js-tp5660756p5660756.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Tapestry and inline Handlebars.js
First thought -- have you tried wrapping the javascript in a CDATA tag? There are some examples at http://en.wikipedia.org/wiki/CDATA On Mon, Apr 23, 2012 at 8:10 PM, yazdog8 j...@paulsenweb.com wrote: I'm trying to use handlebars.js to generate some DOM code on a file upload widget (so there is no going to the server for a generated TML file...just no need). There are two ways to do this...you can include the handlebars template on the page (faster, easier and non cacheable) as opposed to including a JS file (cacheable, you have to wait to download it). Here's my code: It sits inside a TML file that is called into the page as a component. My problem is this...Tapestry is validating this file, or at least attempting to validate this as a valid TML file. It has a problem with the line that has the TD tag with the #unless. Failure parsing template classpath:com/beckon/app/components/widgets/form/FileUploadQueue.tml: Element type td must be followed by either attribute specifications, or /. This is valid as far as handlebars is concerned. And in a script tag. I just can't for the life of me understand why it's exceptionally difficult to do modern JS like this in Tapestry without jumping through hoops to do something that conceptually should be fairly simple in any other environment. Am I being forced to move this into a JS file and include it because of this? Seems somewhat silly to me. Is there a parameter I can pass the t:content to not parse this? Has anyone encountered this problem before? Sorry to seem somewhat cranky, I just run into these problems frequently and it gets very frustrating. It would be nice if JS wasn't treated as such a second class citizen in this framework. -- View this message in context: http://tapestry.1045711.n5.nabble.com/Tapestry-and-inline-Handlebars-js-tp5660756p5660756.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Tapestry and inline Handlebars.js
I did, and the handlebars template returns the tags as text, so a ends up
being lt; entity.
One solution that seems to be working for me is this:
{{#if uploadOption}}
td
Click to add description
/td
{{else}}
td colspan=2
Click to add description
/td
{{/if}}
Essentially repeating the tag twice for the sake of having a closing tag.
Seems redundant an un-necessary, but this is the convention being forced.
It's also interesting to note that Tapestry's TML enforces the XHTML tag
closing when HTML 5 doesn't require it. Front end developers need more
options than this rigid enforcement out of the box, don't you think? I mean,
if you're going to support HTML5, then support it.
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/Tapestry-and-inline-Handlebars-js-tp5660756p5660830.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
