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]
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
(Randal L. Schwartz) schrieb:
David == David Cantrell [EMAIL PROTECTED] writes:
David That's two tasks. It should be two modules.
No, it's an *integrated* task. The form-generation stuff needs tight
coupling
with the getting (and setting) of the incoming param values.
A separate module, say HTML::Formgenerator, could easily use CGI.pm (or
Web.pm,...) to get and set parameters:
$value = $query-param('foo');
$query-param('foo','an','array','of','values');
I see no need to integrate those modules.
Regards
--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]
Re: the CGI.pm in Perl 6
Steffen Schwigon schrieb: Thomas Wittek [EMAIL PROTECTED] writes: An other acceptable solution would be to create a backwards compatible P6 CGI.pm and create a new Web.pm with an all new interface, like Mark suggested. I would strongly expect the CGI module to do the same as it did for the last 200 years and create another name for any new school web development. Catalyst, Jifty, Acme, Acyou, SillyIdol, WhatEver. So we might agree ;) Catalysy, Jifty [..] are all higher level complete frameworks. I used CGI.pm for rather lower level tasks (POST/GET-parsing, HTTP redirects, ...) than as a foundation to build complete applications (where the higher level framework come in). So I think that there should be a (well designed) module for those lower level (donkeywork) tasks and only for those (so definitely no HTML-generation...). Other frameworks (or simple CGI-scripts or even a backwards compatible CGI.pm) could be built upon this foundation. -Thomas
Re: the CGI.pm in Perl 6
Trey Harris schrieb: I agree with the sentiment, but as a practical matter, not having HTML methods in CGI.pm could drastically limit Perl 6 adoption. Oh well. I thought it was common sense that it's a bad idea to mix code and markup. Who really wants to do itself this pain should use a separate module for that imho (or better a templating system like Template Toolkit). If Perl 5 programmers get used to how they can mechanistically port their programs to Perl 6, they will do so with the same sort of ah-hah moments you've posted about on the Pugs blog, and it will be a good experience. They can do: use perl5:CGI; if they want that legacy support. If Perl6 CGI.pm is intended to be the successor of the P5 CGI.pm (the quasi-standard for Perl web programming) is should really get a modern design. An other acceptable solution would be to create a backwards compatible P6 CGI.pm and create a new Web.pm with an all new interface, like Mark suggested. But then this new module cannot profit of the popularity of the name CGI.pm and many people will say Ah, Perl6 web development is stuck at the 10 years old Perl5 CGI.pm interface. I'll use (python|ruby( on rails)?|.+). That would be sad. now: use CGI; use CGI::HTMLgenerators; # Available separately, deprecated That'd be ok. Just my 2ct. -Thomas
Re: class introspection and extention
max demmelbauer schrieb: * how can i serialize objects (like the use Storable qw(freeze thaw) in perl5.8) Try $object.perl(.say) as stated in http://svn.openfoundry.org/pugs/docs/articles/tpr.pod (or http://gedankenkonstrukt.de/perl6doc/articles/tpr.html ;) ) -Thomas
Re: $1,000 prize for Perl 6 Wiki written in Perl 6
Juerd schrieb: * Markdown does not have tables. * Textile does not have paragraphs in table cells. * Kwiki does not have paragraphs in table cells. Unless someone comes up with another way to do side-by-side layouts (extremely useful for showcasing differences between Perl 5 and Perl 6), all of these formats are not suitable. I suppose doing it the Perl-way: Stealing the best of each syntax, adding what's missing. I don't think that we have to choose an existing syntax, but can create one that combines the best features of the existing ones. Of course, this would be more work. Probably it will not be easy to get a common agreement of what's best. Additionally the mixed up syntax shouldn't look too inconsistent - but that won't be too hard I think. Also some restrictions have to be considered. E.g. if we want to allow block oriented parsing (nested blocks in other blocks), the syntax must be unambiguous on how to detect blocks (within other blocks). That's mainly what I did as stated in my first post[1]. Look at several wiki-syntaxes and combine, what _I_ think is the syntax suited best for a wiki. And I think that such a (then collaborative) process might be a good idea for the definition of the syntax of this wiki. -Thomas
Re: $1,000 prize for Perl 6 Wiki written in Perl 6
Damn, forgot the link. Thomas Wittek schrieb: That's mainly what I did as stated in my first post[1]. [...] [1]: news://nntp.perl.org:119/[EMAIL PROTECTED]
