Rails - Feb 2006 - Spring-rich killer: rails rich-client proposal

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@lists.rubyonrails.org
[mailto:rails-bounces@lists.rubyonrails.org] On Behalf Of Doug Douglass
Sent: Tuesday, January 31, 2006 4:40 PM
To: rails@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@lists.rubyonrails.org
>http://lists.rubyonrails.org/mailman/listinfo/rails
>  
>

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

Hello,
I am not trying to suggest any particular technologies as yet as I''m
more just trying to see who would be interested in such a project.  If I
can get enough interest (i.e. more than myself) I will go along with
anything anyone suggests but I think the technical aspirations of such a
project are important and am ready to sharpen my elbows as such.
BR_joe

-----Original Message-----
From: rails-bounces@lists.rubyonrails.org
[mailto:rails-bounces@lists.rubyonrails.org] On Behalf Of Jon Smirl
Sent: Tuesday, January 31, 2006 5:52 PM
To: rails@lists.rubyonrails.org
Subject: Re: [Rails] Spring-rich killer: rails rich-client proposal

Build the front end with XUL runner
http://developer.mozilla.org/en/docs/XULRunner

XULRunner is a single "gecko runtime" installable package that can be
used to bootstrap multiple XUL+XPCOM applications that are as rich as
Firefox and Thunderbird. It will provide mechanisms for installing,
upgrading, and uninstalling these applications.

Build the back end with RoR and WEBrick and run it on the local
machine. Use HTTP to talk to it.

The big advantage to XUL runner is that a year from now Firefox will
be a XUL runner app too.  That means that anyone who is running
Firefox will already have your GUI run-time installed.

On 1/31/06, Joseph Graham <jgraham@majikoz.com>
wrote:
> 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).
You can already get all of this with XUL runner. Note that the
components in XUL ( http://xulplanet.com/references/objref/ ) can be
controlled by any language with XPCOM bindings. That includes C, C++,
Javascript, Java, Python. You don''t have to build everything with
Javascript.

You could even use Ruby to control XUL if someone wrote the XPCOM
bindings for it. It''s not very hard to do. It looks like someone has
already started: http://rbxpcom.mozdev.org/

--
Jon Smirl
jonsmirl@gmail.com
_______________________________________________
Rails mailing list
Rails@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails

On 1/31/06, Joseph Graham <jgraham@majikoz.com>
wrote:
> Hello,
> I am not trying to suggest any particular technologies as yet as
I''m
> more just trying to see who would be interested in such a project.  If I
> can get enough interest (i.e. more than myself) I will go along with
> anything anyone suggests but I think the technical aspirations of such a
> project are important and am ready to sharpen my elbows as such.
> BR_joe
You don''t need to do anything to XUL runner if you don''t mind
writing
the front-end scripts in Javascript/C/C++. Set Ruby up as a server
with WEBrick and use XUL to talk to it with http. XUL is like HTML but
with more controls available. Handle the XUL events with Javascript
and you can start writing your app tomorrow. Optionally, if instead
you want to script the XUL using Ruby, you need to get Ruby XPCOM
bindings working.

Mozilla Foundation is converting Firefox to run on XUL runner. It is
scheduled to be released about a year from now. The work is already
underway so it the conversion is going to happen for sure. You don''t
need to do anything on the Firefox project the Mozilla staff is doing
all the work. The advantage to you is that a year from now everyone
who installs Firefox is also installing the XUL runner run-time. That
means there is a lot less to install for your app.

--
Jon Smirl
jonsmirl@gmail.com

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

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@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@yakima-herald.com
509-577-7732

On 1/31/06, Joseph Graham <jgraham@majikoz.com>
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
Nothing beats the amount of code and effort needed to implement this
either. I have been involved with apps containing close to a million
lines of GUI code.
> 2. native UI "affordances" such as "office-style
toolbars", nice looking
> context menus, dockable windows and so-on.
If cross platform doesn''t matter then build a Windows specific app.
You''d be better off writing it in dotNET than Ruby. dotNET has all of
the Windows OS wrapped in convenient APIs.
> 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
This varies all over the map. I use gmail, how are you going to
integrate with that? Note that you can write your own XPCOM components
in C. C code can get to any integration library provided by the other
apps.
> 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).
Write XPCOM components to do this. Use XUL code to call the
components.
>
> 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
Read the Ruby mailing list. People are making wrappers for OpenGL and
other GUI libs. Rails is really oriented around paged displays and the
REST model. Some things don''t fit into this model - you can''t
write a
CAD/CAM app using RoR.
> 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.
The browser model gives you something that the other don''t  The
browser can run in three configurations. Thin client, thick client and
standalone. Thin client uses something like VNC or X for the display.
Thick client runs the browser and support components locally and the
server remotely. Standalone runs the client and server on the same
machine.

