Non-browser version of Prototype.js?
Christian
In the context of a portal application written in Java, we have chosen
to provide scriptability of some server code using JavaScript (with
Rhino). And given the great enhancements that Prototype.js provides to
JavaScript, and the fact that we use it for client code, we would like
to use it for the server as well. :)
Obviously, in this context we don't need all the client features, but
rather the "generic" features such as class-based inheritance, JSON,
Enumerable, Hash, utility functions, etc.
Running Prototype.js as-is in a Rhino engine does not work, because of
all the references to client objects (window.*, document.*, etc.). I
was able to use it however with only minor modifications to the code,
i.e. mostly commenting of sections of code that use client objects and
the definition of a dummy empty 'window' object. This works very well
so far, but has the consequence that a similar work will be needed for
each new release of Prototype.js .
Are there any plans in the community to provide "official" support for
server-only use in the future (through a configurable option, or a
separate "light" version, or any other way that seams easier)? If
there is an interest, I will gladly participate and provide the
modifications that were needed in my case.
Any thoughts or comments welcome.
Thanks!
-Christian
Adam Rich
similar desire -- to be able to exploit prototype's Class object and
Ruby-inspired extensions of base objects. I quickly came up with the
following by responding to the error messages I received. But, it
would be very nice to have something that worked automatically with
each new version of prototype.
This is loaded before prototype.js to set up an environment containing
the objects prototype assumes exist:
var emptyFunction = function() {};
var window = new Object();
window.attachEvent = emptyFunction;
window.opera = false;
window.HTMLElement = new Object();
var navigator = new Object();
navigator.userAgent = new String();
var emptyElement = new Object();
emptyElement.__proto__ = false;
emptyElement.appendChild = emptyFunction;
function Element() { }
function HTMLElement() { }
var emptyTextnode = new Object();
var document = new Object();
document.evaluate = emptyFunction;
document.createElement = function() { return emptyElement; };
document.createTextNode = function() { return emptyTextnode; };
document.write = emptyFunction;
document.getElementById = function() { return emptyElement; };
One positive benefit to this method is that I do not have to touch the
source code. The downside is that I have several objects residing in
memory which cannot be used predictably, if at all.
I, too, would volunteer my services in maintaining such a project going forward.
Adam Rich
nlloyds
everything that deals with the DOM. I'm planning on putting up a page
with more details soon, but this should do the trick:
http://nlsmith.com/prototype.js.asp
There's nothing in it that depends on ASP, so it should work on any
server-side JavaScript environment.
Let me know if that works for anyone.
Thanks,
Nathan
adamleerich
A problem I see is that every time a new version of prototype.js comes
out, you have to re-sift through all the code and pull out the stuff
that belongs to the DOM. That makes me antsy. My current, albeit
temporary, solution is posted above. With mine, every time a new
prototype comes out, I have to check for new error messages and set
those objects trivially. Not any better, probably worse, but there is
no touching of the source code.
So for maintenance of an altered prototype: how can your pared-down
code benefit, for example, from patches? Are you going to manually
check that the new code is inserted or old code deleted? You could
write a fancy script to incorporate relevant patches, but will you
write it so that it checks whole new sections of code, too? It could
merge changes from version to version of the existing non-browser
code, but what of totally new code?
It wouldn't be preferable, either, to maintain a separate branch of
prototype.js for non-browser use. Maybe the mainstream code could be
written in a way that does not assume the existence of certain
objects? Could all the DOM stuff be segregated from the non-DOM items
and not loaded if not supported?
I'm not claiming to have a solution, only desires for a prospective
solution's parameters.
Adam Rich
T.J. Crowder
> out, you have to re-sift through all the code and pull out the stuff
> that belongs to the DOM.
then you can grab the parts you want; the source is reasonably
modular.
Just a *very* quick review suggests you would want to include these
source files:
array.js (*)
base.js (**)
enumerable.js
hash.js
number.js
range.js
string.js (***)
(* array.js has some Prototype.Browser checks so it can use native
features if they exist)
(** base.js has DOM dependencies in bindAsEventListener and delay)
(** string.js has DOM dependencies in escapeHTML and unescapeHTML)
...and leave these out:
ajax.js
dom.js
event.js
form.js
selector.js
You'd probably want your own copy of the master prototype.js file,
which is very short and just sets up the Prototype object, does some
browser/browser-feature detection to set up the Prototype.Browser
object, then includes the various other files. Your replacement could
basically say it isn't any browser (which I think would solve the
array.js issue above).
So the one-off is creating your own prototype.js master file, and then
the ongoing effort on each release is removing escapeHTML() and
unescapeHTML() from string.js, removing bindAsEventListener() and
delay() from base.js, and combining the files. I wonder how the core
team would feel about moving String.escapeHTML() and
String.unescapeHTML from string.js to dom.js, and
Function.bindAsEventListener() and Function.delay() from base.js to
(say) event.js... (Leaving them on the same objects, just extending
them in different source files so that we can leave out those features
more easily.)
Again, this is based on a very quick review, so there may be a couple
of other dependencies I've missed, but the idea of working from the
source rather than the released prototype.js file is my main point (he
says, several paragraphs later).
FWIW...
--
T.J. Crowder
tj / crowder software / com
Christian Grigis
> I'm very happy that I am not the only one thinking of this . . .
Me too. :-)
> A problem I see is that every time a new version of prototype.js comes
> out, you have to re-sift through all the code and pull out the stuff
> that belongs to the DOM. That makes me antsy. My current, albeit
> temporary, solution is posted above. With mine, every time a new
> prototype comes out, I have to check for new error messages and set
> those objects trivially. Not any better, probably worse, but there is
> no touching of the source code.
Exactly. My quick current solution is very similar to Nathan's, but I
don't think that is really viable (or at least not optimal) in the long
run in terms of maintenance.
Hence the discussion to see how this use case (i.e. Prototype in a
non-browser environment) could be included at the core if possible...
Thanks,
-Christian
Christian Grigis
> Again, this is based on a very quick review, so there may be a couple
> of other dependencies I've missed, but the idea of working from the
> source rather than the released prototype.js file is my main point (he
> says, several paragraphs later).
That's very interesting. I had not yet looked at how Prototype was
built, and I see it looks indeed quite modular.
The build is done using Rake. Maybe an easy way would then be to add a
"dist-server" target in the Rakefile that would appropriately filter the
assembled files for server use?
-Christian
nlloyds
On Mar 14, 5:24 am, Christian Grigis <christian.gri...@nexthink.com>
wrote:
exactly which files were removed (ajax.js, element.js, etc.) on this
thread shortly. Though there were a couple of other places where
browser capabilities are tested which were removed (i.e., adding
Array#concat for Opera.) Since I was targeting JScript, I just picked
whatever behavior it was using for IE in those conditionals, since
it's the same engine. Some other functions that depend on setTimeout
were also removed.
While changes might be necessary with future versions of Prototype,
it's a trivial process to make it work. I plan on doing it this way
with my own projects for the foreseeable future and tracking any
useful updates to Prototype. Having a "dist-server" task would be
great though, what with the increasing popularity and utility of
server-side JavaScript.
DK
dependent on Prototype project (let's call it Proto-Server ;-) ).
Something like Scriptaculous. No matter what you do, if new version of
Prototype occurs, somebody (from this new "Proto-Server" project or
somebody from Prototype Core Team) will have to do some work in order
to make new version of "Proto-Server" working too.
For example, when version 1.6 of Prototype was coming out, there was a
problem with it's compatibility with older versions of Scripty.
Just my 3 cents :P
nlloyds
http://jscripter.net/projects/prototypeasp/
I'll update it whenever a relevant update to Prototype is released.
Any feedback is appreciated.
Thanks,
Nathan