On Mon, 31 Jan 2000, Paul J. Lucas wrote:
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-{
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
We have this problem in my company (and I'm sure it occurs in
others as well). Our web-dev guys use DreamWeaver to create
sexy pages. Previously, said pages must then be taked by
programmers and hacked inserting "magic strings" to later be
substitued for
For that reason HTML::Embperl uses the [ ] blocks to embedd
Perl. This is
normal Text in Dreamwaver, Frontapge or wahtever and causes no problems.
Except I think the designer seeing Perl code all over his
screen would be rather ugly.
If you include the complete Perl source
"Paul J. Lucas" [EMAIL PROTECTED] writes:
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
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
At 07:57 AM 01/30/00 -0800, Paul J. Lucas wrote:
On Sun, 30 Jan 2000, Gerald Richter wrote:
For that reason HTML::Embperl uses the [ ] blocks to embedd Perl. This is
normal Text in Dreamwaver, Frontapge or wahtever and causes no problems.
Except I think the designer seeing Perl code
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"
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
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
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
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
On Fri, 28 Jan 2000, Perrin Harkins wrote:
Looks almost exactly like XMLC from
http://www.enhydra.org/. It's an interesting idea to
sounds a lot more like the approach webobjects takes. except
that webobjects defines a special tag representing a dynamic
element, and then uses a map to type
On Fri, 28 Jan 2000, Paul J. Lucas wrote:
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
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
15 matches
Mail list logo
