in reply to ActiveState's HTML documentation

I second (third?) the advice for using Update HTML Doc.

Since you are editing ActiveState's docs, you might want to check out perltoc.

The author mentioned it on c.l.p.m. a couple of days ago. It adds a search box to the table of contents. You type in a regex directly. The neat thing is that it sets up a "client-side!" perl httpd to handle the requests.

caveats: the author uses CGI but uses a home-grown query-string parser - easily fixed. Also, it's client side - so you need javascript turned on and perlscript needs to be enabled for local files. It therefore only works on IE in a windows environment.

I modified the script to use the CGI.pm for fetching form values and to allow non-regex searches. I want to check with the author to see if it's ok to post the modified code here.

Alternatively, I might just rewrite it using server-side code to do the searching - it would be more secure. The problem with that is that you'd need to run the activestate docs through a real webserver.

Error: Keyboard not attached. Press F1 to continue.

Replies are listed 'Best First'.
Re: Re: ActiveState's HTML documentation
by demerphq (Chancellor) on Sep 03, 2001 at 13:22 UTC
    Hi $code_or_die,

    After posting a couple of mods (I made changes to the search engine part and the install part) and bugfixes that I made to the author of the script you mention he asked me to take over maintainance of it.

    Ive been planning to refactor it and would be very interested in seeing your copy. Perhaps we might merge whatever mods you have made and then we can post it both here and on the original website OpenPSP.Org (where the 'official' version still lives)? That way there aren't too many different versions running around confusing issues... :-)

    As for concerns about Javascript and the like I can see your point either way. I think the reason he uses a tiny snippet of JavaScript was that author knows it better than perl with regards to UI type stuff. The perlscript part (as well you know :-) only handles the creation of a virtual server and searching the files.

    Anyway, I personally think this whole idea has a lot of merit in the business world (intranet) and I certainly find the search engine a cool tool.

    Yves
    --
    You are not ready to use symrefs unless you already know why they are bad. -- tadmc (CLPM)

[reply]
Re: Re: ActiveState's HTML documentation
by John M. Dlugosz (Monsignor) on Jul 29, 2001 at 00:07 UTC
    I'd thought about the feasability of adding a client-side search box. Note that PerlScript can run embedded in a web page, so it could be written in Perl, not Java.
[reply]
      Note that PerlScript can run embedded in a web page, so it could be written in Perl, not Java.

      Most of it is in "PerlScript". Just a tiny bit of javascript that could easily be done in perlscript.

      I just don't think I like "PerlScript"! It's fine if you are writing windows script components or otherwise using it through windows scripting host. But I think it was a bad mistake to make it useable through a web browser.

      It's restricted to IE 4 or higher with Windows 95 or above. And it only runs if you install that option through the ActivePerl install. I also think that it's very dangerous! Much more so that clientside javascript. With "Perlscript" you access the filesystem, Win32::* modules, databases, all without the end user knowing. Thank God that ActiveState has set the default to "enable Local" and not "enable Internet\All"



      Error: Keyboard not attached. Press F1 to continue.

      updated: added "s to bring more attention to the fact I am talking about "PerlScript" and not "Perl" - in the same way that "JavaScript" is not "Java"
[reply]
        I'm not entirely sure if you fully grok the concept of the Windows Scripting Host.

        The idea is that when any program uses the WSH for it's scripting, any WSH compatible language can be used. Take dIRC, a simple IRC client which uses the WSH. You can use any language to program it, even ones released after the program was released. People can chose to code in whatever language the like, be it from ObjectRexx to TCL.

        You say that PerlScript's more dangerous than JavaScript, but I doubt that this is true, especially considering that both will be given the same permissions. PerlScript only runs with the permissions it's given, and obviously those permisions are different based on whether it's through Internet Explorer, through ASP, or through something entirely seperate.

        And PerlScript is _much_ closer to Perl than Javascript will ever be to Java.

[reply]

In Section Seekers of Perl Wisdom