Re: readdir()
On Wed, 25 Apr 2001, Andrew Ho wrote: LSPerl 5.6.0 breaks the readdir() function when running under mod_perl. LSThis is with the most recent versions of Apache and mod_perl, as well LSas with older versions. I see the same problem reported in the LSmailing list going back to December 2000, but no hint of a LSresolution. Is there any fix? Are there references to the problem reports? readdir() works fine for me with Apache 1.3.19, mod_perl 1.25, and Perl 5.6.0 on Solaris 2.7 (x86). AFAIK, it's broken only under Linux and then only when using glibc2.2. It works fine under glibc2.1. - Paul
Re: Strange Problem with opendir / readdir
On Fri, 30 Mar 2001, Cornelius Kuschnereit wrote: I have strange problems while using opendir / readdir under MasonHQ. I'm not shure, but it seems to be a perl / modperl / Apache and not a Mason Bug. I have no problem to run the same directly from the shell. Is there a known bug? As far as I can tell, it's a mod_perl, glibc2.2 compatibility bug. - Paul
Re: Authentication handlers
On Sat, 3 Mar 2001, Pierre Phaneuf wrote: "Paul J. Lucas" wrote: Is there any means of removing the username and password from the browsers cache. $r-nocache(1); No, I think he's talking about the "basic" authentication information, that browsers keep in memory until they are stopped. Oh, silly me. Since this is a mod_perl mailing list, I thought it was actually mod_perl question. Basic authentication is basic authentication; mod_perl has nothing to do with it. - Paul
Re: Authentication handlers
On Sat, 3 Mar 2001, Kiran Kumar.M wrote: Is there any means of removing the username and password from the browsers cache. $r-nocache(1); - Paul
[OT] Re: Search Engine Theory
On Tue, 27 Feb 2001, Jamie Krasnoo wrote: Can anyone point me to any documents on search engine theory and programming search engines with perl? Possibly. Try a search-engine-related mailing list or newsgroup. - Paul
Re: parsing an apache-like conf-file
On Wed, 31 Jan 2001, Matt Sergeant wrote: Looks like a job for XML::Simple. Except we've had no end of trouble with it dumping core in a mod_perl environment. My XML::Tree is far faster, much smaller, and doesn't dump core: http://homepage.mac.com/pauljlucas/software/xml_tree/ - Paul
Re: parsing an apache-like conf-file
On Wed, 31 Jan 2001, Matt Sergeant wrote: My XML::Tree is far faster, much smaller, and doesn't dump core: http://homepage.mac.com/pauljlucas/software/xml_tree/ But its not as simple to use as XML::Simple, which is perfect for these sorts of things :-) What could be simpler than: $xml = XML::Tree-new( 'foo.xml' ); $ref = $xml-as_array(); ? - Paul
Re: parsing an apache-like conf-file
On Wed, 31 Jan 2001, Matt Sergeant wrote: I wrote: What could be simpler than: $xml = XML::Tree-new( 'foo.xml' ); $ref = $xml-as_array(); Its what's in $ref thats complex (or more complex than XML::Simple), see the man page for XML::Simple. Yes, but I think XML::Simple got the data structures generally wrong and has too many options. A user of XML::Simple looking at his own code a few weeks later, or, worse, somebody else's, always has to (re)figure out what options were given to it at data-structure creation time and what that really means in terms of the data structure you get back. This means you're always having to look at the man page. You may think XML::Simple results in simpler data structures; however, the mental energy expended to refigure stuff out makes XML::Simple more complex in the long term. Aside from being slow, this is another complaint about it. In contrast, the data structure you get back from XML::Tree is always the same. As Antoine de Saint-Exupery remarked: A designer knows he has arrived at perfection not when there is no longer anything to add, but when there is no longer anything to take away. - Paul
Re: parsing an apache-like conf-file
On Wed, 31 Jan 2001, Matt Sergeant wrote: I've never heard anyone complain about it being slow. I'm not saying XML::Tree isn't faster, just that I've never heard that complaint about XML::Simple, simply because people don't use it for parsing large files, just small config files. Or perhaps they don't need to handle hundreds of thousands of hits a day, i.e., on the scale of eBay. I guess maybe your measures are different to, erm, the rest of the internet's The benchmark I used is right on my web page. As for being more complex to use, I would say XML::Simple's popularity speaks for itself (especially when compared with say XML::DOM or Grove or even XPath). Or, until now, there wasn't something better. - Paul
Passing data among handlers
Perhaps I've missed it, but is there a better way than the "notes" mechanism to pass data among handlers? The "notes" mechanism not only requires the notes to be scalars, but, apparantly, said scalars must also be simple strings, i.e., no binary data crammed into a scalar. Better ideas? Odds of enhancing the "notes" mechanism? - Paul
Re: [OT] XML::DOM
On Tue, 23 Jan 2001, Matt Sergeant wrote: But if performance is absolutely key in XML parsing/processing, then you really need to be looking towards Orchard, which we're co-developing with Ken MacLeod (author of the PerlSAX bindings and XML::Grove). Current tests reveal that its about 10 times faster at parsing than any Perl tree based parser ... FYI, I recently released my of XML::Tree. My benchmark tests against XML::Parser show mine to be 12 times faster. I wrote it as sort of a challenge (internal to my company). The code is based on my similar HTML::Tree. A current caveat of mine is that it's not a compliant parser. It doesn't currently handle Unicode, CDATA sections, ELEMENT declarations, and probably some other stuff. But, if you're processing straight-forward XML files, like config files, it certainly works, and fast. http://homepage.mac.com/pauljlucas/software/xml_tree/ - Paul
Re: [OT] XML::DOM
On Tue, 23 Jan 2001, Matt Sergeant wrote: Aside from categorically *not* being an XML parser (if it doesn't parse XML 1.0 files then its not officially an XML parser) Whatever. It's still 12 times faster at parsing files that look very much like XML in a majority of real-world cases. (There: happy?) Also, as I stated, is is just version 1.0. it doesn't compile on my stock Mandrake 7.0 laptop: make[1]: Entering directory `/tmp/XML_Tree-1.0/mod/XML/Tree' g++ -c -I../../.. -Dbool=char -DHAS_BOOL -I/usr/local/include -O3 -fomit-frame-pointer -fno-exceptions -fno-rtti -pipe -s -mpentium -mcpu=pentium -march=pentium -ffast-math -fexpensive-optimizations -DVERSION=\"1.0\" -DXS_VERSION=\"1.0\" -fpic -I/usr/lib/perl5/5.00503/i386-linux/CORE -Ubool Tree.c Tree.xs: In function `void XS_XML_Node_att(CV *)': Tree.xs:196: taking dynamic typeid of object with -fno-rtti Tree.xs:196: confused by earlier errors, bailing out Your installation is outdated or broken or both: it should not be adding -fno-rtti. It's certainly not in the distributed makefiles. It requires an ANSI C++ compiler (supporting RTTI). If it doesn't compile ANSI C++ then it's not officially an ANSI C++ compiler. - Paul
Re: [OT] XML::DOM
On Tue, 23 Jan 2001, Matt Sergeant wrote: Its perl adding the -fno-rtti, FWIW, not your Makefiles. Then there's something odd about your Perl installation. Perl shouldn't be giving the option. How does Perl "know" whether RTTI is needed or not? - Paul
Re: New to mod perl help
On Tue, 23 Jan 2001, John Michael wrote: I know that the modperl script has to go in the httpd/perl folder so that apache will recognize it. You can put the script anywhere you please. You only have to make sure the directory is "use lib"'d. If I move the scripts into the httpd/perl folder, if I just require them from the virtual cgi-bins, will they work and how do I pass variables to these scripts. These are just regular cgi scripts. You pass them the same way you always have. I just wanted to gain the effects of the embedded interpreter and start experimenting with the script. You actually have to configure Apache::Registry to handle the scripts in said directories, of course. - Paul
Re: PerlChildInitHandler not being called
On Thu, 11 Jan 2001, Doug MacEachern wrote: On Tue, 2 Jan 2001, Paul J. Lucas wrote: I looked in the archives for this problem and, while mentioned, not definitive solution was apparantly found. I did notice the handler get called once, but only once: total server shutowns and restarts don't make it get called. I'm using Apache 1.3.12, mod_perl 1.24_01, Perl 5.6 under Linux. [ snip ] looks like it works fine. Actually, I played with it some more and it turns out that that a PerlChildInitHandler directive doesn't work inside a VirtualHost block. - Paul
PerlChildInitHandler not being called
I looked in the archives for this problem and, while mentioned, not definitive solution was apparantly found. I did notice the handler get called once, but only once: total server shutowns and restarts don't make it get called. I'm using Apache 1.3.12, mod_perl 1.24_01, Perl 5.6 under Linux. - Paul
Re: searchable site
On Mon, 1 Jan 2001, Bill Moseley wrote: Apache.org uses SWISH-E, if I remember correctly. http://sunsite.berkeley.edu/SWISH-E/ Although getting off-topic, SWISH++ is significantly faster: http://homepage.mac.com/pauljlucas/software/swish/ The CPAN modules will let you move seamlessly from the forked model of 2.0 to the library version of swish-e when 2.1 comes out. This means you can run swish under mod_perl without forking. SWISH++ can run as a multi-threaded daemon that listens on either a Unix-domain or TCP socket, hence also without forking. - Paul
Re: searchable site
On Mon, 1 Jan 2001, Bill Moseley wrote: BTW: http://homepage.mac.com/pauljlucas/software/swish/man/ seems broken. The documentation link (different from above) is now fixed: http://homepage.mac.com/pauljlucas/software/swish/documentation.html Thanks. (Apple, in their infinite wisdom, decided not to implement directory listings in their web server.) - Paul
Re: Trouble building HTML_Tree
On Tue, 12 Dec 2000, Ian Mahuron wrote: Can't load '../blib/arch/auto/HTML/Tree/Tree.so' for module HTML::Tree: ../blib/arch/auto/HTML/Tree/Tree.so: Undefined symbol "__builtin_delete" at /usr/libdata/perl/5.00503/DynaLoader.pm line 169. Any idea? I'm sure someone has run into this before. 1. Did it build correctly? 2. Is libstdc++.so in LD_LIBRARY_PATH? I don't have access to a FreeBSD box to test. - Paul
PerlChildInitHandler not being called
I looked int he archives for this problem and, while mentioned, not definitive solution was apparantly found. I did notice the handler get called once, but only once: total server shutowns and restarts don't make it get called. I'm using Apache 1.3.12, mod_perl 1.24_01, Perl 5.6 under Linux. - Paul
RE: Clarification of PERL_STASH_POST_DATA
On Wed, 8 Nov 2000, Geoffrey Young wrote: ... Apache::RequestNotes may be able to help - it basically does cookie/get/post/upload parsing during request init and then stashes references to the data in pnotes. The result is a consistent interface to the data across all handlers (which is the exact reason this module came about) This is /exactly/ right. The only caveat is that its API is different from Apache::Request. It Would Be Nice(TM) if the module subclassed itself off of Apache::Request so that the Apache::Request API would Do The Right Thing(TM). it requires Doug's libapreq and probably a few code changes, but it may be somewhat helpful... Such functionality should imply be absorbed into Apache::Request. Doug?? - Paul
Clarification of PERL_STASH_POST_DATA
OK, so the documentation for PERL_STASH_POST_DATA reads:
There is an experimental option for Makefile.PL
called PERL_STASH_POST_DATA. If you turn it on,
you can get at it again with $r-subprocess_env("POST_DATA").
This is not on by default because it adds
overhead.
So I rebuilt Apache and mod_perl with PERL_STASH_POST_DATA=1
on the perl Makefile.PL line; however:
1. What *is* $r-subprocess_env("POST_DATA") ? Just the entire
posted data squished up into a single scalar? What about
file uploads?
2. The $r-subprocess_env("POST_DATA") doesn't even seem to
work. I "warn" it to the log file and I get nothing there.
The general problem is preserving POSTed data, including file
uploads, for all handlers.
- Paul
$r-param() goes poof (Was: POST results in HTTP/1.0 (null))
On Fri, 3 Nov 2000, I wrote: So from within a function, I'm doing my $r = Apache::Request-new( Apache-request() ); warn "request=", $r-as_string(), "\n"; and, when I to a POST request, I get: Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */* Content-Length: 6978 Content-Type: multipart/form-data; boundary=curl3cwvW7Ge8lVBtEGuDRCENOMeIVO Host: www.abacus-new.com:80 Pragma: no-cache User-Agent: Mozilla/4.0 HTTP/1.0 (null) I made a much smaller test case that works fine. I've since discovered that the difference between the case that doesn't work and the case that does is the one that doesn't also includes and authentication handler in its Location section. From within my authentication handler, I also access query string parameters. When I do this, the downstream content handler finds that $r-param() is empty. If I have my authentication handler not touch $r-param(), then the downstream content handler properly gets the parameters. Why does accessing $r-param() from within an authentication (or, generally, and upstream handler) blow them away for downstream handlers? - Paul
Re: POST results in HTTP/1.0 (null) ??
On Sat, 4 Nov 2000, G.W. Haywood wrote: On Fri, 3 Nov 2000, Paul J. Lucas wrote: Why is the content merely "HTTP/1.0 (null)"? What happened to the other 6900 bytes or so? Maybe you need to generate them... I did: if you read my original post, I wrote: Orig If I write a mini server in Perl that just dumps the contents Orig of the HTTP post, the posted data is correct. I'm doing a POST with curl: the data curl generates is fine as is in evidence by the above mini server. do you think you could give us a bit more to go on? I'd be happy to: what else would you like to know? - Paul
POST results in HTTP/1.0 (null) ??
So from within a function, I'm doing my $r = Apache::Request-new( Apache-request() ); warn "request=", $r-as_string(), "\n"; and, when I to a POST request, I get: Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */* Content-Length: 6978 Content-Type: multipart/form-data; boundary=curl3cwvW7Ge8lVBtEGuDRCENOMeIVO Host: www.abacus-new.com:80 Pragma: no-cache User-Agent: Mozilla/4.0 HTTP/1.0 (null) Why is the content merely "HTTP/1.0 (null)"? What happened to the other 6900 bytes or so? If I write a mimi server in Perl that jsut dumps the contents of the HTTP post, the posted data is correct. - Paul
Re: return from nested functions
On Wed, 1 Nov 2000, G.W. Haywood wrote: Or you could call a function which does the business and then calls mod_perl's exit() function, page 464 Eagle Book. I tried exit: the status code isn't preserved to downstream stacked handlers. - Paul
Re: return from nested functions
On Wed, 1 Nov 2000, Dave Rolsky wrote:
On Wed, 1 Nov 2000, Paul J. Lucas wrote:
If I'm a few levels deep into function calls, I'd liek to be
able to do something like "return SERVER_ERROR" and have the
entire call stack unwind and the current request stopped.
Is there any way to do that?
Not that this has anything to do with mod_perl really but ...
Actually it does because the status code should be preserved to
downstream stacked handlers (and, my testing, it apparantly
isn't):
sub some_nested_function {
$r-status( SERVER_ERROR );
Apache-exit( 0 );
}
# in downstream.pm handler
sub handler {
# $r-status() is NOT SERVER_ERROR here
}
- Paul
Re: return from nested functions
On Wed, 1 Nov 2000, Matt Sergeant wrote:
On Wed, 1 Nov 2000, Paul J. Lucas wrote:
If I'm a few levels deep into function calls, I'd liek to be
able to do something like "return SERVER_ERROR" and have the
entire call stack unwind and the current request stopped.
Is there any way to do that?
Definitely use exceptions.
It's rather cumbersome. Ideally, I want to be able to do:
sub foo {
if ( $serious_problem )
stop_now_dammit( SERVER_ERROR );
}
anywhere in the code like:
sub bar {
foo();
}
and I do *NOT* have to "catch" anything after the point of
call, i.e., every call of foo() is similar to an "assertion" in
C, i.e., if you get to the line of code after it, it worked; if
it didn't work, you never get to the line after it.
I suppose I want to do something like Apache-exit() but
preserve the response code so the normal Apache error handling
mechanism kicks in and handles the error.
- Paul
Re: return from nested functions
On Wed, 1 Nov 2000, Paul J. Lucas wrote:
Ideally, I want to be able to do:
sub foo {
if ( $serious_problem )
stop_now_dammit( SERVER_ERROR );
}
anywhere in the code like:
sub bar {
foo();
}
and I do *NOT* have to "catch" anything after the point of
call, i.e., every call of foo() is similar to an "assertion" in
C, i.e., if you get to the line of code after it, it worked; if
it didn't work, you never get to the line after it.
I figured out that I can do this by having stop_now_dammit()
use $r-notes() to set a note of the status code, call
Apache-exit(), and have the downstream handler check the note.
If it's anything but OK, simply return that value and the
normal Apache error handline mechanism kicks in. :)
- Paul
Re: status_line() empty
On Wed, 1 Nov 2000, Paul J. Lucas wrote: OK, so, from within a custom ErrorDocument handler, $r-status() is the status code as I expect; however, $r-status_line() is blank. Any ideas why? It turns out that status_line() isn't populated until after send_http_header() is called. - Paul
Re: HTML Template Comparison Sheet ETA
On Mon, 4 Sep 2000, Nelson Correa de Toledo Ferraz wrote:
I still think that this:
? foreach $name (@names) { ?
Name: ?=$name? P
Job: ?=$job{$name}? P
? } ?
Is cleaner (well, as much as perl can be :-)) than this:
TMPL_LOOP NAME=EMPLOYEE_INFO
Name: TMPL_VAR NAME=NAME P
Job: TMPL_VAR NAME=JOB P
/TMPL_LOOP
And I still think that:
DIV CLASS="employee_info"
Name: SPAN CLASS="text::name"John Q. Public/SPANBR
Job: SPAN CLASS="text::job"mod_perl guru/SPAN
/DIV
is cleaner still: *pure* HTML (no fake elements) that any web
tool will understand and dummy-content so the page designer can
see the end-product before any code is written.
Another benefit in not mixing any code in the template is that
the web page designer can wake up tomorrow and change the
template to:
TABLE
TR
THName/TH
THJob/TH
/TR
TR CLASS="employee_info"
TD CLASS="text::name"John Q. Public/TD
TD CLASS="text::job"mod_perl guru/TD
/TR
/TABLE
and not a single line of the associated Perl code has to
change. So when either the web page designers or the marketers
(*shudder*) decide that the web page needs some snazzing up,
they can snazz them up all they want and they don't have to bug
the programmers to change anything.
See http://www.best.com/~pjl/software/html_tree/ for details.
(I've got the day off today so I'm gonna try to figure out how
to get this thing submitted to CPAN.)
And the first one has two major advantages: 1) requires less code in the
Perl modules
But that's where the code belongs.
and 2) allows designers to know how Perl looks like.
Web designers don't care what the Perl looks like.
I agree that one shouldn't put lots of code inside of a template, but
variables and loops are better expressed in Perl than in a "little crippled
language".
I agree: Perl should be used to its full ability, but none of it
should be in the template.
- Paul
Re: HTML Template Comparison Sheet ETA
On Mon, 4 Sep 2000, Perrin Harkins wrote:
"Paul J. Lucas" wrote:
And I still think that:
DIV CLASS="employee_info"
Name: SPAN CLASS="text::name"John Q. Public/SPANBR
Job: SPAN CLASS="text::job"mod_perl guru/SPAN
/DIV
is cleaner still: *pure* HTML (no fake elements) that any web
tool will understand and dummy-content so the page designer can
see the end-product before any code is written.
Having placeholder data in there is an interesting benefit.
I currently use the .chtml extension to tell Apache to do my
magic (via Files *.chtml). But I often do a:
ln file.chtml file.html
and then I can point my browser at the plain .html version when
I want to see what the mock-up page looks like without executing
any code. In production, I remove the links.
What about conditionals and loops though?
I just got another e-mail about this so I could clarify. There
is no loop that you can see in my example, and this is by design
since HTML doesn't loop.
All of this is explained in the documentaion, but, briefly: the
looping is done under the control of the associated .pm file:
for every HTML file, there is an associated .pm file and that's
where all the code is.
The function bound to the class employee_info tells the HTML
Tree engine that it wants to loop (or not loop) by its return
code.
An example of a conditional:
DIV CLASS="if::do_this"
blah
/DIV
where do_this has to have been already evaluated and the result
stuffed into $this-{ do_this }. But, the "if::" is just a
built-in class (to my module) as a short-cut; you're free to
use your own classes.
The underlying HTML parser is smart enough to "know" what
elements terminate other elements (both explicitly and
implicitly) so it "knows" where the end of the conditional or
loop is.
Wouldn't they break the "preview" ability?
No: for loops, you just get one iteration; for conditionals, you
get the result as if the condition were true.
- Paul
Re: HTML Template Comparison Sheet ETA
On Mon, 4 Sep 2000, Billy Donahue wrote: Great, as long as there's no loops or anything but straight up text replacement... I don't like this approach at all! What I showed *was* a loop; read my other follow-up. What if you need to actually USE the `class' attribute of your HTML element? You can use it just fine: read the HTML spec. The CLASS attribute is allowed to have multiple values separated by whitespace. - Paul
Re: HTML Template Comparison Sheet ETA
On Mon, 4 Sep 2000, Perrin Harkins wrote: I can still think of situtations in applications I've worked on where there were mutually excusive chunks of HTML that would have looked funny with this approach, but it gets you about 95% of the way towards a previewing system for free. Cool. Yes, in the case of mutually-exclusive sections of HTML, you would get shown both for a preview. (There is also a built-in "unless::" class.) In my experience, it's doesn't crop up THAT often. I'm also not claiming the technique is perfect or right for every possible situation. Some hairy HTML pages can take some head-scratching to figure out how to get the page generated using the technique, but the majority of cases are fairly straight-forward. - Paul
Re: HTML Template Comparison Sheet ETA
On Mon, 4 Sep 2000, Eric L. Brine wrote: Great idea, but just one note; ':' is not legal in CSS class names. In fact, underscores are not even allowed in CSS class names! So? They aren't CSS class names. The are in fact legal class names according to the HTML spec. - Paul
Re: HTML Template Comparison Sheet ETA
On Mon, 4 Sep 2000, Eric L. Brine wrote: ELB Great idea, but just one note; ':' is not legal in CSS class names. ELB In fact, underscores are not even allowed in CSS class names! PL So? They aren't CSS class names. In the preview mode, they are treated as such, so in effect they are. Then I think the web browser you're using is broken. The CLASS attribute is (and never was) reserved for the exclusive use of styles. Anything not recognized should be ignored. In addition, if those are not stripped out by your module (and as far as I can tell with a quick look, they are not), They probably *could* be. the resulting HTML does not conform to both strict HTML and CSS. It's 100% conformant to HTML: please go read the specification. As to CSS, I can't comment with authority since I'm not that familiar with the specification; but, as I said above, I would hope that anything not recognized is ignored. PL The are in fact legal class names according to the HTML spec. The HTML spec doesn't define what is a legal class name. It's simply defined as "CDATA" (i.e. a HTML escaped string). Then anything that is legal CDATA is a legal class name, by definition. I really don't know how to make that any clearer. - Paul
RE: Templating System (preview Embperl 2.0)
On Fri, 28 Jul 2000, Gerald Richter wrote: As far as I understand you you use mmap to read in the source file, is this correct? Yes. If this is true, then it will not make much difference, because reading in the source is only a very small piece of all the time that it takes to generate the output from a dynamic page. I suggest you do some benchmarks. I have, albeit many months ago. If I recall correctly, I took Yahoo's home page and ran it through my HTML Tree and that of Gisle Aas: HTML was about 7-8 times faster. My point was, that the C implementation of parsering and DOM tree storage/caching, is much faster (uses much less memory) then doing the same in Perl. ...and faster still with mmap(2). - Paul
[OT]: mmap (Was: Templating System (preview Embperl 2.0))
On Fri, 28 Jul 2000, Kenneth Lee wrote: it would be good for the user to choose between mmap or normal i/o at compile time. i'll try HTML::Tree anyway in the meantime. It's not that simple. Using mmap(2) greatly affects how one writes code: it's not a drop-in replacement for standard I/O. An mmap'd file *becomes* memory in the time it takes the OS to handle a page-fault. You then further get speed by accessing the file *as* memory via ordinary pointers rather than function calls and I/O buffers. Inside the HTML Tree code is a generic C++ STL-style container class wrapped around mmap...quite nice if I do say so myself. By definition, file I/O off disk can't be faster than mmap(2). - Paul
Re: template kit.....
On Fri, 28 Jul 2000, Denton River wrote: Its been a long time since i have done a jobb without using sessions. I would really like to have this feature included in the kit im using and i think alot of developers are with me on this one. What I don't understand is *why*. Why can't you use to independent pieces of software: one for templates and the other for sessions that work perfectly well together (or seperately)? I personally prefer smaller, more easily udnerstandable pieces to large, complex, feature-bloated software. - Paul
Re: [OT]: mmap (Was: Templating System (preview Embperl 2.0))
On Fri, 28 Jul 2000, Malcolm Beattie wrote: Assuming the kernel only keeps track of the last fault position in the file, it won't recognise that it's being read linearly (twice :-) and may well not do the async read ahead and drop behind in page cache that it would do otherwise. Once again, you'll lose performance with mmap. And reading in the file twice into two separate I/O buffers is better? - Paul
Re: Templating system
On Thu, 27 Jul 2000, Darko Krizic wrote: I want to write a new application using mod_perl but this time I want to completely divide the code from the HTML. Therefore I am seeking for a powerfull and fast templating system. http://www.best.com/~pjl/software/html_tree/ It does precisely what you're asking. - Paul
RE: Templating system
On Thu, 27 Jul 2000, Darko Krizic wrote: The only problem I see here is the performance. Enhydra compiles the java and the HTML pages and creates methods and a DOM model. Doing this on the fly (for mod_perl) would be a big drawback in performance. Maybe there should be some kind of precompiling. My HTML Tree method (previously gave the URL) is several times faster than conventional DOM parsers. Among other things, it uses mmap(2) to read files and, by definition, you can't get faster I/O. - Paul
Re: Templating System
On Thu, 27 Jul 2000 [EMAIL PROTECTED] wrote: Now, your TD cells are going to get the red (assuming you aren't using Netscape's broken CSS). But how could you force one cell to get the yellow? The normal way to do it would be TD ID="oneTD" but you have already used up your ID tag. ...which is why the CLASS attribute is a better choice: it specifically allows multiple classes, e.g.: CLASS="one two three" - Paul
Re: Templating system
On Thu, 27 Jul 2000, Jeffrey W. Baker wrote:
On Thu, 27 Jul 2000, Paul J. Lucas wrote:
http://www.best.com/~pjl/software/html_tree/
Hey, that's really nice.
Thanks. :) Admitedly, the web site could use more example
other than what's in the manual pages, but where, oh where, to
find the time...
And once the template HTML files are parsed, I can just leave the $root_node
in memory for future requests, right?
Yes, I suppose so... I never thought hard about doing that.
The reason is that you have to be careful about doing it since
the Perl/mod_perl API *intends* for you to manipulate/change
the structure/content, hence what you're left with after a page
generation is not the same HTML tree you started with.
The HTML DOM parsing is really fast since that part of the
software is written natively in C++ with memory-mapped I/O.
(It's the same parsing engine used in SWISH++, FWIW.)
HTML Tree does, however, cache the associated Perl (.pm) code
for a page just like Apache::Registry does (based on timestamp).
And since the parser isn't validating, I can extend HTML with tags like
NODE, BANNER, and WHATEVER, right?
Not really, actually. The reason is that the HTML parser
doesn't know anything about non-standard HTML elements so it
can't know if an element (not "tag") you make up has a required
or optional end tag to get the parsing ("balancing") right. If
this were XML, it would be a different story.
Currently, "made up" elements are ignored entirely, i.e., *not*
added to the resultant HTML DOM tree and do not affect
"balancing" during parsing.
- Paul
Re: Templating system
On Thu, 27 Jul 2000, Matt Sergeant wrote: http://www.best.com/~pjl/software/html_tree/ Aside from the GPL, it does looks nice. What's wrong with the GPL? It's open-source and free of cost. What more do you want? - Paul
[OT]: GPL (Was: Templating system)
On Thu, 27 Jul 2000, Matt Sergeant wrote: I wrote: What's wrong with the GPL? It's open-source and free of cost. What more do you want? The ability to build commercial applications. The GPL allows you to use and incorporate GPL'd software into commercial applications. However, if you *modify* the GPL'd software, you *must* make said modifications freely available under the GPL also. If you don't modify it, there is no issue. Also, just because a piece of code is GPL'd does *not* preclude the author from granting *separate* commercial licenses. As the author for HTML Tree, I can grant as many any additional licenses under any terms I please. For example, if you wanted to use HTML Tree *and* make *proprietary* modifications, I'd be happy to charge you a licensing fee. However, again, merely *using* GPL'd software *as-is* requires so such additional license. Please re-read the GPL. FYI: I've also had correspondence with the FSF on such issues and the above is correct. - Paul
Re: Templating System
On Thu, 27 Jul 2000, Jacob Davies wrote:
INPUT TYPE="TEXT" NAME="first_name" VALUE="#FIRST_NAME HTMLESC"
If I understand what this does, my HTML Tree can do this by
doing:
INPUT TYPE=text NAME="first_name" VALUE="" CLASS="value::first_name"
where the VALUE would be filled in from the value stored in:
$this-{ first_name }
where $this is a reference to an object created by the
associated .pm file and first_name was (presumeably) read in
from a database via DBI.
A HREF="/somehandler?email=#EMAIL URLESC"
This can be done by doing:
A HREF="/somehandler?email=REPLACE" CLASS="repl_email"
and in the .pm:
$node-atts-{ href } =~ s/REPLACE/$real_address/;
or just by changing the entire value:
A HREF="/somehandler?email=bogus" CLASS="href::handler"
where "handler" is taken from:
$this-{ handler }
SELECT NAME="country"
OPTION VALUE="uk" #COUNTRY SELECTEDIF="uk" The Mother Country
OPTION VALUE="us" #COUNTRY SELECTEDIF="us" Some Other Country
/SELECT
This is specifically supported by doing (example take from
Apache::HTML::ClassParser man page):
SELECT NAME="Flavor"
OPTION CLASS="select::flavor_id" VALUE="0"Chocolate
OPTION CLASS="select::flavor_id" VALUE="1"Strawberry
OPTION CLASS="select::flavor_id" VALUE="2"Vanilla
/SELECT
I've seen features one two in some packages, in HTML::Template maybe, but I
haven't seen the third one anywhere at all. Maybe I'm missing where someone
has already done it.
Yes, in HTML Tree.
- Paul
Re: Templating System
On Thu, 27 Jul 2000, Autarch wrote: option value="uk" % 'selected' if $country eq 'uk' % Seems pretty close to what you want, I think. Except it puts Perl code in the HTML file and uses invalid HTML. - Paul
RE: Templating system
On Thu, 27 Jul 2000, Douglas Wilson wrote: http://www.best.com/~pjl/software/html_tree/ Is there a reason this is not on CPAN? The reasons (not necessarily good ones) are: 1. I haven't had the time to figure out their submission procedures. 2. It's not (in my mind) in the "CPAN style" for the C++ part of the build, i.e., you can't just say: perl Makefile.PL make (You can say that for the Perl parts, however.) The C++ part doesn't require Perl at all. 3. Although in practice it will most likely be used with Perl or mod_perl, it's a stand-alone C++ library/API. - Paul
RE: Templating System (preview Embperl 2.0)
On Thu, 27 Jul 2000, Gerald Richter wrote: To keep it fast Embperl is written in C. Unless you use mmap(2), you can't compete with the speed of HTML Tree. The only downside of mmap(2) is that HTML Tree must be first in an Apache::Filter filter chain. - Paul
Re: [is it time for something other than html?] RE: Templating system
On Thu, 27 Jul 2000, Jauder Ho wrote: If there was somehow a way to cache say the template, leaving only the same dynamic portion uncached, it would certainly help things along quite a bit. An improvement to the technique used by HTML Tree is to "collapse" the non-dynamic portions of an HTML file into a single text node. Given: H1Heading/H1 This is ordinary content. It is Bnot/B dynamic. This line, SPAN CLASS="sub_word"however/SPAN, is. You would ordinarily get: Element Node: H1 Text Node: Heading Text Node: This is ordinary content. It is Element Node: B not Text node: dynamic. This line, Element Node: SPAN Text Node: however Text Node: , is. But, since the bulk of that is static, the portains that do *not* contain elements having CLASS attributes could be "collapsed" so that you get: Text Node: H1Heading/H1 This is ordinary content. It is Bnot/B dynamic. This line, Element Node: SPAN Text Node: however Text Node: , is. i.e., the non-synamic HTML elements can be treated just like plain text and passed through untouched. You could also devise a more complicated data structure that would cache such nodes separately. - Paul
RE: [is it time for something other than html?] RE: Templating s
On Thu, 27 Jul 2000 [EMAIL PROTECTED] wrote: H2[+ $forum-title +]/H2 The problem with this is that it looks really ugly in Dreamweaver (for example). The HTML designer can't design a mock-up page with dummy content using that technique that can then be passed off to the coder. With HTML Tree you can say: H2 CLASS="text::forum_title"Recreational basketweaving/H2 i.e., put dummy content so the web page designer can see what a real page will look like and tweak things like spacing, etc. That HTML then can be used *as-is*, dummy content and all, with HTML Tree since the dummy content is replaced dynamically. - Paul
Re: Templating System
On Thu, 27 Jul 2000, Joshua Chamas wrote: Did you know that ASP also has a really great event model, like Session_OnStart, Session_OnEnd, etc, I still don't see this in the other templating modules. IMHO, dynamic content page generation should have nothing to do with session management. - Paul
Re: storing db handles
On Mon, 21 Feb 2000, Brendan W. McAdams wrote:
I found some info on Apache::DBI in the Mod_Perl developers guide that may
help. Basically though I globalised $dbh and then made my connection code
this:
$dbh ||= DBI-connect("dbi:mysql:$database","$db_user","$db_pass");
Unless I'm misreading the Apache::DBI manual page, this is
completely unnecessary. Apache::DBI makes persistent
connections transparent so you can call connect() and
disconnect() as normal. You don't need to do one-time
initializations, global variables, or anything.
- Paul
send_http_header and subrequests
The second example on p. 128 of the Eagle book sets the content
type and send the HTTP headers itself before running a
subrequest.
However, on p. 468, the documentation for the run() method says
in part:
When you invoke the subrequest's response handler in
this way, it will do everything a response handler is
supposed to, includinf sendinf the HTTP headers and the
document body. ... If you arevoking the subrequest
urn() method from within your own content handler, you
must not sen the HTTP headers and document body
yourself ...
These seem to contradict each other. From testing, however, it
seems as though the example on p. 128 is correct and the
documentation on p. 468 isn't. Is this true?
The above aside, I'm having a problem when using subrequests
when the subrequest also involves a (different) content handler.
First, in a VirtualHost block, I have:
AddType text/html .chtml
Files *.chtml
SetHandlerperl-script
PerlHandler +Apache::HTML::ClassParser
/Files
that sets up the aforementioned "different" content handler
that uses .chtml files to generate dynamic content pages. The
ClassParser content handler, as expected, calls send_http_header()
when it's ready to generate output. It does, in part:
sub handler {
# ...
return DECLINED if $r-content_type ne 'text/html';
# ...
$r-send_http_header();
# ... generate content ...
return OK;
}
Using this content handler by itself works just fine; however,
when I try to use it in conjunction with another content
handler, things don't work right.
Briefly, I have a Location block like:
Location /get
SetHandlerperl-script
PerlHandler +My::Get
/Location
that is a content handler that will, among other things, do
on-the-fly conversions (similarly to the ImageMagick example in
the Eagle book). The My::Get handler does, in part:
my $sub_r = $r-lookup_file( $full_path );
my $status = $sub_r-status();
unless ( $status == DOCUMENT_FOLLOWS ) {
$r-log_error( "Can't look up $full_path" );
return $status;
}
$r-send_http_header( $sub_r-content_type() );
return OK if $r-header_only();
return $sub_r-run();
When I use My::Get by itself, it works fine: it will correctly
serve documents of any type. However, I'd like My::Get to
simply be able to serve dynamic content pages if that's what
it's asked to do to provide a uniform URL scheme.
If $full_path refers to some .chtml file, things don't work
right: I get two sets of response headers (200 OK) but the
message that Apache prints is the canned "Document moved" error
(with A HREF=""here/A, i.e., an empty URL). Things I
tried:
1. In My::Get(), not calling send_http_header(). This results in
ordinary documents not being served correctly, e.g., the
content type is wrong.
2. In My::Get(), if $full_path ends up being a .chtml file, do:
$r-filename( $full_path );
return DECLINED;
This results in the correct headers; however, the raw HTML is
served, i.e., the ClassParser handler is never called on the
file.
I looked in the Eagle book about calling send_http_header()
from within subrequests by reading the documentation for
is_initial_req() and is_main(), but neither says anything about
send_http_header().
How can I get Apache to do what I want, i.e., have My::Get serve
a file that is handled by another content handler?
- Paul
Re: lookup_uri and access checks
On Thu, 3 Feb 2000, G.W. Haywood wrote: On Wed, 2 Feb 2000, Paul J. Lucas wrote: I have code that contains the line: $r-lookup_uri( $r-param( 'pm_uri' ) )-filename; [snip] However, if I have an access restriction that forbids access to files ending in a .pm extension and the URI maps to such a filename, then I get a "client denied by server confiruation" message in the error log. Are you checking the status of the subrequest? (Eagle book, p453). No. Intentionally. As I wrote, I don't care what Apache says about the accessibility of the file. I *will* read it. All I want to do is suppress the "client denied by server request" messages in the log. - Paul
lookup_uri and access checks
I have code that contains the line: $r-lookup_uri( $r-param( 'pm_uri' ) )-filename; The parameter pm_uri is a hidden form field that contains a URI for a file. I use lookup_uri() to translate that (eventually) into an absolute filename. However, if I have an access restriction that forbids access to files ending in a .pm extension and the URI maps to such a filename, then I get a "client denied by server confiruation" message in the error log. (Not surprising.) However, I'm still able to read the file myself from within the handler routine. (This is the desired behavior and it's also not surprising. I want to forbid *direct* access to .pm files by a client so user's can't see the contents, but still have them accessible to my handler.) What I'd like, though, is to resolve a URI to a filename *only* and not have Apache do access checks so I don't get a spurious "client denied" error. Is there any way to do this? - Paul
Re: JOB OPENINGS -- INDIANAPOLIS
On Tue, 1 Feb 2000, Mark Jaaneston wrote: Still, I don't know if it is appropriate for [EMAIL PROTECTED] to be a forum for recruiting -- what's the consensus on this guys? Although new to the list, my experience with recruiters is that they aren't worth the space they occupy. E-mail lists are cheap: anybody can easily create a modperl-jobs mailing list. Those who want to read such things can subscribe to it; those who don't won't have to wade through such crap. - Paul
RE: www.modperl.com
On Tue, 1 Feb 2000, Baiju Thakkar wrote: How about putting Chapter 3,4, and 5 online. I own one copy and its usually at work. Sometime when I am at home I wish I had another copy. That's an easily solvable problem: buy another copy. Unless you're severly underpaid as a programmer, you can afford it. - Paul
RE: Novel technique for dynamic web page generation
On Mon, 31 Jan 2000, Matt Sergeant wrote: What about designers wanting to use CSS? Classes not in the class map are ignored, so CSS still works. - Paul
Re: www.modperl.com
On Sun, 30 Jan 2000, Gunther Birznieks wrote: Another question is why www.modperl.com at all? Why not store the material as part of the main mod_perl site? Or off of the apache site? I guess I am just not sure why the site which seems to be centered around the book is its own site anyway? Despite the fact that it's an amazing book, I have to agree with his comments. IMHO, www.modperl.com, if it exists, should be about the module (and not the book) just like www.modssl.org is about the module. The book info should either be a sub-page under www.modperl.com or under the apache site (or even perhaps www.book.modperl.com). - Paul P.S.: Ralf Engelschall designs nice web pages, IMHO; perhaps you can get him to help you with www.modperl.com.
Re: Novel technique for dynamic web page generation
On 30 Jan 2000, Gisle Aas wrote: $ perl test.pl Benchmark: timing 1000 iterations of Parser, Parser3... Parser: 30 wallclock secs (29.31 usr + 0.20 sys = 29.51 CPU) Parser3: 2 wallclock secs ( 1.39 usr + 0.17 sys = 1.56 CPU) ...but this is kind of a useless benchmark, as it does not do anything. It parses the file into a tree which is precisely what I'm benchmarking. - Paul
RE: Novel technique for dynamic web page generation
On Sun, 30 Jan 2000, Ron Pero wrote:
How do you handle "sticky widgets"?
I've never heard that term before.
I put perl variables in the VALUE attribute of input boxes. These show up for
the designer. Are you able to get around that? input type="text"
name="CustomerFName" VALUE="[%$customer_info{'CustomerFName'}%]"
Yes. You simply put in dummy content:
INPUT TYPE=text NAME="CustomerFName" CLASS="value::customer_name"
VALUE="Joe Blow"
where "customer_name" is a key into the page's object hash, i.e.:
$this-{ customer_name }
that was presumeably read via DBI. (You can name the key
anything you like, of course.)
The dummy content is substituted out for actual content.
Again, one of the plusses for this technique is that the
designer sees what a REAL page will look like.
- Paul
Re: Novel technique for dynamic web page generation
On 28 Jan 2000, Randal L. Schwartz wrote:
Have you looked at the new XS version of HTML::Parser?
Not previously, but I just did.
It's a speedy little beasty. I dare say probably faster than even
expat-based XML::Parser because it doesn't do quite as much.
But still an order of magnitude slower than mine. For a test,
I downloaded Yahoo!'s home page for a test HTML file and wrote
the following code:
- test code -
#! /usr/local/bin/perl
use Benchmark;
use HTML::Parser;
use HTML::Tree;
@t = timethese( 1000, {
'Parser' = '$p = HTML::Parser-new(); $p-parse_file( "/tmp/test.html" );',
'Tree' = '$html = HTML::Tree-new( "/tmp/test.html" );',
} );
-
The results are:
- results -
Benchmark: timing 1000 iterations of Parser, Tree...
Parser: 37 secs (36.22 usr 0.15 sys = 36.37 cpu)
Tree: 7 secs ( 7.40 usr 0.22 sys = 7.62 cpu)
---
One really can't compete against mmap(2), pointer arithmetic,
and dereferencing.
- Paul
Novel technique for dynamic web page generation
I've implemented what I believe to be a novel technique for dymanic web page generation. Although explained in much more detail here: http://www.best.com/~pjl/software/html_tree/ essentially it parses an HTML file into a DOM-like tree where a "visitor" function is called for every node in the tree. The parser in written in C++ using mmap(2) for speed, but there is a Perl XS layer and Apache mod_perl module. Using the Apache module, you can bind HTML CLASS attributes to functions via a class map that is simpy a Perl hash. The novel thing about this is that pure, standard HTML files are used. This allows one to create a mock-up of the page complete with dummy data to see how it will look and then take that same page, without modification, and have it used to generate dynamic content. The code behind the page is in a separate .pm file (that is cached similarly to the way Apache::Registry does it). - Paul
Re: Novel technique for dynamic web page generation
On Fri, 28 Jan 2000, Perrin Harkins wrote: Looks almost exactly like XMLC from http://www.enhydra.org/. I hadn't heard of that, but, from a quick look, enhydra is XML/Java not HTML/Perl. It also seems like a much more "involved" solution. It's an interesting idea to use straight HTML, since it enables you to take HTML generated by authoring tools and use it immediately, That's the exact point, yes. :-) Another small benefit is it allows the web page author to see a mock-up page without having to have any code behind it. Hence, a web site can be designed in mock-up first. but it seems like it does tie your program closely to the structure of the documents. It does somewhat, but much less so than existing techniques: 1. Conventional CGI (a print-statement-laden Perl script): this tightly intertwines code and markup. 2. Embedded Perl (e.g., ePerl): variables are placed at specific points in the markup. 3. Non-standard tags: placed at specific points in the markup. (Another downside: DreamWeaver doesn't understand them.) So, to me, all those techniques tightly tie the document structure to the code. However, with this technique, you can move CLASS names around freely and NOT have to touch a single line of code. For example, if at first I have: OL CLASS="query_db" LI CLASS="fetch_next" SPAN CLASS="text::name"John Smith/SPAN lt;SPAN CLASS="text::email"[EMAIL PROTECTED]/SPANgt; /OL that queries a database and lists people and their e-mail addresses, I can then change the HTML to use a table instead: TABLE CLASS="query_db" TR CLASS="fetch_next" TD CLASS="text::name"John Smith/TD TD CLASS="text::email"[EMAIL PROTECTED]/TD /TABLE and not have to touch a single line of the underlying Perl code. In theory, if the people who design the web pages using DreamWeaver and the Perl programmers agree on conventions for CLASS names in advance, the pages generated by the web designers should "just work." The "win" is being able to separate the "getting the data" part in the Perl code and its "presentation" part in the HTML. Am I correct in thinking that if you want to put a piece of text pulled from a database into a page you have to know exactly where it should end up in the HTML parse tree? Yes; but you control where that is by editing the HTML file. And you can reedit it and move it around again and again; and you never have to touch the underlying Perl code. See above. - Paul
Re: Novel technique for dynamic web page generation
On Fri, 28 Jan 2000, Jason Bodnar wrote: The resultant file, no longer pure HTML, is something that can not be read back into DreamWeaver should the page need a tweak. Hmmm ... I thought one of the big pluses of Dreamweaver is that it guaranteed roundtrip HTML. I'm guessing it doesn't? I suppose it depends on what one does to the HTML. Even if it does now, it still doesn't allow mock-up content to be easily replaced. - Paul
Re: Novel technique for dynamic web page generation
On Fri, 28 Jan 2000, Perrin Harkins wrote:
I wrote:
3. Non-standard tags: placed at specific points in the markup.
(Another downside: DreamWeaver doesn't understand them.)
Now that I've seen your example, it seems to me that you are doing almost
exactly the same as #3. The only difference is that you're using HTML
extensions ("CLASS=foo") that are legal in authoring tools.
Not quite. If you use a package like Meta-HTML, the non-
standard tags are used to do ALL the work including (for
example) database queries and iterations. Hence, the "logic"
is very much embedded within a given point in the HTML file as
well.
My technique completely separates the logic from the dynamic
content substitution.
This is different from XMLC, which requires the program using it to specify
which node to replace the contents of.
Right: my technique is not tied to a specific node; it's tied to
ANY node that has the right CLASS names.
I think your approach is better.
Thanks! :-)
- Paul
