[Rails] Spring-rich killer: rails rich-client proposal

[Ezra Zygmuntowicz]

On Jan 31, 2006, at 7:46 PM, Joseph Graham wrote:

> I am actually fairly familiar with XUL both as a standard and as an
> implementation (i.e. mozilla's XUL) and even know a little about XPCom
> (cross-platform COM).  Again I'm not trying to hold anyone's feet  
> to the
> fire on any particular technology.  But here are some of the issues  
> that
> would not come as "easy" as one might think with fullscreen- 
> mozilla, XUL
> and so-on.
> 1. nothing beats a well implemented native GUI toolkit for speed and
> responsiveness
> 2. native UI "affordances" such as "office-style toolbars", nice  
> looking
> context menus, dockable windows and so-on.
> 3. integration with native (deployed) platform such as email clients,
> personal information managers, system trays and other native
> notification systems or applications crucial to your users' business
> requirements
> 4. capability to communicate directly with subsystems on user's  
> desktop
> such as peripherals (i.e. cash drawers), and print spools.  A major  
> user
> complaint is that few things are more annoying than having to click
> "print" twice (i.e. print a grid view that has a print button or
> file->print in the toolbar that produces a standard report for that  
> grid
> but has to be generated as PDF then click print again).
>
> I am not trying to take away anything from the technical merits of the
> suggestions offered thus far.  But I think they are only part of the
> equation. The above list is just a few of the things that a rich- 
> client
> framework should set out to do.  It's all about convenience for the  
> user
> and to be fully convenient you have to get down and dirty with the
> native platform.  You can do this in a platform independent way.  Java
> has a lot of these issues solved with printing support and JDBC/ODBC
> bridges, JNI and so on.  Ruby has many of these features as well.
>
> Swing was designed to solve some of the problems that others have  
> solved
> with WX-Ruby, Ruby-Tk, Ruby-Cocoa, FX-Ruby and so on.  Spring-rich  
> sets
> out to produce a framework that removes a lot of the would-be  
> "exercises
> for the reader" such as handling events in an MVC sort of way,
> data-binding, pluggable widget support, status bars and many of the
> common things one would need in today's common, native business
> application.  I think the reason we are compelled to use approaches  
> such
> as "fullscreen-Firefox" is because rails has not been extended in  
> such a
> way to make it easy to do native applications (yet).  I am not saying
> these approaches do not make sense for certain problems yet the  
> problem
> domain I am addressing has a lot more things that fall into the scope
> besides just throwing a browser at the problem.  I think that if we  
> can
> agree on that we can move forward and make sound decisions in our
> implementation as did the developers of rails who in many ways had to
> anticipate our needs to minimize mistakes and redundancy.
>
> Thanks again for your time.
> BR_joe
> _______________________________________________
> Rails mailing list
> Rails at lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

Joseph-

	I have written a few custom applications using rubycocoa for the gui  
and ActiveRecord on the back end with my own custom controllers that  
don't deal with http but just deal with rubycocoa. Its quite a nice  
system to work with. Of course its not cross platform. I don't know  
if rails controllers that are tied to http and the request response  
cycle are the right concept for a native style app. I do like the  
idea of a nice ruby mvc framework with activerecord and a native app  
style controller and view.

	Please keep me informed if you start to write something like this.

Cheers-
-Ezra Zygmuntowicz
WebMaster
Yakima Herald-Republic Newspaper
ezra at yakima-herald.com
509-577-7732