use perl5:CGI as a solution (was: Re: the CGI.pm in Perl 6)

[Mark Stosberg]

Aankhen wrote:
>
> The major feeling was that there should be no CGI.pm (if someone was
> hellbent on using it, they could use the Perl 5 module).  

In theory, "use perl5:CGI" could be a fine solution. In practice, it
hasn't worked out well for me. Even something that seems simple like
passing a hashref to Perl 5 is not documented now. In summary, I found
it easier to update CGI.pm p6 to meet my needs than to 'use perl5:CGI'
to meet my needs. I think the reality it is yet to been seen now well
calls to Perl 5 modules can work for the general case.

Mark

Re: the CGI.pm in Perl 6

[Fagyal Csongor]

> Randal L. Schwartz wrote:
>
>> The thing that CGI.pm does is put in one place everything you need for
>> a simple web form.  And there's an amazing number of applications for
>> this... putting a "contact us" page on an otherwise static site comes
>> to mind immediately.
>>
>> Sure, if you're building a complex shopping cart application, you're
>> gonna reach for Jifty or Catalyst, or at least roll your own with
>> Template Toolkit or Mason, and you'd be silly to use either CGI.pm's
>> parsing or HTML generation in those cases.
>
> You seem to be forgetting the case in the middle - a small dynamic site.
IMHO that is: "most sites".

>   My weapons of choice for that are CGI.pm to parse requests and
> Template Toolkit to stuff the relevant content into templates.
That's why I use CGI::Lite - no fancy HTML, only a lightweight module with
themost important features. (Gee, I am emitting WML sometimes!)

And let me add this as a side note:
http://www.w3.org/CGI/
IMHO a module should do what its name stands for.

Surely, when I do something with CGI, I also do HTML generation in 99% of
the time. But as the matter of fact, I also use DBI in 99% of the time, so
why not put DBI into CGI.pm, too? ;)

[...]

>> But don't throw out the simplicity of CGI.pm's basic task handling:
>> parsing the incoming parameters (including file upload), and
>> generating sticky forms and other common HTML elements.
>
> That's two tasks.  It should be two modules.
Absolutely.

> I suppose you could argue that generating  tags specifically and
> all their baggage like s might fall under its remit (they are,
> after all, what generates the fancy requests that are CGI's bread and
> butter), but generating  tags is most definitely not anything to do
> with CGI.
Also consider that handling the "input part" of CGI is very
straightforward. No matter what system/language you use, you basically do
the same thing (parse/access GET/POST, the ENV variables, etc.) On the
other hand, handling the output is much more dubious - besides setting the
content type on some other headers, there are dozens of ways to
handle/mangle the content you output. Perl5's CGI.pm provides a way, but
that is IMHO just a legacy API Perl6 has nothing to do with. Basically
everyone who use CGI.pm use ->param() - but only a few use ->h1(), for
example. (IMHO if something beyond CGI input handling must go into CGI.pm,
then that is cookie handling - but that's another story.)

Just my two cents.
- Fagzal

Re: the CGI.pm in Perl 6

[David Cantrell]

Randal L. Schwartz wrote:


The thing that CGI.pm does is put in one place everything you need for a
simple web form.  And there's an amazing number of applications for
this... putting a "contact us" page on an otherwise static site comes to mind
immediately.

Sure, if you're building a complex shopping cart application, you're gonna
reach for Jifty or Catalyst, or at least roll your own with Template Toolkit
or Mason, and you'd be silly to use either CGI.pm's parsing or HTML generation
in those cases.


You seem to be forgetting the case in the middle - a small dynamic site. 
 My weapons of choice for that are CGI.pm to parse requests and 
Template Toolkit to stuff the relevant content into templates.  Frankly, 
to use something heavier when I don't have to (and TT is already 
somewhat heavy for my tastes) would be silly.  And to have a plethora of 
little scripts each using CGI.pm to parse requests and to then generate 
the appropriate HTML, instead of having *one* script which uses TT would 
be, frankly, insane.



But don't throw out the simplicity of CGI.pm's basic task handling: parsing
the incoming parameters (including file upload), and generating sticky forms
and other common HTML elements.


