Anyone knows or can recommend any JSON templating framework that converts JSON output to HTML?
Gibson Tang
DKSG
can already spit out ready dom. Isn't it?
Andrew Ching
Anyway, one use is in thick clients. In order to minimize data exchange between the client and the server, only data (rather than the whole HTML) is sent, and the client then renders the HTML. This can lead to faster, more responsive interfaces, as well as allowing view logic to reside in the client side.
Meng Weng Wong
Tamas Herman
guys, do yourself a favor pls and forget this fucking backbone
for a weekend and start looking into angular finally!
it's gonna be v1.0 in a month probably.
the documentation is a bit out of sync w the very latest rc version,
but the basic approach haven't changed really.
it can save u from writing a loooot on boilerplate code, really.
now the 1 year anniversary of my 1st angular project is coming and
i have to say, i still love it, because it's so compact and so much
holds to the point.
here are some directions:
have a look at the todo example on http://angularjs.org/ (http://angularjs.org/#/)
but then start looking into the next generation here:
http://docs-next.angularjs.org/misc/started
then sign up to the mailing list and follow the jsfiddle examples they share.
those explain very well, how trickier things can be done, like intergartion w
jquery ui or jquery mobile and stuff like that.
or grab https://raw.github.com/sullerandras/SVG-Sequence-Diagram/master/index.html
then just open it from the local filesystem. it shows how can u generate svg dynamically.
u wont regret it, i can guarantee, just dont be afraid of it.
the mailing list reacts to questions within hours most of the time,
so practically u couldn't be stuck w it.
a major selling point of it its testability.
it was written in testability kept in mind all the way down.
--
tom
Tay Ray Chuan
> http://documentcloud.github.com/backbone/, but it might be much more than
> you need.
>
> Anyway, one use is in thick clients. In order to minimize data exchange
> between the client and the server, only data (rather than the whole HTML) is
> sent, and the client then renders the HTML. This can lead to faster, more
> responsive interfaces,
I concur with David, and question this. On client side, after
receiving the JSON, will have to parse JSON + generate HTML + render
in browser. Contrast it to receiving raw HTML which is just render in
browser. So it might not be better for "thin" clients which have poor
processing speed.
(I was about to suggest gzip compression to support the raw HTML case,
but compression can also be applied to JSON so no net advantage)
--
Cheers,
Ray Chuan