Ok. When developing our web applications with Pas, we nearly univerally
break the pages up into parts and use a standard layout to bring
those chunks in. This saves us maintenence, disk-space for the PSP pages
and just generaly make the presentation layer easier to work with.
For example:
<%@ include file = "_header.psp" %>
<%-- page content goes here --%>
<%@ include file = "_footer.psp" %>
This is pretty much the standard approach. It makes it easy for a
standard look and feel across all the pages, logos, standard navigation
elements, etc.
I was just looking at the generated output of one of the pages. Now
if you think about it, the implicaitons of this type of inclusion are
apparent. I had never though about it.
The implicaiton that I just realized is that, provided the included
file is static (no active psp code int it) you end up with the same
header data and same footer data in each and every generated file.
This is a waste of memory and space. It could be refactored so that
pages with static portions that are the same all share the actual same
static region(s). This should, for some sites, save memory. Possibly
significant amounts of memory.
Thinking about this took me back to the concetps of content methods and
taglibs. And to the optmization strategies we were throwing around
before about marking up pages or sections as 'resolve at compile time',
'request-static', and 'static-only'.
Another, probably not quite correct, way to think about this is
like inlined functions. It's the difference between referencing
something shared vs having it expanded everwhere in the code.
There are a few ways I can initially think of we can approach
1. shared/inherited methods
2. shared variables/constants
We could move all these shared content areas into their own package and
make them available as a method name or as a variable name. Then
a static include could look like:
<%@ static include file = "_header.psp" %>
<%-- content goes here %-->
<%@ static include file = "_footer.psp" %>
And the generated code could look something like:
sub execute
{
my($self) = @_;
...
$self->response->print(
Some::Pkg::Name::Based::On::The::Include::Name->_staticContent
);
...
}
Or, maybe, we could just have that method do the printing internally,
you pass in the response object and it appends it's content to it..
sub execute
{
my($self) = @_;
...
Some::Pkg::Name::Based::On::The::Include::Name->_staticContent(
$self->response
);
...
}
Using variables instead of methods it might look like:
sub execute
{
my($self) = @_;
...
$self->response->print(
$Some::Pkg::Name::Based::On::The::Include::Name::_staticContent
);
...
}
Variables might be more efficient than methods/constants. Though I'm
not certin which one is a better solution - which one will lead to better
design and maintenence later on.
As a related aside, the static include could easily be implemented in the
current compiler. The behavior could be for the compiler to attempt to
comple/resolve/evaluate the included file as PSP code, so you could use
it as a simple first generation macro system for expanding out the
static code. A few points to keep in mind are that you could put Perl
code in these static includes, but there would be no request object,
and no session available to you (or there would be but they'd be empty
and/or invalid). They would be invalid because the code is being
executed at compile time, not in response to a request.
That's the latest round of ideas for now. What do you think? Is doing
something like this worth-while? My hunch is that it would be.
Kyle
--
------------------------------------------------------------------------------
Wisdom and Compassion are inseparable.
-- Christmas Humphreys
mo...@vo... http://www.voicenet.com/~mortis
------------------------------------------------------------------------------
|
