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. Advertising

  2. anita

    Tore Aursand Guest

    On Tue, 17 Aug 2004 14:03:57 -0700, anita wrote:
    > 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.


    Check out the HTML::Entities module. It will let you encode any "special"
    characters to HTML.


    --
    Tore Aursand <>
    "The road to hell is full of good intentions." (Bruce Dickinson)
     
    Tore Aursand, Aug 17, 2004
    #2
    1. Advertising

  3. anita wrote:
    > 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.


    If you save before converting to HTML entities, you don't need to
    convert those characters back.

    > 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.


    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
    Email: http://www.gunnar.cc/cgi-bin/contact.pl
     
    Gunnar Hjalmarsson, Aug 17, 2004
    #3
  4. anita <> wrote:

    > I am trying to get to edit my perl scripts through a form.



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

    I am sensing an X-Y problem here...


    --
    Tad McClellan SGML consulting
    Perl programming
    Fort Worth, Texas
     
    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 am sensing an X-Y problem here...


    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 am sensing an X-Y problem here...


    I dont get it. What do you mean X-y problem ?
    Thanks
     
    anita, Aug 18, 2004
    #6
  7. XY problem (was Re: editing perl script through TEXTAREA)

    anita <> wrote:
    > Lets just say I am editing some file, any file through the form...


    >> I am sensing an X-Y problem here...

    >
    > I dont get it. What do you mean X-y problem ?



    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 SGML consulting
    Perl programming
    Fort Worth, Texas
     
    Tad McClellan, Aug 18, 2004
    #7
  8. anita

    gnari Guest

    "Abigail" <> wrote in message
    news:...
    > anita () wrote on September MCMXCIII in
    > <URL:news:>:
    > --
    > -- I am trying to get to edit my perl scripts through a form. I'm loading
    >
    >
    > That sounds about as cumbersome and useful as eating soup through
    > the keyhole of a door.


    naw, you just use one of those bendy straws.

    gnari
     
    gnari, Aug 18, 2004
    #8
  9. anita wrote:
    > One other person suggested that I save before converting. I am not
    > sure what was meant by that.


    Suppose I'm that "other person". Post your code if you want me to
    explain further.

    > From what I understand, my file has to be processed to replace all
    > the special HTML chars before display (so browser wont complain)


    No, your file does not need to be processed. Your *data*, whereever it
    come from, need to be processed before display.

    > 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...


    No. The form takes care of that.

    --
    Gunnar Hjalmarsson
    Email: http://www.gunnar.cc/cgi-bin/contact.pl
     
    Gunnar Hjalmarsson, Aug 18, 2004
    #9
  10. anita

    Tore Aursand Guest

    On Tue, 17 Aug 2004 20:46:05 -0700, anita wrote:
    > 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.


    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 <>
    "When you love someone, all your saved-up wishes start coming out."
    (Elizabeth Bowen)
     
    Tore Aursand, Aug 18, 2004
    #10
  11. Gunnar Hjalmarsson wrote:
    > anita wrote:
    >> One other person suggested that I save before converting. I am not
    >> sure what was meant by that.

    >
    > Suppose I'm that "other person". Post your code if you want me to
    > explain further.


    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
    Email: http://www.gunnar.cc/cgi-bin/contact.pl
     
    Gunnar Hjalmarsson, Aug 18, 2004
    #11
  12. anita

    Guest

    (anita) wrote:
    > 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...


    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

    --
    -------------------- http://NewsReader.Com/ --------------------
    Usenet Newsgroup Service $9.95/Month 30GB
     
    , Aug 18, 2004
    #12
  13. wrote:
    > From what I understand, the textarea() sub (or method) of CGI
    > module will automatically do this conversion for you on the way to
    > html,


    Sounds plausible.

    > and the param() sub or method (or something upstream of it) will
    > automatically do the reverse conversion on the way back.


    Don't understand. What do you mean by that?

    --
    Gunnar Hjalmarsson
    Email: http://www.gunnar.cc/cgi-bin/contact.pl
     
    Gunnar Hjalmarsson, Aug 18, 2004
    #13
  14. anita

    gnari Guest

    "Gunnar Hjalmarsson" <> wrote in message
    news:...
    > wrote:
    > > From what I understand, the textarea() sub (or method) of CGI
    > > module will automatically do this conversion for you on the way to
    > > html,

    >
    > Sounds plausible.
    >
    > > and the param() sub or method (or something upstream of it) will
    > > automatically do the reverse conversion on the way back.

    >
    > Don't understand. What do you mean by that?


    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. gnari wrote:
    > Gunnar Hjalmarsson wrote:
    >> wrote:
    >>> and the param() sub or method (or something upstream of it)
    >>> will automatically do the reverse conversion on the way back.

    >>
    >> Don't understand. What do you mean by that?

    >
    > he means that a character like '&' will be sent by the browser
    > encoded (&amp;), but param() will return it as '&' again.


    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.

    > so if you use textarea() and param(), you never have to worry about
    > it.


    No comments.

    --
    Gunnar Hjalmarsson
    Email: http://www.gunnar.cc/cgi-bin/contact.pl
     
    Gunnar Hjalmarsson, Aug 18, 2004
    #15
  16. On Wed, 18 Aug 2004, Gunnar Hjalmarsson wrote:

    > There is a lot of confusion here.


    Nothing new there, then... :-}

    > 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 '&'.


    Agreed.

    > 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.


    Spot on.

    > 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.


    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. Alan J. Flavell wrote:
    > 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.


    Now we are talking i18n it seems...

    > 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).


    Not even CGI.pm's param() function/method, I presume. ;-)

    --
    Gunnar Hjalmarsson
    Email: http://www.gunnar.cc/cgi-bin/contact.pl
     
    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. anita wrote:
    > Sorry did not mean to offend you with "Other person" remark!


    No problem, I was not offended. ( I see now that my harsh comment may
    have made you believe otherwise. Sorry. ;-) )

    > Basically the browser sends back whatver it has DISPLAYED when I
    > say submit, not what is in the source.


    Yes, it does. (With the exception of what Alan let us know about
    certain internationalization issues...)

    > That way the conversion returns it to &lt before saving it again.


    Suppose you mean before displaying 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.


    Yep.

    --
    Gunnar Hjalmarsson
    Email: http://www.gunnar.cc/cgi-bin/contact.pl
     
    Gunnar Hjalmarsson, Aug 18, 2004
    #19
  20. On Wed, 18 Aug 2004, Gunnar Hjalmarsson wrote:

    > Now we are talking i18n it seems...


    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.

    > > 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).

    >
    > Not even CGI.pm's param() function/method, I presume. ;-)


    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. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. dpackwood
    Replies:
    3
    Views:
    1,805
  2. Augustus
    Replies:
    1
    Views:
    357
    Ken Schaefer
    Sep 10, 2003
  3. Textarea Inside of a textarea

    , Feb 4, 2006, in forum: ASP General
    Replies:
    6
    Views:
    335
    Anthony Jones
    Feb 5, 2006
  4. Lindsey
    Replies:
    2
    Views:
    121
    Markus Ernst
    May 7, 2004
  5. Replies:
    1
    Views:
    315
    Bart Van der Donck
    Jul 4, 2007
Loading...

Share This Page