Gossamer Forum
Home : Products : Gossamer Links : Discussions :

template directory

Quote Reply
template directory
Alex,

A plug-in may want to install their templates in their own subdirectory.

By using the new ::display routine, you can print any template (figured that one out) but you can't pass in a new template directory.

I overrode $IN->param('t') to do it, but that is not the proper way, if you want to dynamically preserve the regular template set.

Maybe there should be a way of passing in a template directory to the load_template routine, which would override (but not obliterate) the existing defaults.

I don't know enough of the logic to say it should be a passed parameter (probably logically the best) or whether setting a param->('u') (for example) would be a better way. I think since it would be a per-call basis, the directory override would be the best way.

I tried passing in "/path/filename.html" but it couldn't parse the name to generate the print sub.

With the ../templates/ directory, it makes sense for a plug-in to set it's templates into a ../templates/plug-in_name directory. Prevents template collisions, and keeps it easy to uninstall.

Some way of passing in the default override would be nice :)

PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://postcards.com/FAQ


Quote Reply
Re: template directory In reply to
Another problem, and I can't figure this one out.

I can't get variables like <%db_cgi_url%> to parse in templates I've added.

I have tried via passing through the param('t') method, and I've moved them into the main /default directory, and while the existing templates parse ok, the ones I've added don't.

<%db_cgi_url%> is shown as "unknown tag".

PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://postcards.com/FAQ


Quote Reply
Re: template directory In reply to
Hi pugdog,

Hmm, I'm not sure about this one. The templates are meant to be logically separated to be copies of the entire site in either different looks or different languages. If a template is in one of the directories, it really should be in all of them.

Although, writing this down, a 'common' directory could definately be a good idea for templates that don't change across sets. Hmm...

Let me think about this one a bit more..

Cheers,

Alex

--
Gossamer Threads Inc.
Quote Reply
Re: template directory In reply to
Hi pugdog,

Those variables are only available if you call load_template. If you are parsing the template by some other means, you can use:

<%Links::Config::load_vars%>

and it will make all your config options available on that page prefixed with cfg_ (so the url is cfg_db_cgi_url).

Cheers,

Alex

--
Gossamer Threads Inc.
Quote Reply
Re: template directory In reply to
This is something I can't figure out. I'm passing in a routine:


print Links::SiteHTML::display ($IN->param('NextPage'), $IN);


and it's not parsing out the tags. It displays the page, but "unknown tag" errors.

I've made one change to Links.pm, but as I said, even if I get rid of that change (one added line that directly assigned $template_set a value based on a GT::CGI->param variable) I get the same problem.

I tried putting the template in default and in it's own directory via t=

There has to be something subtle I'm missing. None of the templates I've added are parsing out, yet the old set of "standard" templates is. These are the same templates I'm using on the 1.13 site.



PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://postcards.com/FAQ


Quote Reply
Re: template directory In reply to
In Reply To:

Although, writing this down, a 'common' directory could definately be a good idea for templates that don't change across sets. Hmm...
Ok, I think we are still missing each other :)

I realize that there are different sets for different things, and each should be a "complete" site. Maybe abstracting out templates that don't change in some ways would be good, but only for "system" things, since as you said, each should be a full set.

_BUT_ what I'm saying is that if you run a plug-in, such as the postcards.cgi, it has it's own templates that may or may not be the same for each template set. I'm assuming they will be. Maybe there will then be the auction plug-in and then a banner plug in, etc. Each of these will have their own templates, many of which -- most of which -- won't depend on the current theme. But, you'd like to preserve the t= so that the user is passed back to their current theme.

It would make more sense to put the the postcards templates in a subdirectory called .../templates/postcards for organizational reasons.

Then, extrapolating this out... if you do need a set of templates for each theme, it would make sense to allow .../templates/theme/sub-theme type files, so that there would be a .../templates/default/postcards directory, as well as a ../templates/av/postcards directory, etc.

This prevents a plug-in author from crashing into another plug-in authors templates.

Maybe even adopting the format of:

../templates/default
../templates/postcards (default name of plug-in)
../templates/av
../templates/postcards_av ('plug-in' . 'template_set')


Whether to put the 'av' in front or in back would depend on whether you viewed keeping all the plug-in templates together or all the template-set directories together: eg: av* or plug-in*




PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://postcards.com/FAQ


Quote Reply
Re: template directory In reply to
Very strange. Can you try adding:

use Data::Dumper;
print "vars: <pre>", Dumper($vars), "</pre>";

just before return $output in Links.pm. See what is getting passed in as template variables.

Cheers,

Alex

--
Gossamer Threads Inc.
Quote Reply
Re: template directory In reply to
Yes,

the db_cgi_url => is the path, in the vars dump. but in the template that follows, it's again "unknown tag"

I tried removing the "" around the tag, and all that did was change it from "unknown tag error" to "unknown" <G>

I can't figure this out. I did a clean install. Copied my templates over. The search templates work -- db_cgi_url is properly translated. The dynamic templates work. But, when I try to print out my added template, it doesn't.

Can something be happening in the way the autoload works? But why would it work for some, and not others?



PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://postcards.com/FAQ


Quote Reply
Re: template directory In reply to
Ah, figured this one out, load_template didn't like getting a GT::CGI object. I've fixed it so it can accept one, but for now change your call from:

Links::SiteHTML::display(page, $IN);

to:

Links::SiteHTML::display(page, $IN->get_hash);

and it will work.

Cheers,

Alex

--
Gossamer Threads Inc.
Quote Reply
Re: template directory In reply to
Oh, also, you don't need to pass $IN through, as CGI input automatically is available as a template tag.

Cheers,

Alex

--
Gossamer Threads Inc.
Quote Reply
Re: template directory In reply to
Ok... That makes sense.

As for the $IN being global... giving up passing parameters (for clarity if nothing else) is hard! :)

So $IN, $CFG and anything you pass is available in the templates? $CFG is comprised of the globals.txt and the config.pm data?

I thought about doing a $IN->get_hash near the beginning of the program, but figured the extra overhead wasn't necessary if I was just passing parameters through, or only assigning one new parameter to the $IN hash.

Better to catch that now, than later, though :)


PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://postcards.com/FAQ


Quote Reply
Re: template directory In reply to
In templates you get:

$IN
globals.txt
the logged in USER info.
the following fields from the config:
db_cgi_url build_root_url build_images_url build_new_url build_ratings_url build_cool_url

Anything else you need to ask for. Specifically, the entire config is not available by default as it is quite large and can cause name space conflicts. You can get it by adding <%Links::Config::load_vars%> at the beginning of your template.

Cheers,

Alex

--
Gossamer Threads Inc.
Quote Reply
Re: template directory In reply to
Don't know if this is significant, but I tried to make a few changes, aand looked at the variables.

In the above, I tried to do:

my $INPUT = shift;

at the top of _compile. Then, access items in that directly, but it shows up as empty.

Shouldn't I have been able to access that, and then change the 'shift' in the &load_template call with $INPUT ?

If I look at the GT::CGI object itself, it holds what I though _should_ have been passed by the $IN->get_hash , and accessible via the $INPUT=shift.

Oddly, the template is now displaying, but that is probably because the parse routines are accessing the $IN variable (GT::CGI object) directly

PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://postcards.com/FAQ


Quote Reply
Re: template directory In reply to
Hi,

Hmm, I'm not sure what you are changing, but it shouldn't be inside of _compile, that's the wrong place. =)

You should only need to change your code from

print Links::SiteHTML::display ('template_name', $IN);

to:

print Links::SiteHTML::display ('template_name', $IN->get_hash);

and it will work.

Cheers,

Alex

--
Gossamer Threads Inc.
Quote Reply
Re: template directory In reply to
Well, the reason is that in _compile I need to add a test for changing $template_dir.

Right now, I've been passing it in $IN->param('Template_Set', 'template')

The reason is that $IN is available as GT::CFG->parm while I can't access the passed variable array itself.

I tried to shift that off the stack, then explicitly pass it, rather than 'shift' it in the call to $load_template.

I don't like adding to $IN if I don't have to, since that really _should_ be what is sent into the program. If I'm passing $IN and $rec I'd rather add the value to $rec than $IN for consistency reasons.

FWIW... you have the checks for existence of the template set in _compile, which means that in order to pass the template set, you need to have the values available in $IN or accessible in the second 'shift' operation.

FWIW2... this means a similar change in &load_template in order to set the $template_set in that routine as well.



PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://postcards.com/FAQ