All the Perl that's Practical to Extract and Report

Too much juggling

Ovid on 2003-02-06T00:16:24

My brain is going to melt today. I'm using Perl to execute SQL, with results that get passed to Template Toolkit, that uses the results to write JavaScript to rewrite HTML on the fly. Every once in a great while I miss writing batch processes in COBOL.

been there

gav on 2003-02-06T00:51:08

now get your javascript to write out tags that call a perl script that writes out javascript which is the result of a database call and changes the page further and you'll understand a project I worked on :)

Re:been there

Ovid on 2003-02-06T04:34:30

We have a problem whereby a country might have states and it might not. We have to populate a selection box based upon that. Thus, with an onchange event with the country select box, we use javascript to detect if the country has states (using a hash of country IDs) and if it does, we launch a pop up with a drop down (populated by a database call :) that allows the user to select a state and then write that state back to the original form via DHTML.

Oh, and due to DHTML issues with the cascading menus (and other issues, but I'll stop), the decision has been taken to use a Python driven GUI to drive the menus, thus throwing a sixth language into the mix. I've never in my career worked on anything so complicated and it's interesting to see how seamlessly everything works together, once I get my brain reinflated with enough caffeine.

A Suggestion

dreadpiratepeter on 2003-02-06T01:01:53

Depending on your miniumum level of browser support you might find is simpler and more portable to have the javascript manipulate the DOM directly. IE 5.5 and Mozilla 1.whatever both have pretty complete DOM support (except for Microsoft's propriatary event stuff).
Plus it really cuts down on the hardest part of the perl-that-generates-html-that-contains-javascript-the-generates-html-that-contai ns-javascript parentheses-nesting nightmare.
With the O'Reilly Dynamic HTML book (2nd edition) it's easy to cut through a lot of that. With Data::Locations to build clean HTML it's even easier.

Pete

Re:A Suggestion

Ovid on 2003-02-06T04:36:19

One of my coworkers was mentioning that book today. Sigh. More money to spend.

I'll have to check out that module, too. I've not heard of it.

Re:A Suggestion

dreadpiratepeter on 2003-02-06T06:07:57

"Dynamic HTML: The Complete Reference" would be a bargain if they priced it at $500 dollars, in the 6 months I have had it, I would estimate that it has saved me at least 20 hours of billable time (probably more). Multiply that by the billing rate of your choosing and calculate it's value. It details every last nook and cranny of HTML, the DOM, all the event models, CSS and JavaScript Core Classes. And it documents what works and doesn't work in every resonable version of IE, Mac IE and Netscape/Mozilla

Data::Locations allows you to collect text and allows you to define insertion points into which you can insert text within the main flow. It treats these as file handles you can write to. For example, I have a $style, $script, and $body handle All the HTML scaffolding around them is built at the top of my script. I can output these three blocks sequentially even though I intermingle writes to each of them throughout the course of writing my page. I then dump the location buffer and get a page.

Of course this has the bad effect that I can't flush the buffer to give the appearence of progress to the browser, but on the other hand I generate much smaller cleaner code with 1 style and 1 script block, rather than lots of little blocks, so the page downloads faster and renders faster.

Re:A Suggestion

vsergu on 2003-02-08T01:59:24

"Dynamic HTML: The Complete Reference"

Is that Dynamic HTML: The Definitive Reference , from O'Reilly, or is there some other book out there?

Re:A Suggestion

dreadpiratepeter on 2003-02-08T14:55:08

Yes, definitive. Sorry. The sad part is that the book was right in front of me when I posted that.