I have been lurking on this list for a while and it is the only place I
can think of where I will get a succinct answer to a potentially
controversial topic. Any ideas or suggestions would be greatly appreciated.
I have an application that I inherited half-way through it''s initial
development. It is a java thin-client application (uses ULC
http://www.canoo.com/ulc/index.html) that sits in front of a JBoss J2EE
server. It is currently served as an applet through a browser.
Despite taking a *long* time to develop, it works quite well - once
it''s
loaded. I am now working on a new version which requires enhancements
such as internationalization. The ULC framework which you essentially
interact with like Swing is kind of *neat* but it''s very cumbersome. -
I
don''t think I have to sell the rich-java-client-is-slow-to-build
argument here.
The application is a business rule composer primarily for insurance
systems. Working with it involves dragging various constructs and
variables onto a "rule tree" (which makes up the decision structure).
There is a small java-style expression editor which handles both
decision evaluation (when in an "if" construct) or calculation when a
part of the "math statement" construct.
The "rule" gets saved to the database after it is built and is later
compiled into a java class which is deployed on the application server
for use by other parts of the system.
I need to make an architectural choice for version 2, here are the
requirements:
User:
*Must support drag & drop functionality*
-The client just has it set in their mind that drag & drop is the way to
convey building rules to non-techies
-The current app is this way and re-training everyone from scratch is
impractical
*Must be "slick"*
- This is something that is hard to describe, but the feeling it gives
you shouldn''t be hard to convey: If you have ever used OS X, written a
project in Rails or sat on a private beach with a good, cold beer -
you''ve got it. This means that flaky hacked javascript, an unresponsive
interface or lack of style is unacceptable.
Technical:
*Must be efficient to write and easy to maintain*
*Must function through recent web browsers*
-Safari, firefox, mozilla, IE 5.5+ (maybe stretch that to 6)
*Must be able to communicate with EJB layer*
-Since these calls are limited, proxying through a web service is
perfectly acceptable
My first thought was this:
ruby/rails
Prototype AJAX
xhtml javascript
I wrote a small "rule tree" builder/manager last night based off of
Thomas Fuchs'' amazing effects package. This package by the way, is very
slick - Thanks Thomas. Given the sheer volume of items and the
requirements for them to be repositioned as they''re dragged and dropped
is already however pushing the limits of the javascript. The changes
that would be required I don''t think would be beneficial to the package
out of the context of my application.
For those of you who have made it this far, thanks. I don''t want to
merely trade slow, reliable java UI development for buggy/hard to debug
javascript.
What are your thoughts?
Cheers, Simon.
--
Simon C. Wex
simon-CdwZJljFklGxC8Nw+8W25jKzEDxYleXD@public.gmane.org
519.679.7888
"There are 10 types of people in this world, those who understand binary,
and those who do not"
On Jun 22, 2005, at 3:41 PM, Simon C. Wex wrote:> I need to make an architectural choice for version 2, here are the > requirements: > > User: > > *Must support drag & drop functionality* > -The client just has it set in their mind that drag & drop is the > way to convey building rules to non-techies > -The current app is this way and re-training everyone from scratch > is impractical > > *Must be "slick"* > - This is something that is hard to describe, but the feeling it > gives you shouldn''t be hard to convey: If you have ever used OS X, > written a project in Rails or sat on a private beach with a good, > cold beer - you''ve got it. This means that flaky hacked javascript, > an unresponsive interface or lack of style is unacceptable. > > Technical: > *Must be efficient to write and easy to maintain* > > *Must function through recent web browsers* > -Safari, firefox, mozilla, IE 5.5+ (maybe stretch that to 6) > > *Must be able to communicate with EJB layer* > -Since these calls are limited, proxying through a web service > is perfectly acceptable > > > My first thought was this: > > ruby/rails > Prototype AJAX > xhtml javascript > > I wrote a small "rule tree" builder/manager last night based off of > Thomas Fuchs'' amazing effects package. This package by the way, is > very slick - Thanks Thomas. Given the sheer volume of items and the > requirements for them to be repositioned as they''re dragged and > dropped is already however pushing the limits of the javascript. > The changes that would be required I don''t think would be > beneficial to the package out of the context of my application. > > For those of you who have made it this far, thanks. I don''t want to > merely trade slow, reliable java UI development for buggy/hard to > debug javascript. > > What are your thoughts?HTML/Ajax ain''t for everything. It sounds like you ought to also investigate other solutions such as Laszlo (and Laszlo on Rails would be quite slick). Erik
I would look into Laszlo. It''s _very_ slick and allows you to connect to anything through SOAP/XML-RPC/REST so it might do the trick for you. It does support drag-and-drop and it is relatively easy to develop in. A very good option for very rich clients. Hope it helps, Adrian Madrid On 6/22/05, Erik Hatcher <erik-LIifS8st6VgJvtFkdXX2HpqQE7yCjDx5@public.gmane.org> wrote:> > > On Jun 22, 2005, at 3:41 PM, Simon C. Wex wrote: > > I need to make an architectural choice for version 2, here are the > > requirements: > > > > User: > > > > *Must support drag & drop functionality* > > -The client just has it set in their mind that drag & drop is the > > way to convey building rules to non-techies > > -The current app is this way and re-training everyone from scratch > > is impractical > > > > *Must be "slick"* > > - This is something that is hard to describe, but the feeling it > > gives you shouldn''t be hard to convey: If you have ever used OS X, > > written a project in Rails or sat on a private beach with a good, > > cold beer - you''ve got it. This means that flaky hacked javascript, > > an unresponsive interface or lack of style is unacceptable. > > > > Technical: > > *Must be efficient to write and easy to maintain* > > > > *Must function through recent web browsers* > > -Safari, firefox, mozilla, IE 5.5+ (maybe stretch that to 6) > > > > *Must be able to communicate with EJB layer* > > -Since these calls are limited, proxying through a web service > > is perfectly acceptable > > > > > > My first thought was this: > > > > ruby/rails > > Prototype AJAX > > xhtml javascript > > > > I wrote a small "rule tree" builder/manager last night based off of > > Thomas Fuchs'' amazing effects package. This package by the way, is > > very slick - Thanks Thomas. Given the sheer volume of items and the > > requirements for them to be repositioned as they''re dragged and > > dropped is already however pushing the limits of the javascript. > > The changes that would be required I don''t think would be > > beneficial to the package out of the context of my application. > > > > For those of you who have made it this far, thanks. I don''t want to > > merely trade slow, reliable java UI development for buggy/hard to > > debug javascript. > > > > What are your thoughts? > > HTML/Ajax ain''t for everything. It sounds like you ought to also > investigate other solutions such as Laszlo (and Laszlo on Rails would > be quite slick). > > Erik > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Adrian Esteban Madrid aemadrid-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
I had never heard of Laszlo until now, I briefly considered developing directly in flash *shudder* and quickly shunned that from my mind. I definitely get that *slick* impression, it even has a plugin for eclipse. I certainly came to the right spot. I will still be using ruby/rails as the configuration/administration interface and I may use it for some of the live app, though much of the functionality is already written in java which is supported by Laszlo. I will update you all on how it turns out. Thanks Erik and Adrian. Cheers, Simon. Adrian Madrid wrote:> I would look into Laszlo. It''s _very_ slick and allows you to connect > to anything through SOAP/XML-RPC/REST so it might do the trick for > you. It does support drag-and-drop and it is relatively easy to > develop in. A very good option for very rich clients. > > Hope it helps, > > > Adrian Madrid > > On 6/22/05, *Erik Hatcher* <erik-LIifS8st6VgJvtFkdXX2HpqQE7yCjDx5@public.gmane.org > <mailto:erik-LIifS8st6VgJvtFkdXX2HpqQE7yCjDx5@public.gmane.org>> wrote: > > > On Jun 22, 2005, at 3:41 PM, Simon C. Wex wrote: > > I need to make an architectural choice for version 2, here are the > > requirements: > > > > User: > > > > *Must support drag & drop functionality* > > -The client just has it set in their mind that drag & drop is the > > way to convey building rules to non-techies > > -The current app is this way and re-training everyone from scratch > > is impractical > > > > *Must be "slick"* > > - This is something that is hard to describe, but the feeling it > > gives you shouldn''t be hard to convey: If you have ever used OS X, > > written a project in Rails or sat on a private beach with a good, > > cold beer - you''ve got it. This means that flaky hacked javascript, > > an unresponsive interface or lack of style is unacceptable. > > > > Technical: > > *Must be efficient to write and easy to maintain* > > > > *Must function through recent web browsers* > > -Safari, firefox, mozilla, IE 5.5+ (maybe stretch that to 6) > > > > *Must be able to communicate with EJB layer* > > -Since these calls are limited, proxying through a web service > > is perfectly acceptable > > > > > > My first thought was this: > > > > ruby/rails > > Prototype AJAX > > xhtml javascript > > > > I wrote a small "rule tree" builder/manager last night based off of > > Thomas Fuchs'' amazing effects package. This package by the way, is > > very slick - Thanks Thomas. Given the sheer volume of items and the > > requirements for them to be repositioned as they''re dragged and > > dropped is already however pushing the limits of the javascript. > > The changes that would be required I don''t think would be > > beneficial to the package out of the context of my application. > > > > For those of you who have made it this far, thanks. I don''t want to > > merely trade slow, reliable java UI development for buggy/hard to > > debug javascript. > > > > What are your thoughts? > > HTML/Ajax ain''t for everything. It sounds like you ought to also > investigate other solutions such as Laszlo (and Laszlo on Rails would > be quite slick). > > Erik > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org <mailto:Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org> > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > -- > Adrian Esteban Madrid > aemadrid-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org <mailto:aemadrid-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > >------------------------------------------------------------------------ > >_______________________________________________ >Rails mailing list >Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >http://lists.rubyonrails.org/mailman/listinfo/rails > >-- Simon C. Wex Sr. Software Developer E-mail: swex-Qmhitw36OxM@public.gmane.org Web: <http://www.mccg.net> "There are 10 types of people in this world, those who understand binary, and those who do not"
Glad to help. Please do let me know how it turns out. I will be doing a Rails/Laszlo app in a couple of months so anything you find/learn will be apreciated. AEM On 6/22/05, Simon C. Wex <swex-Qmhitw36OxM@public.gmane.org> wrote:> > I had never heard of Laszlo until now, I briefly considered developing > directly in flash *shudder* and quickly shunned that from my mind. > > I definitely get that *slick* impression, it even has a plugin for > eclipse. I certainly came to the right spot. > > I will still be using ruby/rails as the configuration/administration > interface and I may use it for some of the live app, though much of the > functionality is already written in java which is supported by Laszlo. I > will update you all on how it turns out. > > Thanks Erik and Adrian. > > Cheers, Simon. > > Adrian Madrid wrote: > > > I would look into Laszlo. It''s _very_ slick and allows you to connect > > to anything through SOAP/XML-RPC/REST so it might do the trick for > > you. It does support drag-and-drop and it is relatively easy to > > develop in. A very good option for very rich clients. > > > > Hope it helps, > > > > > > Adrian Madrid > > > > On 6/22/05, *Erik Hatcher* <erik-LIifS8st6VgJvtFkdXX2HpqQE7yCjDx5@public.gmane.org > > <mailto:erik-LIifS8st6VgJvtFkdXX2HpqQE7yCjDx5@public.gmane.org>> wrote: > > > > > > On Jun 22, 2005, at 3:41 PM, Simon C. Wex wrote: > > > I need to make an architectural choice for version 2, here are the > > > requirements: > > > > > > User: > > > > > > *Must support drag & drop functionality* > > > -The client just has it set in their mind that drag & drop is the > > > way to convey building rules to non-techies > > > -The current app is this way and re-training everyone from scratch > > > is impractical > > > > > > *Must be "slick"* > > > - This is something that is hard to describe, but the feeling it > > > gives you shouldn''t be hard to convey: If you have ever used OS X, > > > written a project in Rails or sat on a private beach with a good, > > > cold beer - you''ve got it. This means that flaky hacked javascript, > > > an unresponsive interface or lack of style is unacceptable. > > > > > > Technical: > > > *Must be efficient to write and easy to maintain* > > > > > > *Must function through recent web browsers* > > > -Safari, firefox, mozilla, IE 5.5+ (maybe stretch that to 6) > > > > > > *Must be able to communicate with EJB layer* > > > -Since these calls are limited, proxying through a web service > > > is perfectly acceptable > > > > > > > > > My first thought was this: > > > > > > ruby/rails > > > Prototype AJAX > > > xhtml javascript > > > > > > I wrote a small "rule tree" builder/manager last night based off of > > > Thomas Fuchs'' amazing effects package. This package by the way, is > > > very slick - Thanks Thomas. Given the sheer volume of items and the > > > requirements for them to be repositioned as they''re dragged and > > > dropped is already however pushing the limits of the javascript. > > > The changes that would be required I don''t think would be > > > beneficial to the package out of the context of my application. > > > > > > For those of you who have made it this far, thanks. I don''t want to > > > merely trade slow, reliable java UI development for buggy/hard to > > > debug javascript. > > > > > > What are your thoughts? > > > > HTML/Ajax ain''t for everything. It sounds like you ought to also > > investigate other solutions such as Laszlo (and Laszlo on Rails would > > be quite slick). > > > > Erik > > > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org <mailto:Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org> > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > > > > > -- > > Adrian Esteban Madrid > > aemadrid-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org <mailto:aemadrid-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > > >------------------------------------------------------------------------ > > > >_______________________________________________ > >Rails mailing list > >Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > >http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > -- > Simon C. Wex > > Sr. Software Developer > E-mail: swex-Qmhitw36OxM@public.gmane.org > Web: <http://www.mccg.net> > "There are 10 types of people in this world, those who understand binary, > and those who do not" > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Adrian Esteban Madrid aemadrid-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Simon C. Wex wrote:> I had never heard of Laszlo until now, I briefly considered developing > directly in flash *shudder* and quickly shunned that from my mind. >We''ve been developing rich client stuff in flash with an XML/SOAP link to the server, which turned out pretty nice. With actionscript 2.0 and the MTASC compiler (http://www.mtasc.org), you don''t need the (slow and bloated) Flash IDE for coding anymore. We only build the vector graphics in the Flash IDE (and for that, the IDE works quite well), and keep all code outside, which is then compiled into the swf file with MTASC. Without MTASC, I admit that developing directly in flash is not a nice experience (especially before actionscript 2.0 was there), but with MTASC, things became much much better, and flash has become a viable possibility for rich client development that I wouldn''t dismiss that quick, especially if your client wants eye candy. Also, for us it was easier to find graphics artists that could work with Flash, which also helped us choose for flash over java. If you''d like some more info, just shoot me a mail off-list. Best regards, Bas
On Jun 22, 2005, at 8:14 PM, Bas van Klinkenberg wrote:> > With actionscript 2.0 and the MTASC compiler (http://www.mtasc.org), > you don''t need the (slow and bloated) Flash IDE for coding anymore. We > only build the vector graphics in the Flash IDE (and for that, the IDE > works quite well), and keep all code outside, which is then compiled > into the swf file with MTASC. > > Without MTASC, I admit that developing directly in flash is not a nice > experience (especially before actionscript 2.0 was there), but with > MTASC, things became much much better, and flash has become a viable > possibility for rich client development that I wouldn''t dismiss that > quick, especially if your client wants eye candy. > > Also, for us it was easier to find graphics artists that could work > with Flash, which also helped us choose for flash over java. >I''ll second that.> If you''d like some more info, just shoot me a mail off-list. >And that. - Ben