I have been working with Cells for a few weeks now, with great
success. A fellow Rubyist pointed this out to me,
http://github.com/sd/embedded-actions/wikis/home. It basically does
what Cells does -- in fact, it basically *is* render_component. It has
an advantage over Cells -- it does not require a new folder structure
for views and controllers. It uses the same controllers/actions/params
strategies as regular views, but you can embed views in views with
another controller action. Like I said, it is render_component reborn,
without requiring the Engines plugin, as Cells does.

Check it out. Let me know what you think. Really digging extjs as
well, just not quite sure how this all comes together best. I mean,
shouldn't the rich UI just be in Javascript, and the Rails back-end
provides services to the UI, including maybe some UI metadata? What is
the right separation of concerns, if you are not obsessed with
avoiding Javascript?

Best,
Mike Pence

Okay, I have a strong bias here.  I think it's ridiculous to fear
Javascript, and that people just create a whole new area of problems
for themselves by using tools written to avoid using js in order to
write js.

So, the way that I started using extjs with IOWA was to write all of
the front end client stuff directly with JS in static files, while
IOWA components, accessed via a REST interface, provided the ability
to query data, save data, etc....

Since then, I have taken it a step further, and am experimenting with
taking extjs widgets and writing IOWA components that will represent
one, writing the JS code for that widget, and excapsulating the state
(for ajax transactions between that widget's Store and the server)
within the component.  I still don't take any pains from insulating
one from js, apart from providing some convenience level configuration
via Ruby, and it's all very messy as I'm just tinkering, but it is an
approach that, IMHO, has promise.

Kirk Haines

Fear no JavaScript.

MVC was originally invented for GUIs. It's pretty much guaranteed that
at some point some people will switch to an MVC approach to GUIs which
preserves the "new" MVC of the Web while also sending templates out as
MVC JS. The advantage is you can send JSON to and from the server, so
essentially you've got Web MVC, but the so-called view is a
lightweight MVC app in JavaScript. First message from the server is a
controller and view; then you send some models, and after that,
everything the browser sends back to the server, or receives from it,
is a JSON model.

I'm reasonably confident that it's not an if, but a when; with the
caveat that it's also a "how many people?" The use cases are probably
not quite sufficiently sophisticated yet, but I did a failed
experiment in this area a couple years ago, and I could see successful
experiments with the same techniques happening today, especially in
the context of things like Flex and Air.

With this in mind, avoiding JavaScript is kind of silly, while
exploring these frontiers is an easy win. Even having a failed
experiment under my belt puts me ahead of the people who are going to
be surprised when it happens. Your worst-case scenario is an early
investment in something which will become more significant in the
future. I absolutely recommend this approach, with the caveat that
I've been too busy with my job, my acting classes, and my own
open-source projects, especially the auto-music-generator thing, to do
anywhere near a detailed investigation. I can't speak to the
implementation specifics but I'd bet the farm it's an approach worth
working on.

--
Giles Bowkett

Blog: http://gilesbowkett.blogspot.com
Portfolio: http://www.gilesgoatboy.org
Tumblelog: http://giles.tumblr.com
Podcast: http://hollywoodgrit.blogspot.com