Perhaps if "not perl" and "no effort" were being used responsibly, I could agree. As it is, when nodes such as My Home Script are reaped almost instantaneously, I (speaking only for myself and not for any other editor or god) am strongly tempted to disallow both. I've even provided code to prevent their use. (It has not been applied, and I suspect it will not be applied. The point was to demonstrate that I'm serious about the matter.)

Let me be clear: I do not see consideration as a way to rid the database of otherwise non-offensive nodes that *someone* thinks *may not* fit into one particular view of the monastery. You are under no obligation to provide a free program to anyone who asks. I'd rather let a few *potentially* off-topic posts slide than prevent the normal system of intelligent and considerate replies from providing adequate guidance.

I've warned certain monks about being overzealous in the past, and will continue to do so. I really don't want to go down the path of meta-consideration, and would prefer just to remove the privilege in cases of abuse.

I hope that footpad's word to the wise will prove sufficient.

As an example, consider my Re: stdout/err redirection, my recent post. It indirectly suggests that a perl wrapper may not be the best solution to do redirection. It is about a tool that I feel a good complement to perl: socat. So does this node should be removed because it is "not perl"? I posted it because I consider it of genuine value even in the perlmonks forum. Nevertheless, as a form of politness, I state clearly from the start that this is not a perl solution so people have information to skip my post if uninterested.

-- stefp -- check out TeXmacs wiki

Here is an example. There are MANY posts on PM about CGI scripts. Most of the books I have read on writing them, including Perl books, seem to agree that any page that wants to be even remotely high performance needs to have some javascript to avoid needless round trips to the server for poor form input and the like. PM has been a very poor place to learn how to write perl scripts that do this, partly because javascript discussion is looked down upon here. JS sites, on the other hand, don't show perl scripts like this because they want to avoid the Perl focus.

I had an application a few months ago where I wanted to use JS in a Perl script to re-sort a short list in a cgi form without requiring a round trip to the server. I needed to have the Perl script write the code to fill the JS array. Being somewhat new to both Perl and JS, I had much difficulty finding examples of how to do this, and felt there should have been much more in Supersearch about writing JS with Perl.

Just my 2 cents.

drinkd

Here is an example. There are MANY posts on PM about CGI scripts. Most of the books I have read on writing them, including Perl books, seem to agree that any page that wants to be even remotely high performance needs to have some javascript to avoid needless round trips to the server for poor form input and the like. PM has been a very poor place to learn how to write perl scripts that do this, partly because javascript discussion is looked down upon here. JS sites, on the other hand, don't show perl scripts like this because they want to avoid the Perl focus. I had an application a few months ago where I wanted to use JS in a Perl script to re-sort a short list in a cgi form without requiring a round trip to the server. I needed to have the Perl script write the code to fill the JS array. Being somewhat new to both Perl and JS, I had much difficulty finding examples of how to do this, and felt there should have been much more in Supersearch about writing JS with Perl.

Everything you do in JavaScript, has nothing to do with Perl.
Everything you do in Perl, has nothing to do with JavaScript.

You may be using one language to generate code for the other, or maybe you found a way to use both languages together, but with normal CGI programming, you have strict separation of client and server side.

You needed some Perl to fill a JS array. Surprise: that has nothing to do with JS, only with its syntax. You would probably want to generate JS, which is (from Perl's view) just a string of code:

my @foo = qw(foo bar baz);
my $js = 'foo = new Array(' . join(', ', map "'\Q$_\E'", @foo) . ');';
[download]

Or something like that.

HTML and Javascript have nothing to do with Perl, but generating them can have. But when generating a string, it doesn't matter if it's executable code or just a string of repeated characters.

Generating Javascript code ("a string") with Perl is of course not off topic, Javascript itself would be. (Such as the recent question about closing a pop-up window. I'm not linking to it, because I hope it's reaped by now :)

By the way, have a look at Data::JavaScript.

any page that wants to be even remotely high performance needs to have some javascript to avoid needless round trips to the server for poor form input and the like.

That is HTTP, HTML, CGI and server maintenance related. It is NOT Perl related! CGI can be written in any programming language that can handle environment variables and stdin/stdout. Yes, you can write CGI programs in C, GW-Basic, Pascal, Visual Basic or even Brainfuck if you don't care about the environment variables.

- Yes, I reinvent wheels.
- Spam: Visit eurotraQ.

A DBI or database related question will often require a SQL answer. Quite often the SQL will be completely unrelated to the specific perl problem/script, but it is still a relevant answer.

I often step in to add additional information relating to Sybase and/or MS-SQL database programming because it enhances the answers given previously, and expands the knowledge of the user asking the original question. That is, IMHO, a reasonable use of the Monastery.

Michael

[ something about SQL related answers]

Non-Perl answers should be allowed, but all m:iw/how [do[es]?|can] [I|one] @tasks in @non_perl_languages/ questions are not good for this monastery. If a user can't tell the difference, that should not be a problem, but explicit non-perl is wrong.

- Yes, I reinvent wheels.
- Spam: Visit eurotraQ.