Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Wanet Telecoms Ltd on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

First off clientside perl is possible!!! 1

Status
Not open for further replies.

Phalanx1

Programmer
Jul 21, 2003
128
US
Response object must equal an HTML Document Object that is updatable like an div or a span. each element accessed requires a name or ID so that u dont access a collection and change them Big message box... $window->alert("this is good thing!\n\n\n\n\nThe End!");
javascript
var FSO = new ActiveXObject("Scripting.FileSystemObject");
FSO.CreateTextFile("C:\\Hello.txt", true);
PerlScript
use Win32::OLE;
my $FSO = Win32::OLE->new("Scripting.FileSystemObject");
$FSO->CreateTextFile("C:\\\\Hello.txt", true)

$window->document->all->SomeDiv->innerText; problem some one help please... print may not be used to write to hta html htm mht all active scripting supporting applications in windows are accessible more is possible please help will trade code for any help...
 
<script language=&quot;PerlScript&quot;>

my @win =$window->alert(&quot;hello World!\n&quot;);
@win =$window->alert(&quot;The World is ours that know perl.&quot;);
$window->alert(@win);
chomp($newdir = &quot;C:\\&quot;);
chdir($newdir) || die &quot;Cannot chdir to $newdir: $!&quot;;
foreach (<*>) {
$window->alert(&quot;$_\n&quot;);
}
</script>
try this :)
 
<body><input type=&quot;text&quot; value=&quot;testing perlscript win32 by:Ryan April aka: Phalanx1&quot; id=&quot;Inp&quot; name=&quot;Inp&quot;>
<script language=&quot;PerlScript&quot;>
if ($window->document->getElementbyID(Inp) eq <>){
$window->document->Write($window->document->getElemetbyID(Inp)->value);
}
my $input = $window->document->getElementbyID(Inp)->value;
$window->alert(&quot;$input&quot;)
</script>
<!-- Insert HTML here -->

</body>
 
Doesn't client side perl script depend on the user having perl installed?

Seems hackish to me, but I am a snob like that ;)
 
that would be true but the ever lasting in comment tag can remove it from clients who don't have it.. not remove bu make it uniterpretable (mbaword) by the browser that does not support it almost like noscript...
 
Hmm, given that perl is not a default Windows install I personally would not recommend this route. To many dependancies. Asking users to install a multi-meg package just to run your webcode that could have been done in javascript or vbscript seems a bit unfriendly..

 
i find it very ironic that your handle is siberian and your calling me unfriendly[pipe]
but i am sorry if that offended you in anyway. work in company with it why not the outside world or better yet my home computer. i am a developer at heart and mind, it's like learning the why before how that makes it interesting to have on my home machine and as i said before i can comment it out of non supporting Browsers.

 
I don't understand what your saying.

When I say 'unfriendly' I mean this :

A user comes to your website

It only works if they download a 10 meg piece of software and install it.

That is not easy for the user, it is not 'user friendly'. Using javascript or vbscript will work in all browsers by default and is thus more user friendly.

I was not saying that you are not friendly. I am not offended.

This is not a 'Supported Browser' issue, its a 'if I do not install a 10 meg perl program I can not use this webpage'

You can not detect if they have perl installed or not, thus your theaory of 'detecting the browser and disabling' is fundamentally flawed.

I am not fighting with you, I am trying to help you. Your approach is complex and will not work for most windows users.
 
<!--
<script language=&quot;PerlScript&quot;></script>
--> this won't work...
 
now i understand what you mean but i work in an organization and learning environment with just such a happening of events thanks in part to me...
 
It seems to me that JavaScript is the defacto standard, so you should try to use what works best for everyone. Most browsers still don't support that well enough let alone another language. I'm a huge fan of Perl, but half of its power is direct interaction with the server. Congratulations if you can convince all of your potential users to install Perl, but I just see this as a future headache. JavaScript can accomplish all the same stuff and is not that syntactically different.

Also, you're mixing conflicting philosophies trying to do Windows programming with Perl. I'd say a more worthwhile goal would be to get your userbase to upgrade to linux.

Sincerely,

Tom Anderson
Order amid Chaos, Inc.
 
I love Linux as well but the world doen't move in such directions when u have just installed the network and install activestate on workstations(batch install with error reporting) so that it was determined that each system supported the base functionality of perl on Win32.
i have learned that it can be used server side and can be instantiated within the Windows Scripting Host which is then passed to the proper dlls or exe Wscript.exe or Cscript.exe and Wperl.exe perl.exe but i can convert most unix perl plx pl script to client side(html, or my favorite HTA which has no security object model and is run with the same permissions as the user almost like
strComputer=&quot;.&quot;
Set Process = GetObject (&quot;winmgmts:\\{impersonationLevel=impersonate}\Win32_Process&quot;)
for each proc in Process
MsgBox proc.name ... so on so forth
next
this must be imported from a script tag with src because GetObject wont work embedded directly into the script in the source but a js vbs plx pl cgi file can run the GetObject Method when run.
more :: text ??
 
VBScript would be a LOT easier for calling windows DLL objects, thats one of the things its built for..

 
that is true for dlls whatabout Windows Script Compoents or more acuratly Windows Com interface which can now be done in PerlScript so you can Call it from vbs... PerlScript from VBS Scary yes, i think so to... but i enjoy a minimal understanding of perl at the current time, but that will change quikly. as i am familiar with other languages...
 
COM object is the same as a DLL, both are componetized interfaces for exporting functions.

VBScript is the best way to manage these, I would ditch the perl entirely.

Your set on doing it your way, enjoy! I think all we are trying to tell you is 'You Are Doing It The Hard Way'.

 
well when the hacker does it the hard way it usually get noticed. when the programmer does it the hard way the hacker is harder to notice.
 
i meant that as in the hacker has to work all the harder to crack the code and exploit you program.
 
O.k. i work in an intranet association for marketing where all workstations and my server have perl installed most of my employees know some kind of scripting language or mabye more, but client side perl in html is confounding the hell out of them and they dare not change any of the code to exploit or corrupt by accident and files these files deal with. its quiet funny really, i mean i coulddeny write access to them but, that is coming sooner or later.(sooner hopefully Mastering ADSI(reading tons...))

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top