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