This opinion was very thoughtful, and responsibly offered 'why' and 'how' to avoid embedding code in HTML, but is it tied to one particular set of experiences, or just a design preference?
I've heard this kind of thing, but I can't fully make sense of it. Maybe I'm doing things all wrong, or maybe just differently enough that the answer is different?
I embed Perl in HTML in ASP-like <%... %> tags, but translate the whole thing to pure perl with a simple little translator. This just converts the parts outside <%... %> to 'here documents' that get printed on STDOUT. So something like:
<% sub process {... } %> <% sub display {... %> <HTML>... with substitutions... </HTML> <% } # end sub display %>
is roughly translated to
sub process {... }
sub display {... print <<END_HTML <HTML>... with substitutions... </HTML> END_HTML } end sub display
In other words I translate from perl embedded in HTML to/from HTML embedded in Perl, and with a minimum of care, each of my pages (which require processing) becomes a pair of subroutines in a separate perl module.
And yet I can use an HTML editor to quickly edit my page layouts. (e.g. Homesite handles <%... %> extremely well).
Each such module encapsulates everything about one page and the glue necessary to attach it to the rest of the system. One subroutine knows how to process that particular page, the other knows how to display it. This file contains the layout and the glue for just that page. Everything that is not particular to processing or displaying that particular page, as laid out, is separate.
Is this what you are talking about? Or not enough?
I was attracted to EmbPerl and ASP and Mason etc, but the complexity and processing models and constraints they imposed didn't seem attractive, let alone the additional complexities of learning and debugging. With just CGI.pm I can debug my new scripts very easily (just specify parameter values).
Either I've fallen upon a great simple way for achieving the separation you talk about, with all the benefits of what you've disavowed, or I'm missing the boat? Comments please?
This opinion was very thoughtful, and responsibly offered 'why' and 'how', but is it tied to one particular set of experiences, or just a design preference? In other words, is it a design choice, or based on past observation? I've heard this kind of thing, but I can't quite make sense of it. Maybe I'm doing things all wrong, or maybe just differently enough that the answer is different? I embed Perl in HTML in ASP-like tags, but translate it all to pure perl with a little translator. This just converts the parts outside to 'here documents' that get printed on STDOUT. So something like:... with substitutions... is roughly translated to sub process {... } sub display {... print... with substitutions... END_HTML } end sub display In other words I translate from perl embedded in HTML to/from HTML embedded in Perl, and with a minimum of care, each of my pages (which require processing) becomes a pair of subroutines in a separate perl module. And yet I can use an HTML editor to quickly edit my page layouts. (e.g. Homesite handles extremely well). Each such module encapsulates everything about one page and the glue necessary to attach it to the rest of the system. One subroutine knows how to process that particular page, the other knows how to display it. This file contains the layout and the glue for just that page. Everything that is not particular to processing or displaying that particular page, as laid out, is separate. Is this what you are talking about? Or not enough? I was attracted to EmbPerl and ASP and Mason etc, but the complexity and processing models and constraints they imposed didn't seem attractive, let alone the additional complexities of learning and debugging. With just CGI.pm I can debug my new scripts very easily (just specify parameter values). Either I've fallen upon a great simple way for doing what you are talking about with all the benefits of what you disavow, or I'm deluded? Comments please?
Slashdot Mirror
[ SORRY this was posted as HTML. First time! ]
... %> tags, but translate the whole thing to pure perl with a simple little translator. This just converts the parts outside <% ... %> to 'here documents' that get printed on STDOUT. So something like:
... } %> ... %> ... with substitutions ... </HTML>
... }
... ... with substitutions ... </HTML>
... %> extremely well).
This opinion was very thoughtful, and responsibly offered 'why' and 'how' to avoid embedding code in HTML, but is it tied to one particular set of experiences, or just a design preference?
I've heard this kind of thing, but I can't fully make sense of it. Maybe I'm doing things all wrong, or maybe just differently enough that the answer is different?
I embed Perl in HTML in ASP-like <%
<% sub process {
<% sub display {
<HTML>
<% } # end sub display %>
is roughly translated to
sub process {
sub display {
print <<END_HTML
<HTML>
END_HTML
} end sub display
In other words I translate from perl embedded in HTML to/from HTML embedded in Perl, and with a minimum of care, each of my pages (which require processing) becomes a pair of subroutines in a separate perl module.
And yet I can use an HTML editor to quickly edit my page layouts. (e.g. Homesite handles <%
Each such module encapsulates everything about one page and the glue necessary to attach it to the rest of the system. One subroutine knows how to process that particular page, the other knows how to display it. This file contains the layout and the glue for just that page. Everything that is not particular to processing or displaying that particular page, as laid out, is separate.
Is this what you are talking about? Or not enough?
I was attracted to EmbPerl and ASP and Mason etc, but the complexity and processing models and constraints they imposed didn't seem attractive, let alone the additional complexities of learning and debugging. With just CGI.pm I can debug my new scripts very easily (just specify parameter values).
Either I've fallen upon a great simple way for achieving the separation you talk about, with all the benefits of what you've disavowed, or I'm missing the boat? Comments please?
This opinion was very thoughtful, and responsibly offered 'why' and 'how', but is it tied to one particular set of experiences, or just a design preference? In other words, is it a design choice, or based on past observation? I've heard this kind of thing, but I can't quite make sense of it. Maybe I'm doing things all wrong, or maybe just differently enough that the answer is different? I embed Perl in HTML in ASP-like tags, but translate it all to pure perl with a little translator. This just converts the parts outside to 'here documents' that get printed on STDOUT. So something like: ... with substitutions ... is roughly translated to sub process { ... } sub display { ... print ... with substitutions ... END_HTML } end sub display In other words I translate from perl embedded in HTML to/from HTML embedded in Perl, and with a minimum of care, each of my pages (which require processing) becomes a pair of subroutines in a separate perl module. And yet I can use an HTML editor to quickly edit my page layouts. (e.g. Homesite handles extremely well). Each such module encapsulates everything about one page and the glue necessary to attach it to the rest of the system. One subroutine knows how to process that particular page, the other knows how to display it. This file contains the layout and the glue for just that page. Everything that is not particular to processing or displaying that particular page, as laid out, is separate. Is this what you are talking about? Or not enough? I was attracted to EmbPerl and ASP and Mason etc, but the complexity and processing models and constraints they imposed didn't seem attractive, let alone the additional complexities of learning and debugging. With just CGI.pm I can debug my new scripts very easily (just specify parameter values). Either I've fallen upon a great simple way for doing what you are talking about with all the benefits of what you disavow, or I'm deluded? Comments please?