That's two tasks.  It should be two modules.

I suppose you could argue that generating  tags specifically and 
all their baggage like s might fall under its remit (they are, 
after all, what generates the fancy requests that are CGI's bread and 
butter), but generating  tags is most definitely not anything to do 
with CGI.


--
David Cantrell | Enforcer, South London Linguistic Massive

  All praise the Sun God
  For He is a Fun God
  Ra Ra Ra!

Re: more on perl5 modules

[A. Pagaltzis]

* Richard Hainsworth <[EMAIL PROTECTED]> [2006-09-18 15:20]:
> I copied your neat program into a file, called it gtk2test.p6
> and got
> pugs gtk2_test.p6
> ***
>unexpected ":"
>expecting term postfix, operator, ";" or end of input
>at gtk2_test.p6 line 2, column 56

Note my translation was purely based on what I picked up, and
completely untested. Debug as needed to fix it.

Regards,
-- 
Aristotle Pagaltzis // 

Re: more on perl5 modules

[Juerd]

Richard Hainsworth skribis 2006-09-18 17:18 (+0400):
> However, I am using pugs from the debian package and not directly from 
> the repository. So perhaps, the problem is I am not using the latest 
> version of pugs.

That version is rather old in our universe :)
-- 
korajn salutojn,

  juerd waalboer:  perl hacker  <[EMAIL PROTECTED]>  
  convolution: ict solutions and consultancy <[EMAIL PROTECTED]>

Re: more on perl5 modules

[Richard Hainsworth]

I copied your neat program into a file, called it gtk2test.p6 and got
pugs gtk2_test.p6
***
   unexpected ":"
   expecting term postfix, operator, ";" or end of input
   at gtk2_test.p6 line 2, column 56

However, I am using pugs from the debian package and not directly from 
the repository. So perhaps, the problem is I am not using the latest 
version of pugs.


Regards,
Richard

A. Pagaltzis wrote:

* Richard Hainsworth <[EMAIL PROTECTED]> [2006-09-17 18:05]:
  

The .can workaround doesnt seem to work for more complex
modules.



Err, the .can workaround is a way to get past missing sub
exports. Methods are never exported. Why are you using the
workaround for sub exports on methods.

  

Here is a working perl5 program that puts up a message with two
buttons.

use strict;
use Gtk2 -init;
use Gtk2::Ex::Dialogs(destroy_with_parent=>-1, modal=>-1, no_separator => 0);
my $window = Gtk2::Window->new('toplevel');
Gtk2::Ex::Dialogs->set_parent_window( $window );
my $r = Gtk2::Ex::Dialogs::Question->ask( "Is Perl only hackers glue?");
if ($r) {print "yes\n";} else {print "no\n";};



Should be simply:

use perl5:Gtk2 '-init';
use perl5:Gtk2::Ex::Dialogs :destroy_with_parent( -1 ) :modal( -1 ) 
:!no_separator;
my $window = Gtk2::Window.new( 'toplevel' );
Gtk2::Ex::Dialogs.set_parent_window( $window );
my $r = Gtk2::Ex::Dialogs::Question.ask( "Is Perl only hackers glue?" );
say $r ?? 'yes' !! 'no';

Regards,
  

Re: perl6 and a multi-interpreted-language example

[Ben Morrow]

Quoth [EMAIL PROTECTED] (Larry Wall):
> Okay, combining all these approaches minimalistically but without
> golfing we get something like:
> 
> my @numbers = sort { rand }, constant @goal = 1..9;
> my $steps = 0;
> 
> until @numbers ~~ @goal {
>say [EMAIL PROTECTED];
>@numbers[ 0 ..^ prompt "Reverse how many? " ] .= reverse;
>++$steps;
> }
> 
> say "Done! That took you $steps steps.";

Can I just say: I've never written a line of Perl6, and I love it
already :).

Ben

-- 
I've seen things you people wouldn't believe: attack ships on fire off
the shoulder of Orion; I watched C-beams glitter in the dark near the
Tannhauser Gate. All these moments will be lost, in time, like tears in rain.
Time to die.[EMAIL PROTECTED]