Re: Loading Index.pl as the Root File
"Jeffrey W. Baker" <[EMAIL PROTECTED]> writes: > On Mon, 23 Apr 2001, Al Morgan wrote: > > > I've been studying Slash to better understand mod_perl. I think I > > understand everything that happens in the config file, except for this: > > That is probably the single worst way to learn about mod_perl. Slash is > the only program that makes me physically ill. It is the single worst > piece of programming ever released upon the world. No, that would be Matt's Script Archive. Have you seen Slash 2.0? Even uses the Template Toolkit. -- Dave Hodgkinson, http://www.hodgkinson.org Editor-in-chief, The Highway Star http://www.deep-purple.com Interim CTO, web server farms, technical strategy
Re: Directive Undefined
> At least two people responded to my last message telling me that they > didn't like Slash much; it was a horrible piece of code. Are you > refering to it as a general piece of Perl code, or how it deals with > mod_perl? If the latter, where I can find some good code to look it? Once you do something not very cleanly people will remember for a long time. I didn't check the latest versions of it, I suppose it's much much better now. It's rewritten by different people too. > Also, Apache can't recognize the directive; it gives me the > following error: > > Invalid command '', perhaps mis-spelled or defined by a module not > included in the server configuration Please read the documentation before posting. e.g. see: http://perl.apache.org/guide/config.html#Enabling > mod_perl.c seems to be installed. 'httpd -l' shows it listed at the > bottom. I've added the directive 'AddModule mod_perl.c' to httpd.conf, > and it doesn't throw an error, so I know /something/ is being loaded, > but the directive still doesn't work. > > Am I missing something? see above _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Directive Undefined
At least two people responded to my last message telling me that they didn't like Slash much; it was a horrible piece of code. Are you refering to it as a general piece of Perl code, or how it deals with mod_perl? If the latter, where I can find some good code to look it? Also, Apache can't recognize the directive; it gives me the following error: Invalid command '', perhaps mis-spelled or defined by a module not included in the server configuration mod_perl.c seems to be installed. 'httpd -l' shows it listed at the bottom. I've added the directive 'AddModule mod_perl.c' to httpd.conf, and it doesn't throw an error, so I know /something/ is being loaded, but the directive still doesn't work. Am I missing something? Thanks, Al Morgan [ [EMAIL PROTECTED] ]
Re: ANNOUNCE: Apache::Reload 0.07
On Mon, 23 Apr 2001, Matt Sergeant wrote: > On Mon, 23 Apr 2001, [EMAIL PROTECTED] wrote: > > > > > Would Apache::Reload be helpful in the case where you have > > multiple virtualhosts which each want their own @INC ? > > I tried fixing this problem with a previous release, but gave up > > when I realized the implication of all those use lib () > > directives in my modules. > > > > If you think so, maybe you should add something to this effect to the docs. > > I think Stas had something he was looking at for doing this. Stas? was I? May be you confuse me with someone else? I've submitted you a patch which solves the problem, where some module gets required relative to '.', and then if the code does chdir() elsewhere, reload was failing, because it was registering a relative to '.' path. I've checked -- this patch is now in :) Currently you can see in the guide various solutions for INC and virtual hosts. But none is good for production. mod_perl 2.0 solves this problem, come in and help us to debug/develop it so it'll get out faster. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Can AxKit be used as a Template Engine?
On Mon, 23 Apr 2001, Matt Sergeant wrote: > The alternative of course it to just plug them both > together - AxKit and Mason play nicely together using > Apache::Filter (though it's a bit slow). with version 2.3 of the java servlet api, you can now create input and output filters, just like the filters in apache 2.0. so your servlet can do the "mason" stuff and an output filter can do the "cocoon" stuff. i feel justified in throwing this out because i'm finally back to work on the perl servlet engine :)
Re: Loading Index.pl as the Root File
On Mon, 23 Apr 2001, Al Morgan wrote: > I've been studying Slash to better understand mod_perl. I think I > understand everything that happens in the config file, except for this: That is probably the single worst way to learn about mod_perl. Slash is the only program that makes me physically ill. It is the single worst piece of programming ever released upon the world. > > > SetHandler "perl-script" > PerlHandler Slash::Host::slashcode::rootHandler > > The "~" means to use a regular expression to match the path part of the URI. The regular expression "^/$" matches only exactly the string consisting of a single slash character, so there is no point to using a regular expression there (as far as I can tell). Also, in Apache 1.3, is preferred over . At least now we know why slashdot is so slow: regex matchine on every request. > Apparently, whenever the user reqests the root document (normally > index.html), it calls rootHandler, which redirects it to index.pl. My > question is: What does the ~ "^/$" mean? I don't quite understand how > they are doing what they're doing. -jwb
Re: Loading Index.pl as the Root File
- Original Message - From: "Al Morgan" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, April 23, 2001 10:11 PM Subject: Loading Index.pl as the Root File > I've been studying Slash to better understand mod_perl. I think I > understand everything that happens in the config file, except for this: > > > SetHandler "perl-script" > PerlHandler Slash::Host::slashcode::rootHandler > > > Apparently, whenever the user reqests the root document (normally > index.html), it calls rootHandler, which redirects it to index.pl. My > question is: What does the ~ "^/$" mean? I don't quite understand how > they are doing what they're doing. > The "^/$" is a regular expression, signifying that it wants to find the location that matches "/" between the start and the end of the line. So it'll match only your root location. Actually the regular expression is unnecessary here, a would have been enough. Now concerning what it does: it intercepts all requests for the root location (for example www.example.com/ ), and calls rootHandler, as you said. I don't think the index.html part will ever be handled, as Slash handles the whole request. Now, I would gladly give you any pointers to a good regular expression tutorial, but I don't have any. I am sure that if you search around a little (perl.com or the apache documentation would seem like a good place to start), you can easily find some nice information. Per Einar Ellefsen [EMAIL PROTECTED]
Re: Loading Index.pl as the Root File
Hi there, On Mon, 23 Apr 2001, Al Morgan wrote: > > SetHandler "perl-script" > PerlHandler Slash::Host::slashcode::rootHandler > > > question is: What does the ~ "^/$" mean? It's a match expression. It means match (the tilde character means match) a line containing a string starting (the caret character means the start of the line) with a slash character and ending (the dollar character means the end of the line) right there. Read up on the ways of specifying classes of strings. They are often called "regular expressions". There are lots of good books on the subject. Beware of the differences between Perl regular expressions and those used by other software, such as many Apache modules and Apache itself. 73, Ged.
Re: Loading Index.pl as the Root File
Al Morgan wrote: > I've been studying Slash to better understand mod_perl. I think I > understand everything that happens in the config file, except for this: > > > SetHandler "perl-script" > PerlHandler Slash::Host::slashcode::rootHandler > > > Apparently, whenever the user reqests the root document (normally > index.html), it calls rootHandler, which redirects it to index.pl. My > question is: What does the ~ "^/$" mean? I don't quite understand how > It is a regular expression: the '~' tells apache it is a regex, The '^' says starts with The '$' says ends with So in other words: If the location selected starts and ends with a / (which would normally default to the index.html) it should be processed instead by the command in the Location directive. > they are doing what they're doing. > > Thanks, > > Al Morgan [ [EMAIL PROTECTED] ]
Loading Index.pl as the Root File
I've been studying Slash to better understand mod_perl. I think I understand everything that happens in the config file, except for this: SetHandler "perl-script" PerlHandler Slash::Host::slashcode::rootHandler Apparently, whenever the user reqests the root document (normally index.html), it calls rootHandler, which redirects it to index.pl. My question is: What does the ~ "^/$" mean? I don't quite understand how they are doing what they're doing. Thanks, Al Morgan [ [EMAIL PROTECTED] ]
Re: ANNOUNCE: Apache::Reload 0.07
On Mon, 23 Apr 2001, [EMAIL PROTECTED] wrote: > > Would Apache::Reload be helpful in the case where you have > multiple virtualhosts which each want their own @INC ? > I tried fixing this problem with a previous release, but gave up > when I realized the implication of all those use lib () > directives in my modules. > > If you think so, maybe you should add something to this effect to the docs. I think Stas had something he was looking at for doing this. Stas? -- /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
Re: ANNOUNCE: Apache::Reload 0.07
Would Apache::Reload be helpful in the case where you have multiple virtualhosts which each want their own @INC ? I tried fixing this problem with a previous release, but gave up when I realized the implication of all those use lib () directives in my modules. If you think so, maybe you should add something to this effect to the docs. Regards, Tom On Sun, Apr 22, 2001 at 07:14:34PM +0100, Matt Sergeant wrote: > This is a minor update as promised with some patches from a couple of > sources to help reload when "use lib" is in effect. > > Let me know if it works (or doesn't) please. > > -- > > > /||** Founder and CTO ** ** http://axkit.com/ ** >//||** AxKit.com Ltd ** ** XML Application Serving ** > // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** > // \\| // ** mod_perl news and resources: http://take23.org ** > \\// > //\\ > // \\
Re: Can AxKit be used as a Template Engine?
On 23 Apr 2001, Michael Alan Dorman wrote: > Well I will say that you made an excellent point that hadn't really > occured to me---I use XML + XSL for a lot of stuff (the DTD I use for > my resume is a deeply reworked version of one I believe you had posted > at one time), but not web sites, in part because I'm not currently > obligated to worry about "other devices"---so I don't exactly regret > getting you to clarify things. You may find the following makefile quite useful (I'm thinking of dubbing this AxKit 2.0 :-) # using gnome libxslt XSLT=xsltproc # dependencies for *.html %.html : %.xml %_html.xsl $(XSLT) $*_html.xsl $< > $@ # dependencies for *.wml %.wml : %.xml %_wml.xsl $(XSLT) $*_wml.xsl $< > $@ # list of files all: foo.html bar.html foo.wml bar.wml > Could I suggest that a better tagline would be that AxKit is superior > when creating easily (re-)targetable sites with mostly static content? > It might stave off more ignorant comments. I'll think about adding it to my .sig :-) -- /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
Re: Can AxKit be used as a Template Engine?
On Mon, 23 Apr 2001, Ian Kallen <[EMAIL PROTECTED]> wrote: > Mason and AxKit solve different but related problems. The former a > code-aware component system with process semantics that lend itself to > easily scoping a component's applicability, the latter a > transformation engine. It would be nice to see a framework published > that uses the best of both (sorry, I don't have time to do it myself > :). The Java world suffers from the same disconnect, in fact I think > it's worse there; JSP and Cocoon don't play together (I've never seen > a servlet chainging example that shows them doing so). Actually what I'm looking at and talking to Phillipe about right now is somehow doing the thing Smartworker does, but using XML and transformations, and adding in AxKit's abilities to detect the requesting device and "do the right thing". I think that would be the best way to build large scale web apps for multiple delivery targets. The alternative of course it to just plug them both together - AxKit and Mason play nicely together using Apache::Filter (though it's a bit slow). -- /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
Re: Can AxKit be used as a Template Engine?
Michael Alan Dorman wrote: > Matt Sergeant <[EMAIL PROTECTED]> writes: > > It depends a *lot* on the type of content on your site. The above > > www.dorado.com is brochureware, so it's not likely to need to be > > re-styled for lighter browsers, or WebTV, or WAP, or... etc. So your > > content (I'm guessing) is pure HTML, with Mason used as a fancy way > > to do SSI, with Mason components for the title bars/menus, and so > > on. (feel free to correct me if I'm wrong). > > It is more sophisticated than that, but you're basically right. I do > pull some tagset-like tricks for individual pages, so it's not totally > pure HTML, but yeah, if we wanted to do WebTV we'd be fscked. > > > AxKit is just as capable of doing that sort of thing, but where it > > really shines is to provide the same content in different ways, > > because you can turn the XML based content into HTML, or WebTV HTML, > > or WML, or PDF, etc. > > Ah---well a web site that does all of that isn't what first comes to > mind when someone talkes about doing a "static site"---though now that > you've explained further, I believe I understand exactly what you > intended. > > > I talk about how the current Perl templating solutions (including > > Mason) aren't suited to this kind of re-styling in my AxKit talk, > > which I'm giving at the Perl conference, so go there and come see > > the talk :-) > > Heh. I agree entirely with this assesment---I can conceptualize a way > to do it in Mason, but the processing overhead would be unfortunate, > the amount of handwaving involved would be enormous, and it would > probably be rather fragile. > > > So I take back that people wouldn't be using Mason for static > > content. I was just trying to find a simple way to classify these > > tools, and to some people (I'd say most people), Mason is more on > > the dynamic content side of things, and AxKit is more on the static > > content side of things, but both tools can be used for both types of > > content. > > > > (I hate getting into these things - I wish I'd never brought up > > Mason or EmbPerl) > > Well I will say that you made an excellent point that hadn't really > occured to me---I use XML + XSL for a lot of stuff (the DTD I use for > my resume is a deeply reworked version of one I believe you had posted > at one time), but not web sites, in part because I'm not currently > obligated to worry about "other devices"---so I don't exactly regret > getting you to clarify things. > > Could I suggest that a better tagline would be that AxKit is superior > when creating easily (re-)targetable sites with mostly static content? > It might stave off more ignorant comments. > > Mike. Matt, I've also found your use of "static" to describe "transformable" or "re-targetable"(unfortunate word)" content to be confusing. This discussion helps clarify things, a little. ;-) Ed
Re: Can AxKit be used as a Template Engine?
Mason and AxKit solve different but related problems. The former a code-aware component system with process semantics that lend itself to easily scoping a component's applicability, the latter a transformation engine. It would be nice to see a framework published that uses the best of both (sorry, I don't have time to do it myself :). The Java world suffers from the same disconnect, in fact I think it's worse there; JSP and Cocoon don't play together (I've never seen a servlet chainging example that shows them doing so). On Mon, 23 Apr 2001, Matt Sergeant wrote: > Having said that, it goes the other way too - currently building web > applications is probably a lot easier with Mason than it is with AxKit, > because that's what it was designed for. AxKit has a pretty cool > technology called XSP, which gives you a cold-fusion like system of > inserting tags into your XML for dynamic functionality. But in my opinion > it doesn't scale well (in the development sense, not in the performance > sense) to large applications, because it is inherently a page-based > technology (like PHP, Cold Fusion, JSP, ASP, etc), and I don't think > page-based web development systems scale well to larger applications. I > prefer something that is turned inside-out from the page based view of > things, like MVC. cheers, -Ian -- Ian Kallen <[EMAIL PROTECTED]> | AIM: iankallen
Re: Can AxKit be used as a Template Engine?
Matt Sergeant <[EMAIL PROTECTED]> writes: > It depends a *lot* on the type of content on your site. The above > www.dorado.com is brochureware, so it's not likely to need to be > re-styled for lighter browsers, or WebTV, or WAP, or... etc. So your > content (I'm guessing) is pure HTML, with Mason used as a fancy way > to do SSI, with Mason components for the title bars/menus, and so > on. (feel free to correct me if I'm wrong). It is more sophisticated than that, but you're basically right. I do pull some tagset-like tricks for individual pages, so it's not totally pure HTML, but yeah, if we wanted to do WebTV we'd be fscked. > AxKit is just as capable of doing that sort of thing, but where it > really shines is to provide the same content in different ways, > because you can turn the XML based content into HTML, or WebTV HTML, > or WML, or PDF, etc. Ah---well a web site that does all of that isn't what first comes to mind when someone talkes about doing a "static site"---though now that you've explained further, I believe I understand exactly what you intended. > I talk about how the current Perl templating solutions (including > Mason) aren't suited to this kind of re-styling in my AxKit talk, > which I'm giving at the Perl conference, so go there and come see > the talk :-) Heh. I agree entirely with this assesment---I can conceptualize a way to do it in Mason, but the processing overhead would be unfortunate, the amount of handwaving involved would be enormous, and it would probably be rather fragile. > So I take back that people wouldn't be using Mason for static > content. I was just trying to find a simple way to classify these > tools, and to some people (I'd say most people), Mason is more on > the dynamic content side of things, and AxKit is more on the static > content side of things, but both tools can be used for both types of > content. > > (I hate getting into these things - I wish I'd never brought up > Mason or EmbPerl) Well I will say that you made an excellent point that hadn't really occured to me---I use XML + XSL for a lot of stuff (the DTD I use for my resume is a deeply reworked version of one I believe you had posted at one time), but not web sites, in part because I'm not currently obligated to worry about "other devices"---so I don't exactly regret getting you to clarify things. Could I suggest that a better tagline would be that AxKit is superior when creating easily (re-)targetable sites with mostly static content? It might stave off more ignorant comments. Mike.
Re: Can AxKit be used as a Template Engine?
On 23 Apr 2001, Michael Alan Dorman wrote: > Errr, respectfully, I think you underestimate Mason's capabilities. Not really. I've researched Mason quite a bit, and I talk with Jon every ApacheCon/OSSCON about how we can bring together the Mason and AxKit synergy. Now Jon has been to my talk, we both know about the advantages of each solution. > www.dorado.com/ is the website for the company I do most of my > contracting with, built entirely in Mason, and it's almost totally > static content, but we make extensive---almost exclusive---use of > Mason's autohandler capabilities coupled with Mason's "object > oriented" features to divorce individual pages from the overall > presentation. > > As a result we were recently able to give the entire site a makeover > in roughly three days from start to finish, because it's designed to > largely separate content from templating. We had to change almost no > individual page files, just the autohandler (read: template) that > handles the site, plus tweaking the names of some rollover graphics. > > No more work than redoing the XPathScript and tweaking your taglibs, > really. It depends a *lot* on the type of content on your site. The above www.dorado.com is brochureware, so it's not likely to need to be re-styled for lighter browsers, or WebTV, or WAP, or... etc. So your content (I'm guessing) is pure HTML, with Mason used as a fancy way to do SSI, with Mason components for the title bars/menus, and so on. (feel free to correct me if I'm wrong). AxKit is just as capable of doing that sort of thing, but where it really shines is to provide the same content in different ways, because you can turn the XML based content into HTML, or WebTV HTML, or WML, or PDF, etc. I talk about how the current Perl templating solutions (including Mason) aren't suited to this kind of re-styling in my AxKit talk, which I'm giving at the Perl conference, so go there and come see the talk :-) So I take back that people wouldn't be using Mason for static content. I was just trying to find a simple way to classify these tools, and to some people (I'd say most people), Mason is more on the dynamic content side of things, and AxKit is more on the static content side of things, but both tools can be used for both types of content. (I hate getting into these things - I wish I'd never brought up Mason or EmbPerl) -- /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
Re: Can AxKit be used as a Template Engine?
Matt Sergeant <[EMAIL PROTECTED]> writes: > The one thing I think AxKit does really well, that other > "templating" solutions aren't really designed for, is allowing you > to build your whole web site with that solution. So for example, > Mason and EmbPerl are really great for building the dynamic parts of > your site, whereas (I imagine, from experience) people will build > the more static parts of their site with just plain HTML. If they are doing that with Mason, they're making a _BIG_ mistake, as you are in suggesting it's not well suited for doing static sites. > Whereas with AxKit the XML + Stylesheets approach applies much more > broadly to the whole site. Errr, respectfully, I think you underestimate Mason's capabilities. www.dorado.com/ is the website for the company I do most of my contracting with, built entirely in Mason, and it's almost totally static content, but we make extensive---almost exclusive---use of Mason's autohandler capabilities coupled with Mason's "object oriented" features to divorce individual pages from the overall presentation. As a result we were recently able to give the entire site a makeover in roughly three days from start to finish, because it's designed to largely separate content from templating. We had to change almost no individual page files, just the autohandler (read: template) that handles the site, plus tweaking the names of some rollover graphics. No more work than redoing the XPathScript and tweaking your taglibs, really. > Now I'm probably going to get replies to this saying how EmbPerl and > Mason and (insert other solution) can do this. And I'm sure they > can. I just think it's more natural with AxKit. Well, you did write AxKit---I'd hope it'd be natural. :-) I've looked at AxKit a lot, and I think it's a great tool that I want to use---now that there's a Debian package so I don't have to do the work to get it installed. The next static site I do for myself, I'll probably try out AxKit---though I just admit that I'd like to see XSLT support, too---but I also think you do Mason a disservice. I will make the caveat that I think I've been using Mason for three years now---almost since it's first public release---and I've built many a static web site with it. I've even got a site that uses XSLT to do transforms of XML files which are then handed off to Mason. Mike.
Re: Initializing CGI Object from $r
Wade Burgett ([EMAIL PROTECTED]) said something to this effect on 04/21/2001:
> sub handler {
> my $r = shift;
> my $CGIQuery = new CGI($r);
> };
I think this will do what you are thining:
sub handler {
my $r = shift;
my $CGIQuery = CGI->new($r->method qe 'POST' ? $r->content : $r->args);
And so on. This will initalize the CGI object with either the
content from STDIN or the query string.
But, why wouldn't you jsut use the native Apache API?
(darren)
--
"... if the source isn't available, it isn't a scientific result...
scientific experiments works on reproducibility, and reproducibility
in computer science experiments includes peer review of the source code
to ensure that your results are due to what you said they were."
-- Andrew Bromage (http://www.advogato.org/person/Pseudonym/)
[DIGEST] mod_perl digest 04/21/01
-- mod_perl digest April 15, 2001 - April 21, 2001 -- Recent happenings in the mod_perl world... Features o mod_perl status o cvs patches o module announcements o mailing list highlights o news o links mod_perl status o mod_perl - stable: 1.25 (released January 29, 2001) [1] - development: 1.25_01-dev [2] o Apache - stable: 1.3.19 (released February 28, 2001) [3] - development: 1.3.20-dev [4] o Perl - stable: 5.6.1 (released April 9, 2001) [5] - development: 5.7.1 [6] cvs patches o fix for make tar_Apache [7] o export hvrv2table (needed by Apache::Request) for aix and win32 [8] o fix $r->no_cache(0) to unset cache headers [9] o back out 'stop win32 crash when bringing down service' change, no longer needed with 1.3.19 [10] o improvements in Apache::MyConfig [11] [12] o make sure global for Apache->request is reset after configuring %ENV [13] o 56 patches to 2.0 this week [14] module announcements o Apache::Reload 0.07 - a replacement for Apache::StatINC, with more features and better debugging [15] o HTML::Mason 1.02 - allows web pages and sites to be constructed from shared, reusable building blocks called components, which contain a mix of Perl and HTML and can call each other and pass values back and forth like subroutines [16] mailing list highlights o This thread compares the advantages and disadvantages of generating your httpd.conf from a database using a template system over using sections [17] o A rather lengthy thread comparing MLDBM, Postgres, and other storage solutions that started back in October. It takes quite a few turns but this week's installation might be worth a read if you are into this - some of the responses actually contain worthy information [18] o Get some very interesting insights into MVC application design using mod_perl based tools [19] news o For some reason, Netcraft released April numbers mid-April... Apache 62.55% IIS 20.64% [20] mod_perl: 2,482,288 Domains, 256,862 IP Addresses [21] links o The Apache/Perl Integration Project [22] o mod_perl documentation [23] o mod_perl modules on CPAN [24] o mod_perl homepage [25] o mod_perl news and advocacy [26] o mod_perl list archives [27] [28] happy mod_perling... --Geoff [EMAIL PROTECTED] -- [1] http://perl.apache.org/dist/ [2] http://perl.apache.org/from-cvs/modperl/ [3] http://www.apache.org/dist/ [4] http://dev.apache.org/from-cvs/apache-1.3/ [5] http://www.cpan.org/src/stable.tar.gz [6] http://www.cpan.org/src/devel.tar.gz [7] http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=98754354908081&w=2 [8] http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=98754418110219&w=2 [9] http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=98754465211646&w=2 [10] http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=98754493312683&w=2 [11] http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=98754716518832&w=2 [12] http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=98754733719250&w=2 [13] http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=98754313806576&w=2 [14] http://marc.theaimsgroup.com/?l=apache-modperl-cvs&r=1&w=2&b=200104 [15] http://forum.swarthmore.edu/epigone/modperl/flunyaxtwan [16] http://forum.swarthmore.edu/epigone/modperl/quimhoukhax [17] http://forum.swarthmore.edu/epigone/modperl/quoblerberd [18] http://forum.swarthmore.edu/epigone/modperl/whalthixgrol [19] http://forum.swarthmore.edu/epigone/modperl/manzhayblix [20] http://www.netcraft.com/survey/ [21] http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=98760695302450&w=2 [22] http://perl.apache.org [23] http://perl.apache.org/#docs [24] http://www.cpan.org/modules/by-module/Apache/ [25] http://www.modperl.com [26] http://www.take23.org [27] http://forum.swarthmore.edu/epigone/modperl/ [28] http://marc.theaimsgroup.com/?l=apache-modperl&r=1&w=2
Re: Can AxKit be used as a Template Engine?
On Sat, 21 Apr 2001, Joachim Zobel wrote: > > Hi. > > I try to understand why and if this XML/XSL stuff is useful. Is it that > transformations (XSL) of XML to HTML can be used instead of the usual HTML > templates (eg. Template-Toolkit)? Partly. But XSLT is also able to transform documents, which is an incredibly useful feature that no other Perl templating module (except XPathScript) is able to do well. Hard to describe without an example, of which there are plenty on the 'net so I won't spam the group here. > Can this do what a template engine can > do? Where are the limitations? Is there something it can't do? Not really, AxKit is as powerful as the other solutions out there, I'd say (well I would, wouldn't I :-). The one thing I think AxKit does really well, that other "templating" solutions aren't really designed for, is allowing you to build your whole web site with that solution. So for example, Mason and EmbPerl are really great for building the dynamic parts of your site, whereas (I imagine, from experience) people will build the more static parts of their site with just plain HTML. Whereas with AxKit the XML + Stylesheets approach applies much more broadly to the whole site. Now I'm probably going to get replies to this saying how EmbPerl and Mason and (insert other solution) can do this. And I'm sure they can. I just think it's more natural with AxKit. Having said that, it goes the other way too - currently building web applications is probably a lot easier with Mason than it is with AxKit, because that's what it was designed for. AxKit has a pretty cool technology called XSP, which gives you a cold-fusion like system of inserting tags into your XML for dynamic functionality. But in my opinion it doesn't scale well (in the development sense, not in the performance sense) to large applications, because it is inherently a page-based technology (like PHP, Cold Fusion, JSP, ASP, etc), and I don't think page-based web development systems scale well to larger applications. I prefer something that is turned inside-out from the page based view of things, like MVC. I have another article on this coming soon that should make things a bit (or a lot) clearer. I'll keep the list informed when it's ready. -- /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
Re: CORE::format() and CORE::write() under 5.6.x
At 20:48 22/04/2001 +0800, Stas Bekman wrote: >There is this entry in the guide: > > >The interface to file handles which are linked to variables with >Perl's tie() function is not yet complete. The format() and write() >functions are missing. If you configure Perl with C, write() and >format() should work just fine. > > >Is this still true under 5.6.x? I _think_ that it is still true. At least, perltie and TieL::Handle seem to say so. I don't know if anyone's working on that, isn't PerlIO going to replace tied handles ? ___ Robin Berjon <[EMAIL PROTECTED]> -- CTO k n o w s c a p e : // venture knowledge agency www.knowscape.com --- Heisenberg may have been here.
