Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Ian Langworth wrote:
It sounds like the name of HTTP is more appropriate:
HTTP::Request
...uri, pathinfo, params, method, headers, etc.
HTTP::Request::Session
...adds to HTTP::Request to provide session() method
HTTP::Response
...response code, content, headers, etc.
HTTP::Response::JSON
...extends response.write() to encode JSON
Maybe CGI.pm could adapt these to the CGI environment and ecapsulate
their functionality.
Maybe it's too servlety.
It is :)
It is probably the *proper* way, but definetely not the *efficient* way.
You rarely do real HTTP handling when you use CGI.
A general, simple CGI handling module fits into 200 lines, including
POD. Imagine like
sub parseQueryStupidAndWrong {
my $self = shift;
$ENV{'QUERY_STRING'} || return {};
my @pairs = split(//, $ENV{'QUERY_STRING'});
my %query;
foreach my $pair (@pairs) {
my ($key, $value) = split (/=/, $pair);
$key =~ tr/+/ /;
$key = whatever::url_decode($key);
$value =~ tr/+/ /;
$value = whatever::url_decode($value);
if ($query{$key}) {
$query{$key} .= , $value;
} else {
$query{$key} = $value;
}
}
return \%query;
}
You don't really need more. IMHO a CGI module
parses/preprocesses/decodes/etc. all incoming parameters (POST, GET,
COOKIES), and that's it. It might give some useful other routines (e.g.
url encoding / decoding, various ways to mix GET+POST, set content types
more easily, etc.), but other than that, it should be very lightweight
and easy to use.
- Cs.
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Fagyal Csongor schrieb: Ian Langworth wrote: A general, simple CGI handling module fits into 200 lines, including POD. [..] You don't really need more. IMHO a CGI module parses/preprocesses/decodes/etc. all incoming parameters (POST, GET, COOKIES), and that's it. I can support this statement: In a ~30k lines (incl POD) web project I actually use CGI.pm mostly for parameter parsing: $ grep -ri 'cgi-' * | grep -v new | wc -l 97 Wehereas I hardly use for anything else: $ grep -ri 'cgi-' * | grep -v new | grep -v param | wc -l 7 4 of these 7 matches address file upload handling, the other 3 match in an other custom module with the name *::CGI - not CGI.pm. But I think that it would be a good idea to create a clean, servlety foundation, upon which you still can implement a 200 lines CGI.pm/Web.pm/foo.pm that covers the most common web-request tasks. Regards -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Fagyal Csongor skribis 2006-09-20 11:28 (+0200): You rarely do real HTTP handling when you use CGI. You may not, but many people do a lot of these things. And when you don't, the datastructures are currently parsed and filled anyway, so I don't know why you say it'd be too inefficient. A general, simple CGI handling module fits into 200 lines, including POD. Imagine like That's not CGI handling, that's form parameter parsing. CGI, and web programming, is much more than that. You don't really need more. I think you mean: I don't really need more. Many people do need a whole lot more, and CGI.pm does do a whole lot more. Just not in a nicely organized set of classes. It's unfortunate that it mostly lets the user handle headers that are communicated through ENV, precisely because that's part of the CGI spec, and not common to other kinds of web programming, so it's specifically a job for a module called CGI.pm It might give some useful other routines (e.g. url encoding / decoding, various ways to mix GET+POST, set content types more easily, etc.), but other than that, it should be very lightweight and easy to use. I agree that things should be lightweight and easy to use. But in Perl 6, that doesn't mean that you should avoid nicely structured OO. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Erm...
Sorry for the bandwith usage again, but what about something like
class CGI
is CGI::Base
does CGI::ParamParser
does CGI::HTML
{ ... }
?
To make CGI.pm kind of backward compatible, but separates the layers.
(Please excuse my bad syntax/semantics.)
- Fagzal
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Fagyal Csongor wrote: # imagine something like: $cgi = new CGI; $html = HTML::CGI-new($cgi); $html-popup_menu( ... ); # I won't do this, but others might... :) My biggest gripe with CGI's html methods is the inconsistency in their names. I use them every now and then, but I always have to go and look up the documentation. It's textfield isn't it? So that would make this one passwordfield: nope, it's password_field. popup_menu so scrolling_menu... Ah, no: scrolling_list. How do I make it multi-select again? I'd love the Perl 6 version to have a compatibility mode where it returned the methods we're all used to, but encouraged something which was more intuitive. Perhaps that would be better in two modules which essentially did the same thing though. All the best, J
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Jacinta Richardson skribis 2006-09-21 0:13 (+1000): My biggest gripe with CGI's html methods is the inconsistency in their names. I use them every now and then, but I always have to go and look up the documentation. It's textfield isn't it? So that would make this one passwordfield: nope, it's password_field. popup_menu so scrolling_menu... Ah, no: scrolling_list. How do I make it multi-select again? Yes, this needs to be redesigned completely. Are you volunteering? I'd love the Perl 6 version to have a compatibility mode where it returned the methods we're all used to, but encouraged something which was more intuitive. Perhaps that would be better in two modules which essentially did the same thing though. The compatibility mode is perl5:CGI, that loads the old Perl 5 CGI.pm. There's little need for us to port bad things to Perl 6. Peoplo who really want or need to use them can, and we should concentrate on creating something that's GOOD for new code. This said, I do think it'd be wise to document changes in accessible tables. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: Trying to make a new operator
Thanks for help. For anyone else, the following works.
sub infix:grew_by_to {...};
(32 grew_by_to 48).say;
sub infix:grew_by_to ($left, $right) {
return ($right/$left - 1) * 100 ~ '%';
};
Yuval Kogman wrote:
On Sun, Sep 17, 2006 at 16:35:39 +0100, Daniel Hulme wrote:
What am I doing wrong?
Sounds like you need to define (or at least declare) the new operator
before you use it. Perl 6, like Perl 5 compiles with a single pass, so
when you are using your random operator, it hasn't yet read the
declaration further down the file.
s/use/parse/;
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Juerd wrote: [...] Fagyal Csongor skribis 2006-09-20 15:43 (+0200): Inefficient was probably a bad choice of word. I would rather say: I would not like to see Perl6's CGI.pm as a monster module, which has one part everyone uses, and one hundred other parts that some uses, because I feel those parts should be put into other modules. Perl 6's Web toolkit, even with all these classes, is likely to be much lighter than Perl 5's CGI.pm with :standard. I guess that's one of the reasons we are heading from 5 to 6 :) But note that especially if it is a well designed bundle of classes/roles, you can pick exactly those things that you need, and leave all others out. That's part of the reason why you should separate things. And here is another reason :) [...] If we talk about nicely structured OO, I can see a few ways: - CGI.pm include something like CGI::HTML, to get rid of the HTML generating part, or maybe even separating CGI::HTML and CGI::Request s:g/CGI/Web/, please! mod_perl has nothing to do with CGI (except perhaps for its compatibility syntax), and neither does HTTP::Daemon. We should write generic code, suitable for any implementation. I'm thinking of: Web::Init::CGI # Initializer for CGI requests Web::Init::FastCGI # Initializer for FastCGI requests Web::Init::ModPerl # Initializer for ModPerl requests Web::Request# Request objects Web::Response # Response objects Web::Session# Session objects Web::HTML # HTML generation Web::Util # HTML-entities, URI-encoding, etc Web # utility module that mostly loads other modules Hmmm. A very sound idea. Reorganising the CPAN namespace :) (This CGI/HTTP/LWP/HTML/etc. got a bit confusing as it grew.) I would say, maybe add Web::Tools::* so that others can add various useful (and not that useful) modules without mixing up everything. And maybe expand Web::HTML something like: Web::Markup::HTML Web::Markup::XHTML Web::Markup::WML etc... But that's might as well be too much. So is Web::Init::* class supposed to be selected by Web, and Web::Init(::*) used by e.g. Web::Request Web::Response, so it all becomes transparent? Yes. I'm talking about a web development toolkit, that does at least what CGI.pm did, and not about CGI as a namespace, because I think that's an incredibly bad thing anyway. I absolutely agree. - Fagzal
Perl6 style-guide
Hi, I was wondering if there is (or there should be) a documentation on how to elegantly write Perl6 code. I am afraid that when I will be starting to write Perl6 code, it will be too much Perl5-ish, and I will end up rewriting my code in every 3 months because I hate when my code is not elegant (at least to my own standards). I was wondering that some - maybe @Larry - already have (mosf ot) Perl6 in their heads, so they could create such a document/recommendation before Perl6 gets used widely, and the coding style gets distorted. Or shall we just leave this to the community? Maybe this documentation shouldn't/can't be written yet? Shall we let Perl6-style grow from usage in 1-2 years, and create a guide like this then, when things mature? - Fagzal
Re: Perl6 style-guide
On 9/20/06, Fagyal Csongor [EMAIL PROTECTED] wrote: I was wondering if there is (or there should be) a documentation on how to elegantly write Perl6 code. yes, there should be. I am afraid that when I will be starting to write Perl6 code, it will be too much Perl5-ish, and I will end up rewriting my code in every 3 months because I hate when my code is not elegant (at least to my own standards). i think that's a problem you'll share with many other folks, as *very few* have written anything of substance in perl 6 so far... and the design is still changing. I was wondering that some - maybe @Larry - already have (mosf ot) Perl6 in their heads, so they could create such a document/recommendation before Perl6 gets used widely, and the coding style gets distorted. i think larry's pretty busy doing what he should be doing at this point... designing. Or shall we just leave this to the community? Maybe this documentation shouldn't/can't be written yet? Shall we let Perl6-style grow from usage in 1-2 years, and create a guide like this then, when things mature? don't just leave this to the community. take part! take advantage of the perl 6 wiki (http://rakudo.org/perl6/index.cgi) and create a page describing the task. write some code yourself. ask folks to contribute, and fix the existing code or add their own. create an outline of what you'd like to see there... and have fun! be the community. ~jerry
Re: the CGI.pm in Perl 6
* Juerd [EMAIL PROTECTED] [2006-09-20 22:25]:
I think it's time we moved away from the param method, and
started using a hash.
I don’t know about that. The `param` method has the nice property
that it allows you to pretend everything’s a single value or to
use multi-valued params, at your own discretion, at any time,
with no change of syntax.
my $foo = $q-param( 'foo' );
my @bar = $q-param( 'bar' );
If you tried to do this with a hash, you’d get
my $foo = $q-param-{ 'foo' }[0];
# my ( $foo ) = @{ $q-param-{ 'foo' } };
my @bar = @{ $q-param-{ 'bar' } };
You could try making the type of the value depend on arity and be
either a scalar or an arrayref, but then you get V*E*R*Y U*G*L*Y
client code that needs to constantly check whether it’s dealing
with one or the other.
Does Perl 6 offer any help in making access to a HoL look like
the first example? If not, then no, let’s please stick with the
`param` protocol.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
OT: Re: Web development I: Web::Toolkit
A. Pagaltzis schrieb: On top of this, roughly 80% (or so it sometimes feels) of the useful attributes defined in HTML do not have any tangible browser support (such as `cite` on `blockquote`/`q`, or `datetime` on `ins`/`del`). At least without CSS. You can use those tags to create a more semantic markup which can be styled using CSS. Of course there is more than just design. The cite attribute of the blockquote tag isn't supported by any browser AFAIK. -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: the CGI.pm in Perl 6
On Thu, Sep 21, 2006 at 12:43:41AM +0200, Juerd wrote:
: my @bar = @{ $q-param-{ 'bar' } };
:
: my @bar = $q.parambar.'@';
: my @bar = @ $q.parambar;
That should work but my preference is just
my @bar = $q.parambar[];
That is, empty .[] has the same arrayifying semantics as @. (This is
currently b0rken in pugs though.) Likewise .{} is equivalen to %.
Larry
Re: Web development I: Web::Toolkit
On 9/20/06, A. Pagaltzis [EMAIL PROTECTED] wrote: I did qualify my statement. I'm sorry, I must have missed it. :-) Aankhen