With XUL you don''t have to be limited to what is available in a normal
browser. With XUL you can create your own components both visual and
invisible.

You really need to consider the parameters of what you are building....
Is it only Windows standalone - use dotNET
Is REST model important, with lots of anonymous network users - use RoR
You want RoR but browser UI isn''t good enough - use RoR + XUL
Crossplatform and standalone - Ruby + wxWidgets
Windows only on highly available local net - dotNET again
CAD/CAM - OpenGL + C for speed
Game - direct X for widest platform availability

--
Jon Smirl
jonsmirl@gmail.com

This is a slight tangent to the thread here, but has anyone come up
with a decent way to obfuscate (or distribute as a binary) a rails
application bundled with WEBrick?

I''m looking to productize a rails app, but my concern is distributing
the source out so that it''s easily copied. Ideally I would like to
distribute it as a compiled executable, though still use browsers as
the client.

On 1/31/06, Ezra Zygmuntowicz <ezra@yakimaherald.com>
wrote:
>
> 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@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@yakima-herald.com
> 509-577-7732
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

On 2/1/06, Theodore Mills <twmills@gmail.com>
wrote:
> This is a slight tangent to the thread here, but has anyone come up
> with a decent way to obfuscate (or distribute as a binary) a rails
> application bundled with WEBrick?
>
> I''m looking to productize a rails app, but my concern is
distributing
> the source out so that it''s easily copied. Ideally I would like to
> distribute it as a compiled executable, though still use browsers as
> the client.
Distribute the app open source and charge for
upgrades/integration/customization. You will be surprised at how many
improvements your customers will send back to you.

I am much happier now that the majority of software I run is open
source. I used to really, really hate trying to debug broken apps 
with a moron on the support call (that means you Microsoft). Now I fix
the minor things myself and send the patch to the maintainer, or I pay
someone to make the changes I need.

Don''t focus so much on revenue from the initial sale. If you do, that
means you need marketing and a sales force which are expensive.
Instead focus on the secondary revenue of support, integration and
customization. People will find the app and come to you instead of you
having to spend a lot of money trying to get them to initially buy the
app. Another strategy is to focus on back end revenue such as monthly
fees for hosting and data storage.

There are probably a million apps in the graveyard because they tried
to sell the app and didn''t have the market/sales clout to get an
initial revenue stream going. I have three dead startups like that in
my past.

Don''t forget that most of your customers are not software developers.
They will choose to pay you to do upgrades/integration/customization
rather than doing it themselves. The key to success is ending up with
a lot of customers, not how much you can initially extract from them.

--
Jon Smirl
jonsmirl@gmail.com

Here''s some good advice for how to distribute a binary rails app on
Windows:

http://www.erikveen.dds.nl/distributingrubyapplications/rails.html

But it''s by no means hack-proof.  It just makes the app more convenient
to run.

Carl

On 2/1/06, Theodore Mills <twmills@gmail.com>
wrote:
> This is a slight tangent to the thread here, but has anyone come up
> with a decent way to obfuscate (or distribute as a binary) a rails
> application bundled with WEBrick?
>
> I''m looking to productize a rails app, but my concern is
distributing
> the source out so that it''s easily copied. Ideally I would like to
> distribute it as a compiled executable, though still use browsers as
> the client.