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

[Joseph Graham]

Hello Doug,
I am not disputing anything you say and in fact, spring-rich is "okay"
as far as swing development goes.  But rails principles adheres to those
which we hold near and dear such as "don't repeat yourself" (note:
spring-rich model, glazed lists model, jgoodies models) and "convention
over configuration (note: xml config files).  Let's get away from that
messy style of development and move on to what we know is already a
superior technology if from no other indicator than the critical mass of
followers.
Thank you very much for your reply and I do really appreciate your
opinion.

BR_joe

-----Original Message-----
From: rails-bounces at lists.rubyonrails.org
[mailto:rails-bounces at lists.rubyonrails.org] On Behalf Of Doug Douglass
Sent: Tuesday, January 31, 2006 4:40 PM
To: rails at lists.rubyonrails.org
Subject: Re: [Rails] Spring-rich killer: rails rich-client proposal

Joseph,

My first post here so take it easy on me :)

I come for the world of Java and have done a couple (smallish) 
spring-rich based projects. Here's just a couple of comments in no 
particular order:

* spring-rich/Java doesn't _have_ to be jar hell, just use the right 
build tool (ahem, maven, ahem, or ivy as that's what the spring project 
has appearantly chosen)

* spring/spring-rich configuration isn't _that_ bad, presuming they've 
finally documented some of the magic component names you need to provide

implementations of.

* for many application problems does Ruby/Rails+Ajax provide a better 
solution than thicker RCP? I've been quite impressed with the ease of 
using Ajax within Rails apps.

That said, I too have thought about how compelling a Rails/RCP framework

could be. There's always the tcl/tk bindings for GUI ;)

Cheers,
DD


Joseph Graham wrote:

>Hello,
>I wanted to put out a message to the rails list to see who else might
be
>interested in setting up a rails rich-client framework.  I am working
on a
>Swing project with spring-rich (not my choice) but it occurred to me
that
>the motivations behind going with spring-rich as a technology have
already
>been solved by the rails API.
>Some background on spring-rich, it basically takes the pluggable
framework
>"spring" and extends it to developing Swing (rich-client) desktop
>applications.  Some of the things the spring-rich framework brings to
the
>table are:
>1. IoC (Inversion of Control) containers (ala Struts or its own
>implementation)
>2. Data binding using whatever model you choose.  For example the data
>binding framework could enable you to select an item in a grid control
and
>which will fire a "rowSelected" type of event that will populate the
text
>fields (or wotever fields) on a detail form.
>3.  Business oriented events and hooks that allow you to implement
things
>like security, login, printing, and hooks to frameworks like reporting
>systems (ala Jasper reports).
>In short it allows you to build desktop application with all of the
widgets
>and speed that would bring to build data-bound, report-enabled
applications
>without dealing with all of the plumbing behind it.
>
>It occurred to me that Rails does these same things but does not have a
>desktop (native) GUI library that it can bind to, and I suppose nor
should
>it really.  However I think such a project would be a serious contender
(if
>not killer) of frameworks such as spring rich because of all the XML
>configuration and jar file hell that is part of the motivation behind
using
>rails in the first place for web applications.
>
>It seems that a project like this could accomplish the following:
>* Provide an abstract means to bind to one or more native GUI tookits
>* Provide a data binding mechanism to link controllers to GUI events
and
>link model objects to fields and GUI widgets.
>* Provide a stub to one or more reporting engines that would allow one
to
>send models from the GUI context to report templates.
>* Provide a client-specific plugin capabilities that would allow people
to
>implement plugins to solve domain specific problems such as login and
>authentication.
>* Integration with a  deployment strategy such as JNLP or some native
>installation mechanism (i.e. Super-pimp installer).
>
>Future or related projects could include designers such as GUI
designers and
>report designers and GUI component libraries.
>
>I know this is a long list but many feel that web applications are
simply
>not fast enough or powerful enough to solve certain problems that
native
>application features could provide.  I think that although it may sound
like
>re-implementing VB in RoR I think that the problem domain holds and the
>problems associated therein will remain.  If nothing else, let's help
those
>out who have to deal with frameworks like spring-rich.
>
>This is an initial poll to rally interest and see how many like-minded
souls
>are out there.  Please advise.
>
>Best Regards,
>Joe Graham
>Josgraha [at] gmail [dot] com 
>
>_______________________________________________
>Rails mailing list
>Rails at lists.rubyonrails.org
>http://lists.rubyonrails.org/mailman/listinfo/rails
>  
>


_______________________________________________
Rails mailing list
Rails at lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails