<div dir="ltr"><br><br><div class="gmail_quote">On Sat, Aug 16, 2008 at 12:45 PM, Ian Tegebo <span dir="ltr"><<a href="mailto:ian.tegebo@gmail.com">ian.tegebo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><br></div>
After a friend had recommend jQuery, I've found I really like it but<br>
had been under the impression that I wouldn't be able to use Jemplate<br>
at the same time. </blockquote><div><br>No, Jemplate WILL COEXIST with any other javascript you may be running client side.<br>In fact, the latest Jemplate release has the option of using jQuery (or YUI) to perform<br>AJAXy stuff (get & post).<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">A second read of Rockway's Editable Addressbook in<br>
chapter 7 of the Catalyst book leaves me wondering how TT, Jemplate,<br>
and jQuery would best "get along". Is it the case that<br>
Catalyst::View::Jemplate exists to reduce HTML munging within<br>
client-side javascript?</blockquote><div><br>Jemplate in general exists for that purpose. The problem with doing heavy<br>HTML/UI-lifting browser-side is that you end up doing things like:<br><br> var html = '<div class="' + styleClass + '"><a href="' + uri ...<br>
<br>It quickly becomes unwieldy. Jemplate basically creates methods that do the above (and more).<br><br>The other option is to use a javascript templating system (interpolating and parsing in javascript? probably slow) or<br>
use a widget system that may not have the specific look & feel you're going for.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
If so, then is it correct to think of jQuery, Jemplate, and the<br>
Catalyst::Controller::REST interface as kind of a browser-side MVC?</blockquote><div><br>jQuery is a really nice way of manipulating DOM + some convenience functions: no MC<br>involved (*maybe* the V part)<br><br>Jemplate is just a templating system that plugs into javascript: again, no MC involved (just the V part)<br>
<br>I suppose you can think of C::C::REST as the data-layer for your model, but then you're still missing the Controller<br>aspect and a way of representing the Model in javascript.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
I'm imagining the REST calls through jQuery as accessing the "model"<br>
while qQuery serves as the controller via its selectors finally<br>
rendering its "view" through Jemplate.</blockquote><div><br>Sounds about right, but it's more like making API calls to your C::C::REST data-layer.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
BTW, it appears Catalyst::View::Jemplate broke after Jemplate >= 0.21<br>
changed the behaviour of Jemplate::runtime_source_code (see RT 35609,<br>
37813). What versions are you running?</blockquote><div><br>I'll try and take a look to at Jemplate and see what's going on. What you *can* do<br>is just do a Jemplate compile via a Makefile or something and then serve the Jemplate<br>
.js as you would any other javascript asset. <br><br>Rob<br></div></div><br></div>