Re: [cgiapp] directory structure and static pages

[Darin McBride <suppressed>]

[Andy - sorry for the duplicate - I sent the original directly to you
by mistake.  Resending for the list.]

On September 4, 2003 08:01 am, Andy Taylor wrote:
> I'm getting ready to start a fairly large project using CGI::App and I was
> just wondering how some of the more experienced/knowledgeable people on
> this list handle some issues.
>
> 1. if you are doing a project with a superclass and several modules, where
> do you put your templates and how do you organize them? For instance, if
> /home/ataylor is my home dir, do most people do something like
> /home/ataylor/project/modules and /home/ataylor/project/templates and put
> all the templates in one big directory?

/var/www/tmpl/%L is the templates (%L is the language identifier, e.g.
en for English, fr for French, etc.)
   In here are subdirectories for different .cgi scripts, or, I
suppose more accurately, for each C::A-derived module.

/var/www/perl is the modules

/var/www/html is the static html (I've set it up to run .cgi scripts,
too)

/var/www/html_template_cache is, well, the H::T cache.

> 2. for a large project, not all of the pages have to be dynamic obviously.
> How do people deal with static pages that you want to still share the look
> of your dynamic pages that you are using HTML::Template for? I was
> considering creating a commandline tool to generate the static pages from
> the HTML::Templates or creating a module just for serving static pages (not
> that they would be static anymore) and wrapping the header and footer,
> setting the title, etc. but each of these have downsides. How do the
> experts do it?

Not that I'm an expert, but I was considering writing a script that
would take the name of a module, load it, look at its runmodes, and
invoke each runmode one after another.  By setting a global variable,
say $::STATIC_MODE, any mode that should not run statically could just
return undef immediately rather than reading databases, etc.  The
wrapper would detect the undef return, and simply not write that one
out.  It would generate <runmode>.html files in the specified output
directory.

Of course, it would require the additional "return undef if
$::STATIC_MODE;" line in any runmode that was not allowed to be static,
but that would be a relatively minor cost.

Another alternative to $::STATIC_MODE would be something like:

my @static_rms;
if ($app->can('static_run_modes'))
{
  @static_rms = $app->static_run_modes;
}
else
{
  @static_rms = # ... some hack to the internals of C::A
}

The default is all runmodes, but you just have to maintain a function
that returns an array of all static runmodes.  The disadvantage is that
this may not do the expected thing in cases where you have AUTOLOAD.

This can be solved by having a subclass such as
CGI::Application::StaticGenerator which you must derive from, and it
has the static_run_modes() in it which returns all runmodes by default
unless you override it.  Then the script would be able to invoke it
without all the C<can> trickery:

die "$module not derived from C::A::SG" unless $app->isa(...);
my @static_rms = $app->static_run_modes;

These are just my ideas.  :-)

> much thanks for any advice and I think the discussions on this list are
> invaluable.


---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed