JavaScript-based solutions for a client-side editor running within a web browser work because most web browsers have JavaScript engines built-in. Most (sane) ones don't have Perl interpreters built in. While there are Flash plugins, Java plugins, and so on, there's really no Perl plugin for web browsers. If you want client side scripting inside of a browser you generally use JavaScript; it's well suited to the task.

Thanks for the reply, davido

This is all understood. My thought's were to accomplish this through the use of Perl. All of this became possible early on with Netscape/Mozilla's "designMode", and IE's "contentEditable" document tag. While both browsers support JavaScript, and currently posses internal JS engines. JavaScript is not a requirement to implement an "Editable" web page. Don't get me wrong. I am not attempting to be argumentative. But I recognize that JavaScript is not a prerequisite for making a web page editable within a browser, that's all.

As such, I'm trying to imagine why I couldn't/shouldn't simply create a Perl Module that accommodates these browser features. Nothing fancy, just a basic editor. Seems like it'd be fairly handy. Costs the web client less resources that most, if not all the current JS based editors currently in use today.

Best wishes, and thanks again for the response, davido

--Chris

Some related information
Rich Text Editing
Content Editable
Midas

#!/usr/bin/perl -Tw
use Perl::Always or die;
my $perl_version = (5.12.5);
print $perl_version;

"All of this became possible early on with Netscape/Mozilla's "designMode", and IE's "contentEditable" document tag."

The contenteditable attribute (not tag) does exist, but it's not especially useful on its own. It allows you to place a caret into an HTML element and start typing. It doesn't allow you to insert new HTML elements though (such as <b> or <ul>), and doesn't allow you to "do" anything with the text you've typed (such as submit it in a form).

To do anything else you'll need to use a scripting language which runs within the browser.

In pre-11 Microsoft Internet Explorers you may be able to persuade the browser to run Perl scripts if ActiveState PerlScript is installed on the client machine. For any other browser, you're out of luck - Javascript is the only scripting language they support.

use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name

Perl isn't... ClientSide, like JavaScript.

I suppose you could create a page containing an HTML textarea with the appropriate event handlers set so that every keystroke within that textarea uses AJAX to send the keypress (and probably also the full state of the textarea itself) so that Perl can be used to process the keystroke and send the result back to update the textarea, but dear god, why??? It would be horribly overcomplicated and I can't imagine that latency would be within the average user's tolerance, even if you were able to solve the issues that would inevitably arise when a new keystroke is sent before the result of the previous one has been received.

If and when WebSockets get broader acceptance, that could be improved on by essentially opening a telnet session to an editor on the server, which could be running in Perl. The persistent connection would help considerably with latency and sequencing issues, but it would still be less responsive than a client-side editor at least occasionally.

That's the only way I can think of to have an in-page editor that's run by Perl (even though it relies heavily on JavaScript/AJAX to get data to and from the server so that Perl can be run against it) without requiring the user to install a browser plugin containing a Perl engine.

As far as I'm aware, nobody has yet done this.

... AJAX ... As far as I'm aware, nobody has yet done this.

Have you heard of Farabi? :)

.... brain****

Why create something when there are so many to choose from? Farabi, Re^2: CSS Show and Tell: Colored Code,