What I've been doing lately is generating show/edit templates server side
and then pulling the html out of the dom with javascript on page load.
Something like this:
blah blah blah
Name:
Name:
$(document).ready(function(){
var templates = {
show: $('.show').rem
Except that with node.js, and I believe that's what you're talking
about when you mentioned JS on the server side, that would be entirely
possible, niceties of Haml included (or rather, intrincasies of
JS-based templating excluded).
http://github.com/creationix/haml-js
whereas I don't think that
On 08/12/2009, at 2:46 PM, Julio Cesar Ody wrote:
> Also Myles, your plugin is nice and Imma let you use it. I think
> though that a substantial amount of markup being maintained both
> through a JS-based templating language and server side is pants.
There's two solutions to that problem: don't d
On Tue, Dec 8, 2009 at 3:00 PM, Mark Wotton wrote:
> On Tue, Dec 8, 2009 at 2:57 PM, Craig Ambrose wrote:
>>
>> On Tue, Dec 8, 2009 at 2:40 PM, Lachlan Hardy
>> wrote:
>>>
>>> > Obviously it'd great if we could run ruby in the browser.
>>> Gestalt is pretty interesting:
>>> http://www.visitmix.c
> I think it's a good question. Certainly that's the technically easiest
> solution here. Javascript is a pretty cool language. It has lots of ruby
> like features. One major hangup for me is actually just the syntax. Bloody
> commas, semi-colons and curly brackets everywhere. Normally I'm not the
On Tue, Dec 8, 2009 at 2:57 PM, Craig Ambrose wrote:
>
> On Tue, Dec 8, 2009 at 2:40 PM, Lachlan Hardy
> wrote:
>>
>> > Obviously it'd great if we could run ruby in the browser.
>> Gestalt is pretty interesting:
>> http://www.visitmix.com/Labs/gestalt/
>
> That would be excellent indeed. I'm actu
On Tue, Dec 8, 2009 at 2:40 PM, Lachlan Hardy wrote:
> > Obviously it'd great if we could run ruby in the browser.
> Gestalt is pretty interesting:
> http://www.visitmix.com/Labs/gestalt/
That would be excellent indeed. I'm actually quite fond of javascript, but
see below.
> > I'm not quite wi
Because...
> Us rails folks do it on the server side, but that means we do suffer from a
> number of disadvantages
...I'd imagine. Not meaning to be offensive here. I know that's the
choice a lot of people make, and if it works for them, thumbs up.
Also Myles, your plugin is nice and Imma let y
> Obviously it'd great if we could run ruby in the browser.
Gestalt is pretty interesting:
http://www.visitmix.com/Labs/gestalt/
> I'm not quite willing to use javascript on the server side, not even for
> consistency's sake.
Why not?
--
You received this message because you are subscribed to t
Also: http://github.com/quackingduck/jquery.builder.js
On Tue, Dec 8, 2009 at 1:28 PM, Daniel N wrote:
> There's quite a few of these client side frameworks getting about now, along
> with renderers.
> sammy.js is prolly the one that sticks out most in my mind for a client side
> framework: http:
It's an interesting point. We don't really want to maintain two sets of
templates. Thus, we either tend to do our templating on the server side, or
the client side. Us rails folks do it on the server side, but that means we
do suffer from a number of disadvantages, the obvious one being our tendenc
That's an architecture discussion, and like every discussion of that
nature, there's many ways to skin this cat, all of which will give you
the expected result, with tradeoffs, minus of course the plain wrong
ones. The approach you pointed out with Prototype is fine in my
opinion, minus the Rails a
Getting the structured data out of the server response isn't really a
problem. The main question is, what handles that? Well, a function
obviously. Is this a function on an object? What does that object represent?
If it's some metaphorical page controller object, what level of abstraction
does it o
There's quite a few of these client side frameworks getting about now, along
with renderers.
sammy.js is prolly the one that sticks out most in my mind for a client side
framework: http://code.quirkey.com/sammy/
There's also haml rendering in javascript
server: http://github.com/creationix/haml-
JAML is a version of HAML in Javascript
http://github.com/edspencer/jaml
Josh
On 08/12/2009, at 1:20 PM, David Lee wrote:
> Gabe, thanks for the link. I think JS templating for jQuery is a great idea.
>
> Now if someone could just implement HAML in JS, it'd be impossible to render
> structura
Gabe, thanks for the link. I think JS templating for jQuery is a great idea.
Now if someone could just implement HAML in JS, it'd be impossible to render
structurally malformed HTML with a typo, and it'd tidy up a bunch of view
code...
On Tue, Dec 8, 2009 at 1:15 PM, Gabe Hollombe wrote:
> Late
if you want to use jQuery, you can specify with a get / post how you wish to
treat the returned values; if you specify 'json' you'll get just that; you
can also choose to eval it, render as HTML, etc. You could also fire events
(using the jQuery event model) when data is received and pass the json
Lately, I've had some similar thoughts myself, Craig. I've been using John
Resig's micro templates approach for outputting html from json data
structures, but I still have a somewhat unstructured approach to where/how I
include event handlers on my pages. So, my reply isn't too much help here,
oth
Hi folks,
I'm feeling the need for a bit of structure, like that provided like a
framework like rails, for the client side of my rails apps. I'm
finding that more and more I'm really disliking returning javascript
from rails requests. Doing so makes lots of assumptions about the page
that is makin
19 matches
Mail list logo
