RE: Novel technique for dynamic web page generation
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-{ 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.
What about designers wanting to use CSS?
--
Matt/
Details: FastNet Software Ltd - XML, Perl, Databases.
Tagline: High Performance Web Solutions
Web Sites: http://come.to/fastnet http://sergeant.org
Available for Consultancy, Contracts and Training.
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: Novel technique for dynamic web page generation
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 dynamic content; or embedding Perl code for the same thing. This is a tedious process. The resultant file, no longer pure HTML, is something that can not be read back into DreamWeaver should the page need a tweak. Instead, the source page must be modified all over again. This is a pain. Hence my technique. For that reason HTML::Embperl uses the [ ] blocks to embedd Perl. This is normal Text in Dreamwaver, Frontapge or wahtever and causes no problems. Our designers works with such tools, with embbeded Perl without problems and without the need to edit the source code. Also you can put all of your Perl code inside the HTML Page, you are also able to put it inside a Perl module and just call it from the page to get the sparation of code and layout you intent. Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925151 WWW:http://www.ecos.de Fax: +49 6133 925152 -
RE: Novel technique for dynamic web page generation
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 in the html page you are right, if you just put the the neccessary code there and the rest in a module, then it maybe also helpfull for the designer to see, that there is something going on... Both methods has their advantages. And, again, the first time the page is designed, the code isn't there: you have to insert it by hand in just the right places. If your design is able to place the right class=foo in the code, he/she could also be insert [- foo -] in the html code, this makes no difference. Most time designers will not be able to inserts both such constructs in the right place, because they are not able to understand what's going on behind the scenes. I don't want to say that Embperl makes your approach senseless, I just want to say it also handles this problem, also in a different way and I am sure their are people who like your way and other who like more Embperl's way. Gerald
Re: Novel technique for dynamic web page generation
"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 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.
That's because you fall back to version 2 compatibility when you don't
provide any arguments to the HTML::Parser constructor. The parser
will then make useless method calls for all stuff it finds, and method
calls with perl are not as cheap as I would wish.
- test code -
use Benchmark;
use HTML::Parser;
timethese( 1000, {
'Parser' = '$p = HTML::Parser-new(); $p-parse_file( "./index.html" );',
'Parser3' = 'HTML::Parser-new(api_version = 3)-parse_file( "./index.html" );'
} );
-
$ lwp-download http://yahoo.com
Saving to 'index.html'...
11.6 KB received in 2 seconds (5.8 KB/sec)
$ 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.
Regards,
Gisle
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
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 all over his
screen would be rather ugly.
How do you handle "sticky widgets"? 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'}%]"
Ron
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
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: 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 each instance of that tag in the html page and to bind attributes for each tag to variables and methods in the class. altho i havent actually looked at the code, im a big fan of the approach. of course a requirement of using it is that your application's interface is strictly html based. but thats the case for a very large percentage of web applications. i will definitely be trying this stuff out.
Re: Novel technique for dynamic web page generation
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 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.)
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. Otherwise,
this is really the same effect as using HTML::Template or Template
Toolkit.
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.
This is different from XMLC, which requires the program using it to
specify which node to replace the contents of. I think your approach is
better.
- Perrin
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
