Re: while - modperl 2.0/Apache 2.0
ok, looks like your setup is fine.
Though I cannot seem to reproduce your problem. Indeed it seems that the
unbuffered output doesn't work. I'm checking on that. But I've devised a
better test that verifies that the requests aren't serialized. If you
run this hander by two clients at the same time, you should see the
lines in /tmp/test123 being interleaved by two processes. If this
doesn't happen and you get first 100 lines from process A followed by
process B's 100 lines than indeed we have a problem.
sub handler {
my $r = shift;
$r-content_type('text/plain');
local $| = 1;
open my $fh, , /tmp/test123 or die $!;
my $oldfh = select($fh); local $| = 1; select($oldfh);
my $i = 0;
while ($i 100) {
$r-print($$: $i \n);
print $fh $$: $i \n;
sleep 1;
$i++;
}
$r-print(__PACKAGE__);
close $fh;
return Apache::OK;
}
If this indeed doesn't work, please try the suggestion at:
http://perl.apache.org/docs/1.0/guide/debug.html#Using_the_Perl_Trace
so you can see where the second process is stalled. If you don't get
anything from this approach try to attach to the second process with gdb
and see where it is stack on the C calls level. Though I suggest that
you test with prefork and this setup:
IfModule prefork.c
StartServers 2
MinSpareServers 2
MaxSpareServers 2
MaxClients 2
MaxRequestsPerChild 0
/IfModule
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: New mod_perl site and oddness with IE
Quoting Jim Helm [EMAIL PROTECTED]: Has anyone else had problems with this particular page under IE (6.0.2600 under XP) being extremly slow to update when paging up/down? It works fine under Mozilla, and it's not a memory or cpu issue (checked with task manager already). And when I say slow, I mean a simple down cursor causes the visible portion of the page to get painted in 4 noticble steps/chunks. --Jim please check if the problem exists on this url: http://www.bullitt.suite.dk/clean3/dst_html/docs/1.0/guide/performance.html if you have other browser software, please check and see if anything else is broken there as well. thanks a lot! /allan
Re: New mod_perl site and oddness with IE
[Let's move this thread to the docs-dev list, otherwise we make an OT noise at the modperl list, so, please, when replying to this email, remove the modperl address from it. thanks!] Has anyone else had problems with this particular page under IE (6.0.2600 under XP) being extremly slow to update when paging up/down? It works fine under Mozilla, and it's not a memory or cpu issue (checked with task manager already). And when I say slow, I mean a simple down cursor causes the visible portion of the page to get painted in 4 noticble steps/chunks. --Jim please check if the problem exists on this url: http://www.bullitt.suite.dk/clean3/dst_html/docs/1.0/guide/performance.html if you have other browser software, please check and see if anything else is broken there as well. Allan, You are trying to solve it by applying HTML::Clean, which reduces the size of the page, right? But even if it does solve the problem for this particular page, what happens if the page grows, or there is some other page which is bigger, and no cleanup will make it small enough to make IE happy. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: New mod_perl site and oddness with IE
Stas Bekman wrote: Jim Helm wrote: Has anyone else had problems with this particular page under IE (6.0.2600 under XP) being extremly slow to update when paging up/down? It works fine under Mozilla, and it's not a memory or cpu issue (checked with task manager already). And when I say slow, I mean a simple down cursor causes the visible portion of the page to get painted in 4 noticble steps/chunks. An older version I tracked down with Google (http://www.apache.jp/perl/guide/performance.html) which is also 300K+ doesn't have the same problem - just to show that it's not purely the raw size of the page that is the problem. Just a little feedback for the new site (which is great, btw). If it's just me with the problem, I'll go find a rock to hide under. :) Is the size of the page causes the trouble? I don't have IE to try so hopefully someone will help us out here. What happens if you shorten the content of the page? My guess is that IE simply cannot cope with a long page and the current complex stylesheet (because as say it works fine with the same page and a simpler stylesheet, which includes no layout instructions). Suggestions on how to fix that are welcome. IE 5.50.4807.2300 (SP2) on Win98SE I had different problems - the first time I went to the page, IE crashed my machine, so I had to reboot. After I'd rebooted I went back to the page. I got the extremely slow scrolling, but, more significantly, I got the second half of the page overlaid on top of the first half. I grabbed a copy of the page with Opera's 'save with images' option (strangely enough doing it with IE, and viewing the result didn't get the same display) and verified that the bug occurred with my local copy. I then had a bit of a fiddle with the stylesheet, and discovered that taking out the 'position: relative's seemed to stop the overlay, improving IEs performance markedly without affecting the page layout in any of the browsers I have installed (Netscape 4.79, Mozilla 2002053012, Opera 6.04) (There was no reason *why* taking out the 'position: relative's should work - it just struck me as the first thing that wasn't necessary in the style sheet. Possibly irritating an IE bug just a little too much) Hope this helps, Steve -- Steve Piner Web Applications Developer Marketview Limited http://www.marketview.co.nz
Re: New mod_perl site and oddness with IE
allan juul wrote: Quoting Jim Helm [EMAIL PROTECTED]: Has anyone else had problems with this particular page under IE (6.0.2600 under XP) being extremly slow to update when paging up/down? It works fine under Mozilla, and it's not a memory or cpu issue (checked with task manager already). And when I say slow, I mean a simple down cursor causes the visible portion of the page to get painted in 4 noticble steps/chunks. --Jim please check if the problem exists on this url: http://www.bullitt.suite.dk/clean3/dst_html/docs/1.0/guide/performance.html if you have other browser software, please check and see if anything else is broken there as well. thanks a lot! /allan Looks good to me with on Win98SE * IE 5.50.4807.2300 (SP2) * Netscape 4.79 * Mozilla 2002053012 * Opera 6.04 -- Steve Piner Web Applications Developer Marketview Limited http://www.marketview.co.nz
Re: New mod_perl site and oddness with IE
Allan Juul wrote: before the mails comes tumbling in ... please check this url [tested on winXP/IE6.0] as already send to the docs list and original poster http://www.bullitt.suite.dk/clean3/dst_html/docs/1.0/guide/performance.html thanks ./allan (There was no reason *why* taking out the 'position: relative's should work - it just struck me as the first thing that wasn't necessary in the style sheet. Possibly irritating an IE bug just a little too much) not sure which rule of position you were talking about. the above url specify no position for the rightbox div div.rightbox had a 'position: relative' specified in ../../../style.css. It also specified a top and left of 0, so essentially the rule was saying 'lay out this box according to normal flow, then offset it from its original position by 0px' i.e. don't move it. It seemed superfluous, so I removed it. Doing so appeared to fix the problem with no discernible side effects. As for why it isn't affecting other pages, I have no idea. It's probably, as Stas suggests, a size thing. Is that the biggest page on the site? Steve -- Steve Piner Web Applications Developer Marketview Limited http://www.marketview.co.nz
How to see debug information in Net::Smtp?
I use Net::Smtp module in my mod_perl script. When I run the fragment of my code from command line I can see the debug info. But running it on the production server I can't see the debug information. What can I do to see the debug info on the production server? Thanks in advance Mark
Re: How to see debug information in Net::Smtp?
[EMAIL PROTECTED] wrote: I use Net::Smtp module in my mod_perl script. When I run the fragment of my code from command line I can see the debug info. But running it on the production server I can't see the debug information. What can I do to see the debug info on the production server? look in the error_log file? __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
RE: How to see debug information in Net::Smtp?
and set your LogLevel to debug -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 17, 2002 10:27 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: How to see debug information in Net::Smtp? [EMAIL PROTECTED] wrote: I use Net::Smtp module in my mod_perl script. When I run the fragment of my code from command line I can see the debug info. But running it on the production server I can't see the debug information. What can I do to see the debug info on the production server? look in the error_log file? __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: How to see debug information in Net::Smtp?
Peter Werner wrote: and set your LogLevel to debug why? after all he is talking about perl logging, not Apache. LogLevel has nothing to do with it. -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 17, 2002 10:27 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: How to see debug information in Net::Smtp? [EMAIL PROTECTED] wrote: I use Net::Smtp module in my mod_perl script. When I run the fragment of my code from command line I can see the debug info. But running it on the production server I can't see the debug information. What can I do to see the debug info on the production server? look in the error_log file? __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [ANNOUNCE] Petal 0.1
I'm curious though, why you've chosen to implement it as a handler for XML::Parser rather than as a SAX Handler (or even better, a Filter)? What SAX buys (among other things) is the ability for folks to invisibly use whatever XML parser is installed, including a pure Perl implementation. Doing Petal as a SAX Filter would mean that it would be totally easy to add it to the mix in things like AxKit and custom SAX pipeline publishing systems. So, doing complex, multi-stage transformations like My::NonXML::SAXGenerator - Petal - SomeXSLT - SomeOtherXSLT come for free. Interesting stuff... And I think it would be quite easy to implement! At the moment Petal features two XML event generators: Petal::Parser::XMLWrapper (based on XML::Parser) Petal::Parser::HTMLWrapper (based on HTML::TreeBuilder) I suppose I could write a Petal::Parser::SAXWrapper... it would be quite trivial to generate the XML::Parser events from that :-) My only problem deals with template caching. Currently Petal does the following: * Generate events to build a 'canonical' template file * Convert that template file to Perl code ** Cache the Perl code onto disk * Compiles the Perl code as a subroutine ** Caches the subroutine in memory Cache is kept fresh using the template file mtime() information. If I had a SAX event parser, then maybe caching could be a bit troublesome? Maybe what I really need would be to write something a bit more generic, i.e. my $template = new Petal ( event_generator = $event_generator, cache_key = $cache_key, cache_expires = \coderef ); I do not have much experience with SAX and pipelines or things, but if you feel like looking at the code and make sensible architectural suggestions to make Petal as generic and modular as possible then I'll be quite happy to implement them :-) Anyway, just random thoughts, really. Petal seems nice and it seems a shame to lock it in the XML::Parser-based-one-off jail. Well, it's not *really*. Take a look at Petal::Parser::HTMLWrapper, you'll see it's pretty straightforward :-) Oh by the way, Petal 0.2 is out, it fixes a stupid critical bug and a couple of documentation bugs... http://search.cpan.org/doc/JHIVER/Petal.0.2/lib/Petal.pm Best regards, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
RE: How to see debug information in Net::Smtp?
its bitten me in the ass a few times before, just thought id mention it cheers -pete -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 17, 2002 1:29 PM To: Peter Werner Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: How to see debug information in Net::Smtp? Peter Werner wrote: and set your LogLevel to debug why? after all he is talking about perl logging, not Apache. LogLevel has nothing to do with it. -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 17, 2002 10:27 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: How to see debug information in Net::Smtp? [EMAIL PROTECTED] wrote: I use Net::Smtp module in my mod_perl script. When I run the fragment of my code from command line I can see the debug info. But running it on the production server I can't see the debug information. What can I do to see the debug info on the production server? look in the error_log file? __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: while - modperl 2.0/Apache 2.0
thanks ;)
now i understand
to run in others browser instances you need change url
example:
http://127.0.0.1/hello-world?a
http://127.0.0.1/hello-world?b
http://127.0.0.1/hello-world?c
http://127.0.0.1/hello-world?d
/tmp/test123
1505: 162 - thread
1505: 155 - thread
1578: 146
1505: 131 - thread
1578: 124
1505: 163 - thread
1505: 156 - thread
1578: 147
1505: 132
:))
bye
nattis
Stas Bekman wrote:
ok, looks like your setup is fine.
Though I cannot seem to reproduce your problem. Indeed it seems that
the unbuffered output doesn't work. I'm checking on that. But I've
devised a better test that verifies that the requests aren't
serialized. If you run this hander by two clients at the same time,
you should see the lines in /tmp/test123 being interleaved by two
processes. If this doesn't happen and you get first 100 lines from
process A followed by process B's 100 lines than indeed we have a problem.
sub handler {
my $r = shift;
$r-content_type('text/plain');
local $| = 1;
open my $fh, , /tmp/test123 or die $!;
my $oldfh = select($fh); local $| = 1; select($oldfh);
my $i = 0;
while ($i 100) {
$r-print($$: $i \n);
print $fh $$: $i \n;
sleep 1;
$i++;
}
$r-print(__PACKAGE__);
close $fh;
return Apache::OK;
}
If this indeed doesn't work, please try the suggestion at:
http://perl.apache.org/docs/1.0/guide/debug.html#Using_the_Perl_Trace
so you can see where the second process is stalled. If you don't get
anything from this approach try to attach to the second process with
gdb and see where it is stack on the C calls level. Though I suggest
that you test with prefork and this setup:
IfModule prefork.c
StartServers 2
MinSpareServers 2
MaxSpareServers 2
MaxClients 2
MaxRequestsPerChild 0
/IfModule
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [ANNOUNCE] Petal 0.1
On Wed, 17 Jul 2002, Jean-Michel Hiver wrote: My only problem deals with template caching. Currently Petal does the following: * Generate events to build a 'canonical' template file * Convert that template file to Perl code ** Cache the Perl code onto disk * Compiles the Perl code as a subroutine ** Caches the subroutine in memory Cache is kept fresh using the template file mtime() information. If I had a SAX event parser, then maybe caching could be a bit troublesome? If you could skip the whole perl code part you could use XML::Filter::Cache (a SAX caching filter) as a cache rather than worrying about a built in one. Sorry for getting off topic for this list though. Just trying to pass around the SAX kool aid ;-) -- !-- Matt -- :-Get a smart net/:-
Re: [ANNOUNCE] Petal 0.1
Jean-Michel Hiver writes: My only problem deals with template caching. Currently Petal does the following: * Generate events to build a 'canonical' template file * Convert that template file to Perl code ** Cache the Perl code onto disk * Compiles the Perl code as a subroutine ** Caches the subroutine in memory I wonder how much code you would save if you wrote the templates in Perl and let the Perl interpreter do the above. Sorry, I know this doesn't help you answer your question, but by eliminating XML from the design, the debate about SAX vs XML::Parser would be irrelevant. Your code would run faster, and you would need fewer 3rd party APIs. Rob
List files from a share of a windows client
Title: List files from a share of a windows client
Hello all,
How can I list the directives and files from a share which is on a windows client? I can only list the directories from the local machine, not from a remote one! If I catch a image with my code below, it works fine.
I start the browser with: http://servername/cgi-file?ordner=../logo=//sharename/pic.jpg
(To display the local directive/files and an image from a remote windows
machine)
If I start the browser with: http://servername/cgi-file?ordner=//sharename/logo=//sharename/pic.
jpg
(I thought this one works with the directory/files from the remote machine, but I get the error msg with: Can't open directory. Also if I change the slashes to backslashes or with the ip-address)
My actually code is:
...
#!/usr/bin/perl -w
use CGI;
$query = new CGI;
print $query-header();
print $query-start_html();
print table border=0 cellspacing=0;
print trtd;
#reading the directory
opendir(DIR, $query-param(ordner)) || die Can't open directory!;
while($datei = readdir(DIR) ) { print $dateibr;
}
closedir(DIR);
#This is only optional, to test if images can displayed (it works
fine) print '/td/trtrtd width=100img
src="file:'.$query-param(logo).' align=center/td';
print /tr/table;
print $query-end_html();
...
I need this configuration, cause to move our intraweb to a Linux Box with Apache. Later I'll have to generate hyperlinks to different files on the remote machines, therefore I have list first the content of the directory. Actually it runs on a Windows machine with perl and sambar and the files and data are on different machines.
There it works fine.
And I can't move the files to the Linux Box. Not yet, and not at all!!!
Thanks for the help.
Regards,
Christian Heiss
_
LANconcept Moll GmbH
Benzstrasse 1
88074 Meckenbeuren
Voice: +49 (0) 7542 940 3 - 18
Fax: +49 (0) 7542 218 24
Mobil: +49 (0) 175 86 91 805
mailto:[EMAIL PROTECTED]
visit our website http://www.datentechnik-moll.de
_
Re: [ANNOUNCE] Petal 0.1
I wonder how much code you would save if you wrote the templates in Perl and let the Perl interpreter do the above. I recommend that you read this Page: http://www.perl.com/pub/a/2001/08/21/templating.html?page=2 I'm an OO-advocate, I believe in proper separation of logic, content and presentation and on top of that I want people to be able to edit templates easily in dreamweaver, frontpage, etc and send templates thru HTML tidy to be able to always output valid XHTML. Petal lets me do that. If that's not of any use to you, fine. The world is full of excellent 'inline style' modules such as HTML::Mason, HTML::Embperl and other Apache::ASP. After all, TIMTOWDI :-) Regards, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
Request object availability in .htaccess
Hi all, I've got some Perl code in an htaccess file to choose some configuration based on client IP. The code starts with $r = Apache-request. The first request that gets handled by a server instance fails to get the request object (the call succeeds but returns undef). Subsequent requests to that server instance work properly. Any thoughts? --- Rodney Broom President, R.Broom Consulting
Re: [ANNOUNCE] Petal 0.1
Jean-Michel Hiver writes: I wonder how much code you would save if you wrote the templates in Perl and let the Perl interpreter do the above. I recommend that you read this Page: http://www.perl.com/pub/a/2001/08/21/templating.html?page=2 Please read the Application Servers section of: http://www.bivio.biz/hm/why-bOP I'm an OO-advocate, I believe in proper separation of logic, content and presentation Moi aussi. What does this have to do with using Perl for business logic and presentation logic? and on top of that I want people to be able to edit templates easily in dreamweaver, frontpage, etc and send templates thru HTML tidy to be able to always output valid XHTML. If you are an OO-advocate, you would hide the presentation format in objects, e.g. Table, String, and Link. This ensures the output is valid through the (re)use of independently tested objects. Objects also provide a mechanism for overriding behavior. Petal lets me do that. If that's not of any use to you, fine. The world is full of excellent 'inline style' modules such as HTML::Mason, HTML::Embperl and other Apache::ASP. These all work on the assumption that the template is written in HTML. If you start with OO Perl, you do not inline anything, not even the HTML. Here is an example page: http://petshop.bivio.biz/items?p=RP-LI-02 And here is the HTML-less source: http://petshop.bivio.biz/src?s=View.items Apologies to those who are tired of the *ML vs. Perl debate. Rob
Re: [ANNOUNCE] Petal 0.1
On Wed, 17 Jul 2002, Rob Nagler wrote: Petal lets me do that. If that's not of any use to you, fine. The world is full of excellent 'inline style' modules such as HTML::Mason, HTML::Embperl and other Apache::ASP. These all work on the assumption that the template is written in HTML. Actually, neither Mason nor Embperl are HTML-specific these days. Mason never really was, and Embperl has become much more generic with version 2, which is in fact now simply called Embperl. Mason will probably changes its name eventually as well. -dave /*== www.urth.org we await the New Sun ==*/
Re: [ANNOUNCE] Petal 0.1
On Wednesday 17 July 2002 22:06, Rob Nagler wrote: Apologies to those who are tired of the *ML vs. Perl debate. We might get tired if the vs in there made any sense. -- Robin Berjon [EMAIL PROTECTED] -- for hire: http://robin.berjon.com/ Windows may be pretty. And easy. But it has no depth or soul. It's like the one-night stand of operating systems. You feel cheap after using it. -- Steph, in User Friendly
Re: [ANNOUNCE] Petal 0.1
Rob Nagler wrote: Apologies to those who are tired of the *ML vs. Perl debate. I think you're confusing the issue. You're not talking about in-line Perl vs. templating languages, but rather templating vs. a whole different concept. Jean-Michel clearly wants to use HTML-based templates, and wrote his module specifically for that purpose. When most people talk about templates for web pages, this is what they have in mind: HTML (or XML or PDF or whatever) bristled with processing instructions in Perl or a templating language. It's an easy transition for people who already know HTML, and provides what most people want from a templating solution. What Bivio uses could reasonably be called a template, but it's a completely different animal from the sort of fill-in-the-blank templates that most people mean, and maybe deserves a different name. It's more like a declarative program, or a configuration file, or CGI.pm widgets. It is an alternative to traditional templating, but suggesting that this will fix issues with XML parsing is kind of like saying you wouldn't need that winter coat if you lived in Hawaii -- true, but not very helpful to someone who lives in Montreal and likes it. - Perrin
Re: [modperl2] Perl Connection Handlers for SSL connections
Stas Bekman wrote:
Pete Rothermel wrote:
I've got the example echo() handler working for a non-HTTP protocol as
outlined on the new web site:
http://perl.apache.org/docs/2.0/user/handlers/handlers.html#Command__Protocol__Phases
Anybody have a similar example for the same protocol handler over SSL?
the echo protocol working over the socket skips filters, so it won't
work with SSL.
at the above URL scroll down to the Apache::Eliza2 example, which uses
bucket brigades and therefore should work over SSL.
I didn't have a chance to document it yet, but for simple things you
just change the code inside this snippet:
if ($data) {
$data =~ s/[\r\n]*$//;
$last++ if $data =~ /good bye/i;
$data = $eliza-transform( $data ) . \n\n;
$bucket = APR::Bucket-new($data);
}
the rest most likely will stay unmodified.
Stas,
Worked like a charm. You might want to include an example over
ssl in the doco. I used the openssl executable as the client
application.
openssl.exe s_client -connect hostip:sslport
thanks again
Pete
Re: [ANNOUNCE] Petal 0.1
Dave Rolsky [EMAIL PROTECTED] wrote: On Wed, 17 Jul 2002, Rob Nagler wrote: Petal lets me do that. If that's not of any use to you, fine. The world is full of excellent 'inline style' modules such as HTML::Mason, HTML::Embperl and other Apache::ASP. These all work on the assumption that the template is written in HTML. Actually, neither Mason nor Embperl are HTML-specific these days. Mason never really was, and Embperl has become much more generic with version 2, which is in fact now simply called Embperl. Mason will probably changes its name eventually as well. -nod- (As an example of a non-HTML [and potentially twisted] app:) I'm working on our next-generation administrative web application (handles some system account management and other similar things for the University). I decided early on to use the MVC paradigm because the programmers (me) are better at programming the MC part than writing the content for the V part. So, looking at the modules available on CPAN (I'm trying to make maximal use of CPAN), I decided to use the following: Mason (Controller): provides easy management of form values from the client, clean division between sections (init, once, shared, etc.), and nice inheritance. For now, Mason is called from AxKit. TT2 (View): makes it easy for non-programmers to edit XML and embed occasional references to data without having to understand the underlying object model -- views are ultimately called from Mason. I use Data::FormValidator to decide which view to use. AxKit (View): translates the XML to the output device the customer is using. Also can support themes. Allows us to internally structure content in a logical manner that may ultimately aid in building a search engine (for a document repository, for example). Also provides the site a the consistent look feel. Perl (Model): actual database manipulation is done through Perl modules I think I am using each item in its strongest area. There is no HTML until AxKit sends it to the client. It's also easier to throw a few more CPUs or sticks of RAM at the solution than half-a-dozen programmers that can't write anything customer-friendly or technical writers that can't deal with code. (Of course, one of my other mantras is: Always write for a webfarm.) -- James Smith [EMAIL PROTECTED], 979-862-3725 Texas AM CIS Operating Systems Group, Unix
