I would like to be able to do client-side scripting things that in the
past have been done with javascript embedded in html pages...with Ruby
instead of javascript.
With so many different projects going on in Ruby these days I'm
wondering if this is already in existence and I just haven't happened
upon an explanation of how to do it, or if there is a project underway,
or if there is expected to be a Ruby interpreter built in to some soon
to be available versions of the mainstream browsers?
Is there anything existing or about to pop along these lines?
thanks,
jp
···
--
Posted via http://www.ruby-forum.com/.
Hi,
Unless you are planning on developing for an intranet where you'd have COMPLETE control over the clients' configuration, I very much doubt that it would be a good idea to use Ruby instead of Javascript.
I am also not quite sure there are browsers out there which implement Ruby as a scripting language, or if it's even possible to write an extension for Mozilla/Netscape that adds Ruby support to the client (but I might be wrong).
I googled about it a little while ago, and didn't find it!
Merc.
···
I would like to be able to do client-side scripting things that in the
past have been done with javascript embedded in html pages...with Ruby
instead of javascript.
With so many different projects going on in Ruby these days I'm
wondering if this is already in existence and I just haven't happened
upon an explanation of how to do it, or if there is a project underway,
or if there is expected to be a Ruby interpreter built in to some soon
to be available versions of the mainstream browsers?
Is there anything existing or about to pop along these lines?
thanks,
jp
--
Posted via http://www.ruby-forum.com/\.
Hi Jeff,
I would like to be able to do client-side scripting things that in the
past have been done with javascript embedded in html pages...with Ruby
instead of javascript.
I agree with James and Tony that you would be better off doing the
client-side scripting in JavaScript. ActiveScript Ruby will make that bond
with Internet Explorer unbreakable. Anyway, I've tried it and it worked
fine for my simple tests (getElementById, set value, etc).
You might want to check out the prototype.js library. It's Ruby friendly,
and its Enumerable module that mixes in collection methods like each,
collect, grep, inject into the Array prototype is really cool.
Hristo Deshev
···
On 2/22/06, Jeff Pritchard <jp@jeffpritchard.com> wrote:
} I would like to be able to do client-side scripting things that in the
} past have been done with javascript embedded in html pages...with Ruby
} instead of javascript.
[...]
Is there a FAQ list out there somewhere? This is the second time this has
come up within a week or two. I'd like to be able to respond to questions
like this with an URL (including an anchor to the specific
question/answer).
Also, I want to mention that JavaScript is a rather nice language. Its
primary failings are:
1) Minor implementation inconsistencies between browsers
2) Major API inconsistencies between browsers
3) Inconveniently missing facility for method callbacks (which can be
overcome with a really simple function)
JavaScript has many of the same language features Ruby has, including
extension by mixin, duck typing, a YAML equivalent (JSON), arbitrary class
and object extension (i.e. adding methods/properties to classes or specific
objects at any time), simple arrays and hashes, etc. It also has
first-class functions, which are equivalent (though not identical) to
blocks.
While it does require one to shift syntax when working on both the client
side and the server side, I see little problem with JavaScript and little
reason to even want to replace it with Ruby on the client. At the same
time, I have no great desire to use JavaScript on the server side, either,
since Ruby/Rails (and other web frameworks in other languages) are at least
as good for the purpose.
} thanks,
} jp
--Greg
···
On Wed, Feb 22, 2006 at 12:45:09PM +0900, Jeff Pritchard wrote:
Tony Mobily wrote:
Hi,
Unless you are planning on developing for an intranet where you'd have COMPLETE control over the clients' configuration, I very much doubt that it would be a good idea to use Ruby instead of Javascript.
I am also not quite sure there are browsers out there which implement Ruby as a scripting language, or if it's even possible to write an extension for Mozilla/Netscape that adds Ruby support to the client (but I might be wrong).
I googled about it a little while ago, and didn't find it!
I believe you can use ActiveScript Ruby for this, but it requires that the client use IE and have ActiveScript Ruby installed.
You are likely better off using modern JavaScript (e.g. DHTML) to interact with Ruby business logic running on a Web server.
···
--
James Britt
http://www.ruby-doc.org - Ruby Help & Documentation
Ruby Code & Style - The Journal By & For Rubyists
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys
http://www.30secondrule.com - Building Better Tools
You might want to check out the prototype.js library. It's Ruby friendly,
and its Enumerable module that mixes in collection methods like each,
collect, grep, inject into the Array prototype is really cool.
Forgot the link:
http://prototype.conio.net/
Hristo Deshev
···
On 2/22/06, Hristo Deshev <hristo.deshev@gmail.com> wrote:
Gregory Seidman wrote:
Also, I want to mention that JavaScript is a rather nice language. Its
primary failings are:
1) Minor implementation inconsistencies between browsers
2) Major API inconsistencies between browsers
Greg,
These two reasons are why I choose to hate javascript. The reason for
the question though is that in this new era of "that's so ten minutes
ago", this old dog is starting to feel like a jack of all trades, but
master of none. I long for a day when the tools settle down a bit and I
can learn just one syntax (Ruby looks like a good candidate) really well
and do lots of neat stuff with it.
My interest in Ruby started when a colegue of mine started sending me
snippets of Ruby to explain an idea for implementing something at work
(which would, of course, have to be converted into quasi object oriented
C and then tested with a perl test framework). That was mildly
entertaining, but now he's sending me stuff in Haskel! That stuff will
eat your brain in a hurry.
The way things are going though, I'll have to deal with "Ruby++" long
before I ever feel that I've mastered Ruby. Guess it's a sign of
getting old, but I'm getting sick and tired of learning new languages
every time I turn around. One partial solution would be to be able to
do many different types of things with the same syntax. Ruby is part of
the way there, with ways to do many server side things in Ruby, and also
ways to do real application programming in Ruby. I just think it would
be cool if it went one more step to a seamless implementation of client
side embedded Ruby.
thanks,
jp
···
--
Posted via http://www.ruby-forum.com/\.
Hi,
Unless you are planning on developing for an intranet where you'd have COMPLETE control over the clients' configuration, I very much doubt that it would be a good idea to use Ruby instead of Javascript.
I am also not quite sure there are browsers out there which implement Ruby as a scripting language, or if it's even possible to write an extension for Mozilla/Netscape that adds Ruby support to the client (but I might be wrong).
I googled about it a little while ago, and didn't find it!
I believe you can use ActiveScript Ruby for this, but it requires that the client use IE and have ActiveScript Ruby installed.
Out of curiosity... can you give me a link about this one?
I looked and looked...
You are likely better off using modern JavaScript (e.g. DHTML) to interact with Ruby business logic running on a Web server.
I agree!
Merc.
When completed, Pandora (http://pandora.rubyveil.com/) will allow Ruby
scripting on the browser without requiring any client-side extensions.
The idea is to mark certain Pandora pages as scriptable, and then use
ERB to execute the embedded code in a sandbox on the server. The
effect is that the end user (or "programmer") does not have to be on
the server to code dynamic extensions / plugins for the system. All
they need to do is edit the page using the Wiki editor form to enter
Ruby code into the page. The safety of this approach will depend
heavily on how the sandbox is implemented and what functions it
provide.
On a longer term, something like Scriptaculous can be integrated on the
server as well so that client side Javascript code can be callable from
Pandora Box code written in Ruby--no Javascript programming required.
No client side extensions are required--just use a plain old browser to
create dynamic Web pages.
Best regards,
Julian I. Kamil <julian.kamil@gmail.com>
Dňa Streda 22 Február 2006 22:06 Jeff Pritchard napísal:
Gregory Seidman wrote:
> Also, I want to mention that JavaScript is a rather nice language. Its
> primary failings are:
>
> 1) Minor implementation inconsistencies between browsers
> 2) Major API inconsistencies between browsers
(snip)
Just plugging Ruby into browsers wouldn't really solve the API problems. A
bonus of Javascript in this is that it has standards to support it, both
language ones, and the W3C document API ones. If there are inconsistencies,
at least there's authoritative points of reference to support these.
Also, you can't possibly plain plug in the existing Ruby into browsers across
the board. Unfortunately there is no standard governing client-side scripting
in general, so if nothing else, making the required plugins would take a
while. Also, the interpreter would have to go through some trimming to ensure
sandboxing. Bits of the standard library would have to go away due to them
being unnecessary or unsuited for browser scripting (Tk, readline?). Then,
not all browsers were created equal, so there'd be further trimming of both
the language and libraries to cater for mobile devices and the like. And
sooner or later, Microsoft would decide to "improve" things and bundle IE
with "Ruby Blunt: Whizbang Edition", and the list of things goes on and on.
The bottom line is, you'd very probably end up with something that is at best
similar to Ruby on webbrowsers, and the story of Javascript would at least
partially repeat itself. Switching languages is not the solution for problems
with browser scripting, and I'd dare say it's not even -a- solution for those
problems. And right now, Javascript works, for given values of works (blessed
be all you who don't deploy to proprietary set-top-box browsers).
That said, it's not an unworthy goal, but there's quite a lot to do before
it's actually good for anything serious, like letting Ruby loose on the
unsuspecting web, with early-adoption problems aplenty on the road.
David Vallner
getting old, but I'm getting sick and tired of learning new languages every time I turn around. One partial solution would be to be able to
Then learn Smalltalk and be done with it.
using JavaScript is definitely a good idea.. there is also ruby.js
which was written by flrgr.
"This is a port of some of Ruby's standard library to JavaScript. It
shows that JavaScript is indeed a well-thought out language (even if
it's standard library is quite cumbersome). The fact that pretty much
everything is based on other components clearly without duplicating
logic should make this interesting.
.....
Note that there are some differences between this and Ruby, especially
that Hash#each yields value,key instead of key,value"
related links:
http://www.advogato.org/proj/Ruby.js/
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/117184
http://www.openjsan.org/doc/f/fl/flgr/ruby/js/0.4.0/
Tony Mobily wrote:
Out of curiosity... can you give me a link about this one?
I looked and looked...
ActiveScriptRuby 1.8.4.1
http://arton.hp.infoseek.co.jp/
···
--
James Britt
"A principle or axiom is of no value without the rules for applying it."
- Len Bullard
That said, it's not an unworthy goal, but there's quite a lot to do before it's actually good for anything serious, like letting Ruby loose on the unsuspecting web, with early-adoption problems aplenty on the road.
Hmm... JRuby as an applet? 
Ah, apparently it's been tried...
DataVision User's Manual says,
Since JRuby uses a custom class loader, you will have to either sign the applet
or edit the client's java.policy file and add the line:
permission java.lang.RuntimePermission "getClassLoader";
Regards,
Bill
···
From: "David Vallner" <david@vallner.net>
Ramon Leon wrote:
getting old, but I'm getting sick and tired of learning new languages every time I turn around. One partial solution would be to be able to
Then learn Smalltalk and be done with it.
Yeah, but then he'll get antsy again, and someone will tell him to learn Lisp.
···
--
James Britt
"Programs must be written for people to read, and only incidentally
for machines to execute."
- H. Abelson and G. Sussman
(in "The Structure and Interpretation of Computer Programs)
FYI, this is more a limitation of the Bean Scripting Framework than of
JRuby itself. JRuby currently has no hard dependencies on
security-risky features like custom classloaders, and a version of
JRuby could be built--sans BSF--that would run just fine as an applet.
···
On 2/22/06, Bill Kelly <billk@cts.com> wrote:
From: "David Vallner" <david@vallner.net>
>
> That said, it's not an unworthy goal, but there's quite a lot to do before
> it's actually good for anything serious, like letting Ruby loose on the
> unsuspecting web, with early-adoption problems aplenty on the road.
Hmm... JRuby as an applet?
Ah, apparently it's been tried...
DataVision User's Manual says,
Since JRuby uses a custom class loader, you will have to either sign the applet
or edit the client's java.policy file and add the line:
permission java.lang.RuntimePermission "getClassLoader";
Regards,
Bill
--
Charles Oliver Nutter @ headius.blogspot.com
JRuby Developer @ jruby.sourceforge.net
Application Architect @ www.ventera.com
> Since JRuby uses a custom class loader, you will have to either sign
> the applet or edit the client's java.policy file and add the line:
> permission java.lang.RuntimePermission "getClassLoader";
FYI, this is more a limitation of the Bean Scripting Framework than of
JRuby itself. JRuby currently has no hard dependencies on
security-risky features like custom classloaders, and a version of
JRuby could be built--sans BSF--that would run just fine as an applet.
Cool, nice to know!
I'd really like to try this. My java's a bit rusty... I've
downloaded the latest JDK and verified I can build JRuby from
source. I grepped for BSF and:
src/org/jruby/javasupport/bsf/JRubyEngine.java:import org.apache.bsf.BSFDeclaredBean;
src/org/jruby/javasupport/bsf/JRubyEngine.java:import org.apache.bsf.BSFException;
src/org/jruby/javasupport/bsf/JRubyEngine.java:import org.apache.bsf.BSFManager;
src/org/jruby/javasupport/bsf/JRubyEngine.java:import org.apache.bsf.util.BSFEngineImpl;
src/org/jruby/javasupport/bsf/JRubyEngine.java:import org.apache.bsf.util.BSFFunctions;
// . . .
It looked like it was mostly confined to that JRubyEngine.java file, although I'm a little lost looking at the source, as I
don't know what the purpose of a BSF is yet. 
But before I delve into it, I was wondering, would you say it
should be fairly easy to remove the BSF dependency? Or am I looking at a lot of hacking and slashing?
Also, if JRuby is running as an applet, the ruby standard library
files and my own program scripts will reside on the server, not
the client's system. Is this something that will somehow be fairly transparent to the applet? Or will I be looking at hacking
in the ability for JRuby to read .rb files from the server?
Thanks for your thoughts,
Regards,
Bill
···
From: "Charles O Nutter" <headius@headius.com>
On Fri, 03 Mar 2006, Bill Kelly defenestrated me:
From: "Charles O Nutter" <headius@headius.com>
>
>> Since JRuby uses a custom class loader, you will have to either sign
>> the applet or edit the client's java.policy file and add the line:
>> permission java.lang.RuntimePermission "getClassLoader";
>
>FYI, this is more a limitation of the Bean Scripting Framework than of
>JRuby itself. JRuby currently has no hard dependencies on
>security-risky features like custom classloaders, and a version of
>JRuby could be built--sans BSF--that would run just fine as an applet.
Cool, nice to know!
It looked like it was mostly confined to that JRubyEngine.java
file, although I'm a little lost looking at the source, as I
don't know what the purpose of a BSF is yet.
A more detailed explanation of BSF is at jakarta.apache.org/bsf. We
generally encourage anyone embedding JRuby (Ruby) into a Java application
to use BSF, since it takes care of setting up and managing the interpreter
with a fairly simple API.
For some context of use of BSF with JRuby check out our lithe example
doc:
http://jruby.sourceforge.net/docs/bsf.shtml
To embed JRuby in an applet without using BSF basically would be grokking
our JRubyEngine to understand under the covers how we set up, invoke, and
tear down the interpreter. We have the desire to make this easy to do
without requiring BSF, but have not found the time to make it happen yet.
But before I delve into it, I was wondering, would you say it
should be fairly easy to remove the BSF dependency? Or am I
looking at a lot of hacking and slashing?
The impl of JRubyEngine we have shows the amount of code you need.
If you understand the url above on BSF usage and understand this manager
impl, you should get a good idea.
Also, if JRuby is running as an applet, the ruby standard library
files and my own program scripts will reside on the server, not
the client's system. Is this something that will somehow be
fairly transparent to the applet? Or will I be looking at hacking
in the ability for JRuby to read .rb files from the server?
I have some ideas on this that I have not added yet to the source. We
want to extend the include path to give the ability to provide url paths.
We need to do this in a safe way, but I have given it at least some thought.
Any continued discussion on this may be better served on
jruby-devel@list.sourceforge.net.
-Tom
···
--
+ http://www.tc.umn.edu/~enebo +---- mailto:enebo@acm.org ----+
Thomas E Enebo, Protagonist | "Luck favors the prepared |
> mind." -Louis Pasteur |
Well as long as you're giving this a try, I'll see if I can help.
First off, removing BSF from JRuby should be very easy; we have no
dependency on BSF ourselves, and the JRubyEngine class is probably the
only piece of code you would have to remove or disable. Removing that
and any other references to BSF should not break JRuby (if they do,
I'll personally fix it).
Second, in order for the standard Ruby libraries to be available, the
simplest way would be including them in the JRuby jar file. This would
allow the JRuby and all the libraries to run locally in the browser,
effectively providing a full Ruby environment within an applet. Of
course, this would increase the size of the jar.
If you were intent on running JRuby as an applet with Ruby's .rb
libraries on the server, this would still be possible...but it would
require some work.
JRuby does support (in some capacity) the ability to use a URL as part
of your load path; in other words, you can do the equivalent of
-Ihttp://somewhere.com/rubyfiles and JRuby should be able to use that
location for loading "require"s. However, this is a fairly new
capability, and I can't guarantee it's working 100%. I think it's
pretty cool, though, and I'd be willing to help make it work if you're
interested in trying it.
I'd recommend you pop over to the jruby-user or jruby-devel lists on
jruby.sf.net. We're pretty responsive these days and a JRuby applet
would be cool to have working for our JavaOne presentation.
···
On 3/3/06, Bill Kelly <billk@cts.com> wrote:
I'd really like to try this. My java's a bit rusty... I've
downloaded the latest JDK and verified I can build JRuby from
source. I grepped for BSF and:
src/org/jruby/javasupport/bsf/JRubyEngine.java:import org.apache.bsf.BSFDeclaredBean;
src/org/jruby/javasupport/bsf/JRubyEngine.java:import org.apache.bsf.BSFException;
src/org/jruby/javasupport/bsf/JRubyEngine.java:import org.apache.bsf.BSFManager;
src/org/jruby/javasupport/bsf/JRubyEngine.java:import org.apache.bsf.util.BSFEngineImpl;
src/org/jruby/javasupport/bsf/JRubyEngine.java:import org.apache.bsf.util.BSFFunctions;
// . . .
It looked like it was mostly confined to that JRubyEngine.java
file, although I'm a little lost looking at the source, as I
don't know what the purpose of a BSF is yet.
But before I delve into it, I was wondering, would you say it
should be fairly easy to remove the BSF dependency? Or am I
looking at a lot of hacking and slashing?
Also, if JRuby is running as an applet, the ruby standard library
files and my own program scripts will reside on the server, not
the client's system. Is this something that will somehow be
fairly transparent to the applet? Or will I be looking at hacking
in the ability for JRuby to read .rb files from the server?
Thanks for your thoughts,
Regards,
Bill
--
Charles Oliver Nutter @ headius.blogspot.com
JRuby Developer @ jruby.sourceforge.net
Application Architect @ www.ventera.com