editing perl script through TEXTAREA

Discussion in 'Perl Misc' started by anita, Aug 17, 2004.

  1. anita

    anita Guest

    Hello
    I am trying to get to edit my perl scripts through a form. I'm loading
    the perl script into the TEXTAREA, but the browser interprets the
    stuff in the edit box. so if it happens to see another </TEXTAREa>
    area in the text, it assumes it has found the end of the textarea and
    the rest of my script is just spit out on the screen outside of the
    textarea.
    I can replace the > and < with HTML entities, while displaying and
    whenthe user edits the fields, reinterpret the &entity back into > <
    before saving.
    My question is this- is there anything else I need to interpret before
    I save ?
    Like all those innumerable special chars in perl ?!

    I realize this is strictly not a PERL question but would appreciate
    any feedback. Especially if there are already some modules I can use
    to do this sort of thing.
    Thanks
    anita
     
    anita, Aug 17, 2004
    #1
    1. Advertisements

  2. anita

    Tore Aursand Guest

    Check out the HTML::Entities module. It will let you encode any "special"
    characters to HTML.
     
    Tore Aursand, Aug 17, 2004
    #2
    1. Advertisements

  3. If you save before converting to HTML entities, you don't need to
    convert those characters back.
    I'm not sure if there is a *need* to convert any other characters for
    this limited purpose. However, this is a function I'm using:

    sub entify {
    my $ref = defined wantarray ? [ @_ ] : \@_;
    for ( grep defined, @$ref ) {
    s/&/&amp;/g;
    s/"/&quot;/g;
    s/</&lt;/g;
    s/>/&gt;/g;
    }
    @$ref > 1 ? @$ref : $$ref[0]
    }

    Besides < and > it converts & and ".

    There are also modules, of course, such as HTML::Entities, or you can
    use the escapeHTML() function in CGI.pm.

    HTH
     
    Gunnar Hjalmarsson, Aug 17, 2004
    #3

  4. Why are you trying to get to edit your perl scripts through a form?

    I am sensing an X-Y problem here...
     
    Tad McClellan, Aug 17, 2004
    #4
  5. anita

    anita Guest

    Lets just say I am editing some file, any file through the form... Not
    necessarily a perl script. That- is a good example because it tends to
    have a lot of special characters.
    One other person suggested that I save before converting. I am not
    sure what was meant by that.

    From what I understand, my file has to be processed to replace all the
    special HTML chars before display (so browser wont complain) and once
    the user edits and tries to save it through the form, it has to be
    stripped off the special entities, so it can be saved...

    I will look into the HTML module.
    I dont get it. What do you mean X-y problem ?
    Thanks
     
    anita, Aug 18, 2004
    #5
  6. anita

    anita Guest

    Lets just say I am editing some file, any file through the form... Not
    necessarily a perl script. That- is a good example because it tends to
    have a lot of special characters.
    One other person suggested that I save before converting. I am not
    sure what was meant by that.

    From what I understand, my file has to be processed to replace all the
    special HTML chars before display (so browser wont complain) and once
    the user edits and tries to save it through the form, it has to be
    stripped off the special entities, so it can be saved...

    I will look into the HTML module.
    I dont get it. What do you mean X-y problem ?
    Thanks
     
    anita, Aug 18, 2004
    #6

  7. An XY problem is when you want to do X, but you ask how to do Y
    instead, because you've decided that Y is the best way to accomplish X.


    If you tell us why you think you want to edit programs in a browser,
    then maybe we could suggest a better or easier alternative...
     
    Tad McClellan, Aug 18, 2004
    #7
  8. anita

    gnari Guest

    naw, you just use one of those bendy straws.

    gnari
     
    gnari, Aug 18, 2004
    #8
  9. Suppose I'm that "other person". Post your code if you want me to
    explain further.
    No, your file does not need to be processed. Your *data*, whereever it
    come from, need to be processed before display.
    No. The form takes care of that.
     
    Gunnar Hjalmarsson, Aug 18, 2004
    #9
  10. anita

    Tore Aursand Guest

    You still want to use the HTML::Entities module. Here's an example for
    you to (hopefully) learn from (untested):

    #!/usr/bin/perl
    #
    use strict;
    use warnings;
    use HTML::Entities qw( encode_entities );

    my $data = 'whatever'; # This is very you read the data you want to
    # convert to HTML from a file or something.

    $data = encode_entities( $data ); # Convert any "special" characters
    # to HTML entities.

    # Do whatever you need to do with the converted $data variable.
     
    Tore Aursand, Aug 18, 2004
    #10
  11. Second thought: The test.pl script below should explain the logic that
    is my starting-point.

    #!/usr/bin/perl -T
    use strict;
    use warnings;
    use CGI::Carp 'fatalsToBrowser';
    use CGI 'escapeHTML';
    my $q = new CGI;
    my $in;

    my $file = 'file_to_edit.txt';

    if ($ENV{REQUEST_METHOD} eq 'POST') {
    $in = $q->Vars;
    } else {
    if ( open my $f, $file ) {
    $in->{content} = do { local $/; <$f> };
    } else {
    $in->{content} = '';
    }
    }

    open my $f, "> $file" or die $!;
    print $f $in->{content}; # here it's saved ...
    close $f;

    $in->{content} = escapeHTML $in->{content}; # and here it's converted

    print $q->header;
    print <<FORM;
    <form action="test.pl" method="post">
    <textarea name="content" cols="50" rows="25">$in->{content}</textarea>
    <br>
    <input type="submit">
    </form>
    FORM

    __END__
     
    Gunnar Hjalmarsson, Aug 18, 2004
    #11
  12. anita

    Guest

    From what I understand, the textarea() sub (or method) of CGI module will
    automatically do this conversion for you on the way to html, and the
    param() sub or method (or something upstream of it) will automatically
    do the reverse conversion on the way back.

    Xho
     
    , Aug 18, 2004
    #12
  13. Sounds plausible.
    Don't understand. What do you mean by that?
     
    Gunnar Hjalmarsson, Aug 18, 2004
    #13
  14. anita

    gnari Guest

    he means that a character like '&' will be sent by
    the browser encoded (&amp;), but param() will
    return it as '&' again.
    so if you use textarea() and param(), you never have to
    worry about it.

    gnari
     
    gnari, Aug 18, 2004
    #14
  15. There is a lot of confusion here.

    A '&' character that is submitted via a textarea control is URI
    encoded, not converted to the corresponding HTML entity. Accordingly,
    after URI decoding, it's still a '&'.

    It's when you want to display content initially in a textarea field
    that you should first convert certain characters to HTML entities, but
    if you for instance have:

    <textarea name="demo">Smith &amp; Son Co.</textarea>

    the browser will convert the '&amp;' to '&' and display it as '&'
    right away, i.e. before submitting.

    So my point, which I also tried to illustrate with a little program
    in another post in this thread, is that there is never a need for the
    Perl program to do any "reverse conversion" of HTML entities.
    No comments.
     
    Gunnar Hjalmarsson, Aug 18, 2004
    #15
  16. Nothing new there, then... :-}
    Spot on.
    As a matter of principle you're correct here. But that isn't quite
    true in practice, as I'll deal with in a moment.

    As usual, it's all a matter of dividing the problem up into its
    component parts, and understanding how each one works separately,
    before assembling them into a working application.

    But, over and above this, if folks go pasting weird characters into
    their form submission (and there's no way you can stop them doing so),
    then browsers do strange things with them. As the Perl Encode
    documentation so engagingly remarks:

    It is beyond the power of words to describe the way HTML
    browsers encode non-ASCII form data.

    - http://www.perldoc.com/perl5.8.0/lib/Encode/Supported.html

    And there are some browsers (or should I say "browser-like operating
    system components"?) which, when the user feeds into a form a
    character which cannot be represented in the prevailing character
    encoding, will turn it into or even into &entityname; format
    for submission.

    On arrival at the server, of course, the server-side process can have
    no idea whether the user typed just a curly-quote character, or typed
    the ASCII string “ (ampersand, hash, 8, 2, 2, 0, semicolon). By
    that time they are indistinguishable. The behaviour in this situation
    is undefined anyway, and browser developers have addressed it in
    various different ways as they saw fit.

    But Perl is only a small part of this problem - the major issues
    really need to be hammered out on a suitable WWW-related group.
    Where one might even get referred to my no-longer-quite-new
    tutorial-ish page on the topic,
    http://ppewww.ph.gla.ac.uk/~flavell/charset/form-i18n.html

    have fun
     
    Alan J. Flavell, Aug 18, 2004
    #16
  17. Now we are talking i18n it seems...
    Not even CGI.pm's param() function/method, I presume. ;-)
     
    Gunnar Hjalmarsson, Aug 18, 2004
    #17
  18. anita

    anita Guest

    Sorry did not mean to offend you with "Other person" remark!
    Anyway I think I get it now- script makes it very clear.
    Basically the browser sends back whatver it has DISPLAYED when I say
    submit, not what is in the source. I kept thinking that if it sent the
    browser say a &lt and displayed it as <, then when it came back it
    would still comeback as &lt. Now I see it does not. So what comes back
    is the display of &lt ie., <

    That way the conversion returns it to &lt before saving it again.
    And if the user typed in &lt, that will be sent in as &lt and after
    conversion gets becomes &amp;lt, so gets displayed the same as the
    used typed in.

    Thankyou
    Anita
     
    anita, Aug 18, 2004
    #18
  19. No problem, I was not offended. ( I see now that my harsh comment may
    have made you believe otherwise. Sorry. ;-) )
    Yes, it does. (With the exception of what Alan let us know about
    certain internationalization issues...)
    Suppose you mean before displaying it again...
    Yep.
     
    Gunnar Hjalmarsson, Aug 18, 2004
    #19
  20. If you want to interpret it that way, yes. But many devotees of Bill
    have no idea that curly quotes, trademark signs etc. can lead to such
    complications; they type them in quite happily on the client side
    (there's nothing you can do to prevent them), and then when it gets to
    the server side process, it's left to the programmer to pick up the
    pieces. That was the issue that I was trying to bring out in this
    comment.
    You know as well as I do that CGI.pm isn't telepathic: it gets fed
    exactly the same data stream as any other CGI process would get fed.

    It's a pity that an extension mechanism to the %xx URL encoding
    definition didn't get defined in good time, to deal with this
    situation unambiguously (analogous to Perl's wide character
    constants).
     
    Alan J. Flavell, Aug 19, 2004
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.